Restore a Local MCP Environment

Restore a Local MCP Environment

Restoring a local MCP environment means rebuilding every part that a Feluda workflow depends on.

This may include:

• Feluda user data;
• Studio workflows;
• Journal entries;
• a local model runner;
• downloaded AI models;
• a local MCP server;
• source files;
• local databases;
• output folders;
• protected credentials;
• permission rules;
• RunFlows testing; and
• scheduled workflows.

Restore the environment in stages.

Begin with data and configuration, then reconnect services, test read-only tasks, verify write actions, and resume schedules last.

When restoration may be needed

You may need to restore after:

• device failure;
• operating-system reinstallation;
• accidental deletion;
• storage corruption;
• failed software updates;
• damaged Feluda user data;
• local database failure;
• migration to another approved computer;
• local MCP server replacement; or
• loss of important configuration.

Do not begin by restoring schedules or write actions.

First confirm that the environment can complete a safe read-only task.

Start with a recovery plan

Before changing the device, identify:

• what failed;
• what remains available;
• which backup will be used;
• which workflows are most important;
• which services must be reinstalled;
• which credentials must be re-entered;
• which sources must be restored;
• which schedules are paused;
• who owns the recovery; and
• how success will be verified.

A clear plan prevents several parts from being changed at once.

Define the target environment

Confirm whether you are restoring to:

• the original computer;
• a repaired computer;
• a replacement computer;
• a different operating system;
• another approved local device; or
• a test environment.

Paths, ports, permissions, and service startup may differ on a new device.

Prioritise recovery

Restore in this order when possible:

1. Feluda user data.
2. Local model runner.
3. Required AI model.
4. Local MCP server.
5. Critical source data.
6. Critical read-only workflows.
7. Required write workflows.
8. Scheduled automation.
9. Historical output.
10. Optional models and tools.

Restore the most important capabilities first.

Confirm the backup

Before restoration, confirm that:

• the backup exists;
• the backup date is known;
• the backup is readable;
• expected folders are present;
• expected files are present;
• database exports are complete;
• encryption access is available;
• the backup was created from the intended environment; and
• the backup has passed a restoration test when possible.

Do not overwrite the only working copy of the backup.

Preserve the current state

If the device still works partly, create a separate copy of the current state before restoring.

Preserve:

• current Feluda user data;
• current workflows;
• current Journal entries;
• current local files;
• current databases;
• visible errors;
• server settings;
• model-runner settings; and
• schedule information.

This gives you a rollback point if the restoration makes the situation worse.

Close active applications

Before restoring files or configuration:

• close Feluda;
• stop active RunFlows;
• pause schedules;
• stop local write tools;
• close the local model runner when required;
• stop the local MCP server when required;
• close local databases when required; and
• confirm that no backup or synchronisation process is changing the files.

Restoring active files can create inconsistent data.

Restore Feluda user data

Feluda stores user-created content separately from the application files.

This can include:

• flows;
• Journal entries;
• Genes;
• settings;
• provider configuration;
• saved workflow data; and
• other user-created content.

Restore the complete approved user-data folder when appropriate.

Restore on Windows

Feluda's public installation guidance identifies the Windows user-data location as:

%APPDATA%\Feluda\

Before restoring:

• confirm the correct Windows user;
• close Feluda;
• back up the current folder;
• restore the selected backup version;
• preserve the folder structure; and
• check file permissions.

Restore on Linux

Feluda's public installation guidance identifies the Linux user-data location as:

~/.config/Feluda/

Or:

$XDG_CONFIG_HOME/Feluda/

Confirm which location the current Linux user uses.

Restore the data with the correct ownership and permissions.

Restore on macOS

The exact local user-data location may depend on the Feluda build and macOS application settings.

Use the current Feluda installation guidance and macOS application-data tools to identify the active folder.

Confirm that the folder contains current Feluda content before replacing it.

Reinstall Feluda when needed

Install the current approved Feluda desktop application on the target device.

Then:

• open Feluda once;
• confirm the Dashboard loads;
• close Feluda before replacing user data when required;
• restore the user-data folder;
• reopen Feluda; and
• confirm Studio, Workbench, RunFlows, Journal, AI Providers, MCP Servers, and Schedule Manager open normally.

Application files can be reinstalled separately from user data.

Verify restored Feluda content

Confirm that:

• Studio workflows appear;
• workflow names are correct;
• Journal entries appear;
• installed Genes appear when expected;
• saved settings are present;
• RunFlows items are visible;
• schedules are visible but remain paused;
• provider records are present; and
• MCP connection records are present.

Do not run write workflows yet.

Reinstall the local model runner

Install the approved local model runner.

Common options include:

• Ollama;
• LM Studio; or
• another compatible local endpoint.

Use the same runner and version when reproducibility matters.

Restore or download the AI model

Confirm the exact:

• model name;
• model version;
• model size;
• quantisation when relevant;
• context settings;
• local storage location; and
• hardware requirements.

Restore the model files from backup or download the approved model again.

Test the model runner separately

Before reconnecting Feluda, test the model in its own runner.

Confirm that:

• the runner starts;
• the model loads;
• a simple response appears;
• response time is acceptable;
• memory use is stable;
• the server remains running; and
• no error appears.

This separates model-runner problems from Feluda problems.

Confirm the local endpoint

Common local endpoints include:

• Ollama: http://localhost:11434
• LM Studio: http://localhost:1234

Use the endpoint shown by the local model runner when it differs.

Record:

• protocol;
• host;
• port;
• path when required; and
• startup behaviour.

Reconnect the local provider

Open AI Providers in Feluda.

Then:

1. select or add the local provider;
2. confirm the base URL;
3. save the provider;
4. select Fetch Models;
5. confirm the restored model appears; and
6. select the model for testing.

A normal local model connection does not require a cloud model key.

Test the local model in Workbench

Open Workbench.

Select the local provider and model.

Send a simple message without tools.

Confirm that:

• the response appears;
• the intended model is used;
• no cloud provider is selected;
• response time is acceptable; and
• the model runner remains stable.

Do not test MCP tools until this succeeds.

Restore the local MCP server

Reinstall or restore the local MCP server using the approved source.

Confirm:

• server name;
• server version;
• endpoint;
• port;
• startup method;
• required local applications;
• required source paths;
• required destination paths;
• available tools; and
• update status.

Use the same version when compatibility matters.

Start the MCP server separately

Before reconnecting it to Feluda, confirm that:

• the process starts;
• the endpoint is reachable;
• the intended port is available;
• the firewall allows access;
• required local services are running;
• required source paths exist; and
• no unexpected remote dependency appears.

Reconnect the MCP server in Feluda

Open MCP Servers.

Confirm or recreate:

• server name;
• endpoint;
• authentication method;
• account;
• connection state; and
• expected tool list.

Use a clear name when the restored connection is temporary.

For example:

Local Documents MCP — Restored Test

Re-enter protected credentials

Supported secrets should be stored through Feluda's protected settings and the operating system's secure credential store.

Re-enter credentials through the approved secure process.

Never place them in:

• Workbench messages;
• Studio prompts;
• Journal entries;
• source files;
• screenshots;
• recovery notes; or
• ordinary backup archives.

Verify credential ownership

Confirm that:

• the credential belongs to the correct service;
• the account remains active;
• the scope is correct;
• the credential has not expired;
• the account owner is known; and
• old credentials are revoked when appropriate.

Do not restore access that is broader than the original approved scope.

Restore local source files

Restore approved source folders and files.

Confirm:

• folder structure;
• filenames;
• file versions;
• file types;
• file ownership;
• local availability;
• modification dates; and
• read permissions.

Preserve stable paths when workflows depend on exact locations.

