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

Far exceeds what annotations provide. Discloses pricing ($0.015 USDC via x402), that calling returns an HTTP request and payment requirements rather than data, the LLM-vs-deterministic fallback, that results are type-checked with nulls for missing fields, char/property limits, and an accuracy caveat. This is exactly the behavioral context an agent needs.

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?

Dense but front-loaded with the cost and the input/output contract; each sentence carries distinct information (payment, fallback, limits, caveat, params, transport). Slightly run-on and packed, but virtually no wasted words.

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 paid x402 tool with an LLM/heuristic pipeline and no output schema, the description covers the critical gaps: the payment round-trip, output shape (clean JSON, nulls for missing), limits, and reliability caveat. Nothing essential for correct invocation 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?

With 67% schema coverage the description still adds meaning: it enumerates the params (text, schema as JSON string, mode=auto|heuristic) and adds constraints absent from the schema, notably 'schema <= 30 top-level properties (flat objects, arrays of scalars)' and the 6,000-char text cap. Not fully exhaustive, but it goes beyond the schema.

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 specific verb and resource ('Messy text + JSON Schema in, clean JSON out') and names the exact mechanism (LLM with heuristic fallback). An agent immediately understands this converts unstructured text into schema-conformant JSON, which no sibling tool does.

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?

Explains the internal auto/heuristic mode behavior and invocation transport ('GET query or POST JSON body'), but gives no explicit when-to-use guidance or criteria for choosing mode=auto vs mode=heuristic. Implied usage only, adequate but not directive.

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