In this categoryTroubleshooting ยท 27
- How to Fix an OpenAI 401 'Invalid API Key' ErrorStart
- How to Fix OpenAI 429 Rate Limit Errors With Backoff
- How to Fix Anthropic Claude API 401 Authentication Errors
- How to Fix Google Gemini 'API Key Not Valid' Errors
- How to Fix an API Key That Loads as Undefined
- How to Handle Anthropic 529 'Overloaded' Errors
- How to Fix Rate Limit Errors from an AI API
- How to Fix CORS Errors When Calling an AI API From the Browser
- How to Fix 'Model Not Found' and Deprecated Model Errors
- How to Rotate a Leaked API Key Without Downtime
- How to Fix SSL Certificate Errors When Calling AI APIs
- How to count tokens before sending a prompt to Claude
- How to Fix 'Context Length Exceeded' Token Limit Errors
- How to fix a context length exceeded error in the Claude API
- How to fix a Claude response that gets cut off mid-sentence
- How to reduce Claude hallucinations by grounding answers in your documents
- How to keep a long Claude conversation under the context limit
- How to stop Claude from calling tools when it should not
- How to handle a Claude Fable 5 refusal with a fallback model
- How to choose the right Claude model for cost and quality
- How to cut Claude API costs with prompt caching
- How to halve Claude costs for bulk jobs with the Batch API
- How to cap spend on a Claude agent with a task budget
- How to Debug an MCP Server That Will Not Connect
- How to Ask an Agent to Explain a Bug Before Fixing It
- How to Roll Back a Bad Deploy Quickly
- How to Fix Cursor Not Indexing Your Codebase
How to stop Claude from calling tools when it should not
Fix overtriggering by softening aggressive prompt language and tuning effort instead of adding more guardrails.
On recent Claude models a common surprise is the model calling a tool too often, like spawning a search or a subagent for something it could answer directly. The usual cause is prompt language written for older, more reluctant models. Newer models follow instructions much more literally, so all-caps demands now overtrigger. The fix is to dial the language back, not to pile on more rules.
- Access to the system prompt and tool descriptions
- An example request where the wrong tool fired
- The Anthropic SDK to re-test after each change
Step 1: Find the aggressive instructions
Scan your system prompt and tool descriptions for phrasing meant to overcome old reluctance. Lines like CRITICAL: you MUST use this tool, or default to using the tool, or if in doubt use the tool, now cause overtriggering.
Step 2: Soften the language
Replace the demands with plain, conditional guidance that states when the tool applies. Describe the trigger condition rather than ordering the model to always act.
Step 3: Put the trigger in the tool description
The tool's own description is a strong lever. Make it prescriptive about when to call, not just what it does. This gives measurable lift on whether the model reaches for the right tool at the right time.
{
"name": "search",
"description": "Search the web. Call this only when the user asks about current prices, recent events, or anything not already present in the conversation.",
"input_schema": {
"type": "object",
"properties": { "query": { "type": "string" } },
"required": ["query"]
}
}Step 4: Re-test on the failing case
Run the exact request that misfired. The model should now answer simple questions directly and reserve the tool for cases that actually need it.
Result: after replacing the all-caps demands with conditional guidance and moving the trigger into the tool description, the assistant stopped firing a web search on trivial questions and only searched when the answer genuinely required fresh data.
Watch related tutorials
12:36
18:52
22:40
7:18
1:42:18
28:14New guides in your inbox
Fresh step-by-step how-to guides as we publish them. One email a week, no more.