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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly mentions the cost ('Costs one Read on an identified key'), the async nature ('Async — a ticket in ~1s, collected with get_answer'), and a prerequisite ('self-issue one free: POST /api/keys'). It also clarifies the scope (live tracked coverage) and the default behavior (shared state from recent answer), which adds transparency beyond the schema.

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 two sentences with zero fluff. The first sentence front-loads the core purpose and the key distinctions. The second sentence covers cost, async behavior, and the alternative for collecting results. Every sentence earns its place, and the structure is well-organized.

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?

For a tool with only 2 parameters and no output schema, the description covers all necessary aspects: purpose, scope, cost, async behavior, prerequisite, and the follow-up tool. It leaves no ambiguity about how to invoke it correctly or what to expect in terms of result collection. An agent has enough context to call this tool effectively.

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 50% (fresh has a description, question does not). The description adds meaning to both parameters: for 'question', the tool's purpose implies it should be a query about a tracked entity/event; for 'fresh', the description explains it 'Force a new synthesis instead of the maintained record's recent answer... default false — shared state is the default'. This compensates for the schema's missing description on question and enhances understanding of fresh beyond its basic boolean type.

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 clearly states the tool's purpose: 'Ask what the tracked record shows about a named entity or unfolding event: what changed, what the record holds now, and which sources corroborate it.' This is a specific verb and resource with an explicit scope. It also distinguishes itself by stating 'Not general knowledge or history — grounding is live tracked coverage,' which differentiates it from general-purpose Q&A and clarifies it is specifically about tracked records.

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 description implies when to use the tool: when you need live tracked coverage about an entity or event, not general knowledge. It also mentions that results are collected via get_answer, implying a workflow. However, it does not explicitly name alternative tools for cases like retrieving raw records (e.g., get_entity or get_record), nor does it state when NOT to use it beyond the general knowledge distinction. Still, the context is clear enough for an agent.

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