Use Read-Only MCP Tools Safely

Use Read-Only MCP Tools Safely

Read-only MCP tools let Feluda retrieve or inspect information without intentionally changing the connected system.

They can help you:

• search an approved source;
• look up a record;
• read a supported file;
• list available items;
• inspect a service;
• compare returned information; or
• retrieve structured data.

Read-only tools are a good starting point when learning how MCP tools work.

They reduce the risk of changing a file, record, message, task, or external service during testing.

What read-only means

A read-only tool is designed to view or retrieve information.

It may:

• search;
• list;
• read;
• retrieve;
• inspect;
• compare; or
• return information.

It should not intentionally:

• create;
• update;
• send;
• move;
• remove;
• overwrite; or
• change information.

Always review the tool description.

A tool name alone may not clearly explain whether it can write.

Why read-only tools still need review

Read-only does not mean risk-free.

A read tool may still receive:

• search terms;
• record identifiers;
• document text;
• file paths;
• names;
• dates;
• internal URLs; or
• other information required for the task.

It may also return sensitive information.

Review both what is sent and what comes back.

Before you begin

Confirm that:

• the MCP server is connected;
• the server is available;
• authentication is complete;
• the tool is described as read-only;
• the selected model supports tool use;
• the account has only the access required;
• the source is approved; and
• you understand whether the server is local or remote.

Use non-sensitive sample information for the first test.

Choose the right tool

Review the tool description before enabling it.

Check:

• the tool name;
• the MCP server that provides it;
• the source it reads;
• the information it expects;
• the result it returns;
• whether it performs only read actions; and
• whether another similar tool exists.

Prefer a tool whose purpose clearly matches the task.

Confirm the server source

A read-only tool may come from:

• Feluda's built-in MCP server;
• an installed Gene;
• a local external MCP server;
• an internal organisational server; or
• a remote service.

Confirm which server provides the tool.

A local model can still send information to a remote MCP server when it calls that tool.

Use read-only accounts when possible

When the connected service supports it, use an account that cannot perform write actions.

A read-only account may limit access to:

• viewing records;
• searching documents;
• listing items;
• reading files;
• inspecting status; or
• retrieving approved information.

Avoid using an administrator account for routine lookups.

Limit the source scope

Give the tool access only to the sources required for the task.

Depending on the connection, this may mean limiting:

• projects;
• customer records;
• folders;
• document collections;
• accounts;
• workspaces;
• URLs;
• IP addresses;
• paths; or
• ports.

A read-only tool should not automatically read every available source.

Use the least information required

Before sending a request, ask:

• Does the tool need the full document?
• Can one section be used instead?
• Can names be removed?
• Can a reference number replace personal information?
• Can the query be shorter?
• Can sample data be used?
• Can unrelated fields be excluded?

Send only what the tool needs.

Use read-only tools in Workbench

To use a read-only MCP tool in Workbench:

1. open Workbench;
2. choose a provider and tool-capable model;
3. open Tools;
4. find the intended MCP tool;
5. enable only that tool;
6. write a clear read-only instruction;
7. send the message; and
8. review the Activity drawer.

Start a new conversation when testing a tool for the first time.

Write a clear read-only instruction

State the source, task, expected output, and limit.

For example:

Use the enabled customer-record search tool.

Find the record with reference number 48321.

Return:
* customer name;
* current status;
* assigned owner; and
* last update date.

Do not create, update, send, delete, or change anything.

The final sentence makes the read-only boundary explicit.

Name the tool when several are available

If several similar tools are enabled, use the exact tool name.

For example:

Use only the enabled Internal Knowledge Search tool.

Do not call any create, update, delete, messaging, or file-writing tool.

Disable unrelated tools when possible.

Ask for source details

A useful read-only result should explain where the information came from.

You may ask for:

• source title;
• record identifier;
• filename;
• returned date;
• service name;
• source link;
• reporting period; or
• another reference supplied by the tool.

This makes later verification easier.

Ask for missing information to remain visible

Tell the model what to do when the tool does not return a required field.

For example:

If a required value is missing, write "Not provided."
Do not guess.

This reduces unsupported claims.

Review Workbench Activity

After the response, open Activity.

Confirm:

• the correct tool was called;
• the tool input was necessary and accurate;
• no write tool was called;
• the expected source was used;
• the returned output is complete;
• warnings were reviewed;
• errors were understood; and
• repeated calls did not occur unexpectedly.

Do not rely only on the final conversational answer.

Compare raw output with the answer

The model may summarise the tool result incorrectly.

Compare:

• names;
• dates;
• amounts;
• statuses;
• record identifiers;
• source references;
• missing fields; and
• warnings.

Keep the raw returned values separate from the model's explanation when accuracy matters.

Distinguish no result from an error

These outcomes are different.

No result:

The tool worked but found no matching information.

Error:

The tool could not complete the request normally.

The final response should make the difference clear.

Handle no-match results

When the tool finds nothing, check:

• spelling;
• reference number;
• search filters;
• date range;
• selected source;
• account scope; and
• whether the item exists.

Do not let the model invent a result.

A useful response is:

No matching record found.

Handle partial results

A tool may return only some of the requested fields.

Review whether:

• the source lacks the information;
• the account cannot access every field;
• a filter removed part of the result;
• the result was shortened;
• the model omitted data; or
• the wrong record was returned.

Mark missing values clearly.

Handle permission errors

A read-only tool can still be blocked by:

• account restrictions;
• URL rules;
• IP rules;
• path rules;
• port rules;
• project scope;
• record scope; or
• external-service policy.

Confirm the intended source before changing access.

Expand only the permission required for the approved task.

Handle authentication errors

Check whether:

• the credential is current;
• the account remains active;
• the credential belongs to the correct server;
• the required read permission is included;
• the authentication method changed; and
• the protected connection setting is complete.

Never paste credentials into the prompt.

Handle unavailable servers

Check:

• whether the server is running;
• whether the endpoint is correct;
• whether the network is available;
• whether a VPN is required;
• whether the port is reachable;
• whether authentication is valid; and
• whether the remote service is online.

Test the smallest safe request after restoring access.

Use read-only tools in workflows

A simple read-only workflow may look like:

Input
→ Retrieve Information with MCP Tool
→ Prepare Summary
→ Output

Keep the first version small.

Test the tool in Workbench before placing it into Studio.

Add a clear workflow instruction

The LLM block should explain:

• which tool to use;
• what input to pass;
• what fields to return;
• how to handle no matches;
• how to handle missing fields; and
• that no write action is allowed.

For example:

Use the enabled Internal Knowledge Search tool.

Search for information matching the user's query.

Return:
1. a concise answer;
2. the source details returned by the tool;
3. missing information; and
4. uncertainty.

Do not create or change anything.

Use Emit blocks during testing

Add an Emit block when you need to inspect the raw tool result.

For example:

Input
→ MCP Search
→ Emit Raw Result
→ Prepare Summary
→ Output

This helps you determine whether an error came from:

• the tool;
• the returned data;
• the next AI step; or
• the final formatting.

Add a no-result path

A workflow should handle empty results clearly.

For example:

Input
→ MCP Search
→ Match Found → Prepare Summary → Output
→ No Match → Return No Match Message

Test both paths.

Add an error path

A clear error path may return:

The connected source could not be reached.
Review the MCP connection and try again.

Do not allow the workflow to return a normal-looking answer after the read tool failed.

Review RunFlows output

After saving the workflow:

1. open RunFlows;
2. provide sample input;
3. start the workflow;
4. inspect intermediate output;
5. review the MCP call;
6. confirm the raw result;
7. read warnings and errors; and
8. compare the final answer with the source.

This confirms that the saved version behaves as intended.

Confirm that no write action occurred

Review:

• enabled tools;
• Workbench Activity;
• RunFlows output;
• workflow branches;
• external service history; and
• any unexpected item creation or update.

A read-only instruction should not rely only on the model's promise.

Use read-only permissions and accounts where possible.

Review privacy

A read-only tool can still expose sensitive information.

Before using it, confirm:

• what input leaves Feluda;
• where the MCP server runs;
• what source it can read;
• what result returns;
• whether logs contain sensitive data;
• who can access the connected account; and
• whether the final answer should be saved.

Remove unnecessary information from the request.

Protect returned information

The tool may return private or confidential data.

Before copying, saving, or sharing the result, check:

• who needs it;
• whether every field is necessary;
• whether personal information should be removed;
• whether the Journal is an appropriate destination;
• whether the result should remain local; and
• whether organisational rules apply.

Read-only access can still reveal information that must be handled carefully.

Use read-only tools with local models

A local model can call a local or remote read tool.

Review the complete path.

A local model with a remote MCP tool still sends the tool input to that remote server.

Do not describe the complete task as local unless the model, server, source, and result all remain local.

Use read-only tools with cloud models

A cloud model may receive:

• the user's request;
• source text;
• tool descriptions;
• tool results; and
• conversation context.

Confirm that the provider is appropriate for the data.

Remove unnecessary source content before sending the task.

Test repeated calls

A model may call the same read tool more than once.

Several calls may be reasonable when the task needs multiple lookups.

Investigate when:

• the same query repeats;
• the tool already returned a complete answer;
• the model ignores a no-match result;
• the tool returns an error repeatedly; or
• several similar tools are enabled.

Simplify the task and reduce the enabled tools.

Compare models

Different models may use the same read-only tool differently.

Compare:

• tool selection;
• search input;
• number of calls;
• handling of no results;
• use of source details;
• interpretation of returned data; and
• unsupported claims.

Use the model that performs the complete task reliably.

Use scheduled read-only workflows carefully

A scheduled workflow may retrieve information without a person watching the live run.

Before scheduling:

• test the connection;
• confirm the account is read-only;
• review the source scope;
• handle empty results;
• make errors visible;
• understand normal runtime;
• avoid overlapping runs;
• decide where the result is stored; and
• assign a reviewer.

Review scheduled results regularly.

Review saved results

A read-only workflow may still save its final answer to:

• the Journal;
• a file;
• a report;
• another workflow output; or
• another approved destination.

Saving the result is a separate write action.

Review that destination even when the MCP retrieval itself is read-only.

Understand mixed read and write workflows

A workflow may read from one service and later write to another.

For example:

MCP Read Tool
→ AI Summary
→ Journal Write Tool

The first action is read-only.

The final action is not.

Review every step separately.

Do not describe the complete workflow as read-only when a later step writes.

Stop when unexpected write behaviour appears

Stop the task and investigate when:

• a write tool is called;
• a record changes;
• a file is created;
• a message is sent;
• a task is added;
• an external destination changes; or
• the Activity log shows an unexpected action.

Disable unrelated tools and review the connection permissions.

A practical read-only routine

Use this process:

1. Identify the approved source.
2. Choose a clearly read-only tool.
3. Confirm the server and account.
4. Limit the accessible source.
5. Enable only the required tool.
6. Use non-sensitive sample input.
7. Give a clear no-write instruction.
8. Ask for source details.
9. Review Workbench Activity or RunFlows output.
10. Compare raw data with the final answer.
11. Confirm that no write action occurred.
12. Handle no results and errors clearly.
13. Protect returned information.
14. Test scheduled use separately.
15. Disable access when it is no longer needed.

Read-only MCP tools are a safer way to begin using connected information in Feluda, but they still require careful source, privacy, and result review.