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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description correctly aligns with these. Beyond annotations, it adds valuable behavioral context: the data is a 'bounded, self-hosted mirror' (suggesting limited scope or coverage) and explicitly states that licensed CUSIP identifiers are not exposed. It also mentions 'snapshot hash and provenance' in returns, giving insight into data integrity. This goes beyond the annotation safety profile.

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 concise and well-structured: it opens with the core purpose, follows with the return value summary, provides concrete usage examples, and ends with a limitation. Every sentence earns its place; there is no fluff or redundancy. The front-loading of purpose and the clear examples make it easy for an agent to process quickly.

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?

Given the tool has 4 parameters, 100% schema coverage, and no output schema, the description provides sufficient context: it explains what the tool returns (list of fields), clarifies usage, and notes a key limitation (CUSIP exclusion). It does not specify the exact response structure or error handling, but that is not strictly necessary for a read-only search tool with well-documented parameters. The description is complete enough for an agent to call it correctly.

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 every parameter (query, limit, offset, response_format) already has a clear explanation in the schema. The description adds minimal additional meaning beyond what the schema provides—it repeats the query semantics ('Ticker fragment or issuer-name phrase') and mentions pagination indirectly via 'pagination' in the return list. Since the schema carries the heavy lifting, a 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 description states a specific action ('Search ticker symbols and issuer names') and identifies the resource ('LiveDataLink's bounded, self-hosted mirror of official SEC fails-to-deliver files'), clearly differentiating it from sibling tools like sec_ftd_compare, sec_ftd_history, sec_ftd_latest, and sec_ftd_top, which handle other aspects of FTD data. It also lists the returned fields (symbols, names, hosted coverage, counts, etc.), making the tool's function unmistakable.

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 provides concrete usage examples ('find the FTD ticker for GameStop', 'which SEC fail records mention Tesla?') and explicitly states a primary use case ('resolve a symbol before a lookup'), which guides the agent on when to invoke this tool. It also gives a clear exclusion ('It does not expose licensed CUSIP identifiers'), preventing misuse. However, it does not explicitly mention sibling tools or when to prefer them, though the context is implied by the search-focused examples.

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