Use MCP Tools in Workbench

Use MCP Tools in Workbench

MCP tools let an AI model use capabilities provided by Feluda's built-in MCP server or a connected external MCP server.

In Workbench, these tools can help the model:

• retrieve information;
• search an approved source;
• read supported files;
• look up records;
• create notes;
• use a connected service; or
• perform another supported action.

You choose which tools are available for the conversation.

Enable only the tools needed for the current task.

Before you begin

Make sure that:

• Feluda is open;
• an AI provider is connected;
• a tool-capable model is available;
• the MCP server connection is active;
• the required tool appears in Feluda;
• authentication is complete when required; and
• you understand whether the tool reads or writes information.

Test a new tool with non-sensitive sample information.

Step 1: Open Workbench

Select Workbench from the Feluda sidebar.

Workbench is the interactive area where you can:

• chat with an AI model;
• attach supported content;
• enable tools;
• review model responses; and
• inspect tool activity.

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

This keeps earlier messages from affecting the result.

Step 2: Choose a provider and model

Select the AI provider and model you want to use.

The model must support the type of tool use required by the task.

Models can differ in how well they:

• recognise when a tool is needed;
• choose the correct tool;
• provide required fields;
• interpret returned information;
• follow read-only limits; and
• report errors.

Use a model you have already tested in Workbench when possible.

Step 3: Open the Tools selector

Select Tools in the Workbench header.

The selector shows tools currently available to Feluda.

These may include tools provided by:

• installed Genes;
• Feluda's built-in MCP server; and
• connected external MCP servers.

Review the tool names and descriptions before enabling anything.

Step 4: Find the MCP tool

Locate the tool you need.

A clear server name makes its tools easier to recognise.

For example, a server named Internal Knowledge Server may provide tools for searching internal documents.

Review:

• the tool name;
• its purpose;
• the server that provides it;
• the information it expects;
• the result it returns;
• whether it performs a read or write action; and
• any limits described by the provider.

Do not select a tool only because its name sounds relevant.

Step 5: Enable only the required tool

Turn on the tool needed for the task.

Leave unrelated tools disabled.

Using one tool at a time during early testing makes it easier to understand:

• why the model chose it;
• what information was sent;
• what result came back;
• which permission was used; and
• where an error occurred.

Enable more than one tool only when the task genuinely needs them.

Step 6: Give a clear instruction

Tell the model:

• what you want to achieve;
• which tool it should use;
• what information it should provide;
• what output format you expect;
• which limits it must follow; and
• whether it may perform an action or should only prepare a draft.

For a read-only task, you could write:

Use the enabled customer-record search tool to find the record with
reference number 48321.

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

Do not create or change anything.

The final sentence clearly limits the task to reading information.

Use the exact tool name when helpful

When several similar tools are available, name the one you want the model to use.

For example:

Use only the enabled Internal Knowledge Search tool.

Do not call any create, update, or delete tool.

This reduces the chance that the model selects an unrelated capability.

Ask for a defined output

A clear output structure makes the result easier to review.

For example:

Return:

1. a short answer;
2. the source details returned by the tool;
3. any missing information; and
4. any uncertainty.

Structured output also makes it easier to compare the model's answer with the raw tool result.

Step 7: Send the message

Send the instruction.

The model may decide that the enabled tool is needed and call it during the conversation.

Depending on the task, you may see:

• a normal model response;
• a tool call;
• a returned tool result;
• a follow-up model response;
• a warning; or
• an error.

Allow the action to complete before sending another instruction.

Step 8: Review the Activity log

Open the Activity log after the response.

Review:

• which tool was called;
• the input passed to it;
• the result it returned;
• whether the call completed;
• whether a warning appeared;
• whether an error occurred; and
• how long the action took when that information is shown.

The Activity log is the clearest way to confirm what happened.

Do not rely only on the model saying that it used a tool.

Compare the tool result with the final answer

The tool may return accurate information while the model summarises it incorrectly.

Check whether the final answer:

• preserves names;
• preserves dates;
• preserves amounts;
• uses the correct record;
• separates facts from suggestions;
• marks missing information clearly; and
• avoids unsupported claims.

When accuracy matters, ask the model to show the returned fields separately from its explanation.

Read tools

A read tool retrieves or views information without intentionally changing a destination.