Restore local output folders

Recreate or restore approved output folders.

Confirm:

• folder path;
• write access;
• available storage;
• naming rules;
• overwrite behaviour;
• duplicate prevention; and
• backup coverage.

Keep source and output folders separate when possible.

Restore local databases

Follow the database's approved restore method.

Confirm:

• database software version;
• database name;
• host;
• port;
• account;
• schema;
• record count;
• indexes;
• sample records; and
• backup date.

Start with a read-only test.

Restore local applications

Some MCP tools depend on a desktop application or local service.

Confirm that:

• the application is installed;
• the correct user profile is active;
• required local data is available;
• the integration remains supported;
• the application version is compatible;
• local permissions are correct; and
• online sign-in is not unexpectedly required.

Restore path permissions

Review the Studio Permissions panel for affected workflows.

Restore only the approved:

• input paths;
• output paths;
• project folders;
• file paths; and
• database locations.

A path may change when restoring to another operating-system user or device.

Restore URL, IP, and port permissions

Confirm:

• allowed URLs;
• allowed IP addresses;
• allowed ports;
• localhost access;
• local-network access;
• blocked destinations; and
• firewall rules.

Keep the permission set as narrow as possible.

Review operating-system path differences

A workflow moved between operating systems may require different path formats.

For example:

Windows:

C:\Users\Name\Documents\Feluda\Source

Linux or macOS:

/home/name/Documents/Feluda/Source

Update paths only after confirming the intended source and destination.

Review file ownership

Restored files may belong to the wrong operating-system user.

Confirm that the Feluda user and local MCP server can:

• read approved sources;
• write approved output;
• access local databases;
• open required folders; and
• create required files.

Avoid giving unnecessary broad permissions.

Review the discovered tool list

Compare the restored tool list with the environment record.

Look for:

• missing tools;
• renamed tools;
• new tools;
• duplicate tools;
• changed descriptions;
• changed input fields;
• changed output fields; and
• changed read or write behaviour.

Treat unexpected changes as untested.

Run a known-good read test

Use a safe sample.

For example:

Use only the enabled Local Documents Search tool.

Search for "local MCP restoration test".

Return:
1. document title;
2. local source path;
3. returned summary;
4. last updated date; and
5. any warning.

Do not create or change anything.

Start a new Workbench conversation.

Review Workbench Activity

After the test, open Activity.

Confirm:

• the expected tool was called;
• the expected server provided it;
• the input was correct;
• the restored source was used;
• the raw result was complete;
• warnings were understood;
• errors were absent or resolved;
• no repeated call occurred; and
• the final answer matched the tool result.

Test a no-result case

Use a value that should not match anything.

Confirm that:

• the tool completes;
• no result is returned;
• the model reports no match;
• no record is invented;
• no remote fallback is used; and
• no write action occurs.

Test an error case

Use an approved safe method.

Confirm that:

• the error is visible;
• the model does not invent a normal result;
• repeated calls stop;
• the workflow follows its error path; and
• the user receives a clear review message.

Review restored Studio workflows

Open every important workflow.

Confirm:

• block layout;
• provider;
• model;
• selected MCP tool;
• prompts;
• input mappings;
• output mappings;
• branch logic;
• permissions;
• no-result paths;
• error paths;
• Emit blocks;
• write approvals; and
• destinations.

A restored flow may still contain a missing model or tool reference.

Use Emit blocks during recovery

Add or keep Emit blocks after important steps.

For example:

Input
→ Restored MCP Tool
→ Emit Raw Result
→ Extract Fields
→ Emit Extracted Fields
→ Final Output

This makes restoration problems easier to locate.

Test restored workflows in Studio

Use non-sensitive sample input.

Test:

• normal result;
• no result;
• invalid input;
• permission error;
• unavailable source;
• timeout;
• multiple matches; and
• long input when relevant.

Do not begin with a production write action.

