Use MCP Tools in Workflows

Use MCP Tools in Workflows

MCP tools can add connected capabilities to a Feluda workflow.

A workflow may use an MCP tool to:

• retrieve information;
• search an approved source;
• read a supported file;
• look up a record;
• use an internal service;
• create or update an item; or
• perform another supported action.

In Studio, an MCP tool can become part of a repeatable process.

Test the tool in Workbench before adding it to a workflow.

Before you begin

Confirm that:

• the MCP server is connected;
• the server is available;
• authentication is complete;
• the required tool appears in Feluda;
• the selected model supports tool use;
• the tool has been tested in Workbench;
• you understand whether it reads or writes information; and
• the workflow has a clear purpose.

Use non-sensitive sample information for the first workflow tests.

Start with a tested Workbench task

Workbench is the best place to understand a new tool before building a repeatable flow.

In Workbench, confirm:

• which tool should be used;
• what input it expects;
• what result it returns;
• how the model calls it;
• what errors can appear;
• whether empty results are possible; and
• whether the action changes an external destination.

Record the successful instruction and expected result.

This gives you a clear starting point for Studio.

Decide what the workflow should do

Describe the process in plain language before adding blocks.

For example:

Receive a customer reference number.
Use the connected search tool to retrieve the customer record.
Summarise the current status.
Return the result.

Then match the steps to the workflow:

Input
→ LLM with MCP Search Tool
→ Output

Keep the first version as small as possible.

Open Studio

Select Studio from the Feluda sidebar.

Start a new workflow or open a saved flow that you want to extend.

Before editing an existing workflow, review:

• its current input;
• its model settings;
• its branches;
• its tools;
• its outputs; and
• any scheduled use.

Pause related schedules before making an important change.

Add an Input block

Add an Input block when the workflow needs information from the user or RunFlows.

Give it a clear name.

Examples include:

• Customer Reference;
• Search Query;
• Document Name;
• Project Identifier; or
• Source Text.

The input name should explain exactly what the workflow expects.

Add an LLM block

Add an LLM block after the Input block.

The LLM block will receive the input, decide how to use the enabled MCP tool, and prepare the next result.

Select:

• the provider;
• the model;
• the instruction; and
• the MCP tool.

Use the same model and tool combination that worked in Workbench.

Enable the MCP tool

Open the tool settings for the LLM block.

Find the required MCP-provided tool.

Enable only the tools needed for that step.

This helps:

• reduce accidental calls;
• make model behaviour easier to understand;
• keep permissions narrow;
• simplify troubleshooting; and
• make the workflow Activity easier to review.

Add more tools only when the workflow has a clear need for them.

Write a clear tool instruction

The LLM instruction should explain:

• what the task is;
• which tool to use;
• what input should be passed;
• what information should be returned;
• what limits apply;
• what to do when nothing is found; and
• whether the tool may write or only read.

For example:

Use the enabled customer-record search tool.

Search for the record that matches the user's reference number.

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

If no record is found, return "No matching record found."
Do not create or change anything.

This instruction defines the task, output, empty-result behaviour, and read-only boundary.

Connect the workflow

Connect the blocks in the intended order.

For a simple read workflow:

Input → LLM with MCP Tool → Output

Confirm that:

• Input connects to the LLM block;
• the LLM block connects to Output;
• the connection direction is correct; and
• no old connection skips the tool step.

Give every block a clear name.

Add an Output block

Add an Output block after the tool-enabled LLM step.

Use a name such as:

• Customer Record Summary;
• Search Result;
• Retrieved Information;
• Review Message; or
• No Match Result.

The Output block should return a result that users can understand and review.

A basic read workflow

A simple MCP workflow may look like:

[Customer Reference]
→ [Retrieve Customer Record]
→ [Customer Record Summary]

The middle block:

• uses the selected model;
• calls the MCP search tool;
• receives the returned record; and
• prepares the final summary.

Test this simple version before adding decisions, tools, or additional AI steps.

Separate retrieval from analysis when needed

One LLM block may be enough for a small task.

Use separate steps when the process becomes difficult to review.

For example:

Input
→ Retrieve Information with MCP Tool
→ Analyse Retrieved Information
→ Output

This can make it easier to see whether an error came from:

• the tool result; or
• the later AI analysis.

Use intermediate output when you need to review the raw returned data.

Add intermediate output

An Emit block can show an MCP result before the workflow continues.

For example:

Input
→ MCP Retrieval
→ Emit Retrieved Data
→ Prepare Summary
→ Output

This is useful while testing because it helps you confirm:

• which information the tool returned;
• whether the correct record was found;
• whether fields are missing;
• whether the next AI step received the right content; and
• where an error first appeared.

