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

Annotations already cover read-only/idempotent/closed-world safety, and the description adds real behavioral context beyond them: two-phase 'proposes execution' flow, no paid execution until a proposal is accepted, free to call, and the caution that routing catalogue IDs are not evidence publication IDs. The main omission is any note on latency, limits, or what a proposal response contains.

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?

Front-loads the core routing purpose, but the prose is dense, jargon-heavy, and relies on unexplained domain terms ('published taxonomy', 'governed semantic query', 'bounded corporate network/path'), with semicolon-packed clauses that slow comprehension. The final 'Free.' fragment is efficient but the middle sentences do not fully earn their length.

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?

An output schema exists so return values need not be described, and the proposal/acceptance model is covered. What is missing is enough parameter-level guidance to call it correctly (required question, optional place_slug) and any signal about how router results should be consumed or cited downstream.

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 description coverage is 0% for two parameters, so the description must carry their meaning and largely does not: 'question' is never discussed, and 'place_slug' is only obliquely gestured at by 'Route a place/kind'. It does not explain the required/optional split or how a place slug changes routing, which is exactly the gap the empty schema leaves.

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?

States a specific role — routing a question ('place/kind', 'dated figure', 'exact references') to the right downstream handler, and explicitly distinguishes proposal from execution. The resource is somewhat abstract (a router rather than a data tool), but an agent can tell it is the entry-point dispatcher rather than one of the concrete lookup siblings.

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?

Gives category-level triggers (place/kind, dated figure, corporate reference) and notes that it does not execute paid work and requires acceptance of a proposal, which is useful usage context. However, it never tells the agent when to use this router versus calling query_semantic, query_sql, or property_lookup directly — the key selection decision against siblings is left implicit.

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