I’m creating a workflow where the agent cross-references one spreadsheet with another. I’ve provided the first spreadsheet in a ‘Get row(s) from sheets’ node before the AI Agent; and the second in the ‘Get row(s) in sheet in Google Sheets’ tool attached to the AI Agent.
I’ve made it extremely clear in the prompt for the Agent to call this tool. But whenever I run the workflow the Agents output claims it needs to access the second spreadsheet, even though it already can extract data from it.
Any Ideas?
Hi Tim
The issue is almost certainly the tool description and/or your system prompt — the agent has the tool but doesn’t understand when or why to call it.
Two things to check:
-
Add a description to the Google Sheets tool node
In the tool node settings there’s a description field — fill it in explicitly. Something like: “Use this tool to look up rows from the [sheet name] spreadsheet. Call it when you need to cross-reference against [what the data contains].” The LLM uses this description to decide when to call the tool.
-
Reference the tool in your system prompt
Add a line like: “You have access to a tool that retrieves data from [spreadsheet name]. Use it to look up [specific thing]. Do not ask for access — call the tool directly.”
Also worth checking: go to Executions, open a run, and see if the tool node is actually being called. If it shows no execution of the tool node at all, the agent isn’t calling it — which confirms it’s a description/prompt issue rather than a credentials issue.
Tim, this is a classic reasoning failure where the agent isn’t identifying the tool as the correct state for the task.
Try these two specific fixes:
-
Schema-Level Definition: Don’t rely on the UI description. Ensure your Google Sheets node operation is set to a specific, narrow function (like Get or Get Many) rather than a generic one. This forces the model to understand the required input parameters (Row ID, filters).
-
System Prompt Constraint: Add this to your agent’s system instructions:
Constraint: You have read-only access to [Sheet Name] via the ‘Google Sheets’ tool. If data retrieval is needed for cross-referencing, you must emit a function call to this tool before synthesizing any response. Do not hallucinate that you lack access."
Check your Executions tab. If you don’t see tool_calls in the JSON payload for the Agent node, the model isn’t even attempting the invocation—confirming it’s a prompt/description issue, not a connection one.
@Tim_Barrett
Both of these are right, and the Executions check is the first thing to do. If the tool node shows zero executions and there’s no tool_calls in the Agent’s output, it’s not a credentials problem, the model just isn’t invoking the tool.
One thing nobody’s mentioned yet: check which model you’re driving the agent with. That “I need access to the second spreadsheet” output is a classic tell of a model that’s weak at tool calling. Instead of emitting a function call, it narrates what it would need in plain text. Strong tool-callers rarely do this; weaker ones do it constantly, no matter how clearly you word the prompt.
If you’re on Haiku (or a small local model, or an older cheap one), that’s very likely your problem. Haiku in particular is fast and cheap but not great at reliably deciding to call a tool. The prompt tweaks above help, but you can spend an hour perfecting the description and still lose to a model that just isn’t good at this.
Fast way to isolate it: change only the model to a stronger tool-caller (Sonnet, GPT-4-class, etc.), run the exact same workflow, and see if it starts calling the tool. If it does, it was the model, not your prompt. If it still doesn’t, then it’s the description/prompt/wiring and you’re back to what emmet and Swapnil laid out.
Order I’d debug in: confirm the tool actually shows in Executions → swap to a known-good tool-calling model → then tune the tool description and system prompt. Fixing the prompt first only works if the model was capable of calling in the first place.
Alright, now that I’ve dug into the actual workflow, here’s my read. This isn’t a tool-calling or prompt problem, and you’re already on Sonnet 4.5 which is strong at tool calls. It’s structural, in how the data reaches the agent.
Your “Get row(s) in sheet” node returns every food row, then Edit Fields1 emits one item per row. The AI Agent node runs once per incoming item. So it isn’t running once over the whole sheet, it’s firing separately for each food, and each run only sees a single item in its prompt (List Chicken and 75). Meanwhile your system prompt tells it to “process every single row” and “compile ALL data into one document,” which it literally can’t do, because you only handed it one row that execution. That mismatch is exactly why it comes back saying it needs to access the spreadsheet. It knows it’s missing the full picture.
Fix is to collapse the first sheet into one item before the agent:
- Add an Aggregate node (or Summarize) after “Get row(s) in sheet” to roll all rows into a single item.
- Build the user prompt from that full list instead of List {{ $json.Item }} and {{ $json[‘Temperature (Celsius)’] }}, so the agent sees the whole table in one shot.
- Now it runs once, calls the Standard Temperatures tool to cross-reference, and returns one document, which is what your PDF node downstream actually wants.
Quick way to confirm: run it and look at the Agent node in Executions. If it executed 15 times instead of once, that’s the fan-out, not a tool issue.
Few smaller cleanups while you’re in there:
- The tool still deserves a one-line description (“Look up standard safe temperatures by food item”). Doesn’t hurt.
- maxIterations is set to 1e20. Set it to something like 10.
- Your Edit Fields node outputs {{ $json.output }} {{ $json.output }} {{ $json.output }}, so the PDF gets the text three times. Drop it to a single reference.
Do the aggregation fix first. The rest is polish. That one’s the actual bug.
One thing worth checking before anything else: open the execution log and see if the Google Sheets tool node actually ran, or if it shows zero calls. If the node has no executions in the log, the model decided not to call it - that’s a prompting issue and emmet’s suggestions will fix it. If the node did run but returned an error, that’s a credential or config issue (wrong sheet ID, credential missing the right OAuth scope, sheet not shared with the service account). Two very different fixes, and the log tells you which path you’re on.