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

Annotations already indicate read-only, idempotent, and non-destructive behavior, and the description adds useful behavioral detail: three independent LLM perspectives, severity levels, Ed25519 signing, and on-chain publishability. There is no contradiction with 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 dense and front-loaded with the core audit capability, but it is a single block that ends abruptly mid-JSON example at 'chain' without closing the payload. The truncation and lack of formatting hurt scannability.

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?

The description provides enough to understand the audit inputs and outputs, and an output schema exists so return-value documentation is not required. However, it is not fully complete: accepted chain values and language options are not specified, and the POST example conflicts with the single string parameter in the schema, leaving the exact input serialization unclear.

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?

The schema only documents a generic input string with a Spanish description, while the tool description provides the meaningful structure: a JSON object with source/language or address/chain. This adds significant value beyond the schema, although the mismatch between the schema's string parameter and the described POST object creates some ambiguity.

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 (Solidity/Vyper smart contracts) and the function (multi-LLM audit with security, logic, and gas perspectives plus static pattern scan). It is clearly distinct from the sibling risk/intel tools, though it relies on a noun phrase rather than an explicit action verb.

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 intended use is implied by the audit terminology and by the two request shapes (source/language or address/chain), but there is no explicit when-to-use statement, exclusions, or comparison to alternatives. The sibling tools are unrelated, so the context is clear but guidance is left to inference.

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