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

With no annotations, the description carries the full burden, and it does disclose two genuinely useful traits: the call is paid ($0.02 via x402 over HTTP) and the tool itself returns calling instructions. However, it omits what happens when no identifier is supplied, whether a payment/x402 handshake is required before any result, error behavior, and whether results are cached or live.

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?

Two short sentences with no filler, and the data-domain statement is front-loaded ahead of the payment caveat. The second sentence is terse to the point of ambiguity rather than verbose.

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 four-parameter tool with no annotations and no output schema needs the description to explain identifier requirements and return shape; instead it leaves both unstated and adds a confusing claim that the tool returns how to call the endpoint. The payment model is the only completeness win.

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 0% across four parameters, so the description must compensate and does not: cik, lei, name, and ticker are never mentioned, nor is the critical fact that all four are optional (so presumably at least one identifier must be supplied, or matching/priority rules apply). It adds no meaning beyond the bare property names.

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?

Names the resources (LEI records, SEC EDGAR registration) and the domain object (a company), but the second sentence muddies it: 'this tool returns how to call it' implies the tool is a discovery stub returning invocation instructions for a paid HTTP endpoint rather than the entity data itself. An agent cannot be certain whether a call yields records or metadata about how to obtain them.

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 guidance on when to choose this over siblings such as company_financial_facts, nor any exclusions or prerequisites. The only implicit signal is that it is entity-identity data rather than financial or sanctions data, which the agent must infer from the noun phrase alone.

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