Troubleshoot MCP Tool Results
An MCP tool can connect successfully and still return a result that is:
- empty;
- incomplete;
- outdated;
- malformed;
- inconsistent;
- duplicated;
- difficult to interpret;
- based on the wrong source;
- based on the wrong filters; or
- summarised incorrectly by the AI model.
Begin by identifying where the problem first appears.
The issue may be in:
- the tool input;
- the connected source;
- the MCP server;
- the returned tool data;
- a workflow transformation;
- the AI model's interpretation; or
- the final output format.
Do not change every part of the workflow at once.
Separate tool problems from AI problems
A typical tool task has several stages:
User Input
→ AI Model Prepares Tool Call
→ MCP Tool Retrieves Data
→ Tool Returns Result
→ AI Model Interprets Result
→ Final Answer
The first step in troubleshooting is to compare the raw tool result with the final answer.
If the raw result is wrong, investigate the tool, source, input, or server.
If the raw result is correct but the final answer is wrong, investigate the model instruction or workflow transformation.
Start with the visible symptom
Use the symptom to choose your first check.
| Symptom | First check |
|---|---|
| No result | Search input, filters, source, and account scope |
| Partial result | Returned fields, permissions, limits, and source completeness |
| Outdated result | Source date, cache, reporting period, and record timestamp |
| Malformed result | Raw tool output, field structure, and server changes |
| Duplicate results | Search breadth, pagination, repeated calls, and source duplication |
| Inconsistent results | Input changes, source updates, model behaviour, and server state |
| Wrong record | Identifier, filters, source, account, and multiple matches |
| Correct raw data but wrong answer | Model interpretation and later workflow steps |
| Unexpected warning | Tool output, source limitations, and permission scope |
| Result changed after an update | Tool schema, field names, server version, and workflow mapping |
Correct the earliest clear problem.
Review the raw tool result
In Workbench, open the Activity drawer.
In a workflow, review:
- RunFlows output;
- the tool call;
- intermediate values;
- Emit blocks;
- warnings; and
- errors.
Read the raw result before reviewing the final AI response.
Confirm:
- what the tool returned;
- how many records were returned;
- which fields are present;
- which fields are missing;
- whether a warning appears;
- whether the result is current; and
- whether the result matches the intended source.
Review the tool input
Incorrect input often produces a technically valid but irrelevant result.
Check:
- search query;
- record identifier;
- filename;
- path;
- date range;
- filters;
- source;
- account;
- project;
- workspace;
- language;
- sort order; and
- result limit.
Compare the actual input shown in Activity with the instruction you intended.
Confirm the correct tool was used
Several tools may provide similar capabilities.
Check:
- tool name;
- MCP server;
- test or production connection;
- read or write capability;
- source system;
- account;
- environment; and
- tool description.
A correct search against the wrong tool or environment still produces the wrong result.
If the result is empty
An empty result means the tool completed but returned no matching information.
Check:
- spelling;
- identifier format;
- date range;
- selected source;
- account scope;
- project scope;
- filters;
- result limit;
- whether the record exists; and
- whether the source is available.
Do not let the model invent a result.
Distinguish empty results from errors
These are different outcomes.
Empty result:
The tool worked but found nothing.
Error:
The tool could not complete the request normally.
A useful no-result response is:
No matching information was returned by the connected source.
An error response should explain what failed.
Check the search query
A query may be too:
- narrow;
- broad;
- vague;
- misspelled;
- long;
- language-specific;
- outdated; or
- dependent on an exact match.
Try a simpler approved query.
For example, replace:
onboarding process for new full-time employees in Amsterdam office
with:
onboarding process
Then add filters only when needed.
Check exact-match behaviour
Some tools search for exact values.
Confirm whether the tool expects:
- exact identifier;
- exact filename;
- exact title;
- exact account name;
- exact date; or
- exact status.
A small difference in punctuation, spacing, or capitalisation may produce no result.
Check filters
Filters may remove valid results.
Review:
- date range;
- project;
- owner;
- status;
- category;
- region;
- language;
- account;
- workspace; and
- record type.
Remove one filter at a time and repeat the same test.
Check account scope
The connected account may not be allowed to see every record.
Confirm:
- account identity;
- workspace;
- project membership;
- read permission;
- record scope;
- folder scope;
- team access; and
- environment.
A no-result response may actually reflect limited access.
Check whether the source is available
The source may be:
- offline;
- unavailable;
- moved;
- renamed;
- empty;
- not mounted;
- not synchronised;
- restricted; or
- temporarily delayed.
Test the source outside the workflow when possible.
If the result is partial
A partial result contains only some of the expected information.
Check whether:
- the source lacks the missing field;
- the connected account cannot access it;
- a result limit was reached;
- pagination is required;
- a filter removed related records;
- the model omitted part of the result;
- the server returned a shortened response; or
- the workflow dropped fields later.
Compare raw output with the final answer.
Check missing fields
List the fields you expected.
For example:
Record ID
Customer Name
Status
Owner
Last Updated
Deadline
Then compare them with the raw result.
Mark missing values clearly.
Use:
Not provided
instead of allowing the model to guess.
Check permissions for missing fields
Some fields may require additional access.
Confirm whether the connected account can view:
- private notes;
- customer details;
- financial fields;
- attachments;
- internal status;
- audit history; or
- restricted metadata.
Do not expand access until the field is confirmed as necessary.
Check result limits
A tool may return only the first:
- record;
- page;
- set of matches;
- number of files;
- number of fields; or
- amount of text.
Review whether the tool supports:
- a larger result limit;
- pagination;
- next-page values;
- narrower queries; or
- separate follow-up requests.
Do not assume the first page is the complete result.
Check pagination
Multiple-page results can appear incomplete when only the first page is read.
Confirm:
- page size;
- page number;
- next-page token;
- total result count;
- sort order; and
- whether the workflow requests later pages.
Avoid uncontrolled repeated paging when the result set is very large.
If the result is outdated
A tool can return valid information that is no longer current.
Check:
- source timestamp;
- last-updated field;
- reporting period;
- record status date;
- file modification date;
- cache date;
- synchronisation time; and
- whether a newer source exists.
Include the source date in the final answer when freshness matters.
Check the reporting period
A result may cover:
- today;
- yesterday;
- a week;
- a month;
- a quarter;
- a project phase; or
- another defined period.
Confirm that the tool result covers the period requested by the user.
A current run can still return an older reporting period.
Check caching
Some sources or services may return cached information.
Review whether:
- the tool refreshes automatically;
- a manual refresh is needed;
- a local index is current;
- the source was synchronised;
- a cached copy is used; or
- the connected service updates with a delay.
Do not claim that a result is live unless the source confirms it.
Check local file versions
A local tool may read an older copy of a file.
Confirm:
- exact path;
- filename;
- duplicate filenames;
- modification time;
- synchronised folder state;
- mounted drive;
- downloaded version; and
- whether the workflow reads a temporary copy.
Use stable source folders for repeated workflows.
If the result is malformed
A malformed result may contain:
- missing field names;
- invalid structured data;
- broken tables;
- unclosed text blocks;
- unexpected nesting;
- duplicate keys;
- mixed data types;
- invalid dates; or
- unreadable characters.
Review the raw output before the model changes it.
Check whether the server format changed
An MCP server update may change:
- field names;
- field order;
- nesting;
- data types;
- warning structure;
- error structure;
- page information;
- date format; or
- result labels.
Compare the new result with an earlier successful run.
Pause dependent workflows when the change affects later blocks.
Check structured output
When a workflow expects structured fields, confirm:
- valid field names;
- required fields;
- data types;
- nested values;
- arrays or lists;
- empty values;
- number formats; and
- date formats.
A small structure change can break later extraction or branching.
Check date formats
Dates may appear as:
2026-06-08;08-06-2026;06/08/2026;- a full timestamp;
- a local timezone; or
- UTC.
Confirm how the workflow interprets the value.
Avoid ambiguous date formats in final output.
Check number formats
Review:
- decimal separator;
- thousands separator;
- currency;
- units;
- percentage sign;
- negative values; and
- scientific notation.
Do not let a formatting conversion change the meaning.
Check character encoding
Unexpected characters may appear when the source contains:
- accented text;
- non-Latin scripts;
- symbols;
- copied formatting;
- special punctuation; or
- unsupported encoding.
Test the source language and characters directly.
Confirm that the MCP server and workflow preserve them.
If duplicate results appear
Duplicate records may come from:
- repeated tool calls;
- broad queries;
- pagination overlap;
- duplicated source data;
- several connected sources;
- multiple environments;
- repeated indexing; or
- the model combining the same result twice.
Compare identifiers and timestamps.
Check unique identifiers
Use stable values such as:
- record ID;
- file path;
- customer reference;
- task ID;
- source URL;
- message ID; or
- external identifier.
Two records with similar titles may still be different.
Two identical-looking records with the same identifier are likely duplicates.
Check repeated tool calls
Review Activity or RunFlows output.
Confirm whether the same tool was called:
- with the same input;
- after a successful result;
- after a timeout;
- in a workflow loop;
- by two parallel branches; or
- by overlapping scheduled runs.
Stop repeated write-capable calls immediately.
Check pagination overlap
Duplicate results may appear when one page includes an item also returned on the next page.
Review:
- page boundaries;
- sort order;
- next-page token;
- total count;
- source updates during paging; and
- duplicate-removal logic.
Use stable identifiers to remove repeated items.
Check duplicate source records
The connected system may contain real duplicates.
Confirm whether:
- two records share a title;
- one is archived;
- one is a corrected version;
- one belongs to a test environment;
- one belongs to another workspace; or
- the source itself needs cleanup.
Do not automatically merge records without review.
If results are inconsistent
Inconsistent results may change between identical runs.
Check:
- source updates;
- changing sort order;
- non-deterministic model behaviour;
- changing filters;
- server availability;
- cache state;
- account permissions;
- time-based data;
- tool version; and
- concurrent writes.
Repeat the same controlled test.
Use the same test conditions
For a fair comparison, keep these unchanged:
- model;
- MCP server;
- tool;
- instruction;
- input;
- filters;
- permissions;
- source;
- date range; and
- output format.
Record the timestamp of each run.
Check changing source data
A live source may change between tests.
Confirm whether:
- records were updated;
- files changed;
- new items were added;
- statuses changed;
- an index refreshed; or
- another user changed the source.
Inconsistency is not always a tool failure.
Check sort order
A tool may return different first results when no stable sort is defined.
Use an explicit sort when supported.
For example:
- newest first;
- oldest first;
- name;
- identifier;
- relevance;
- status; or
- last updated.
Record the sort rule in recurring workflows.
Check model variation
The raw tool result may remain the same while the model's answer changes.
Compare:
- omitted fields;
- wording;
- interpretation;
- unsupported suggestions;
- classification;
- summary length; and
- handling of uncertainty.
Use a more structured prompt or a more reliable model when needed.
If the wrong record is returned
Check:
- identifier;
- search term;
- multiple matches;
- account;
- workspace;
- environment;
- filters;
- source;
- sort order; and
- archived records.
Use unique identifiers instead of names when possible.
Handle multiple matches
When several records match, the model should not choose one silently.
Ask it to return:
- every candidate;
- identifier;
- title or name;
- status;
- date;
- source; and
- the reason each record matched.
Then ask for clarification before continuing.
Check test and production environments
Similar tools may connect to different environments.
Confirm whether the result came from:
- test;
- development;
- staging;
- production;
- personal account; or
- organisational account.
Use clear server and connection names.
If the raw result is correct but the answer is wrong
The problem is likely in the model instruction or a later workflow step.
Check:
- summary prompt;
- extraction prompt;
- classification labels;
- formatting step;
- previous conversation context;
- output length;
- selected model; and
- later transformations.
Keep the raw result visible with an Emit block.
Use source-bound instructions
Tell the model:
Use only the information returned by the MCP tool.
Preserve names, dates, amounts, statuses, and identifiers exactly.
If a value is missing, write "Not provided."
Separate source facts from suggestions.
Do not guess.
This reduces unsupported additions.
Check long-context loss
A long tool result may exceed what the model can handle reliably.
Signs include:
- missing later records;
- mixed fields;
- incomplete summaries;
- repeated content;
- lost source references; or
- wrong conclusions.
Reduce the result size or process it in smaller sections.
Check output length limits
A response limit may cut off important content.
Review whether:
- the raw result is complete;
- the final answer ends unexpectedly;
- tables are incomplete;
- later sections are missing;
- warnings were dropped; or
- records were omitted.
Request a shorter structure or multiple reviewed sections.
Check workflow transformations
A workflow may alter the result through:
- LLM Extract;
- LLM Label;
- Expression;
- filtering;
- sorting;
- formatting;
- aggregation;
- another tool; or
- a final LLM summary.
Review each intermediate value.
Use Emit blocks
Add Emit blocks after important steps.
For example:
Input
→ MCP Tool
→ Emit Raw Result
→ Extract Fields
→ Emit Extracted Fields
→ Final Summary
→ Output
This shows where information changes.
Check extraction steps
Compare every extracted field with the raw result.
For example:
| Field | Raw result | Extracted value |
|---|---|---|
| Status | Pending | Pending |
| Owner | Mia | Mia |
| Deadline | Not provided | Friday |
In this example, Friday is unsupported.
Check classification steps
A classification is a model decision.
Review:
- label names;
- label descriptions;
- source values;
- selected label;
- fallback path;
- overlapping categories; and
- uncertainty.
Do not present the classification as a raw source fact.
Check Expression logic
An Expression block may fail because of:
- capitalisation;
- spaces;
- spelling;
- date format;
- number format;
- missing value;
- unexpected type; or
- outdated field name.
Compare the actual incoming value with the rule.
If warnings are missing from the final answer
The model or workflow may have removed them.
Check:
- raw result;
- extraction fields;
- summary instruction;
- output structure;
- length limits; and
- later formatting.
Important source warnings should remain visible.
If the result is correct once but fails later
Review what changed:
- server;
- endpoint;
- authentication;
- account permissions;
- tool version;
- source structure;
- model;
- prompt;
- workflow;
- network; or
- schedule.
Compare the failed run with the last successful run.
Compare successful and failed runs
Record:
- timestamp;
- model;
- tool;
- server;
- input;
- filters;
- raw output;
- warnings;
- errors;
- workflow version; and
- final answer.
Differences often reveal the cause.
If scheduled results differ from manual results
Compare whether the scheduled run used:
- the same workflow version;
- the same input;
- the same model;
- the same MCP server;
- the same account;
- the same filters;
- the same source availability;
- the same permissions; and
- the same reporting period.
Also check whether the source changed between the manual and scheduled run.
If offline results differ
A disconnected workflow may use:
- a local cache;
- an older local file;
- a limited local index;
- a missing remote source;
- another fallback;
- or no result.
Confirm that the workflow does not silently replace a remote source with an outdated local copy.
Check fallback behaviour
A workflow may use another source when the preferred source fails.
Confirm:
- whether fallback is allowed;
- which source was used;
- whether the result is clearly labelled;
- whether freshness differs;
- whether permissions differ; and
- whether the user should approve the fallback.
Do not hide fallback use.
If a result contains sensitive data unexpectedly
Stop regular use and review:
- tool input;
- account scope;
- source permissions;
- query breadth;
- returned fields;
- model output;
- saved destinations; and
- who can access the result.
Reduce permissions and source scope before retesting.
If credentials appear in the result
Stop using the tool.
Do not copy or publish the credential.
Review:
- source data;
- server configuration;
- logs;
- tool output;
- account settings;
- protected fields; and
- whether the credential should be revoked.
Credentials should never appear in normal tool results.
If the result cannot be verified
Do not rely on it for an important decision.
Ask:
- Is the source known?
- Is the tool input visible?
- Is the record identifier present?
- Is the date visible?
- Can the raw result be reviewed?
- Can the source be opened separately?
- Can another approved source confirm it?
Use human review when evidence remains incomplete.
Correct one layer at a time
Change only one of these before retesting:
- tool input;
- filters;
- account;
- permissions;
- server;
- source;
- model;
- prompt;
- workflow mapping; or
- output format.
Repeat the same controlled test.
Re-test the normal case
After correcting the issue, test:
- valid result;
- no result;
- partial result;
- warning;
- error;
- multiple matches;
- long result;
- repeated run; and
- scheduled use when relevant.
A fix for one case should not break another.
Pause automation when results are unreliable
Pause related schedules when:
- results are repeatedly empty;
- important fields disappear;
- outdated data is returned;
- tool format changes;
- duplicate records appear;
- the wrong environment is used;
- warnings are hidden;
- unsupported claims are saved; or
- results cannot be verified.
Resume only after successful manual and RunFlows tests.
A practical troubleshooting routine
Use this process:
- Define the exact result problem.
- Identify the MCP server and tool.
- Review the actual tool input.
- Review the raw tool result.
- Confirm the source and account.
- Check filters, limits, and pagination.
- Check freshness and timestamps.
- Check field structure and data types.
- Check duplicate identifiers.
- Compare raw data with the AI answer.
- Review every workflow transformation.
- Add Emit blocks where needed.
- Correct one layer.
- Repeat the same controlled test.
- Test no-result, error, and scheduled cases.
- Resume automation only when results are dependable.
Reliable MCP results require correct input, a trustworthy source, visible raw output, and careful model interpretation.