Review MCP Tool Activity

Review MCP Tool Activity

Reviewing MCP tool activity helps you understand what an AI model or workflow actually did.

A final answer may look correct while the wrong tool was used, the wrong information was sent, or an external action affected the wrong destination.

Feluda gives you visibility into tool activity through:

• the Workbench Activity drawer;
• RunFlows output;
• intermediate output from Emit blocks; and
• visible warnings and error messages.

Use these views to confirm every important tool action.

Why activity review matters

MCP tools can retrieve information or change connected systems.

Activity review helps you confirm:

• which tool was called;
• what input it received;
• what output it returned;
• whether the call completed;
• whether a warning appeared;
• whether an error occurred;
• whether the model interpreted the result correctly; and
• whether an external action reached the intended destination.

Do not rely only on the model saying that the tool succeeded.

Where to review tool activity

The best review location depends on where the tool was used.

Area	What to review
Workbench	Tool calls, input data, output data, warnings, and errors in Activity
RunFlows	Workflow tool calls, intermediate output, branch results, and final output
Studio	Tool configuration, instructions, permissions, and Emit blocks
External service	The actual record, file, task, message, or other destination

Use more than one view when the action is important.

Review activity in Workbench

After using an MCP tool in Workbench:

1. wait for the model response to finish;
2. open the Activity drawer;
3. find the relevant tool call;
4. review the tool name;
5. review the input;
6. review the returned output;
7. read warnings or errors; and
8. compare the activity with the final answer.

Start a new conversation when testing a new tool so earlier messages do not make the activity harder to understand.

Review activity in RunFlows

For a workflow:

1. open the completed or failed run;
2. confirm the workflow name;
3. review the starting input;
4. inspect intermediate output;
5. find the MCP tool call;
6. review its input and output;
7. confirm the branch that followed;
8. read warnings and errors; and
9. compare the final result with the tool data.

A later workflow error may begin with an earlier incorrect tool result.

Identify the tool

Confirm the exact tool that was used.

Check:

• the tool name;
• the MCP server that provides it;
• whether it is a read or write tool;
• whether it matches the task;
• whether another similarly named tool was available; and
• whether the correct account or environment was used.

A model can select the wrong tool when several related tools are enabled.

Confirm the server source

A tool may come from:

• Feluda's built-in MCP server;
• an installed Gene;
• an external MCP server;
• a test connection; or
• a production connection.

Confirm which server supplied the tool.

Clear connection names such as:

• Customer Records MCP — Read Only;
• Customer Records MCP — Production; or
• Project Service MCP — Test

make this easier.

Review the tool input

Tool input is the information sent to the MCP tool.

It may include:

• a search query;
• a record identifier;
• a filename;
• a path;
• a date;
• structured fields;
• source text;
• a destination;
• a message; or
• another action parameter.

Confirm that the input matches the intended task.

Check for missing input

A failed or incomplete call may be caused by missing required information.

Review whether the tool received:

• the full identifier;
• the correct date format;
• the expected destination;
• the required fields;
• a valid path;
• an approved URL;
• the correct account; and
• enough information to complete the action.

Improve the instruction or earlier workflow step when required input is missing.

Check for excessive input

A tool may receive more information than it needs.

Look for:

• complete documents when one section is enough;
• personal information unrelated to the task;
• old conversation content;
• private notes;
• unnecessary file paths;
• credentials;
• unrelated records; or
• duplicate text.

Remove unnecessary information before repeating the task.

Review the raw tool output

Tool output is the information returned by the server or connected service.

It may include:

• a matching record;
• a list of results;
• file information;
• a created item;
• a changed value;
• a confirmation;
• a warning;
• an empty result; or
• an error.

Review the raw returned values before relying on the model's summary.

Compare output with the final answer

The model may misread or omit part of the tool result.

Compare:

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

Ask the model to separate raw tool values from its explanation when accuracy matters.

Distinguish tool facts from model interpretation

Keep these separate:

• Tool result: information returned by the connected source.
• Model interpretation: the model's explanation, summary, or suggestion.

For example:

## Tool Result

Status: Pending
Owner: Mia
Last updated: 2026-06-07

## AI Summary

The item is still pending and was last updated recently.

The summary should not add facts that were not returned.

Understand successful completion

A successful tool call means the request completed without a blocking error.

It does not automatically mean that:

• the correct tool was used;
• the input was correct;
• the returned record was the intended one;
• the result is current;
• a write action used the correct destination; or
• the final answer is accurate.

Review the content, not only the completion state.

Understand empty results

An empty result means the tool completed but found no matching information.

This is different from an error.

Check:

• spelling;
• identifiers;
• filters;
• date ranges;
• source selection;
• account access; and
• whether the item exists.

The model should report the empty result clearly.

It should not invent a match.

Understand warnings

A warning may mean the tool completed but something requires attention.

Examples include:

• incomplete data;
• a fallback source;
• a partial result;
• a skipped optional field;
• an outdated record;
• a permission limitation; or
• a result that needs review.

Read the full warning before accepting the final answer.

Understand errors

An error means the tool could not complete the request normally.

Common causes include:

• unavailable MCP server;
• incorrect endpoint;
• expired authentication;
• missing required input;
• permission denial;
• unavailable source;
• network failure;
• unsupported action;
• timeout; or
• remote service failure.

Find the first failing step before changing the workflow.

Review repeated tool calls

Several calls may be normal when the task requires more than one lookup.

Repeated calls deserve attention when:

• the same input is sent again;
• the same write action repeats;
• the tool returns success but the model calls it again;
• the tool returns an error repeatedly;
• several similar tools are enabled; or
• the workflow appears stuck.

