Agent Tools UK

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

Goes well beyond the annotations by disclosing error semantics (400 unsupported pair, 422 conversion failed), the return behavior, and especially the payment model ($0.02 USDC per call via x402), which an agent cannot infer from readOnlyHint/idempotentHint. This is exactly the kind of context annotations don't carry.

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?

Front-loaded with purpose, then formats, usage, parameters, return, errors, and price in a logical order. The format enumerations are long but essential for a conversion tool; the only mild slack is the compressed multi-clause parameter sentence.

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 correctly states it returns the converted file and adds error codes and pricing. Together with the fully-covered schema, an agent has enough to invoke it correctly; minor gaps like supported size limits per conversion are not critical.

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 100%, so the schema already documents all four parameters including the url-or-base64 mutual exclusion and the 20 MB limit. The description's restatement of "{url} or {base64}, plus filename (with extension) and to" adds little beyond what structured fields provide, so baseline 3 applies.

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 (Convert) and resource (office documents and images) with an explicit format matrix in both directions. The breadth of the format list clearly distinguishes it from narrower siblings like html_to_pdf, which is a subset of this tool's scope.

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?

"Use when a user or system needs a file in a different format" gives a clear selection condition. It stops short of naming when NOT to use it or routing to the narrower alternatives (e.g. html_to_pdf for HTML), so it lacks explicit exclusions.

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?

Goes well beyond the annotations (which only cover readOnly/idempotent/openWorld/destructive) by disclosing the rendering engine, the 2 MB HTML ceiling with the 413 error, 400 on missing input or private URL, and the $0.01 USDC x402 payment requirement. Those are exactly the operational facts an agent cannot infer from the schema or hints.

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?

Front-loads what the tool produces and when to use it before invocation details, errors and pricing, with essentially no filler. The final sentence is a dense catch-all bundling return value, two error codes and a price, which slightly hurts scannability.

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 4-param tool with no output schema, the description covers the return value ('Returns the PDF'), input combinations, the enum space, failure modes and cost. Nothing an agent needs before invoking it is missing.

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 only 50%, with format and landscape undocumented in the schema, but the description compensates by enumerating the accepted formats (A4, Letter, A3, A5, Legal) and confirming landscape plus the html-XOR-url rule. It adds real meaning over the structured fields, though defaults and the XOR constraint's enforcement are left implied.

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+resource (HTML/web page → print-quality PDF) and concretely names the output artifact and renderer ('rendered by Chrome with backgrounds and CSS'), which implicitly separates it from siblings like webpage_to_markdown or screenshot_webpage. It never names an alternative sibling explicitly, so it stops short of a 5.

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?

Gives a clear use condition: 'Use when you need to hand a person a polished, printable document,' plus the intake shape ('Send {html} or {url}'). There is no explicit when-not or named alternative for the case where markup or a screenshot is wanted instead, so it is context without exclusions.

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 the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial behavioral detail on top: the text-layer fallback and its exactness benefit, a 20 MB / 20 page ceiling, error codes 400 and 413, the x402 payment requirement at $0.01 USDC per call, and the return shape. This is unusually rich disclosure for an annotated tool.

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?

Front-loads purpose, then fallback behavior, usage contexts, input form, hard limits, return shape, errors, and price in a tight sequence. Every clause carries information an agent needs; there is no filler.

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 compensates by naming the return object {text, method, pages}. Limits, error codes, cost, language handling, and the text-layer fallback are all covered, so an agent has everything needed to invoke and interpret the call.

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 100%, so the baseline is 3, but the description adds the lang default ('default eng, e.g. eng+fra') which the schema does not state, and restates the url-or-base64 requirement alongside the size limit. The addition of a default value is genuine value beyond the 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?

States a specific verb and resource ('Read the text from a photo, screenshot, scan or scanned PDF') and immediately scopes it with '(OCR)', which separates it from siblings like pdf_tables_to_json, convert_file, and transcribe_audio. An agent can identify the tool without opening the 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?

'Use when text is only available as an image: receipts, letters, forms, signs' gives clear positive conditions, and the fallback note ('If the PDF already has real text, that is returned instead') implicitly signals when the tool is unnecessary. It does not name an alternative sibling for the text-layer case, so it stops short of explicit routing.

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 readOnly/idempotent/non-destructive, and the description adds operational constraints well beyond them: 'Max 20 MB, first 50 pages', a truncation flag, explicit error codes (400 not a PDF, 413 too large), and a per-call price with the x402 payment scheme. That is exactly the extra context agents need before invoking.

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?

Front-loads purpose, then constraints, then return shape and errors in a tight sequence with no filler sentences. Slight redundancy between the schema's param descriptions and 'Send {url} or {base64}' costs a point.

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?

No output schema exists, and the description supplies the return shape ({pages, tables:[{page, rows}], truncated}), limits, error behavior, and payment requirements. An agent has everything needed to call and interpret the result.

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% and both parameters already document the url-OR-base64 mutual exclusivity, so the baseline applies. The description's 'Send {url} or {base64}' largely repeats the schema, though the 20 MB limit for base64 adds a small amount of binding.

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 precise verb+resource ('Extract every table from a PDF ... as rows of cells in JSON') and adds the returned granularity ('with the page number of each table'). This clearly separates it from siblings like ocr_read_text (raw text) and convert_file (format conversion).

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?

Gives a concrete when-to-use context ('numbers from financial statements, invoices, price lists or reports that are locked in a PDF'), which is more specific than most. It stops short of naming alternatives or exclusions, e.g. when to prefer ocr_read_text for scanned PDFs, so it is clear-but-not-routing.

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?

Goes well beyond the annotations by disclosing the real Chrome rendering engine, the PNG output format, specific failure semantics (400 on bad/private URL, 504 on 30s timeout), a per-call price ($0.01 USDC x402), and the default viewport width. These are operational traits the read-only/idempotent hints cannot convey.

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?

Front-loads purpose, then usage, options, error codes, and price in tight sentences. 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?

For a screenshot tool with no output schema, the description covers purpose, return format (PNG), usage triggers, parameter defaults, error conditions, and cost. An agent has everything needed to call it correctly and interpret failures.

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 already 100%, but the description still adds the default width of 1280, which the schema does not state, and clarifies 'full=true for the whole page.' That marginal value over the schema justifies above the baseline.

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 ('Render any public web page... return a PNG screenshot'), so the agent knows exactly what it produces. It does not differentiate from siblings like webpage_to_markdown or website_status_check, which overlap on the 'inspect a page' use case, so it stops short of a 5.

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?

Provides concrete triggers: 'see how a page looks, check a layout, capture visual evidence, or read content that only appears after JavaScript runs.' It lacks explicit when-not guidance or named alternatives (e.g. use webpage_to_markdown for text extraction), so it is clear context without exclusions.

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 the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description adds substantial operational context beyond them: the 15-minute limit, 20 MB base64 cap, automatic language detection, specific error codes (413 over-length, 422 not audio), and the $0.03 USDC x402 payment requirement. This is exactly the kind of cost/limit disclosure an agent needs before invoking.

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?

Front-loaded with capability and limits, then inputs, then return shape, then errors and price. Every clause carries operational information (formats, duration cap, cost) with no filler.

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?

Although no output schema exists, the description spells out the return shape ({language, duration, text, segments with start/end times}), documents both failure codes, and states the price. For a three-parameter, zero-required transcription tool, nothing needed to call it correctly is missing.

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 100%, so the baseline is 3, but the description reinforces the url-or-base64 choice, flags language as an optional 2-letter code, and ties the format list and size constraints to what the parameters accept. It adds modest value over the schema rather than relying on it entirely.

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+resource (transcribe speech from an audio/video file), names the engine (Whisper), enumerates supported formats, and caps length at 15 minutes. An agent can immediately distinguish this from siblings like ocr_read_text or convert_file.

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?

"Use when you need the words from a voice note, meeting, podcast clip or video" gives clear positive context for when to reach for this tool. It stops short of naming alternatives or exclusions (e.g. when to prefer ocr_read_text for image-borne text), so it is clear but not fully routing.

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 readOnly, idempotent, openWorld and non-destructive, so safety is covered; the description adds genuinely new operational context in the error contract (400 invalid number, 404 not found) and the paid-call requirement (x402, $0.005 USDC per call), which an agent must know before invoking. It omits rate limits and response/latency behavior, but the additions are meaningful.

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?

Front-loaded with the action and identifier, followed by the payload of returnable fields, then usage, errors and price — each element earns its place. The field enumeration is long but directly substitutes for the absent output schema, so the length is justified rather than padded.

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 takes on the burden of describing returns and does so field by field, plus error codes and the payment model. Nothing material an agent needs to call this correctly – input, outcome, failure modes, cost – is missing.

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 100% for the single 'number' parameter, and the schema already supplies the format example and the leading-zeros note. The description only restates 'by company number', adding essentially nothing beyond the schema – baseline 3 for a fully documented parameter set.

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 ('Check a UK company on the official Companies House register by company number') and enumerates exactly what is returned (name, status, type, incorporation date, address, SIC codes, accounts, charges, insolvency, directors). It is unmistakably distinct from every sibling tool, all of which concern file/web/audio conversion or postcode and website checks.

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?

Gives explicit use cases – supplier checks, due diligence, confirming a business is real and active – which sets the intent clearly. It does not name a when-not condition or an alternative, but no sibling operates in this domain, so there is no real competing tool to route away from.

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 readOnly/idempotent/openWorld/non-destructive, and the description adds genuinely new behavioral facts: the x402 payment requirement and cost ($0.001 USDC per call), the error contract (400 invalid format, 404 not found), and input normalization ('Spaces optional'). This is meaningful context an agent could not derive from the annotations alone.

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?

Front-loads the purpose and return fields, then the when-to-use cases, then the format/error/billing details. Every sentence carries distinct information (outputs, triggers, normalization, errors, price) with no filler or repetition.

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 results and does so by listing the returned geography fields. It also covers error codes and the payment model, so an agent has everything needed to call and interpret this tool.

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 100% for the single postcode parameter, so the baseline is 3, and the description adds the non-obvious normalization rule that spaces are optional (e.g. 'SW1A1AA' vs 'SW1A 1AA'). That is real added meaning about accepted input formats, though no further constraints are described.

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+resource ('look up any UK postcode') and enumerates the returned attributes (lat/long, council, county, ward, parish, constituency, region, country). It also names the data source (official ONS data), which cleanly separates it from the unrelated siblings like uk_company_check.

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?

Gives explicit usage contexts: 'place a UK address on a map, work out which council or MP covers it, or check a postcode is real.' That is clear when-to-use guidance, though no when-not-to-use case or named alternative is offered (none of the siblings are plausible substitutes anyway).

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 annotations (readOnly/openWorld/idempotent/non-destructive), it discloses cleanup behavior (menus, ads and footers removed), the exact return payload keys, specific error codes and their meanings, and a per-call price of $0.003 USDC via x402. This is exactly the kind of behavioral detail annotations cannot carry.

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?

Front-loaded with what it does and what it returns, then usage guidance, then output shape, errors and price. Every sentence carries distinct information; no filler.

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 compensates by enumerating the returned JSON fields and enumerating failure modes (400/422/502) plus cost. An agent has everything needed to invoke it and interpret results.

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?

Only one parameter with 100% schema description coverage, and the schema already states "http/https, public". The description reinforces the public-URL constraint (400 for bad or private URL) but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 (fetch) and resource (public web page) plus the exact transformation and output (main article as clean Markdown with title, byline, excerpt). This clearly separates it from siblings like screenshot_webpage, html_to_pdf and convert_file, which operate on other formats or produce other artifacts.

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?

"Use when you need to read, summarise or quote a web page cheaply without parsing HTML yourself" gives a clear positive trigger and implicitly contrasts with HTML-parsing alternatives. It stops short of explicitly naming sibling tools or stating when-not to use it (e.g. vs. screenshot_webpage for JS-heavy or paywalled pages).

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?

Goes well beyond the annotations by disclosing a non-obvious return contract ('a site that is down still returns 200 with up:false and the error'), the failure mode and status code for bad/private URLs, and the per-call price with the x402 payment scheme. Annotations only cover the safety profile; the description carries the operational detail.

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?

Front-loaded with the capability and returned fields, then usage triggers, then edge-case/error/pricing notes. Every clause earns its place and nothing is repeated from the schema or annotations.

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 compensates by naming the return fields and the down-site behavior, plus error and cost semantics. An agent has everything needed to call and interpret this tool 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 coverage is 100% with a single documented 'url' parameter, so the schema already does the work. The description adds no format, scheme, or constraints beyond the schema's 'http/https' note, making the baseline 3 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?

States a specific verb and resource ('check whether a website is up') and enumerates exactly what is returned: HTTP status, response time, redirect chain, and SSL certificate validity/issuer/expiry. This cleanly separates it from siblings like screenshot_webpage or webpage_to_markdown, which fetch content rather than probe availability.

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?

Gives three concrete triggering scenarios (monitoring, diagnosing a broken link, expiring certificate), which is clear context. It never names an alternative sibling or a when-not-to-use condition, so it falls short of the explicit routing a 5 requires.

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