Analysis of 500 agent runs reveals agents consistently misuse the search_issues MCP tool by passing full bug descriptions as the query parameter (e.g., 'The payment service is throwing NullPointerException when processing refunds for international orders'). The tool's description reads: 'Search GitHub issues by providing a search query.' The tool functions correctly when given proper GitHub search syntax but returns poor results for natural-language queries. Which tool refinement MOST directly addresses this misuse at the definition level?
Select an answer to reveal the explanation.
Short Explanation and Infographic
If 500 agents all misuse the same tool the same way, the tool's instructions are the problem — not the agents. A description that says 'provide a search query' is an open invitation to treat it like Google. Rewriting it with format constraints, anti-pattern warnings, and a hard character limit closes the ambiguity gap where the misuse lives.
Full explanation below image
Full Explanation
Tool misuse patterns at scale are almost always symptoms of underspecified tool definitions, not model capability failures. LLMs fill ambiguity with the most statistically plausible behavior from their training — which for a 'search' tool is natural language input, because most search interfaces accept it.
Effective tool definition refinement uses three mechanisms simultaneously:
1. Precise format specification: '2-5 keywords in GitHub search syntax' sets a quantified expectation. Mentioning GitHub search syntax (which uses structured operators like label:, is:, author:, milestone:) further constrains expected input beyond just 'fewer words.'
2. Explicit anti-pattern exclusion: 'Do NOT pass full sentences' directly counteracts the specific behavior 500 agents exhibited. LLMs respond strongly to explicit exclusion statements because they override the natural-language bias that the training distribution creates.
3. Runtime input validation: A character limit of 100 enforced server-side creates a feedback loop — when an agent generates a long query, the tool returns a descriptive error ('Query too long — provide 2-5 keywords only') that the agent can act on immediately in the same run.
Option A (pre-processing wrapper) compensates for the bad input rather than fixing the root cause. The agent continues generating incorrect input; the wrapper hides this from visibility and never teaches the agent the correct behavior. Option C (second tool) legitimizes the incorrect behavior pattern rather than correcting it. It also increases the agent's tool selection burden and creates ambiguity about when to use which tool. Option D (fine-tuning) is disproportionate investment for a single tool's misuse — tool definition improvement is faster, more targeted, and immediately effective without model retraining. Fine-tuning is appropriate when the model lacks capability, not when the tool definition lacks precision.