It may:

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

Read tools are a good starting point when learning MCP tools.

They let you test:

• the server connection;
• authentication;
• tool discovery;
• model compatibility;
• input format; and
• returned data.

Write tools

A write tool creates, changes, sends, or removes information.

It may:

• create a task;
• update a record;
• save a file;
• send a message;
• create a note;
• change a status; or
• remove an item.

Write actions require additional review.

A wrong instruction can affect a real destination.

Use a draft-first process

For an important write task, ask the model to prepare the action without performing it.

For example:

Prepare the customer-record update.

Show:
* the record that would be changed;
* the fields that would be updated;
* the new values; and
* the reason for the change.

Do not submit the update yet.

Review the draft.

Request the final action only after confirming the destination and content.

Confirm important details before a write

Before authorising the final action, check:

• the account;
• the record or file;
• the destination;
• the recipient;
• the content;
• the date or time;
• whether the action can be reversed; and
• whether another person must approve it.

Keep high-impact actions behind human review.

Confirm the action at its destination

After the write tool completes, inspect the connected service.

For example:

• open the created task;
• review the updated record;
• check the saved file;
• confirm the sent message;
• open the new note; or
• verify the correct status.

A successful tool call does not guarantee that the correct content or destination was used.

Avoid duplicate write actions

A delayed response or timeout may make a successful action look like a failure.

Before retrying:

1. review the Activity log;
2. inspect the destination;
3. confirm whether the item already exists;
4. compare timestamps; and
5. retry only when the first action did not complete.

This helps prevent duplicate records, files, tasks, messages, or notes.

Use tools from Feluda's built-in MCP server

Feluda's built-in MCP server starts with the application.

Tools from installed Genes can become available through this server.

To use one:

1. confirm the Gene is installed and synced;
2. open Workbench;
3. select a tool-capable model;
4. open Tools;
5. enable the Gene-provided tool;
6. send a clear instruction; and
7. review Activity.

The exact tool list depends on the Genes available in your Feluda setup.

Use tools from an external MCP server

An external MCP server must be connected and available.

Before using one of its tools, confirm:

• the server connection is active;
• authentication is still valid;
• the tool appears in Workbench;
• the server is trusted;
• the action is appropriate;
• the data path is understood; and
• the selected model can use the tool.

External service availability can change after the connection was created.

Use local MCP tools

A local MCP server may run on your own computer or local network.

Keep the server application or service running while using its tools.

Confirm:

• the endpoint is available;
• the required local service is open;
• the port has not changed;
• the tool appears in Workbench; and
• the local source or destination exists.

A local connection may work without the internet when every required part is also local.

Use remote MCP tools

A remote MCP server requires network access.

Before sending information, review:

• who operates the server;
• where it processes data;
• what the tool receives;
• whether it stores information;
• whether another service is involved;
• whether the connection is approved; and
• whether unnecessary details can be removed.

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

Protect sensitive information

Before using private or confidential content, confirm:

• whether the tool needs the full source;
• whether personal details can be removed;
• whether the MCP server is local or remote;
• which external service receives the information;
• whether the tool writes to a destination;
• whether logs may contain input or output; and
• who can access the connected account.

Give the tool only the information required for the task.

Never place credentials in the prompt

Do not paste:

• passwords;
• API keys;
• access tokens;
• private connection values; or
• other credentials

into a Workbench message.

Store them in the intended protected settings.

The model should not need to read or repeat private authentication values.

Use one conversation for one clear task

A long conversation may contain old instructions and unrelated context.

Start a new conversation when:

• testing a new tool;
• changing servers;
• switching from a read task to a write task;
• handling sensitive information;
• comparing models; or
• troubleshooting an unexpected call.

This reduces confusion about which instruction the model should follow.

Disable tools after testing

When the task is complete, turn off tools that are no longer needed.

This helps:

• reduce accidental calls;
• keep later conversations focused;
• make Activity easier to review; and
• limit access to connected services.

Re-enable the tool when a new task requires it.

Test missing information

Ask the tool to retrieve an item that does not exist or use a safe example with missing information.

Confirm that the model:

• reports that nothing was found;
• does not invent a record;
• does not replace the missing value with a guess;
• explains what information is needed; and
• does not call an unrelated write tool.

A successful empty result is different from a tool error.

Test unexpected input