Remove unnecessary intermediate output when it no longer helps the user.

Handle empty results

A tool call can succeed without finding a match.

Decide what the workflow should do.

It may:

• return "No matching information found";
• ask for a clearer input;
• follow a human-review path;
• stop the workflow; or
• use another approved source.

Do not allow the model to invent information when the MCP tool returns an empty result.

Add a no-result path

When needed, route an empty result to a clear endpoint.

For example:

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

Use an Expression or another suitable decision step when the returned value can be checked with a fixed rule.

Test both paths.

Handle MCP errors

The MCP call may fail because:

• the server is unavailable;
• authentication expired;
• the endpoint changed;
• the network is unavailable;
• required input is missing;
• permission is denied;
• the connected service is unavailable; or
• the tool returns an unexpected response.

Add a clear error path when the workflow depends on the tool.

Add an error path

A useful pattern is:

MCP Tool Step
→ Success → Continue Workflow
→ Error → Review Output

A review message could say:

The connected service could not complete the request.
Review the MCP server connection and run the workflow again.

Do not allow the workflow to produce a normal-looking final result after the tool failed.

Distinguish errors from empty results

An empty result and an error are different.

Empty result:

The tool worked but found nothing.

Error:

The tool could not complete the request normally.

Use different outputs for these situations.

This helps the user decide whether to change the search input or repair the connection.

Use write tools carefully

An MCP write tool may:

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

A repeatable workflow can perform the same action quickly.

That makes destination and approval checks especially important.

Use a review-before-write workflow

For an important action, separate preparation from execution.

For example:

Input
→ Retrieve Record
→ Prepare Proposed Update
→ Emit Update for Review
→ Approved Path
→ MCP Write Tool
→ Output

The exact approval process depends on your workflow and organisation.

The important principle is that the proposed action remains visible before the final write.

Keep high-impact actions reviewable

Human review is especially important when the tool affects:

• customers;
• employees;
• money;
• contracts;
• legal rights;
• health;
• safety;
• security;
• access to services; or
• important business records.

A workflow can prepare the action.

A person should approve high-impact changes where appropriate.

Confirm tool input

Before relying on the workflow, inspect what the MCP tool receives.

This may include:

• search terms;
• record identifiers;
• file paths;
• names;
• dates;
• structured fields;
• user-provided text; or
• content prepared by an earlier block.

Confirm that the tool receives only the information needed for the action.

Incorrect input can produce an incorrect result even when the tool works normally.

Confirm tool output

Review the raw result when available.

Check whether:

• the correct source was used;
• the expected record was returned;
• required fields are present;
• dates and amounts are correct;
• the result is current;
• an empty result is clearly marked; and
• the next block interprets it accurately.

Do not rely only on the model's summary of the tool output.

Confirm write actions at the destination

After a write action, inspect the connected service.

For example:

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

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

Avoid duplicate write actions

A timeout or delayed response may make a successful action appear to have failed.

Before retrying:

1. review the workflow activity;
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.

Test the workflow in Studio

Use a small sample.

Test:

• normal input;
• missing input;
• an invalid identifier;
• an empty tool result;
• an unavailable MCP server;
• an authentication error;
• a permission error;
• a slow response;
• a write-tool failure; and
• a repeated run.

Review each affected path.

One successful run is not enough.

Test with the server unavailable

Temporarily use a safe test condition where the server cannot respond, or use another approved method supplied by the server owner.

Confirm that:

• the error is visible;
• the workflow does not invent a result;
• the error path runs;
• no write action occurs; and
• the final message tells the user what to review.

Restore the connection after testing.

Test authentication failure

Use only an approved test method.

Confirm that the workflow:

• shows a clear authentication error;
• does not expose the credential;
• does not retry indefinitely;
• does not return a false success message; and
• routes the result for review.

Never paste private credentials into a workflow input.

Test an invalid identifier

Use a sample identifier that should not return a real record.

Confirm that:

• the tool returns no match;
• the workflow distinguishes no match from an error;
• the model does not invent a record;
• the user receives a clear result; and
• no write tool is called.

Test the selected model

Different models may use the same tool differently.

Test whether the selected model:

• calls the correct tool;
• supplies required fields;
• follows read-only instructions;
• handles empty results;
• understands returned data;
• avoids unnecessary repeated calls; and
• reports errors clearly.

Use the model that performs the complete workflow most reliably.

Save the workflow

Give the flow a clear name.

Examples include:

• Search Customer Record;
• Retrieve Project Status;
• Prepare Record Update for Review;
• Check Internal Knowledge Source; or
• Save Approved Task to Service.

Add a description that explains:

• the expected input;
• the MCP server or tool dependency;
• the returned result;
• whether the flow performs a write action; and
• whether human review is required.

