Maintain a Local MCP Environment

Maintain a Local MCP Environment

A local MCP environment needs regular maintenance.

It may depend on:

• Feluda;
• a local model runner;
• one or more downloaded AI models;
• a local MCP server;
• approved files and folders;
• local databases or applications;
• protected credentials;
• permission rules;
• backups; and
• scheduled workflows.

Each part can change independently.

A dependable environment is one that is reviewed, tested, and documented before small problems become workflow failures.

What maintenance should cover

Regular maintenance should confirm that:

• Feluda opens normally;
• the local model runner starts;
• the required model is installed;
• the MCP server is available;
• tools still appear;
• local sources remain accessible;
• local destinations remain writable;
• authentication remains valid;
• permissions remain narrow;
• Activity and RunFlows show expected behaviour;
• backups can be restored; and
• scheduled workflows still complete.

Review the complete path, not only the AI model.

Keep an environment record

Maintain a simple record for important local setups.

Include:

• operating system;
• Feluda version;
• local model runner;
• model name;
• model endpoint;
• MCP server name;
• MCP endpoint;
• required ports;
• approved source paths;
• approved destination paths;
• authentication method;
• dependent workflows;
• dependent schedules;
• backup location;
• last successful test date; and
• responsible owner.

Do not record raw passwords, keys, access tokens, or private headers.

Assign an owner

Every important local environment should have someone responsible for:

• model availability;
• MCP server health;
• software updates;
• permissions;
• backup checks;
• workflow testing;
• schedule review;
• incident response; and
• documentation.

An environment without an owner can become outdated without anyone noticing.

Use a recurring review schedule

Review frequency depends on how important the environment is.

A simple setup used occasionally may need a monthly review.

A setup that writes important records or runs scheduled workflows may need:

• weekly health checks;
• review after every update;
• review after every authentication change;
• review after operating-system changes; and
• immediate review after repeated errors.

Use a consistent checklist.

Check Feluda first

Confirm that:

• Feluda opens;
• the expected user profile is active;
• AI Providers loads;
• MCP Servers loads;
• Workbench opens;
• Studio opens;
• RunFlows opens;
• Journal entries remain visible; and
• Schedule Manager shows expected schedules.

A wider application problem may affect several local services at once.

Review the local model runner

Local models may run through Ollama, LM Studio, or another compatible local endpoint.

Confirm that:

• the runner is installed;
• the service starts;
• the endpoint is unchanged;
• the port is available;
• the required model is installed;
• the model loads;
• the server remains running; and
• no unexpected error appears.

Test the model in its own runner before troubleshooting Feluda.

Confirm the local endpoint

Common local endpoints include:

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

Use the endpoint shown by your local model application when it differs.

Check:

• protocol;
• host;
• port;
• path when required;
• firewall access; and
• whether another application is using the port.

Confirm the model in AI Providers

Open AI Providers in Feluda.

Confirm that:

• the local provider is saved;
• the base URL is correct;
• Fetch Models returns the expected model;
• the selected model is still available;
• no cloud provider is selected accidentally; and
• a simple Workbench prompt succeeds.

A model may disappear after it is removed or renamed in the local runner.

Review model changes

A model change can affect:

• tool selection;
• parameter formatting;
• structured output;
• exact-value preservation;
• context handling;
• speed;
• memory use;
• repeated calls; and
• error handling.

Re-test MCP tasks after:

• changing the model;
• downloading a new model version;
• changing quantisation;
• changing context settings;
• changing the local runner; or
• changing hardware settings.

Keep only needed models

Local models can use significant storage.

Review installed models and remove those that are:

• no longer used;
• duplicated;
• incompatible;
• replaced by a tested version; or
• too large for the computer.

Before removing a model, confirm that no workflow or schedule depends on it.

Review storage space

Local environments may store:

• model files;
• source files;
• generated reports;
• Journal data;
• database files;
• logs;
• temporary files; and
• backups.

Confirm that enough free storage remains.

Low storage can cause:

• failed model downloads;
• incomplete writes;
• database errors;
• corrupted output;
• slow performance; or
• failed backups.

Review memory and processing use

Test the environment under normal workload.

Watch for:

