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

With no annotations, the description carries the full burden and does disclose the critical trait: the tool is not yet served, so calling it produces no filing data and instead records a requirement. That is exactly the kind of side-effect disclosure an agent needs before invoking. It stops short of saying whether the call errors, returns an empty payload, or has any rate/side-effect cost.

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 clauses with the most decision-relevant fact ('not yet served') front-loaded, followed by what the tool would do and what a call actually accomplishes. No filler; only minor redundancy between 'roadmap probe' and 'not yet served'.

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 stub with no annotations and no output schema, the description covers the essential caveat, but leaves open what an agent observes on invocation (error vs. acknowledgement) and offers no guidance on filing_type values. Enough to avoid a wrong expectation, not enough to plan a workflow around it.

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 coverage is nominally 100%, so the baseline of 3 applies, but the schema descriptions are tautological (the field names repeated verbatim). The tool description adds nothing about what filing_type accepts or which Companies House filing categories are valid, so the agent learns no more than the field 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?

States a specific verb and resource (fetch and parse a Companies House filing into structured JSON) and immediately qualifies it as an unserved roadmap probe. An agent can tell this is about company filings rather than, say, sanctions or director data, though it is not differentiated from the closest sibling (uk_company_profile) which may also surface filings.

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?

'Roadmap probe, not yet served' plus 'Calling records the requirement' implies the usage: call it to register demand, not to obtain data. But it never says what to use instead when actual filing content is needed, and no sibling is named as the fallback.

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