Save after important changes.

Test the saved flow in RunFlows

After saving:

1. open RunFlows;
2. select the saved flow;
3. provide non-sensitive sample input;
4. start the workflow;
5. watch intermediate output;
6. review tool activity;
7. confirm the final output; and
8. inspect any external destination.

This confirms that the saved version works outside the Studio editing session.

Protect sensitive information

Review the complete data path.

Check:

• what the user provides;
• what earlier blocks add;
• which model receives the information;
• whether the model is local or cloud-based;
• what the MCP server receives;
• whether the server is local or remote;
• which connected service is involved;
• where output is saved; and
• what activity may be logged.

Remove information that is not required.

Local models and remote MCP tools

A workflow may use a local model and a remote MCP server.

In that case, model processing may happen locally, but the tool call still sends information to the remote server.

Do not describe the complete workflow as local unless every required model, tool, source, and destination is local.

Protect credentials

Store MCP authentication values in the intended protected settings.

Never place:

• passwords;
• API keys;
• access tokens;
• private headers; or
• connection secrets

inside workflow prompts, Input blocks, Journal entries, or normal notes.

The workflow should use the configured connection without exposing its credential to the model.

Add the workflow to a schedule carefully

A scheduled workflow may use an MCP tool when the connection and connected service remain available at run time.

Before scheduling:

• run the flow manually several times;
• test server errors;
• test empty results;
• confirm authentication;
• understand normal runtime;
• prevent duplicate writes;
• review external destinations;
• avoid overlapping runs; and
• assign a reviewer.

External service availability can change after the schedule is created.

Review scheduled MCP results

After a scheduled run, check:

• whether the schedule started;
• whether the MCP server was available;
• whether the correct tool was called;
• what input it received;
• what output it returned;
• whether an error path ran;
• whether a write action completed;
• whether a duplicate was created; and
• whether the final result is accurate.

Pause the schedule after repeated connection or destination problems.

If the tool does not appear in Studio

Check that:

• the MCP server is connected;
• the connection is available;
• authentication succeeded;
• the server exposes the tool;
• Feluda refreshed the tool list;
• the selected model supports tool use; and
• the tool is available in the LLM block.

Return to the MCP Servers page and review the connection state.

If the model does not call the tool

Confirm that:

• the tool is enabled in the LLM block;
• the instruction clearly requires it;
• the model supports tool use;
• another tool is not confusing the model;
• the block receives the required input; and
• the exact tool name is used when needed.

Test the same instruction in Workbench.

If the wrong tool is called

Disable unrelated tools in the block.

Use a direct instruction:

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

Review tool names and descriptions for overlap.

If the workflow receives the wrong tool result

Check whether:

• the correct server was used;
• the tool input was accurate;
• the source is current;
• filters were applied;
• the returned data is complete;
• the workflow passed the result correctly; and
• the next AI block interpreted it accurately.

Add an Emit block to inspect the raw result.

If the MCP call times out

Review:

• server availability;
• network connection;
• external service status;
• request size;
• workflow runtime;
• other active runs;
• the destination of any write action; and
• whether the first call completed.

Do not retry a write action until the destination has been checked.

If repeated calls occur

Repeated calls may be caused by:

• an unclear instruction;
• an empty result;
• the model not recognising success;
• a tool error;
• several similar tools;
• a loop in the workflow; or
• an output format the model cannot interpret.

Stop the run when repeated calls could create unwanted actions.

Simplify the workflow and test one tool at a time.

If the connection changes

When the endpoint, authentication, or tool list changes:

1. identify dependent workflows;
2. pause related schedules;
3. update the MCP connection;
4. test the tool in Workbench;
5. open the workflow in Studio;
6. confirm the tool still appears;
7. test every affected path;
8. save the flow; and
9. resume schedules only after successful runs.

A connection change can affect several workflows at once.

If the server is removed

Removing an MCP server makes its tools unavailable.

Before removal, identify:

• Workbench users who rely on it;
• Studio workflows that use its tools;
• saved RunFlows items;
• scheduled workflows; and
• related Genes or processes.

Update or pause dependent workflows before removing the connection.

Final workflow checklist

Before regular use, confirm that:

• the MCP server is trusted and available;
• authentication is protected;
• the required tool is visible;
• the tool was tested in Workbench;
• the workflow purpose is clear;
• only required tools are enabled;
• tool input is correct;
• empty results are handled;
• errors follow a visible path;
• write actions require appropriate review;
• destinations are confirmed;
• duplicate prevention is in place;
• the saved flow works in RunFlows;
• sensitive information is limited; and
• scheduled use has been tested separately.

MCP tools can turn a connected service into a repeatable workflow step.

Careful testing keeps that step dependable and understandable.