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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description goes beyond them with genuinely non-obvious context: the call costs $0.03, is paid in USDC on Base via x402, meaning a paid/authenticated request path the agent must anticipate. It does not disclose failure behavior for unknown numbers or any rate limits, which keeps it short of a 5.

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 sentence front-loads the core purpose and then lists contents, with the pricing sentence appended. Every enumerated field earns its place by telling the agent what data comes back, though the list is long enough that a bulleted or comma-chunked structure would scan faster.

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?

With no output schema, the description carries the burden of describing returns, and it does so field by field. It also covers the payment requirement. Missing only response shape/ordering and error semantics for an invalid or non-existent company number, which are minor for a read-only profile fetch.

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?

There is a single required parameter and schema description coverage is 100%, with the schema itself supplying format examples ('00445790 or SC123456'). The description adds no further meaning about the company number — no note on zero-padding, jurisdiction codes, or what happens if the number is malformed — so it sits at the baseline where the schema does the work.

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 retrieval verb and a tightly scoped resource ('Full profile of one UK company from Companies House'), then enumerates the exact payload: status, SIC/industry, accounts and confirmation statement dates with overdue flags, current directors with other appointments, PSCs, last 10 filings, charges and insolvency flags. That enumeration makes it distinguishable from siblings like companies_search (lookup) or companies_changes (filings only) without needing to name 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?

Usage is only implied by the phrase 'one UK company' and the requirement of a company number — an agent can infer this is for deep single-company lookups on a known number. There is no explicit when-to-use statement, no exclusions (e.g. 'use companies_search if you only have a name'), and no alternatives named, so routing still requires inference.

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