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

The description goes far beyond annotations by disclosing the exact answer sources (ratified spec sheet with row citations plus live stock/services reads), that no model-generated content is involved, that answers include goods ids, variants, preview images, owner descriptions, and per-item size_charts, and that untaught questions result in an honest refusal that gets recorded. It even warns against reading fit measurements off another row, which is critical behavioral context an agent must know to use the answer correctly.

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

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

The description is a single dense, run-on paragraph packed with nested parentheticals and em-dash interruptions. While nearly every clause carries useful information, the lack of sentence-level structure makes it harder for an agent to parse quickly, and the opening purpose statement is immediately buried under highly detailed size_chart mechanics. It is information-dense but not concisely structured.

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

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

Because there is no output schema, the description carries full responsibility for explaining what the tool returns. It does so thoroughly: cited rows, live stock/services data, goods row fields (ids, variants, preview image, description, size_chart), refusal behavior, and the fit-measurement ownership rule. An agent has enough context to invoke the tool and interpret its answer correctly.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds meaningful context beyond the schema: it clarifies that 'question' is in plain words, provides example phrasings, and hints at the answer surface (stock, sizing, owner descriptions) that shapes what a good question targets. This is more than the schema alone gives, so it earns above the baseline.

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

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

The description names a specific verb ('ask') and resource ('a shop's brain'), and anchors it with concrete example questions. This clearly distinguishes it from siblings like concierge_document or market_search, which are about retrieving documents or searching the marketplace rather than asking a shop-specific question in plain words.

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

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

The examples ('is this turf good for dogs', 'does the relaxed tee run small') imply when to use this tool, and the refusal behavior tells the agent what to expect when the shop lacks an answer. However, there is no explicit guidance about when to prefer a sibling tool (e.g., concierge_document or market_search) or any stated exclusions, leaving the routing decision largely to inference.

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