Try a safe input that does not match the tool's expected format.

For example:

• an incomplete reference number;
• a missing filename;
• an invalid date;
• a vague search term; or
• an unsupported action.

The tool or model should return a clear explanation rather than performing an unrelated action.

If the tool does not appear

Check that:

• the MCP server is connected;
• the server is available;
• authentication succeeded;
• the server exposes tools;
• the tool list has refreshed;
• Workbench was reopened when needed;
• the Gene is installed when relevant; and
• the selected model supports tool use.

Return to MCP Servers and review the connection state.

If the model does not call the tool

Check whether:

• the tool is enabled;
• the instruction clearly requires it;
• the selected model supports tool use;
• the tool description matches the task;
• another tool is confusing the model;
• the request can be answered from conversation context; and
• the model needs the exact tool name.

Try:

Use the enabled Internal Knowledge Search tool.
Do not answer from memory.

Then review Activity.

If the wrong tool is called

Disable unrelated tools.

Use a more direct instruction.

For example:

Use only the enabled customer-record search tool.
Do not call any create, update, delete, file, or messaging tool.

Review tools with similar names or overlapping descriptions.

If the tool returns an error

Read the complete error.

Common causes include:

• unavailable server;
• incorrect endpoint;
• failed authentication;
• expired credential;
• missing required input;
• unavailable source;
• permission restriction;
• unsupported action;
• network problem; or
• remote service failure.

Test the smallest supported request after correcting the issue.

If the server is unavailable

Check:

• whether the server is running;
• whether the endpoint is correct;
• whether the network is available;
• whether authentication is valid;
• whether a firewall blocks access;
• whether the remote service is online; and
• whether Feluda needs to refresh the connection.

Do not change the model until the server connection itself has been tested.

If authentication fails

Confirm that:

• the credential belongs to the correct server;
• it was copied completely;
• it has not expired;
• the account remains active;
• it has the required permission; and
• it is stored in the protected connection settings.

Never paste the credential into Workbench for troubleshooting.

If the result is incorrect

Check whether:

• the correct server was used;
• the correct tool was called;
• the input was accurate;
• filters were applied;
• the source is current;
• the tool returned complete data;
• the model preserved the returned values; and
• another source should be checked.

Find the first difference between the tool result and the final answer.

If the result is empty

An empty result may mean:

• no matching item exists;
• the search term is too narrow;
• a filter excludes the result;
• the source is empty;
• required input is missing; or
• the tool completed normally with no match.

Ask the model to state clearly that no result was found.

Do not let it replace an empty tool result with invented information.

If the action times out

Review:

• Activity;
• the server state;
• network availability;
• the connected service;
• the action destination;
• whether the first action completed; and
• whether the request was too large.

For a write action, inspect the destination before retrying.

If the same tool is called repeatedly

Repeated calls may be caused by:

• an unclear instruction;
• incomplete results;
• the model not recognising success;
• a tool error;
• several enabled tools with similar purposes; or
• a long conversation with conflicting context.

Stop the conversation when repeated calls could create unwanted actions.

Start a new conversation with one tool and one clear task.

Compare two models

Different models may use the same MCP tool differently.

To compare them fairly:

1. start a new conversation for each model;
2. enable the same tool;
3. use the same instruction;
4. use the same sample input;
5. review each Activity log; and
6. compare tool choice, input, output interpretation, and errors.

Choose the model that performs the real task most reliably.

Move a successful task into Studio

When the Workbench task works consistently, you may turn it into a workflow.

Before doing so, record:

• the model;
• the enabled tool;
• the instruction;
• the required input;
• the returned format;
• expected errors;
• empty-result behaviour; and
• whether human review is required.

Build the smallest useful flow and test it again in Studio.

A tool call that works once in Workbench still needs workflow testing.

Final MCP tool checklist

Before accepting the result, confirm that:

• the intended MCP server was available;
• the correct tool was enabled;
• unrelated tools were disabled;
• the instruction was clear;
• the model called the expected tool;
• Activity shows the actual input and output;
• the final answer matches the tool result;
• sensitive data was limited;
• write actions were confirmed at the destination;
• duplicate actions were avoided; and
• human approval remains in place where needed.

MCP tools can make Workbench more capable.

Careful selection and review keep those capabilities understandable and controlled.