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

Annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true) already signal mutation risk and an open capability set, so the bar for added value is met by the description's extra behavior: it 'verifies results' and 'asks for missing information instead of inventing it,' which sets accurate expectations about follow-up questions and honesty guarantees. It also adds the tenant-scoped constraint. No contradiction with annotations, though the destructiveHint is never echoed in prose.

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?

Three sentences, each earning its place: core function, behavioral guarantees, and routing caveat. Front-loaded and free of fluff or schema repetition.

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 an open-world dispatch tool with no output schema, the description covers the invocation contract, scope, verification behavior, and the search-first workflow. The main gaps are the undocumented history parameter and no account of return values, but both are minor given the tool's delegation model and the context signals provided.

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%, so the description must compensate for the two parameters. It implies prompt is a natural-language request for a desired capability and hints that incomplete prompts will trigger clarification, but it never names or explains the history array or how it should be populated. Partial compensation at best.

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 clear verb+resource pair: 'Use any AI-ready LocalTry feature' through the 'live capability registry,' and clarifies this is a generic dispatch tool where 'LocalTry chooses and executes its own tenant-scoped domain action.' It differentiates from the sibling search_localtry_features by instructing the agent to search first when unclear. Not a 5 because the concrete domain-action space is left open and no explicit contrast with the run_workflow sibling is drawn.

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 one explicit routing rule: 'Search the feature registry first when the requested capability is unclear,' which points the agent to the relevant sibling search_localtry_features as a prerequisite step. The description implies this tool is the execution step that follows registry lookup, but it never states when to avoid this tool or how it compares to run_workflow. Useful but partial guidance.

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