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

Beyond the readOnly/idempotent annotations, the description discloses significant behavioral traits: it is a paid call priced $0.02 over x402 on Base, requires an x-credit-token header for unlimited calls, offers 1 free call/day per tool, needs no wallet or API key, and reads live from the NEAR RPC. It also reveals the GO/HOLD/STOP decision logic. No claim contradicts the annotations.

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 front-loaded with the core question and verdict, then flows through decision rules, supplement data, and operational details. It is longer than average, but every section earns its place — pricing and auth details are directly actionable for an agent deciding whether to call. The key-scanning mechanism explanation is slightly wordy but not wasteful.

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-value documentation is covered structurally. The description supplies everything else an agent needs to decide and invoke correctly: the decision taxonomy, input requirements, pricing and payment mechanics, data source, and failure conditions (paused, no contract, non-NEP-141). Nothing critical is missing.

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 100% with a single parameter already described as 'NEAR token contract account'. The description reinforces that the token must be a NEP-141 contract and that invalid inputs yield STOP, which adds functional context, but it does not add format or syntax detail beyond the schema. Baseline 3 is appropriate.

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 opening line 'Who can change a NEAR token's contract? GO / HOLD / STOP' states a specific verb (assess contract-control safety) and resource (NEP-141 token on NEAR) with a concrete output taxonomy. This clearly differentiates it from generic siblings like token_info, token_price, and token_risk, which report metadata or risk scores rather than who controls the contract.

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 gives an explicit trigger condition — 'Before an agent takes a NEP-141 token on NEAR' — and defines when the tool is not applicable ('paused, no contract or not NEP-141 → STOP'). However, it does not name alternative sibling tools to use instead, so the when-not guidance is implicit rather than explicit.

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