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

Adds substantial context beyond the annotations: deterministic and offline, English-only, code-point offsets in the result, overlap resolution policy, and a per-successful-call price of $0.003 USDC via x402 on Solana with an HTTPS alternative endpoint. Pricing and payment requirements in particular are information the agent cannot get from annotation hints.

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?

One dense but front-loaded sentence capped by a short pricing/endpoint note. The taxonomy is long yet every clause maps to an actual capability, so little is wasted; it could be broken into structure for readability but is not padded.

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?

A read-only extractor with no output schema needs its return shape implied, and the description does that by promising normalised values and code-point offsets. Payment and endpoint details are covered. It leaves the exact result envelope (field names, confidence scores) unstated, a minor gap for a tool whose annotations already declare the safety profile.

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 100%, so all four parameters (including dateOrder and referenceDate semantics) are already documented. The description only echoes the 'type filter' and gestures at reference-date anchoring for relative expressions, adding little beyond the schema baseline.

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 ('rule-based entity and value extraction') and enumerates the exact taxonomy it covers, including normalisation rules for dates, times and money. An agent can predict the output classes precisely. It never names an overlapping sibling (contact_extract, ioc_extract, pii_detect, keyword_extract, url_links_extract), so differentiation is left to inference.

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?

No explicit when-to-use or when-not statement, but the taxonomy implicitly defines the use case: free-text scanning for dates, money, URLs, mentions, etc. Nothing tells the agent to prefer this over an ordered subset tool like contact_extract or pii_detect, so routing must be inferred from the type list.

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