• high memory use;
• graphics-memory exhaustion;
• slow model loading;
• delayed tool calls;
• computer instability;
• thermal slowdown;
• repeated timeouts; and
• competing workflows.

A model that works only when the computer is otherwise idle may not be suitable for regular automation.

Review the local MCP server

Open MCP Servers in Feluda.

Confirm:

• the server appears;
• the endpoint is unchanged;
• the connection state is healthy;
• authentication is valid;
• expected tools are visible;
• no unexpected tools appeared;
• warnings are understood; and
• errors are resolved.

Test the MCP server separately from the model when possible.

Confirm the MCP server process

A local MCP server may fail because:

• the process stopped;
• the service did not start after restart;
• the port changed;
• another process uses the port;
• the local firewall blocks it;
• authentication changed;
• a required local application is closed; or
• the server was updated.

Record how the service is started and stopped.

Review the tool list

Compare the visible tool list with the expected baseline.

Check for:

• removed tools;
• renamed tools;
• new tools;
• duplicate tools;
• changed descriptions;
• changed read or write behaviour;
• changed input fields; and
• changed result formats.

Treat new or changed tools as untested.

Review tool descriptions

Confirm for each important tool:

• purpose;
• source;
• destination;
• required input;
• returned output;
• read or write behaviour;
• permissions;
• limits;
• warnings; and
• errors.

Update workflows and documentation when these change.

Test one read-only tool

Use a known-good sample.

For example:

Use only the enabled Local Documents Search tool.

Search for "local MCP maintenance 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.

Review the Workbench Activity drawer.

Review Workbench Activity

Confirm:

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

Keep the same test for future comparisons.

Review local source folders

Confirm that:

• folders still exist;
• paths are unchanged;
• files are fully available;
• filenames are clear;
• duplicate files are understood;
• temporary files are not used as permanent sources;
• synchronised files are actually stored locally; and
• permissions still allow the tool to read them.

Stable source paths reduce workflow failures.

Review local output folders

Confirm that:

• the output folder exists;
• the tool can write there;
• filenames remain unique;
• old output is reviewed;
• duplicate files are controlled;
• overwrite behaviour is understood;
• free storage is sufficient; and
• backups include important output.

Do not allow a workflow to write to an unknown or temporary folder.

Review local databases

For a local database, confirm:

• the database service starts;
• the host and port are correct;
• the expected database exists;
• the account remains valid;
• read and write scope are appropriate;
• backups complete;
• database size is manageable; and
• a read-only test succeeds.

Test write operations separately.

Review local applications

Some MCP tools depend on a desktop application.

Confirm that:

• the application is installed;
• it opens normally;
• the expected profile is active;
• required data is available;
• the local integration is still supported;
• the application version is compatible; and
• the tool does not depend on an online sign-in unexpectedly.

Review credentials

Local services may still require:

• passwords;
• access tokens;
• API keys;
• database credentials;
• protected headers; or
• local account access.

Confirm that credentials:

• remain valid;
• belong to the correct service;
• have the intended scope;
• are stored in protected settings;
• are not exposed in prompts or logs; and
• have a known owner.

Rotate credentials carefully

Before rotating a credential:

1. identify dependent tools;
2. identify dependent workflows;
3. pause related schedules;
4. update the protected value;
5. test one read-only action;
6. test required write actions;
7. test affected RunFlows items; and
8. resume schedules gradually.

Do not place the new credential in a test prompt.

Review account permissions

Use the least access required.

Confirm whether the account still needs:

• read access;
• write access;
• project access;
• file access;
• database access;
• administrative access; or
• access to every local source.

Remove permissions that no current workflow needs.

Review Studio permissions

Open affected workflows in Studio.

Review the Permissions panel for:

• URL rules;
• IP rules;
• path rules;
• port rules; and
• other visible restrictions.

Confirm that approved sources and destinations work while unrelated ones remain blocked.

Review path rules

Check that path rules still point to:

• the approved input folder;
• the approved output folder;
• the intended project directory; and
• existing files or folders.

Paths may change after:

• moving a project;
• renaming a folder;
• changing users;
• reinstalling software; or
• mounting a different drive.

Review IP and port rules

Confirm:

