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

The description discloses the important behavioral constraint that the session_token must match the one from the original suggestion and that the operation is scoped to quote, which adds context beyond the annotations. It does not explain whether resolving a suggestion consumes it, whether repeated calls are allowed, or what the response contains, but given the annotations it is not a serious contradiction.

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 very short and contains no filler. 'Scope: quote' adds a useful constraint, and the session_token caveat is front-loaded. The main structural weakness is that it is a fragmentary phrase rather than a clearly organized sentence, and it repeats the title almost verbatim, but it remains economical.

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 two-parameter tool with no output schema and limited annotations, the description provides the core purpose, session-token constraint, and quote scope, which is enough to attempt invocation if the agent already has a place_id and session_token from a prior suggestion. It is incomplete about required parameters, return value, and error behavior, so it is adequate but not fully self-sufficient.

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?

With 0% schema description coverage, the description must compensate for the bare parameter names. It partially does: 'suggestion' implies that place_id is a suggestion identifier, and 'same session_token' clarifies that session_token must match the prior suggestion session. It still does not state that both parameters are effectively required or define expected value formats, so the compensation is minimal.

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 uses a specific verb ('Resolve') and a concrete object ('a suggestion to a full address'), and it adds the key constraint 'same session_token.' In the sibling list, suggest_addresses is the natural counterpart, so the tool's role is fairly clear, though it does not explicitly name that sibling or define what a 'suggestion' refers to.

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 phrase 'same session_token' and 'Scope: quote' imply that this tool should be used within an active quote session after obtaining a suggestion, and with the same session token used for that suggestion. However, it does not explicitly state when not to use it or point to an alternative for other flows, so usage guidance is mostly implied rather than stated.

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