Test the saved flow in RunFlows

After saving:

1. open RunFlows;
2. select the restored flow;
3. use the known-good sample;
4. review starting input;
5. inspect the MCP tool call;
6. review raw output;
7. review intermediate values;
8. confirm the correct branch;
9. review warnings and errors; and
10. compare the final output with the baseline.

Compare with the original baseline

Compare:

• model;
• model version;
• MCP server;
• tool;
• input;
• raw result;
• required fields;
• runtime;
• warnings;
• errors;
• source path;
• destination path; and
• final answer.

Document accepted differences.

Test write tools separately

Use a safe test destination.

Begin with a draft-first instruction.

For example:

Prepare a local restoration test file.

Show:
* filename;
* destination folder;
* content;
* whether an existing file would be replaced; and
* how the file can be removed.

Do not create the file yet.

Review and approve one exact action.

Verify restored write destinations

After the tool runs, inspect the actual destination.

Confirm that:

• the correct item changed;
• only approved content was written;
• the correct folder or database was used;
• the timestamp is correct;
• no duplicate appeared; and
• the test can be reversed.

Activity confirms the call.

The destination confirms the outcome.

Test timeout handling

Confirm what happens when a restored tool responds slowly.

Before retrying a timed-out write:

• review Activity;
• review RunFlows;
• inspect the destination;
• compare timestamps; and
• confirm whether the first action completed.

This prevents duplicates.

Review Journal restoration

Confirm that:

• important Journal entries appear;
• dates are correct;
• Markdown renders correctly;
• entries remain associated with the intended environment;
• sensitive content remains protected; and
• workflows can write new test entries when approved.

Test Journal writes separately.

Review Genes and reusable flows

Confirm that installed Genes and their:

• prompts;
• tools;
• flows;
• resources; and
• settings

appear as expected.

Resync or reinstall only through the approved process.

Check whether a Gene depends on an external MCP server that was not restored.

Keep schedules paused

Do not resume recurring automation after only one successful Workbench test.

Keep schedules paused until:

• the model works;
• the MCP server works;
• sources are available;
• destinations are verified;
• Workbench tests pass;
• Studio tests pass;
• RunFlows tests pass;
• write tests pass when needed; and
• one-time scheduled tests pass.

Review each schedule

Confirm:

• schedule name;
• workflow;
• frequency;
• time;
• timezone;
• model;
• MCP server;
• source;
• destination;
• write action;
• normal runtime;
• reviewer; and
• conflict warnings.

A schedule restored to another device may run at the wrong local time.

Test a one-time schedule

Create or use a one-time scheduled test.

Confirm that:

• Feluda is open;
• the computer is awake;
• the local model runner is active;
• the MCP server is active;
• sources are mounted;
• the workflow starts;
• the result is correct;
• the destination is correct;
• no duplicate appears; and
• Schedule Manager records the run.

Resume schedules gradually

Resume schedules in a controlled order.

A useful sequence is:

1. low-risk read-only workflows;
2. important read-only workflows;
3. low-risk local writes;
4. approved production writes; and
5. high-volume or overlapping workflows.

Review the first runs closely.

Test offline operation

When the environment must work offline:

1. complete connected tests;
2. disconnect from the internet;
3. keep Feluda open;
4. keep the local model runner active;
5. keep the local MCP server active;
6. repeat the Workbench test;
7. repeat the RunFlows test;
8. inspect the local destination; and
9. confirm no hidden remote dependency appears.

Check for hidden remote dependencies

Review every workflow block and tool for:

• cloud models;
• remote MCP servers;
• web search;
• cloud storage;
• online authentication;
• remote databases;
• cloud messaging;
• remote fallback; and
• local tools that call an online service.

A restored local environment may behave differently when the network is unavailable.

Test after restarting the computer

Restart the device and confirm that:

• Feluda opens;
• the model runner starts;
• the required model remains installed;
• the MCP server starts;
• endpoints remain correct;
• local files remain mounted;
• local databases start;
• credentials remain available;
• Workbench can call the tool; and
• RunFlows completes the known-good test.

Restore service startup

Configure approved startup behaviour for:

• Ollama;
• LM Studio server;
• local MCP server;
• local database;
• file service;
• document index; and
• other required local applications.

Test startup rather than assuming it works.

Review power and sleep settings

Scheduled local workflows depend on the device remaining available.

Review:

• sleep settings;
• laptop lid behaviour;
• battery-saving mode;
• automatic restarts;
• login requirements;
• power availability; and
• service startup after reboot.

Review hardware capacity

A replacement device may have different resources.

Test:

• model loading;
• response speed;
• memory use;
• graphics-memory use;
• MCP server load;
• local database performance;
• concurrent workflows; and
• scheduled runtime.

Use a smaller model or reduce overlapping runs when needed.

Review storage capacity

Confirm enough space for:

• Feluda user data;
• model files;
• source files;
• generated output;
• local databases;
• logs;
• temporary files; and
• future backups.

Low storage can cause incomplete writes or failed updates.

Review backup coverage after restoration

The restored device may need a new backup plan.

Confirm that backups now include:

• the new Feluda user-data path;
• restored workflows;
• Journal entries;
• local sources;
• local databases;
• output folders;
• MCP records;
• model and runner records;
• schedule records; and
• permission records.

Test the new backup.

Revoke obsolete credentials

After successful restoration, revoke credentials that belong only to:

• the failed device;
• an old MCP server;
• an old local database account;
• a retired test environment; or
• a replaced service.

Confirm that no current workflow depends on them.

Remove temporary recovery access

During restoration, temporary broad permissions may have been used.

Remove unnecessary:

• administrator access;
• broad folder access;
• firewall rules;
• port ranges;
• test accounts;
• temporary credentials;
• duplicate server connections; and
• temporary output folders.

Return the environment to its approved boundaries.

Update the environment record

Record:

• recovery date;
• target device;
• operating system;
• Feluda version;
• model runner;
• model;
• model endpoint;
• MCP server;
• MCP endpoint;
• source paths;
• destination paths;
• permissions;
• schedules restored;
• tests completed;
• reviewer; and
• remaining issues.

Do not include raw credentials.

Monitor after recovery

Review the first normal work period.

Check:

• model availability;
• MCP connection health;
• tool calls;
• result completeness;
• warnings;
• errors;
• runtime;
• write destinations;
• duplicate actions;
• schedule history; and
• user reports.

A missed dependency may appear only during normal use.

Respond to a missed dependency

If a workflow fails after recovery:

1. pause its schedule;
2. identify the missing model, tool, source, path, permission, or destination;
3. correct one layer;
4. run the known-good test;
5. test the workflow in Studio;
6. test it in RunFlows;
7. verify any write destination; and
8. update the recovery record.

Do not broaden access without understanding the cause.

Final restoration checklist

Before declaring recovery complete, confirm that:

• Feluda opens normally;
• user data is restored;
• Studio workflows appear;
• Journal entries appear when required;
• the local model runner works;
• the required model is installed;
• AI Providers shows the model;
• the MCP server is connected;
• expected tools appear;
• protected credentials are re-entered securely;
• source files and databases are restored;
• output destinations are correct;
• permissions are narrow;
• a known-good Workbench test succeeds;
• Activity shows the expected call;
• no-result and error tests succeed;
• Studio workflows pass;
• RunFlows tests pass;
• write destinations are verified;
• a one-time schedule succeeds;
• recurring schedules are resumed gradually;
• restart testing succeeds;
• offline testing succeeds when required;
• obsolete credentials are revoked; and
• the new environment is backed up.

A local MCP environment is restored only when the complete path works again, from model and tools to sources, destinations, workflows, and schedules.