• server address;
• port;
• service using the port;
• local or network location;
• firewall rules;
• VPN requirements; and
• whether the port changed after an update.

Do not allow broad ranges when one host and port are enough.

Review write tools

For each write-capable tool, confirm:

• exact destination;
• account;
• file or record;
• required fields;
• overwrite behaviour;
• duplicate handling;
• reversibility;
• approval requirements; and
• confirmation format.

Use a safe test destination.

Test write tools separately

Use a draft-first process.

For example:

Prepare a local maintenance 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.

Approve only the exact action.

Confirm write results

After the test, inspect the real local destination.

Confirm that:

• the correct item changed;
• the expected content was written;
• no unrelated item changed;
• no duplicate appeared;
• the timestamp is correct; and
• the test can be reversed.

Activity shows the call.

The destination shows the real result.

Review Studio workflows

Open every important local MCP workflow.

Confirm:

• provider;
• local model;
• selected MCP tool;
• prompt;
• input mapping;
• output mapping;
• permissions;
• no-result path;
• error path;
• Emit blocks;
• write approval; and
• destination.

Update one workflow at a time.

Review RunFlows

Test the saved workflow through RunFlows.

Use a known-good sample.

Review:

• starting input;
• raw tool output;
• intermediate results;
• workflow branches;
• warnings;
• errors;
• final output; and
• local write destinations.

A Studio preview is not enough for regular maintenance.

Review schedules

Open Schedule Manager.

Confirm:

• expected schedules exist;
• paused schedules are intentional;
• next-run times are correct;
• the computer will be awake;
• Feluda will be open;
• the model runner will be active;
• the MCP server will be active;
• local sources will be mounted;
• destinations will be writable; and
• overlapping runs are controlled.

Test a one-time schedule

Use a one-time scheduled run after important changes.

Confirm:

• the schedule starts;
• the local model loads;
• the MCP server responds;
• the tool uses the correct source;
• the workflow completes;
• the destination is correct;
• no duplicate appears; and
• Schedule Manager records the run.

Resume recurring schedules only after this test succeeds.

Review power and sleep settings

Scheduled local workflows depend on the computer remaining available.

Check:

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

A sleeping or restarted computer may miss a run.

Review service startup

Confirm which services start automatically.

These may include:

• Ollama;
• LM Studio server;
• local MCP server;
• local database;
• file service;
• document index; or
• another required application.

Test after a full computer restart.

Test after restart

Restart the computer and confirm that:

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

Test offline behaviour

When offline use is required:

1. complete a successful connected test;
2. disconnect from the internet;
3. keep local services running;
4. repeat the Workbench test;
5. repeat the RunFlows test;
6. inspect the local destination; and
7. confirm that no hidden remote dependency appears.

Re-test after significant changes.

Review hidden remote dependencies

A local workflow may still depend on:

• a cloud model;
• remote MCP server;
• web search;
• cloud storage;
• online authentication;
• remote database;
• cloud messaging;
• remote fallback; or
• a local tool that calls an online API.

Review every enabled tool and workflow block.

Review fallback behaviour

Do not allow an offline or private workflow to switch silently to a remote service.

Confirm:

• whether fallback is enabled;
• which service it uses;
• what information would be sent;
• whether approval is required;
• how the user is informed; and
• what happens when remote access is unavailable.

Return a clear error when remote fallback is not approved.

Review backups

Back up information that must be preserved.

This may include:

• local source files;
• local databases;
• important output;
• workflow documentation;
• configuration records;
• local server settings; and
• Journal data.

Follow the approved backup process for your environment.

Test backup restoration

A backup is useful only when it can be restored.

Use a safe test to confirm:

• the backup exists;
• the backup is readable;
• the correct version is present;
• file permissions are preserved;
• database recovery works;
• restored paths are understood; and
• the restored data can be used by the intended tool.

Do not test restoration by overwriting the only working copy.

Review backup privacy

Confirm whether the backup is:

• local;
• encrypted;
• removable;
• network-based;
• cloud-based; or
• managed by another service.

A cloud backup changes the wider storage path even when the workflow itself is local.

Review logs and temporary files

Local applications may create:

• tool logs;
• model logs;
• temporary files;
• cached results;
• prompt history;
• database journals; or
• error files.

