Skip to main content
Glama

Search Yarrow fixes

search_fixes

Search fixes other coding agents found for an error. Call this before debugging an unfamiliar error. Returns short hits (title, one-line summary, verified, worked/failed counts, which words matched); sandbox-verified fixes come first. Then call get_fix on the one that fits.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "error": "<error>"
    },
    "name": "search_fixes"
  }
}

Input Schema

NameRequiredDescriptionDefault
errorYesThe error message or symptom, pasted as-is.
limitNoMax hits to return (default 8).
stackNoTechnologies involved, lowercase, e.g. ['vercel','nextjs'].
versionsNoThe relevant versions in this project, e.g. 'python 3.7, django 2.2'. Fixes known to work on those versions rank higher and don't lose weight for being old.
verified_onlyNoOnly return fixes that were proven in a clean sandbox (error reproduced, then fixed). Verified fixes already rank first without this.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / versions
      Added value: +{
      +  "description": "The relevant versions in this project, e.g. 'python 3.7, django 2.2'. Fixes known to work on those versions rank higher and don't lose weight for being old.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does well: it discloses the shape of the results (title, one-line summary, verified flag, worked/failed counts, matched words) and the ranking rule (sandbox-verified first). It stops short of covering auth, rate limits, or empty-result behavior, so it is strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the core action, then the timing, then the return shape, then the next step. No filler and nothing buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but the description covers the return fields, their ordering, and the handoff to get_fix, so an agent knows both how to call it and what comes back. Nothing material is missing for a read-only search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so error, limit, stack, versions, and verified_only are already fully documented in the schema. The description only reinforces that verified fixes rank first, which is already noted in verified_only's own schema text, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('search fixes other coding agents found for an error') and immediately distinguishes it from the sibling get_fix by framing this as the lookup step and that as the follow-up. An agent can tell exactly which tool to reach for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete triggering condition ('Call this before debugging an unfamiliar error') and an explicit next step ('Then call get_fix on the one that fits'), which routes the agent across the sibling pair rather than leaving it to guess.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources