L50 UK Company Data

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds genuinely non-derivable behavior: the external data source (Companies House), per-call cost ($0.05), payment rail (USDC on Base) and protocol (x402). It does not say whether results are paginated or capped in total size, but the cost/auth disclosure is meaningful added context beyond the annotations.

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 tight sentences with zero filler, the substantive data scope front-loaded and the cost/payment caveat trailing. Nothing is wasted, though the absence of any clause addressing date-parameter choice is a content gap rather than a verbosity issue.

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 read-only, no-output-schema query tool with three parameters, the description covers the domain scope, source and cost, which is the minimum an agent needs. It still leaves open the return shape (grouped per company or flat), pagination, and the days-vs-since semantics, which matter for correct invocation.

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?

At 33% schema coverage the description must carry the load, and it only partly does: 'up to 20 UK companies' and 'since a date' map to numbers and since, but the `days` parameter is undocumented in both schema and description, and the likely overlap/precedence between `days` and `since` is left entirely unexplained. An agent has to guess how to choose between the two date parameters.

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-object set (director appointments, resignations, PSC changes) over a specific resource (UK companies) and names the source (Companies House). It is distinguishable from companies_new / companies_overdue, but the near-identical sibling companies_changes_feed is never mentioned, so the agent cannot tell from the description alone which of the two 'changes' tools applies.

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?

Scope constraints ('up to 20 UK companies', 'since a date') imply when the tool fits, but there is no explicit when-to-use/when-not-to-use guidance and no routing to companies_changes_feed or companies_changes_feed_sample. Usage must be inferred from the data scope rather than stated.

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

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

Annotations already declare readOnlyHint and openWorldHint, yet the description still adds genuinely useful behavior: a hard cap of 100 rows, daily refresh from Companies House, and a paid model ($0.10 per call in USDC on Base via x402). It omits what happens on payment failure or rate limits, and does not point at the free sample sibling, which would complete the picture.

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 dense sentences with no filler: scope and freshness first, then filter dimensions, then cost and payment rail. Every clause carries operational weight for an agent deciding whether to spend $0.10.

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 read-only feed with five optional parameters and no output schema, the definition covers scope, time window, cap, freshness and pricing. The main gap is return shape: with no output schema, the description could say roughly what a row contains beyond the change type.

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 40%, so the description carries partial burden. It maps filters to plain language ('town, postcode, industry and change type') and the 'Up to 100 rows' phrase hints at the max parameter, but it adds no syntax or format detail beyond what the enum and postcode description already supply, and never clarifies locality-versus-town naming.

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 pair (new director appointments, resignations, PSC changes), a fixed time window ('last 24 hours'), a geography ('UK', 'across all companies') and the filter dimensions. It does not name or differentiate itself from the close siblings companies_changes or companies_changes_feed_sample, so an agent cannot tell from this text alone which of the three to call.

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 implied by the 'last 24 hours' framing and the row cap, which suggest a daily-monitoring use case, but there is no explicit when-to-use, when-not-to-use, or reference to the sibling feed_sample or the broader companies_changes tool. The reader must infer routing from the tool name.

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

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

Annotations already cover safety (readOnlyHint) and open-world scope, so the description's job is to add traits: it discloses the hard 3-row cap, the daily refresh cadence, the UK geographic scope, and that the paid feed is the full-data counterpart. It does not describe the returned record shape, which matters since there is no output schema.

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, no filler, and the key constraint (free, max 3 rows) is front-loaded before the filter-parity note. Every clause carries information.

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 simple 4-optional-parameter read tool with no output schema, the description covers source, scope, row cap, and filter behavior. The remaining gap is the shape of the returned rows, which neither the description nor an output schema supplies.

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 50% — types and postcode are documented in-schema, while industry (enum only) and locality carry no text. The description adds only the pointer that filters match companies_changes_feed, which hints at filter parity but gives no semantics for the two undocumented parameters.

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 — returns up to 3 rows from the daily UK director and owner changes feed — plus the free-tier cap and the exact sibling whose filters it mirrors. An agent can distinguish it from companies_changes_feed and companies_changes without opening either schema.

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?

"Try before you pay" plus "same filters as companies_changes_feed" makes the evaluation use case and the paid alternative clear. It stops short of an explicit instruction such as "switch to companies_changes_feed when you need complete results," leaving that inference to the agent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely non-obvious behavior: a $0.10 per-call charge settled in USDC on Base via x402, plus a hard 10-result cap — an agent needs both before calling. It stops short of describing response shape or what happens when no filters are supplied.

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 sentences, with the resource and scope front-loaded and the cost/payment constraint appended as a distinct operational sentence. Every clause carries information; nothing is padding.

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?

Without an output schema, the description carries the return-value burden and partially does so by naming director, website check and email details. However, for a five-parameter tool with zero schema documentation, it leaves defaults, the recency window semantics, and unfiltered behavior unexplained.

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 0%, so all five parameters fall to the description. It maps town/postcode/industry to locality/postcode/industry but says nothing about 'max' (its default or cap semantics beyond 'up to 10') or 'days' (the recency window and its 1–30 range), leaving two parameters with no meaning anywhere.

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 resource and scope: newly registered UK companies from Companies House, capped at 10, filterable by town, postcode or industry. The 'newly registered' framing implicitly separates it from siblings like companies_changes and companies_overdue, but no sibling is named explicitly.

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 statement of when to use this versus companies_changes or companies_changes_feed, and no prerequisites. The only contextual guidance is operational (cost and payment rail), which is useful but not usage guidance.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses a hard result cap of 10 and, unusually, the commercial model — $0.20 per call settled in USDC on Base via x402 — which materially affects whether an agent should invoke it. It does not cover rate limits, pagination, or what happens with zero results.

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 tight sentences with zero filler, front-loading the result shape and follow-up usage before the cost caveat. Every clause carries information an agent needs.

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 read-only, filter-driven lead-gen tool with no output schema, the description usefully states the returned fields and the result ceiling. However, it never explains filter interactions or defaults (e.g. what mode/locality do when omitted), leaving gaps an agent must guess at before calling.

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?

With 0% schema description coverage, the description has to carry parameter meaning and only partly does: 'Up to 10' clarifies the max cap and 'overdue (or soon-due)' hints at the mode enum. Industry, locality, and dueWithinDays — including their defaults — are left entirely to the bare schema.

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 names a concrete resource — UK companies with overdue or soon-due Companies House accounts — and the payload it carries (director and email details), which separates it from sibling feeds like companies_new or companies_changes_feed. It omits an explicit verb, but the retrieval intent is unambiguous.

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?

'Leads for accountants' implies the intended audience and use case, but there is no explicit when-to-use framing, no named alternatives among the sibling company tools, and no statement about when this is inappropriate. Usage is inferred rather than stated.

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