Stop the task when repeated calls could create duplicate actions.

Identify why calls repeat

Repeated calls may be caused by:

• unclear instructions;
• incomplete output;
• empty results;
• the model not recognising success;
• tool errors;
• overlapping tool descriptions;
• a workflow loop; or
• an unexpected output format.

Reduce the enabled tools and simplify the instruction.

Review the order of calls

The sequence of tool calls can reveal how the model approached the task.

Ask:

• Did it search before writing?
• Did it retrieve the correct record first?
• Did it call an update tool before review?
• Did it repeat a lookup unnecessarily?
• Did it use a fallback tool?
• Did it stop after an error?

The order should match the intended process.

Review read actions

For a read tool, confirm:

• the intended source was queried;
• the search or identifier was correct;
• filters were appropriate;
• returned data is complete;
• the result is current enough; and
• the model did not add unsupported details.

A successful lookup can still return the wrong record.

Review write actions

For a write tool, confirm:

• the exact tool;
• the destination;
• the account;
• the record or file;
• the content;
• the recipient;
• the returned confirmation; and
• whether human approval was required.

Write actions need both activity review and destination review.

Confirm write actions externally

Inspect the connected service after the tool call.

For example:

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

Do not treat a model-generated success sentence as proof.

Review destination identifiers

A write action may use:

• a record ID;
• a filename;
• a folder;
• a workspace;
• a recipient;
• an account;
• a project; or
• another destination value.

Confirm that the identifier belongs to the intended target.

A correct action against the wrong destination is still a failed outcome.

Avoid duplicate write actions

A delayed response or timeout can make a completed action appear to fail.

Before retrying:

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

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

Review activity after a timeout

Check:

• whether the tool call began;
• whether it returned partial output;
• whether a write confirmation appeared;
• whether the external item exists;
• whether another call was started; and
• whether the connected service processed the request.

A timeout can occur after the external service has already acted.

Review tool permissions

A permission error may involve:

• read or write access;
• account access;
• URL rules;
• IP address rules;
• file-path rules;
• port rules; or
• external-service permissions.

Confirm the intended source and destination before changing access.

Expand only the permission required for the approved task.

Review privacy in activity

Tool activity may reveal what information was sent.

Check whether the input contains:

• personal information;
• confidential text;
• complete documents;
• file paths;
• private identifiers;
• internal URLs; or
• other sensitive details.

Remove unnecessary data from future runs.

Never include credentials in tool input.

Review local and remote calls

Confirm whether the MCP server is:

• local;
• internal;
• remote; or
• provided by an external service.

A local model can still send information to a remote MCP server.

Activity review helps confirm which connected tool received the task.

Use Emit blocks for workflow review

In Studio, add an Emit block when you need to inspect intermediate data.

For example:

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

This helps separate a tool problem from a later AI problem.

Remove unnecessary Emit blocks when they no longer help users.

Compare raw and transformed data

A workflow may transform tool output before the final result.

Review each stage:

1. raw tool result;
2. extracted fields;
3. classification;
4. summary or report;
5. final output; and
6. external write action.

Find the first point where the information changes incorrectly.

Review branch decisions

A tool result may determine which workflow path runs.

Confirm that:

• the returned value was correct;
• the Expression or label rule matched it;
• the expected branch ran;
• fallback paths are clear; and
• errors do not enter a normal success path.

A correct tool result can still lead to the wrong branch.

Review scheduled tool activity

For scheduled workflows, use Schedule Manager and RunFlows together.

Check:

• whether the run started;
• which tool was called;
• what input it received;
• whether the server was available;
• what output returned;
• whether a warning or error appeared;
• whether a write action completed; and
• whether a duplicate was created.

Pause schedules after repeated or unexplained tool behaviour.

Review activity after a server change

A server update may change:

• tool names;
• input fields;
• output fields;
• error messages;
• permissions;
• authentication; or
• behaviour.

Compare new activity with an earlier successful run.

Update dependent workflows when the returned format changes.

Review activity after a model change

Different models may call the same tool differently.

Compare:

• tool selection;
• input values;
• number of calls;
• handling of empty results;
• response to errors;
• interpretation of output; and
• final answer quality.

Use the model that performs the complete task most reliably.

Review unexpected tool use

Stop and investigate when:

• a write tool is called during a read-only task;
• an unrelated server is used;
• personal information is sent unnecessarily;
• a tool is called repeatedly;
• the wrong environment is used;
• the wrong account is selected; or
• the destination is unclear.

Disable unrelated tools and start a new conversation or test run.

Use a review checklist for important actions

Before accepting an important MCP result, confirm:

• the expected server was used;
• the correct tool was called;
• the input was necessary and accurate;
• the output is complete;
• warnings were reviewed;
• errors were resolved;
• repeated calls were understood;
• the model's answer matches the tool result;
• write actions reached the correct destination; and
• human approval remains in place where needed.

A practical Activity review

Use this process:

1. Identify the task.
2. Confirm the server and tool.
3. Open Activity or RunFlows output.
4. Review the tool input.
5. Remove unnecessary data from future runs.
6. Review the raw tool output.
7. Read warnings and errors.
8. Check for repeated calls.
9. Compare the final answer with the tool result.
10. Confirm the workflow branch.
11. Inspect external write destinations.
12. Check for duplicates.
13. Record recurring problems.
14. Update the instruction, permissions, or workflow when needed.
15. Retest with non-sensitive sample information.

Activity review turns a model's claim into a result you can verify.