Review where these are stored and who can access them.

Remove unnecessary test data according to your normal retention practices.

Protect the device

Local processing places more responsibility on the computer.

Protect:

• the operating-system account;
• screen lock;
• local user permissions;
• disk encryption;
• source folders;
• output folders;
• credentials;
• backups;
• removable media; and
• physical access.

A local environment is not secure when the device itself is unprotected.

Review software updates

Relevant updates may include:

• Feluda;
• operating system;
• model runner;
• AI model;
• MCP server;
• local database;
• desktop application;
• drivers; or
• security software.

Do not update every component at the same time when the environment is important.

Apply updates in stages

Use this process:

1. record the current working state;
2. save known-good tests;
3. pause schedules;
4. confirm backups;
5. update one component;
6. restart when required;
7. test the model;
8. test the MCP server;
9. test one read tool;
10. test write tools;
11. test RunFlows;
12. test a one-time schedule; and
13. resume automation gradually.

This makes failures easier to trace.

Re-test after Feluda updates

Confirm that:

• AI Providers still shows the local model;
• MCP Servers still shows the local connection;
• tools still appear;
• Workbench Activity remains visible;
• Studio workflows load;
• RunFlows works;
• Journal data remains available;
• permissions remain correct; and
• schedules remain configured.

Re-test after model-runner updates

Check:

• endpoint;
• port;
• model list;
• model loading;
• hardware settings;
• context settings;
• tool-use behaviour; and
• startup behaviour.

A runner update can change performance without changing the model name.

Re-test after model updates

Compare:

• tool selection;
• parameter accuracy;
• exact-value handling;
• structured output;
• no-match handling;
• error handling;
• repeated calls;
• runtime; and
• memory use.

Use the same controlled sample.

Re-test after MCP server updates

Review:

• endpoint;
• authentication;
• tool list;
• tool names;
• input fields;
• output fields;
• permissions;
• warnings;
• errors; and
• write behaviour.

Update dependent workflows before resuming schedules.

Re-test after operating-system updates

Confirm:

• service startup;
• firewall rules;
• port availability;
• file permissions;
• mounted drives;
• protected credential access;
• graphics drivers;
• model performance; and
• scheduled availability.

Operating-system changes can affect several local components at once.

Compare with the last successful test

Record:

• test date;
• model;
• server;
• tool;
• input;
• raw result;
• final answer;
• runtime;
• warnings;
• errors; and
• destination.

Differences can reveal what changed.

Respond to repeated errors

Pause dependent schedules when:

• the model no longer loads;
• the MCP server becomes unavailable;
• tools disappear;
• permissions fail repeatedly;
• write destinations change;
• duplicates appear;
• output becomes inconsistent;
• offline tests fail; or
• backups cannot be verified.

Resume only after manual and RunFlows tests succeed.

Remove unused components

Review and remove:

• unused models;
• obsolete MCP connections;
• retired tools;
• duplicate test servers;
• temporary test files;
• old credentials;
• unused write permissions;
• abandoned schedules; and
• outdated documentation.

Check dependencies before removal.

Review environment trust

Stop regular use when:

• the server owner is unclear;
• unexpected tools appear;
• a local tool begins making remote calls;
• sensitive data appears unexpectedly;
• permissions become broader without explanation;
• credentials appear in logs;
• write behaviour changes; or
• the environment cannot be verified.

Investigate before continuing.

A practical maintenance routine

Use this recurring process:

1. Open Feluda and confirm the main areas load.
2. Confirm the local model runner and model.
3. Confirm the local MCP server and endpoint.
4. Compare the tool list with the expected baseline.
5. Review source and destination paths.
6. Review authentication and permissions.
7. Run the known-good read-only Workbench test.
8. Review Activity.
9. Test required write actions safely.
10. Test affected workflows in RunFlows.
11. Review schedules and service startup.
12. Test after restart.
13. Test offline behaviour when required.
14. Verify backups and restoration.
15. Review storage, memory, and logs.
16. Apply updates one component at a time.
17. Remove unused access and components.
18. Record the review date and outcome.

A maintained local MCP environment stays understandable, testable, and dependable as models, tools, files, and services change.