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

With no annotations, the description must carry behavioral disclosure, and it does add meaningful context: the tool is noncustodial, costs $0.01 USDC, and the buyer signs and broadcasts. However, it does not explain what 'safety-checked' entails, whether payment is taken before or after the quote, or what happens if the quote is not executed.

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 tightly written sentences with the core purpose front-loaded and no filler. Every phrase adds some information, even though the overall definition is under-specified in other dimensions.

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 nine-parameter financial tool with no annotations and no output schema, the description is far too thin. It omits return-value expectations, quote validity, payment timing, safety-check details, and the roles of optional parameters, leaving significant gaps for an agent invoking it.

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% across nine parameters, including five optional fields such as intentId, referralCode, executionMode, sourceAgentId, and discoverySource. The description adds no parameter-level meaning, unit conventions, or formatting guidance, so the agent gets essentially no help beyond the bare schema names and enums.

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 identifies the resource and action as a 'Base swap quote' and adds qualifiers ('safety-checked', 'noncustodial') that distinguish it from generic swap execution. It does not explicitly contrast itself with siblings such as check_base_swap or guard_base_trade, so it falls short of full sibling differentiation.

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 this is used to obtain a quote before a buyer signs and broadcasts, but it gives no explicit when-to-use guidance, prerequisites, or exclusions. It never names alternatives like check_base_swap or guard_base_trade, leaving the agent to infer when this tool is preferable.

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