x402-farm

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals a key technical behavior: 'Requests exit through a residential IP with a real browser, since Amazon rejects datacenter traffic.' This adds important context about how the tool operates and why.

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?

The description is concise (two sentences) and front-loaded with purpose and output. The pricing note is extra but relevant. The only structural issue is the misleading 'search term' phrase, which would ideally be removed or aligned with the schema.

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 one-parameter lookup tool, the description covers the output fields and use cases. However, the search term mismatch and lack of information about not-found or error scenarios leave gaps. Since there is no output schema, the description's partial return-field listing is helpful but incomplete given the schema discrepancy.

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?

The schema has one required parameter 'asin' with 0% description coverage. The description says 'by ASIN or search term', but the schema only supports ASIN, making the 'search term' part misleading. While the description identifies ASIN as a product identifier, it fails to clarify the single parameter and introduces ambiguity.

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 clearly states the tool's purpose: 'Look up an Amazon product by ASIN or search term' and lists the returned fields (title, price, availability, etc.). However, it mentions 'search term' as an input option, which is not reflected in the schema, creating slight confusion.

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?

The description explicitly names target use cases: 'tracking prices, monitoring competitors or verifying a listing before a purchase decision.' This provides clear context for when to use the tool, though it does not mention alternatives or 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?

With no annotations provided, the description carries full burden. It discloses that the tool collects fresh headlines, summarises them into a JSON brief with numbered sources, returns raw headlines for verification, and mentions the cost and payment method (x402/USDC). It does not go into rate limits or failure modes, but is fairly transparent for a read-like operation.

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?

The description is concise enough, front-loaded with the core purpose and output format. It includes cost and payment details, which are useful but slightly tangential to tool invocation. No redundancy; every sentence contributes context.

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?

The description explains the output structure and return payload well, which is helpful given the lack of an output schema. However, it omits parameter semantics, any prerequisites or limitations (e.g., supported languages, rate limits), and does not detail how the tool behaves with edge cases. For a tool with only 3 optional params, this is a moderate gap.

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%, so the description must compensate for the three parameters (q, gl, max_items). The description implies 'q' via 'send a topic' and hints at max_items via 'fresh headlines' but gives no explicit definitions or constraints for gl or max_items. An agent would likely struggle to set correct values without additional knowledge.

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 clearly states the tool's function: send a topic and receive a sourced news briefing with structured output (summary, key points with sources, open questions). It differentiates from siblings by explicitly claiming it replaces a two-call workflow (news search + summarisation), making its purpose 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?

The description provides clear context on when to use it: whenever an agent needs a sourced news brief, and explicitly mentions it replaces the alternative two-step process. However, it does not explicitly state when not to use it (e.g., when raw headlines without summary are needed) or name sibling tools like search_news, though the implication is strong.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It details that the page is fetched via a French residential IP and a real Chromium browser, and mentions pricing and payment method. This goes beyond basic purpose and is highly transparent.

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?

The description is two sentences, front-loaded with the main purpose, and each sentence adds essential information: output format, fetching method, and cost. It is concise and well-organized with no wasted words.

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?

Given there is no output schema, the description explains the return value ('clean markdown'), covers technical behavior (JavaScript rendering, residential IP), and includes pricing details. For a simple one-parameter tool, this is complete and covers all necessary contextual aspects.

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?

The schema has one parameter 'url' with no description and 0% coverage. The description adds 'Send a URL', which minimally clarifies the parameter's role, but does not specify format constraints or additional details such as required schemes. The description compensates only partially for the lack of schema documentation.

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 clearly states the tool's function: 'Send a URL and receive the main content of the page as clean markdown'. It specifies the resource (web page) and distinguishes from siblings like 'screenshot' or 'render' by focusing on content extraction.

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?

The description provides clear context on when to use the tool (fetching JavaScript-rendered content or bypassing datacenter restrictions), but does not explicitly mention alternative tools or exclude cases. The context is useful, but no direct comparison to siblings is given.

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?

With no annotations, the description carries full burden. It discloses key behaviors: uses residential IP to bypass blocks, uses an LLM for extraction, and costs $0.015/call via x402 USDC. It does not mention rate limits or error handling, but provides sufficient transparency for typical use.

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?

The description is concise (3 sentences) and front-loaded with the core purpose. It includes pricing and payment details, which add some length but are relevant. Could be slightly more streamlined by moving pricing to secondary position.

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?

Given no output schema and 0% schema coverage, the description covers input semantics and core mechanism. It lacks details on return format structure, error handling, and timeouts, but for a tool of this complexity it provides adequate completeness for typical usage.

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 description must compensate. It fully explains the two parameters: 'url' is a string, and 'fields' can be a comma-separated list or free-text schema (via ?schema=). It clarifies that output is clean JSON with requested fields, adding significant meaning beyond the basic 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 clearly states the tool extracts structured data from a URL using a residential IP and an LLM, outputting clean JSON. It differentiates itself from siblings like 'extract' by mentioning specific features (residential IP, cheap, Firecrawl-extract territory).

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?

The description provides clear context on when to use the tool (for structured extraction from any URL) and mentions pricing. However, it lacks explicit when-not-to-use guidance or alternatives among the many sibling tools, such as 'extract' or specialized scrapers.

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?

With no annotations, the description carries the transparency burden. It discloses pricing and payment method (x402/USDC), data sources (DVF, DPE, INSEE), and the 'one call' aggregation behavior. However, it lacks information on response format, error handling, or how to handle invalid addresses/surfaces, which is a gap for a complex analysis 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?

The description is two sentences and front-loaded with the key action and object. It efficiently packs a long list of analysis components and adds pricing info without fluff. Slightly long but well-structured.

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?

The description gives a solid high-level overview of what the tool returns and its data sources, but omits practical invocation details (parameter formats, output structure, failure modes). Given the tool's complexity and lack of output schema, more guidance would be needed for an agent to reliably use 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?

The schema provides zero description coverage for the two parameters (adresse, surface). The description mentions 'from its address' and 'per square metre', but does not explain expected formats (e.g., full address string, numeric surface without units). The agent must infer or rely on external knowledge to invoke correctly.

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 clearly states the tool's function as a 'Full investment analysis of a French property' and enumerates specific outputs (estimated value, median price per m², energy performance, risk exposure, demographics, rental yield). It distinguishes from siblings like fr_estimation-immo (estimation only) and fr_analyse-immo_partial (partial analysis) by emphasizing 'Full' and 'in one 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?

The description provides clear context: use when a comprehensive property investment analysis is needed, and highlights the convenience of one-call aggregation. It does not explicitly name alternatives or exclusion criteria, but the 'Full' vs partial distinction and listing of data sources imply appropriate use cases.

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?

No annotations are provided, so the description carries the full burden. It discloses pricing ($0.03/call via x402) and frames the tool as lite/cheap, which is useful contextual behavior. However, it does not explicitly state read-only nature, return format details, or potential error conditions, but for a simple analysis tool, the listed outputs give fair transparency.

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?

The description is highly concise and well-structured. It leads with the core purpose, then adds usage guidance, upgrade path, and pricing in a logical order. Every sentence earns its place with no redundant 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 tool with simple parameters and no output schema, the description covers the essential context: purpose, key outputs, usage guidance, and cost. The main gaps are parameter format details and explicit return structure, but the listed outputs provide a reasonable understanding. The tool appears complete enough for an agent to select and invoke it 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?

The input schema has two string parameters (adresse, surface) with zero descriptions. The description mentions 'French address' but does not clarify the format or expected values for adresse, nor does it explain that surface likely refers to area in square metres. With 0% schema coverage, the description should compensate but only provides minimal implicit hints, leaving the agent to infer.

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 clearly identifies the tool as a lite property analysis for French addresses, listing specific outputs (median price per sqm, estimated value, investment score). It distinguishes itself from the full 'fr_analyse-immo' sibling by explicitly positioning this as the cheap screening version. The verb 'analyse' and resource 'French property' are specific and 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?

The description explicitly states when to use this tool ('to screen a shortlist of addresses cheaply before committing to depth') and when to upgrade ('Upgrade to /v1/fr/analyse-immo for...'). It names the alternative sibling and contrasts their capabilities, providing clear usage boundaries.

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?

With no annotations, the description carries the burden. It discloses methodology (comparing live listings against DVF transaction data), return includes 'gap expressed in percent', and cost/payment ($0.05/call via x402 USDC). But it does not describe return structure, rate limits, permission needs, or edge cases. Some transparency is provided, but significant gaps remain.

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?

The description is concise and front-loaded: first sentence states purpose and key metric, second adds methodological detail, and pricing is appended cleanly. Every sentence earns its place with no fluff.

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?

The tool has no output schema and only two parameters with no schema descriptions. The description explains the concept but omits critical invocation details: return format (list? count? sorting?), parameter formats/examples, and error behavior. Without additional guidance, an agent may struggle to call this correctly despite knowing what it does.

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 description must compensate. It mentions 'French properties in an area' and 'asking price', but it does not clarify that cp likely means postal code, the expected format (e.g., 5-digit), or how city and cp interact. No examples or constraints are given, leaving the agent to guess parameter meaning.

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 clearly states the tool's function: 'Find undervalued French properties in an area' and defines 'undervalued' specifically via DVF sales comparison. This distinguishes it from sibling real-estate tools like fr_estimation-immo or fr_seloger by emphasizing price-gap percent against actual transactions.

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 context is implied: use this to find undervalued listings based on real transaction data. However, there is no explicit guidance on when to choose this tool over alternatives, nor any exclusions or when-not-to-use. The description does not name sibling tools or explain selection criteria.

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?

No annotations are provided, so the description carries the full burden. It discloses the data source (INPI national register), the specific returned fields (revenue, net income, share capital), the list of accounting periods, and the pricing/payment method ($0.06/call via x402 USDC). This is substantial behavioral info, though it omits error handling and validation details.

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?

The description is three sentences: purpose+source, returns+use case, and pricing. It is front-loaded with the core function, contains no redundant wording, and every sentence adds distinct value.

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 single-parameter tool with no output schema, the description covers the key return fields, source, and cost. It lacks details on SIREN validation, error cases, and the exact structure of the accounting periods list, but these are minor for a tool of this simplicity.

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?

The schema has zero description coverage for the 'siren' parameter. The description only says 'by SIREN' without explaining what SIREN is, its format (9 digits), or how to obtain it. This is minimal compensation for the low schema coverage; the agent must rely on external knowledge.

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 clearly identifies the resource ('Annual accounts and financial statements of a French company by SIREN') and the action is implied via 'Returns revenue, net income and share capital'. It distinguishes from sibling tools by emphasizing the INPI national register source, but lacks an explicit command verb like 'retrieve'.

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?

The description provides context about the data being from an 'authentication-gated source most public APIs cannot reach', implying a use case when other sources are insufficient. It also notes the agent can 'see both the figures and how current they are', suggesting a recency-checking subtask. However, it does not explicitly state when to use this tool instead of siblings or provide alternatives.

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?

With no annotations, the description carries the transparency burden and does more than repeat the name: it discloses the matching logic (activity code + geographic area), the output dimensions (size, age, status), and the fact that results are intended for ranking. It also mentions per-call pricing. It omits caveats like pagination or edge cases, but for a read-style lookup the core behavior is well disclosed.

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?

Three compact sentences: definition and outputs, target use cases, and pricing. The most important information is front-loaded and there is no filler or repetition of schema details.

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 2-parameter tool with no annotations and no output schema, the description covers purpose, algorithm, output fields, use cases, and cost. The main gap is operational detail: an agent still has to infer what values q and zone accept and how results are paginated or structured. It is adequate but not complete.

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?

The schema provides only bare names (q, zone) with 0% documentation coverage, so the description must compensate. It plausibly maps q to the French company and zone to the geographic area, but it never labels the parameters explicitly or states expected formats (e.g., SIREN, name, city, postal code). This is partial compensation, not complete.

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 opens with a specific verb and resource ('Identify the competitors of a French company') and immediately defines the semantics: businesses sharing the same activity code in the relevant geographic area. It also names the returned dimensions (size, age, current status), which distinguishes it from generic or sibling data-lookup tools.

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?

It explicitly states the intended use cases: market analysis, competitive benchmarking, and sales territory planning on the French market. It does not name alternative tools or say when not to use it, so it stops short of a 5, but the context is clear.

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?

No annotations are present, so the description carries full burden. It discloses pricing and payment method (x402) and the data source (official registries), but does not mention rate limits, data freshness, or any side effects. It avoids contradiction but provides limited behavioral 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?

The description is a single, information-dense sentence with a logical flow: main deliverable, then components, then use-case justification, then pricing. It is efficient and front-loaded, though the long list makes it slightly less scannable than ideal.

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 complex tool with no output schema, the description lists what the dossier includes, which partially covers return expectations. However, it omits input format and any prerequisites (e.g., company must be French, identifier type), leaving notable gaps in completeness.

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?

The input schema has a single parameter 'q' with zero description coverage, and the description does not indicate what q should contain (e.g., SIREN number, company name, or address). This is a critical gap for a tool with only one parameter, and the description fails to compensate.

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 uses a specific verb ('assembled') and resource ('due-diligence dossier on a French company'), listing concrete components (legal identity, directors, beneficial owners, accounts, insolvency, risk). It clearly distinguishes from siblings like fr_kyb or fr_entreprise-360 by emphasizing the holistic, one-call 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?

The description gives clear usage context: it replaces a paid solvency report and hours of manual research, signaling when to choose this tool for a comprehensive French company investigation. It does not explicitly exclude alternatives or state when not to use it, but the context is sufficiently clear.

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?

With no annotations, the description carries the full burden. It adds operational detail (cost of $0.080002/call via x402 USDC) and data provenance ('registry-backed'), but it does not disclose side effects, permissions, rate limits, or error behavior. It implies read-only behavior via 'returns' but does not state it explicitly.

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?

The description is two tight sentences plus a cost note. The purpose and use case are front-loaded, and every sentence adds value without fluff.

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?

It covers the core purpose and return fields, but the mismatch between described inputs (SIREN/website) and the schema (name/city), plus the lack of output-format details, leave gaps an agent needs when invoking the 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 description coverage is 0%, so the description must compensate. It mentions 'a name, a SIREN or a website' as inputs, but the schema only has 'name' and 'city'. It does not explain how SIREN/website should be passed, and the 'city' parameter is entirely unexplained, leaving an agent to guess.

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 states a specific action ('Enrich a French company record') and enumerates exact outputs (verified legal identity, activity code, headcount bracket, headquarters address, current status), making the tool's purpose clear and distinct from sibling company-analysis tools.

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?

It gives a clear use case: turning a partial CRM row into a complete, registry-backed record. It does not name alternative tools or explicitly state when not to use it, but the context is unambiguous enough for an 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?

With no annotations, the description carries the full burden. It usefully discloses the assembled official sources, the richness of the data, and the $0.04/call x402 payment model. However, it does not explain query requirements, response format, error behavior, or whether data is real-time, leaving notable transparency gaps for an agent.

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?

The description is two concise sentences and a short pricing note, yet it packs a great deal of specific, useful information. It is front-loaded with the core purpose and avoids fluff 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?

Although the description lists the data categories included, it omits essential invocation details: what 'q' expects, whether an output schema exists (none is provided), and what the response structure looks like. This incompleteness is significant for a tool with only one required parameter and no annotations or output schema to fall back on.

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?

The only parameter, 'q', is completely undocumented in the schema (0% description coverage) and the description provides no clarification about whether 'q' should be a SIREN, a company name, or another identifier. Since this is a required parameter, the lack of any semantic guidance is a critical failure.

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 is explicit: 'Complete profile of a French company in a single call' clearly identifies the resource and scope. It enumerates the specific data categories (legal identity, address, activity code, headcount, incorporation date, annual accounts, insolvency, establishments), which distinguishes it from more focused sibling tools like fr_entreprise-360_partial or fr_bilans.

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?

The description provides clear context: use this tool when you need a consolidated French company profile from official sources, and it explicitly states it replaces 'four or five separate lookups against INSEE Sirene, INPI RNE and BODACC.' It does not explicitly name sibling alternatives or give 'when not to use' guidance, but the use case is clear.

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?

With no annotations, the description carries the full behavioral burden even though this is a read-only lookup. It discloses the data source (official INSEE Sirene registry), the fields returned, the 'current' nature of the status, and the paid-per-call cost via x402 USDC, which is meaningful behavioral context beyond a bare tool name.

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 front-load the purpose, scope, source, and use-case, then add the pricing detail. No filler or repetition exists, and the key differentiator (cheaper preview of full 360) appears immediately after the function summary.

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 single-parameter lookup with no output schema, the description covers what the tool does, what data comes back, where the data comes from, when to use it, and the cost model. It is missing exact retry/error/format nuancesholistics, but the absence is minor given the tool's simplicity and the explicit data source and preview positioning.

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?

The input schema provides only a generic required string 'q' with 0% description coverage, so the description must compensate. It does so by stating that q accepts 'SIREN or name', which is the essential semantic needed to invoke the tool. It stops short of specifying formats such as SIREN digit length or exact-name matching behavior, but it gives enough for a basic correct call.

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 states a specific operation and resource: a 'Lite overview of a French company by SIREN or name' covering legal identity, activity code, headcount bracket, and administrative status. It clearly distinguishes this from the full 360 profile by calling itself the 'cheaper preview', so an agent can tell it apart from fr_entreprise-360.

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?

It explicitly positions the tool as a pre-purchase confirmation step: 'meant to let an agent confirm it has the right company before paying for depth.' This gives a clear context for use and implies the full 360 profile is the deeper alternative, though it does not list exclusions or other sibling alternatives explicitly.

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?

With no annotations provided, the description carries the full burden of behavioral disclosurehol. It adds meaningful context: it uses DVF recorded sale prices rather than listings, returns a median price per square metre and the sample size for reliability judgment, and discloses the per-call cost and payment method. It does not explain failure modes, address normalization, or coverage limitations, but the core behavior is well disclosed.

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?

The primary purpose is front-loaded in the first sentence, the second sentence explains outputs and reliability cues, and the pricing note is appended without bloating the description. Every sentence adds value and there is no redundant repetition of the tool name or schema.

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?

The description covers the main input of address/surface, the data source, the output components, and the cost, which is helpful given there is no output schema. However, it is incomplete for a required parameter 'type' and does not specify units (e.g., square metres), output format, currency, or error conditions, leaving notable gaps for an autonomous agent.

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%, so the description must compensate by documenting the three required parameters. It explains 'adresse' and 'surface' in prose, but it fails to mention the required 'type' parameter at all, leaving the agent without guidance on what values are expected or how it affects the estimate.

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 uses a specific verb ('Estimate the market value') and a precise resource ('a French property from its address and surface area'), then distinguishes the tool from listing-based approaches by grounding it in the DVF open dataset of recorded sale prices. This makes the tool's role clear and differentiates it from siblings that likely source from listing sites like fr_seloger or fr_leboncoin.

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?

The description implies the tool should be used when estimating a French property's value from address and surface data, especially when actual sale prices are preferred over asking-price listings. However, it does not explicitly state when to use this tool over alternatives such as fr_valorisation or fr_analyse-immo, nor does it give any 'when not to use' 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?

With no annotations provided, the description carries the full burden. It discloses the study's contents and data sources (INSEE and official open data) and pricing, but does not specify the exact output format (e.g., PDF, JSON) or any potential side effects, leaving some behavioral ambiguity.

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?

The description is extremely concise at two sentences, front-loads the core purpose, and every clause adds value: purpose, deliverables, data sources, and pricing. No fluff or redundancy.

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 tool with no output schema and no parameter descriptions, the description covers the main purpose, contents, and cost, but omits explicit parameter guidance and return-value details. It is adequate for a simple research tool but leaves notable gaps.

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 descriptions are absent (0% coverage), so the description must compensate. It indirectly hints that 'commune' is the French address/commune and 'activite' is the business activity (via 'same activity'), but does not clarify expected formats like commune name vs. postal code or activity code vs. free text.

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 clearly states it provides a 'Location study for opening a business at a French address' and lists specific components (demographics, purchasing power, competition, footfall, area evolution). This distinguishes it from sibling tools like fr_immo or fr_entreprise-360, making the purpose unmistakable.

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?

The description conveys a clear use case: opening a business at a French address. It implies the tool should be used when assessing a location for a new venture, but does not explicitly mention alternatives or when not to use it.

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?

No annotations are present, so the description carries the burden. It discloses the data source (DVF), that values are recorded rather than asking prices, and that the call is billed $0.030001 via x402, which is useful. It does not mention output format, pagination, freshness, or authorization, leaving some behavioral gaps.

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 plus a pricing note; every sentence carries information and the main data content is front-loaded. 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?

For a two-parameter lookup with no output schema, the description covers data source, returned fields, and cost, but it leaves the input semantics ambiguous ('address' vs city/cp) and doesn't specify output shape or limits. It is adequate but not fully self-sufficient.

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 the description needed to explain city and cp, but it never mentions them. It says 'around an address' while the schema takes only city and postal code, which is confusing and fails to define what 'cp' means. No format hints, examples, or constraints are given.

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 (official DVF dataset) and the data returned (actual sale prices, dates, surface areas, property types), so an agent can tell this is a historical transaction comparables tool. It doesn't explicitly contrast with sibling tools, so it loses the top mark.

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?

The 'comparable sales nearby' and 'not asking prices' language imply usage for transaction comparables rather than current listings or estimates, but no explicit when-to-use or alternatives are named. An agent must infer the distinction from 'not asking prices' rather than being told when to prefer this over siblings.

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?

No annotations are provided, so the description carries the disclosure burden. It discloses data sources (official registries), return type (structured file), and cost/payment details ($0.10/call via x402). It lacks caveats about data availability or errors, but is otherwise transparent.

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?

The description is front-loaded with the core purpose, then details the content and return value, ending with billing info. It is efficient and every sentence adds value, though slightly dense.

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?

The description covers purpose, sources, content, return type, and cost, but lacks guidance on the q parameter and does not specify the structure of the returned file. Given no output schema, more detail on expected input would improve completeness.

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?

The only parameter, q, has zero schema description and is never explained in the tool description. The description does not state whether q expects a company name, SIREN number, or registration number, leaving the agent to guess.

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 clearly identifies a know-your-business dossier for French companies, assembled from official registries, and lists specific contents (legal identity, directors, beneficial owners, insolvency). This distinguishes it from sibling tools like fr_bilans or fr_due-diligence.

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?

The description explicitly states the intended context: 'for compliance and onboarding'. This gives clear usage context, though it does not mention alternatives or when not to use the tool.

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?

With no annotations, the description carries full behavioral disclosure. It discloses that it returns three specific pieces of information (legal existence, admin status, insolvency flag), implying a read-only operation. It also adds the pricing model ('$0.030002/call, paid per request via x402') which is useful behavioral context. However, it doesn't explicitly state that it won't modify anything or clarify the absence of an output schema, but given the read-only nature implied by 'check', it's reasonably transparent.

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?

The description is concise and well-structured: it opens with the purpose, then the scoping ('The minimum...'), then the upgrade path, then pricing. Every sentence adds value and there is no fluff. It is front-loaded with the most important 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 tool with one simple parameter and no output schema, the description covers the purpose, usage, and pricing, but misses the essential definition of the 'q' parameter. This is a significant omission because an agent cannot correctly invoke the tool without knowing what to supply. It is otherwise fairly complete for the minimal scope, but that missing parameter explanation brings it down.

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?

The schema has a single required parameter 'q' with no description, and schema description coverage is 0%. The description does not explain what to pass in 'q' — it doesn't mention that it should be a company name, SIREN, or registration number. Since the description is the only source of parameter meaning, this is a critical gap. It fails to compensate for the schema's lack of parameter documentation.

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 states a specific verb ('Lite know-your-business check'), a specific resource ('a French company'), and enumerates the scope ('legal existence, current administrative status and any insolvency flag'). It also differentiates from the full sibling by calling itself 'Lite' and explicitly naming the upgrade path to /v1/fr/kyb, so an agent can tell it apart from fr_kyb and other sibling tools.

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?

It provides explicit usage guidance: 'The minimum an agent needs to decide whether a counterparty is real and active before going further' and 'Upgrade to /v1/fr/kyb for directors, beneficial owners and the full compliance dossier.' This tells the agent exactly when to use this tool versus the full version, and includes the pricing detail per call.

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?

With no annotations, the description carries the full burden and does a strong job: it discloses that datacenter traffic is blocked, that calls run through a French residential IP with a real browser (implying a slower, browser-driven execution), and that each call costs $0.020002 via x402. It omits failure modes and 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?

Three sentences with zero filler: purpose and output contract first, routing rationale second, pricing third. Every sentence earns its place and the most decision-relevant information is front-loaded.

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 2-param tool with no annotations and no output schema, the description covers purpose, output fields, routing behavior, and cost — the essentials an agent needs before invoking. The main gaps are failure behavior (e.g., blocked requests, empty results) and the unresolved 'category' reference.

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 the description must compensate; it maps text→keyword and city→location, which gives basic meaning to both required params. However, it also mentions a 'category' filter that has no corresponding schema parameter, and it doesn't specify city format (name vs. postcode), leaving partial ambiguity.

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 uses a specific verb+resource ('Search Leboncoin listings') and enumerates the returned fields (title, price, location, publication date, listing link), giving an agent a precise contract. The Leboncoin marketplace is clearly distinct from siblings like fr_seloger, fr_immo, and search.

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?

When to use the tool is implied — an agent needing Leboncoin classifieds data — but the description never names alternatives or exclusion conditions. It explains the routing and cost model, which is useful context, but a comparison to search or fr_seloger would be needed for a higher score.

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?

No annotations are provided, so the description carries the behavioral burden. It adds useful context: data is structured, from official sources, and paid via x402/USDC. Still, it does not disclose data freshness, coverage, pagination, or any operational limits, though the tool is a simple read-only search.

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?

The description is a single, efficiently front-loaded sentence that states the action, resource, and returned fields, followed by a compact pricing note. Every clause adds useful information, with no redundancy or 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 and no annotations, the description is the only source of operational context. It lists returned fields but fails to define the required `departement` parameter format or explain how `q` interacts with it. It also omits any result-count or pagination behavior, leaving meaningful gaps for a two-parameter 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?

The input schema has zero description coverage, so the description must explain the parameters. It mentions keyword, buyer, and region, but does not clearly map them to `q` and `departement`, nor specify the expected format for `departement` (e.g., code vs. name). An agent would have to guess at valid values.

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 opens with a specific verb and resource: 'Search French public procurement notices'. It then lists the returned fields (object, buyer, estimated value, deadline, notice link) and states the data comes from official sources, making the tool's purpose unmistakable and distinct from the other French business-data siblings.

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?

The scope is clear: French public procurement notices. However, the description never explicitly states when to prefer this tool over the many sibling research/enrichment tools, nor does it give exclusion criteria. Usage is implied by domain rather than directly instructed.

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?

With no annotations provided, the description carries the full burden and does a credible job: it implies read-only lookup behavior, cites official BODACC announcements for provenance, and discloses the $0.030003/call x402 cost model. It leaves 'synthetic status' undefined and never addresses BODACC publication lag or what occurs when a company has no proceedings — both material for an insolvency check.

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?

Every element earns its place: purpose question, three return components, source provenance, and per-call price — all in two tight clauses. No filler or restatement of the tool name.

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 one-parameter lookup with no output schema, the description names its outputs and source, which is decent coverage. The gaps are the undefined `siren` format, the opaque 'synthetic status' output, and the absence of guidance on how this tool relates to overlapping fr_* siblings.

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%, so the description must compensate, but it only weakly does so via 'this French company,' implying `siren` is a French company identifier. It never states that a SIREN is a 9-digit registry number, nor any format or validity constraints, leaving an agent dependent on domain knowledge about the French registry.

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?

Opens with a precise, answerable question ('Is this French company in insolvency proceedings?') and identifies a concrete resource: the history of court judgments covering safeguard, receivership, and liquidation. It names three specific return elements plus the authoritative BODACC source, which sets it apart from sibling tools like fr_bilans (financial statements) or fr_entreprise-360 (general company data).

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?

The question framing gives clear context for when to use this tool — any insolvency-status check for a French company. However, it names no alternatives and states no exclusions, even though the sibling list contains overlapping fr_* tools (fr_due-diligence, fr_entreprise-360, fr_kyb) that could plausibly also surface legal status.

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?

With no annotations, the description carries the full transparency burden. It discloses that the tool is paid ($0.120001/call via x402 USDC) and specifies that results are already filtered, returning rows with registry identity, headcount, age, and solvency signals. This adds behavioral detail beyond schema, though it could mention whether it's read-only, rate limits, or error handling. The pricing and filtering disclosure warrant a high score.

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?

The description is concise, with the main purpose front-loaded in one sentence and the pricing information as a separate, clearly demarcated addition. It avoids redundancy and follows a logical flow. Slightly longer than necessary perhaps, but efficient and readable.

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?

Given the tool's complexity (filtered lead generation), lack of output schema, no annotations, and 0% schema parameter coverage, the description is incomplete. It does not explain the acceptable formats for activity and location, result pagination, limits, or failure modes. An agent cannot fully determine how to call the tool correctly without additional assumptions.

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% and the description does not elaborate on the 'activity' or 'location' parameters. It merely restates them in passing ('from an activity and a territory') without defining acceptable values, formats, or examples. This leaves the agent without crucial semantic guidance for constructing valid inputs, failing to compensate for the schema's silence.

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 clearly states the tool builds a list of qualified French company leads from an activity and a territory, specifying the exact output characteristics (verified registry identity, headcount bracket, age, solvency signals). This is a specific verb+resource combination that distinguishes it from general search tools and other fr_* tools which focus on individual company data or other domains.

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?

The description states the tool's purpose but provides no explicit guidance on when to use this vs. alternative sibling tools. There is no mention of exclusions or conditions (e.g., 'use for lead generation; for company verification use fr_kyb'). The usage context is implied but not spelled out, leaving the agent to infer based on the description alone.

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?

With no annotations, the description carries the disclosure burden and does reveal useful behavioral traits: temporal scope ('holds or held a mandate'), output content ('status and activity'), and cost/payment via x402. However, it does not address authentication requirements, rate limits, or response format, leaving the disclosure only moderately complete.

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?

The description is three sentences with the core verb and scope front-loaded. The use-case sentence adds decision-relevant context, and the pricing sentence is compact operational detail. No significant redundancy or 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?

For a two-parameter lookup with no output schema, the description covers the purpose, target use cases, output content, temporal scope, and pricing. It omits concrete output structure or field names, but that is not critical for a correct first 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?

Schema description coverage is 0% and the description never mentions nom or prenom, nor their format or meaning. It only implies a person identity via 'same person', leaving the two required parameters entirely dependent on their raw names for interpretation.

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?

Opens with 'Map the network of a French company director', a specific verb and resource, then defines scope: every other company where the same person holds or held a mandate. It also contrasts with 'a single-company lookup', making the tool's unique contribution clear among the French-entity siblings.

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 concrete trigger contexts: compliance checks, fraud detection, and acquisition research on French counterparties. It implies a distinction from single-company lookups but does not name an alternative sibling or state explicit when-not conditions, so it stops short of a 5.

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?

With no annotations, the description carries the transparency burden and does well: it discloses the exact data sources, the inputs to the computation, what is returned, and even the pricing model. It does not mention side effects or permissions, but as a read-only scoring tool those are not material concerns.

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?

Three dense sentences cover what, how, output, use case, and price without redundancy. The main purpose is front-loaded and every sentence earns its place.

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?

The description explains the score's inputs, output components, and use case well, and the tool is simple (one parameter, no output schema). However, it omits the critical detail of what q should be and does not clarify the relationship to the partial sibling, leaving an agent uncertain about 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?

The single required parameter 'q' has no schema description and the tool description never defines what q should contain (SIREN, company name, address, etc.). The French-company context gives a weak hint, but the agent cannot reliably know how to populate the parameter from the text alone.

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 clearly identifies the tool as computing a 0-100 solidity/risk score for a French company from financial, insolvency, age, and status data, so its purpose is unmistakable. However, it does not explicitly distinguish itself from the sibling fr_score-entreprise_partial or other company-analysis tools, so it misses full sibling differentiation.

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?

It gives a concrete use case: replacing a paid solvency report for supplier vetting and credit decisions, and notes the agent can explain the verdict. It does not mention when not to use it or name alternative tools, so it lacks explicit exclusions and sibling 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?

With no annotations, the description carries the burden of explaining behavior. It discloses that it returns a rating, qualitative level, and insolvency count, and mentions the cost and payment method (x402/USDC). It also implies read-only nature by describing a lookup. However, it doesn't mention rate limits, error conditions, or whether the operation is idempotent, but for a single-parameter query this is acceptable. The cost disclosure is a nice addition.

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?

The description is front-loaded with the core purpose in the first sentence, followed by usage guidance and cost. It is not overly verbose and every sentence adds value, though the cost note at the end is a bit tangential. Slightly trimmed wording would earn a 5, but it's well-structured and efficient.

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 tool with one parameter and no output schema, the description must explain both inputs and what to expect back. It explains the output fields partially (rating, level, count) but omits any explanation of the `q` parameter, which is the sole input. Without knowing how to specify the company, an agent cannot reliably invoke the tool. Additionally, there's no mention of response format, language, or error behavior. The description is incomplete for a production 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?

The only parameter, q, has zero schema description coverage and the description doesn't even mention what q represents (e.g., SIREN, company name, legal form). This is a critical gap – an agent has no idea what to pass. The description fails to add any meaning beyond the bare 'q' property, making this the weakest dimension.

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 clearly states the verb (score), resource (French company), and output (rating 0-100, qualitative level, insolvency count). It immediately distinguishes itself as the 'Lite' version and explicitly references the full counterpart, fr_score-entreprise, so an agent can tell them apart 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?

It explicitly says this tool is for cheap triage of a list of companies and to 'decide which ones deserve a closer look.' It also tells the agent to upgrade to /v1/fr/score-entreprise for deeper analysis, giving both when-to-use and when-not-to-use conditions. This is exemplary 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?

With no annotations, the description carries the transparency burden. It discloses two non-obvious behavioral traits: the site rejects datacenter traffic, so calls exit through a French residential IP driving a real browser, and requests are paid per call via x402. This is genuinely useful context beyond what any structured field would provide.

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?

The description is compact and front-loaded: the first sentence states the function and output, and the second adds essential operational context. There is no filler, and every sentence contributes to understanding the tool.

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?

This is a simple-looking tool with an important proxy behavior and no output schema, so the description needed to cover both invocation and results. It lists output fields, but the mismatch between the advertised budget/type filtering and the actual two-parameter schema is a serious gap. It also omits practical details like pagination, empty-result behavior, and rate limits, making the description insufficient for reliable 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?

Schema coverage is 0%, so the description needed to clarify city and cp, but it only vaguely groups them under 'location'. Worse, it advertises 'budget and type' as search dimensions that have no corresponding parameters in the schema, leaving the agent unable to actually express those constraints.

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 specific resource and action: 'Search SeLoger property listings', and lists the returned fields, which clearly distinguishes it from property-adjacent siblings like fr_leboncoin and fr_immo. However, it claims filtering by 'budget and type' even though the schema only accepts city and cp, so the stated purpose is broader than the actual input surface.

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 is given on when to choose this tool over alternatives such as fr_immo, fr_leboncoin, or fr_estimation-immo. The description implies use for SeLoger listings, but it never states exclusions, precedence, or a decision rule.

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?

With no annotations, the description must disclose behavior. It explains that the tool draws on INPI accounting data rather than declarations and that it returns a range with assumptions, which implies a read-only analysis. However, it does not mention side effects, authentication needs, or limitations (e.g., what happens if data is missing). The core behavior is clear but not exhaustive.

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?

The description is a single paragraph that front-loads the main purpose, then adds data source, use cases, and pricing. It is efficient and readable, though the pricing line could be separated. Overall, it is appropriately sized with no fluff.

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 tool with no output schema and a single ambiguous parameter, the description must compensate. It fails to define the input (q) and only vaguely describes the output as a 'range with assumptions'. Given the complexity of valuation and the need for precise input format, this is incomplete for reliable agent use.

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?

The schema has a single required parameter 'q' (string) with no description, and schema coverage is 0%. The tool description never explains what 'q' represents (e.g., company name, SIREN number, or URL). An agent cannot know how to populate this parameter correctly, making this a critical gap.

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 states a specific action ('estimate the value of a French company'), a clear resource, and the method (sector multiples on revenue and earnings). It also specifies the output (range with assumptions) and the data source (INPI), making it distinct from sibling tools like fr_bilans or fr_score-entreprise.

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?

The description explicitly lists use cases: screening acquisition targets, preparing a negotiation, or giving an owner an order-of-magnitude answer before a formal valuation. This gives clear when-to-use context, but it does not mention when not to use the tool or name alternative tools, so it stops short of a full routing guide.

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?

With no annotations, the description carries the full burden. It discloses the types of records checked (legal existence, trade registration, activity code, age, insolvency) and the per-call pricing, but does not mention authentication, rate limits, data freshness, or failure behavior. It implies a read-only lookup, but that is not explicit.

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?

The description is a compact block with the core purpose first, followed by use cases and pricing. It has no filler, but the pricing information, while useful, is not about tool behavior and could be moved elsewhere. It is adequately structured, though not exemplary.

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?

The description lists the data points returned, but fails to specify what value 'q' should take or what the response format looks like. For a tool with one parameter and no output schema, the description must compensate for the missing structured metadata; it does not. It also omits any error or edge-case information.

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?

The single parameter 'q' is entirely undocumented in the schema and the description. The tool's purpose implies 'q' identifies the artisan, but there is no guidance on format (e.g., SIRET/SIREN number, name, address). This is a critical gap for an agent to invoke the tool correctly.

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 'Verify' with a clear resource ('French craftsman or building trade professional') and enumerates the exact data points checked. While it doesn't name alternative tools, the scope is specific enough to separate it from general company-check siblings like fr_kyb or fr_entreprise-360.

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 scenarios where the tool should be used: 'marketplace or an insurer must settle', 'vetting contractors, onboarding trades on a platform, or checking a quotation'. It does not mention exclusions or alternatives, but the context is clear.

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?

No annotations are provided, so the description carries the full burden — and it delivers: it discloses the residential-IP fetch behavior, the return payload (verdict, 0-100 score, findings with snippets, sanitized copy), and even per-call pricing via x402. It omits a few behaviors like content retention and the verdict vocabulary, but the core behavioral profile is well covered beyond the minimum.

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 purpose front-loaded, followed by input modes, return values, and pricing. Every clause adds information — threat categories, the residential-IP safety mechanism, the verdict/score/findings/sanitized-copy payload, and cost. It is slightly dense but free of filler; the pricing detail earns its place for a paid tool.

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 one-parameter tool with no output schema and no annotations, the description is largely complete: purpose, both input modes, the full return payload, and cost are all stated. The main gaps are the verdict value vocabulary and how sanitization transforms flagged text, which an agent would need to branch on the result, but the description covers the essential decision surface.

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% and the only parameter `content` is a bare string type, yet the description fully compensates: 'Pass raw content, or a URL we open from a residential IP' explains both accepted value forms and the behavioral difference between them. The single parameter is completely specified by the description, exceeding the baseline expectation.

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 states a specific verb and resource: 'Screen untrusted text before your agent acts on it,' and enumerates the exact threat categories (prompt injection, data exfiltration, phishing, wallet-drainer intent). This distinguishes it from siblings like `extract`, `llm`, and `unblock` — an agent can tell this is a safety/guardrail tool, not a data-extraction or proxy tool.

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?

The description gives a clear usage context: invoke before the agent acts on untrusted text. It also explains the two input modes ('Pass raw content, or a URL we open from a residential IP') and when each is appropriate. It doesn't explicitly name sibling alternatives or exclusions, but the invocation timing and mode-selection guidance are sufficient for a single-purpose tool.

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?

With no annotations provided, the description carries the full transparency burden. It discloses meaningful behavioral traits: real browser rendering, inclusion of JavaScript-injected links, absolute URL resolution, and anchor text return. It also discloses commercial conditions ($0.005001/call via x402). It does not describe failure modes, timeouts, or behavior on invalid URLs, but the core behavior is well exposed.

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?

Three tightly written sentences with no filler. The what, the key behavioral nuance, and the commercial note are each contained in their own sentence. The most important information is front-loaded, and every sentence earns its place.

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 single-parameter, no-output-schema tool, the description covers the essential flow: input URL, rendered page, extracted links, and anchor text. It is mostly complete, but it omits obvious edge-case expectations such as behavior for pages with no links, invalid URLs, or very large pages. These are minor gaps given the low complexity.

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%, so the description must compensate for the undocumented 'url' parameter. It only restates that a URL is sent, adding no details about required format, protocol, constraints, or examples. While the parameter is self-explanatory, the description adds minimal meaning beyond the schema's property name and type.

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 uses a specific verb-resource pair: 'Send a URL and receive every hyperlink found on the page'. It clearly defines scope (every hyperlink), transformation (resolved to absolute addresses), and output content (anchor text). It also implicitly differentiates itself from extraction or rendering siblings by emphasizing that it returns link-level data rather than page content or screenshots.

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?

The description gives clear contextual usage guidance: 'the page is rendered by a real browser first, so links injected by JavaScript are included rather than missed.' This tells the agent when the tool is valuable, especially for dynamic pages. However, it does not explicitly name alternatives or state when not to use it, so it falls short of explicit exclusion 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?

Describes core behavior: no account/API key needed, pay-per-call, request format, and token limit. With no annotations, it sufficiently discloses basic traits but omits rate limits or error handling.

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 concise sentences covering purpose, constraints, and usage details with no waste.

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?

Covers essential aspects for a simple tool: model, token limit, cost, payment method, and request format. Lacks response format details and error handling, but adequate given complexity.

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 only has 'prompt' with 0% description coverage; description adds optional 'system' and 'max_tokens' parameters with context, significantly compensating for schema gaps.

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?

Clearly states it's a cheap LLM inference tool, specifying model (DeepSeek v4), output token limit (2000), and payment model. Implicitly differentiates from sibling 'llm_pro' via cost emphasis.

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?

Emphasizes low cost, implying use for cost-sensitive scenarios, but does not explicitly contrast with alternative 'llm_pro' or provide when-to-use/when-not-to-use 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?

With no annotations, the description discloses the output budget, the per-call price, and the x402/USDC payment mechanism, which are the main behavioral traits an agent needs. It stops short of describing response format or failure modes, but covers the essential cost and output constraints.

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 front-load the core purpose and then pack the key differentiator, request body, pricing, and payment method without wasted words.

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 single-prompt LLM call, the description covers what the tool does, when to choose it, how it is paid for, and what the request body accepts. The lack of an output schema or explicit response format is a minor gap, but not critical for invoking 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?

The input schema only lists 'prompt' with 0% schema coverage, so the description compensates by providing the full request body shape: prompt plus optional system and max_tokens. It goes beyond the schema, though it does not elaborate on parameter types or constraints for those optional fields.

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 specific operation ('Long-form LLM inference'), ties it to the same engine as /v1/llm, and differentiates it by a four-times larger output budget (up to 8000 tokens). This makes it distinguishable from the sibling llm tool.

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?

It explicitly states the use case: 'for answers the cheap route truncates,' signaling that this is the option when the standard LLM endpoint cuts off long responses. It does not fully spell out when not to use it or name the exact sibling, but the context is clear.

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?

With no annotations provided, the description carries the behavioral burden. It discloses that this is a direct, structured search API, returns a structured result set rather than raw scraped pages, and importantly states the pricing model ('$0.030005/call, paid per request via x402 (USDC)'). It does not cover pagination, rate limits, or error behavior, but for a simple read-style search tool the key operational traits are present.

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?

The description is compact and front-loaded: the verb, resource, inputs, and output fields are all in the first sentence, with the use case and payment model in the second. Every sentence earns its place, and there is no redundant or filler language.

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 two-parameter search tool with no output schema and no annotations, the description provides enough context to select and invoke the tool: what it searches, what inputs to provide, what result fields will be available, and a clear use case. It is slightly incomplete on operational details like response format or pagination, but it goes beyond the minimum viable definition.

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?

The input schema provides zero description coverage, leaving q and location as bare strings. The description partially compensates by mapping the search to 'activity' and 'location', giving meaning to both parameters. However, it does not provide format hints, examples, or constraints such as required syntax for location (city, postal code, coordinates), so the compensation is incomplete.

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 opens with a specific verb and resource ('Search local businesses on a map') and immediately clarifies the two key inputs ('by activity and location'). It also enumerates the returned data fields, so an agent can distinguish this from generic siblings like 'search' or 'search_news' without inspecting schemas.

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?

The description gives concrete use cases: building a prospect list or verifying a physical presence. It also contrasts itself with an alternative approach ('without scraping a mapping site directly'), which helps an agent decide when to call this tool rather than a proxy/scraping tool. It does not name a specific sibling tool or state explicit when-not-to-use conditions.

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?

With no annotations available, the description carries the behavioral burden and discloses two meaningful facts: execution uses a real browser so client-side injected tags are captured, and each call is metered at $0.005002 via x402. This gives an agent useful expectations about rendering behavior and cost, even though timeouts or failure modes are not mentioned.

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?

The description is compact, front-loaded with the core action and return payload, then adds relevant rendering and pricing detail. Both sentences earn their place and there is no redundant phrasing.

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 one-parameter metadata tool the description is mostly self-contained and enumerates return fields despite the lack of an output schema. But with no annotations, no parameter descriptions, and no sibling guidance, the overall context is only minimally sufficient for correct tool selection and 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?

Schema coverage is 0% and the only parameter, 'url', has no schema description; the tool description merely says 'Send a URL' without clarifying requiredness, URL format, or constraints. This does not compensate for the absence of parameter documentation, especially since the schema marks zero parameters as required.

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 action ('Send a URL and receive its metadata') and enumerates the exact fields returned (title, description, Open Graph, Twitter card, canonical, language, favicon). The browser-rendering detail sets it apart from generic extract/render siblings by explaining that it targets metadata, not raw page content.

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?

The description implies the tool is for metadata fetching but provides no explicit when-to-use, when-not-to-use, or alternative routing among the many sibling tools (extract, render, search, etc.). No prerequisites or exclusion criteria are given, so an agent must infer selection entirely from the tool name and context.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It transparently states the cost ($7.00/call), payment method (x402/USDC), validity (30 days), the shared-IP nature of mobile carrier addresses, and that carrier/ASN are verified live and returned. Some operational details are missing (e.g., exactly how the proxy key is consumed), but the most important financial and delivery behaviors are disclosed.

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?

The description is three sentences with no wasted words. Each sentence adds substantive value: the purchase terms and validity, the reason mobile IPs are valuable, and the live verification plus pricing/payment detail. It is front-loaded with the core purpose and remains readable.

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?

The description is rich about the service being purchased and the cost, but it leaves the sole required parameter completely unexplained and provides no output schema to clarify the response shape. An agent would understand the product but could not confidently construct a valid 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?

The only required parameter, 'exit', is completely undocumented in both the schema and the description. Schema description coverage is 0%, and the description never mentions 'exit' at all, making it impossible for an agent to know what value to supply. This is a critical gap for a required parameter.

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 uses a specific verb ('Buy') and clearly identifies the resource: 1 GB of mobile proxy bandwidth on a specific mobile carrier and ASN in the French West Indies, yielding a 30-day proxy key. It is unambiguous about the core purpose, though it does not explicitly differentiate itself from similar siblings like mobile-proxy_5gb or proxy_mobile_1gb beyond the quantity stated in the description.

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?

The description gives clear context for when to use this tool: when a hard-to-block mobile carrier IP is needed, explaining the shared-subscriber advantage. It does not explicitly state when not to use it or point to alternatives, so it stops short of full routing 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?

No annotations are provided, so the description carries the full burden. It discloses that the IP is shared by thousands of subscribers, that carrier/ASN/uptime are verified live at purchase, and that the key is valid for 30 days. It also states the price and payment method. It doesn't mention whether the proxy is sticky or rotating, or how the key is delivered, but the disclosed details are substantial.

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?

The description is a single dense paragraph, but it front-loads the core purpose and includes only relevant details. The pricing and payment info at the end is useful context. It could be slightly more structured, but every sentence earns its place.

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 purchase tool with one parameter and no output schema, the description covers the product, the use case, and the commercial terms. However, it leaves the 'exit' parameter unexplained and doesn't describe what the response contains (e.g., the proxy key). Given the tool's simplicity, this is adequate but not complete.

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%, and the only parameter 'exit' has no description. The tool description does not explain what 'exit' means or how to format it (e.g., country code, IP, URL). With a single required parameter and zero schema coverage, the description should have compensated by explaining the parameter, but it doesn't.

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 states a specific verb ('Buy'), a precise resource ('5 GB of mobile proxy bandwidth'), and the delivery mechanism ('proxy key valid for 30 days'). It also names the carrier and ASN, which distinguishes it from generic proxy tools. The sibling list includes several proxy variants, and this description clearly identifies the mobile 5GB offering.

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?

The description gives clear context for when to use it: 'agents running sustained collection against sites that already reject residential exits.' It doesn't explicitly name alternatives or say when not to use it, but the context is strong enough to guide selection among the many proxy siblings.

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?

No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: uses a real Chromium browser, exits through a French residential IP, runs JavaScript before printing, and costs $0.01 per call. It does not mention failure modes or limitations, so it is not 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?

The description is concise: two core sentences plus a brief cost note. The primary action is front-loaded in the first sentence, and every additional detail (JavaScript execution, use cases, cost) earns its place.

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 tool with a single parameter and no output schema, the description is quite complete. It explains the core action, rendering behavior, geographic IP aspect, use cases, and pricing. There is no ambiguity about what the tool does or when to invoke 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?

The description only says 'Send a URL,' which merely restates the schema's 'url' property. With 0% schema description coverage, the description should compensate with details about URL format, requirement, or error behavior, but it does not. The parameter remains underspecified.

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 clearly states a specific action: 'Send a URL and receive the page as a PDF document.' It also mentions rendering by Chromium and JavaScript execution, which distinguishes it from sibling tools like screenshot or render. The resource and output format are explicit.

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?

It provides clear use cases: 'archivable, shareable record of a web page: a quotation, a legal notice, a listing or any document that must be kept exactly as it was published.' This gives context but does not explicitly name alternatives or when-not-to-use, so it stops at 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?

With no annotations, the description fully carries the behavioral burden and delivers thoroughly: delivery format, 30-day validity, per-gigabyte metering, price, ISP/ASN, reverse DNS, geolocation ambiguity disclosed honestly, pre-sale reachability/proxy-blacklist probing, 'no charge if no exit is verified', and x402 payment. This goes well beyond expected transparency.

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?

The description is long but front-loaded with the core transaction, then layers in ISP, geolocation, probing, and payment details. Every sentence adds substantive value; only a mild marketing sentence at the end is expendable. Not tight enough for a 5, but far from bloated.

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?

Covers the commercial side (delivery, validity, terms, exit details) and the output form (key) well. However, the undocumented required parameter undermines completeness — an agent still doesn't know how to call the tool. With no output schema, the description should clarify both input and usage, and it only covers output.

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% and the sole required parameter 'exit' is never defined. The description uses 'exit' as a noun in 'If no exit is verified live' but never tells the agent what to put in the parameter (e.g., a destination URL? a target host?). This is a major omission that the description's richness does not compensate for.

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 ('Buy'), a precise resource (1 GB of French West Indies residential proxy bandwidth), and the delivery form (a key like http://buyer:KEY@host). The size, region, and residential nature distinguish it from proxy_5gb, proxy_20gb, and mobile-proxy siblings without needing to open their schemas.

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 clear usage context: scraping and agent traffic that need a Caribbean residential exit. It stresses that a Caribbean residential exit is rare and cannot be imitated by datacenter ranges, implying when this tool is valuable. However, it does not explicitly name alternatives or say when not to use it (e.g., for other volumes or regions).

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?

With no annotations, the description carries the full transparency burden and does so thoroughly: 30-day validity, metered billing, no charge if the exit is not live, one-time payment, no account or subscription, and per-request payment via x402. It also discloses geolocation database disagreement, carrier details, and proxy-blacklist status.

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?

The description is long but front-loaded and dense with decision-relevant facts. Some phrases are promotional or highly technical, but nearly every sentence contributes to purchase confidence or distinguishes this tool from its siblings.

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?

Product and pricing context is unusually strong, but the single required input is left undocumented and there is no output schema to clarify the response. Since safe invocation depends on understanding `exit`, the description is not complete enough for reliable use.

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?

The only required parameter, `exit`, has zero schema description, and the tool description never explains what value to pass. The word 'exit' appears as a product attribute rather than as a parameter instruction, so an agent cannot determine whether to supply a country code, an IP address, a node identifier, or some other string.

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 leads with a concrete action and resource: 'Buy 20 GB of French West Indies residential proxy bandwidth'. It clearly differentiates the tool from sibling proxy products by size, price, and intended usage pattern.

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?

It explicitly positions the tool for 'long crawling campaigns or continuous monitoring, where bandwidth is consumed steadily over weeks'. It does not name rejected alternatives, but this context strongly implies the smaller 1GB/5GB proxy siblings are meant for shorter or lighter workloads.

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?

With no annotations, the description carries the full burden and is unusually candid: it discloses live verification before sale, proxy-blacklist status, split geolocation records, no-charge-if-unverified, payment via x402, and the 30-day key. It even avoids picking the flattering geolocation result, which is a strong transparency signal.

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?

The main purpose is front-loaded and every sentence adds a distinct operational fact (carrier, DNS, geolocation discrepancy, verification, price, payment). It is slightly dense and includes some marketing-style comparisons that could be trimmed, but it is not bloated.

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 paid transactional tool with no output schema, it is missing key contract details: there is no explicit statement of what a successful call returns beyond 'proxy key,' no delivery semantics, and no explanation of the `exit` parameter. Despite rich product context, an agent cannot fully predict how to invoke it 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 0% for the only required parameter (`exit`), and the description never defines what value `exit` should take, what formats are valid, or whether it is a code, country, hostname, or free-text label. It discusses 'the exit' as a product feature, not as the input contract an agent must satisfy.

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 uses a specific verb ('Buy') and names the exact resource: 5 GB of French West Indies residential proxy bandwidth with a 30-day proxy key. It distinguishes itself by stating 'residential' and 'real FTTH home line,' which separates it from datacenter and mobile-proxy siblings.

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?

It gives explicit when-to-use guidance: 'suited to agents running sustained crawling or data-collection jobs where a datacenter IP would be blocked on the first request.' It also notes no account and no monthly commitment. It does not, however, name sibling proxy tools as alternatives or provide exclusion criteria, so it stops short of a 5.

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?

With no annotations, the description carries the full burden and does well: it discloses automatic carrier-side IP rotation (six IPs in one hour), shared subscriber addressing, and survivability against blocking. It also transparently states the cost and payment method ($7.000001/call via x402 USDC), which is critical for a paid 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?

The description is compact and front-loaded, opening with the core purchase action and resource. Every sentence adds value: network specifics, rotation behavior, resiliency rationale, and pricing. No filler or redundant restatement of the tool name.

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?

While the description richly explains the product's behavior and value, it leaves the sole required parameter completely undocumented. There is no output schema, so return behavior is also unaddressed. An agent would struggle to actually invoke this tool correctly without more parameter guidance.

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?

The schema has one required parameter 'exit' with no description, and schema coverage is 0%. The tool description never explains what 'exit' means, what values it accepts, or how to use it. This is a critical gap because an agent cannot know what to pass as the exit value.

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 clearly states the verb 'Buy' and the resource: 1 GB of rotating mobile proxy bandwidth on a specific carrier. It also distinguishes itself from residential/datacenter proxies by emphasizing the mobile carrier and automatic rotation, making its purpose immediately identifiable.

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?

The description specifies intended uses ('scraping and agent traffic') and provides a strong usage rationale: mobile IPs survive blocking where residential and datacenter exits fail. It does not explicitly name sibling tools or state when not to use it, but the context is clear enough for an agent to infer appropriate selection.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the purchase nature (costs money), the metering (per GB), the validity period (30 days), the delivery (proxy key), and the verification (carrier/ASN/uptime verified live). It also mentions payment via x402 (USDC). It doesn't state side effects or limitations (e.g., no refunds), but the key behavioral aspects are transparent. It doesn't contradict any annotations because none exist.

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?

The description is longer than typical but every sentence adds value: purpose, technical details, benefits, target use case, and pricing. The most important information (what it buys) is front-loaded, and the structure flows logically. It is not redundant or verbose; it just has a lot of relevant detail.

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?

Given the tool has one required parameter with zero documentation and no output schema, the description should have explained the 'exit' parameter and what the agent should provide. It also doesn't mention how the proxy key will be returned or any prerequisites for using it. The description covers the tool's nature well but omits essential operational details needed 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?

Schema description coverage is 0% and the description completely ignores the only parameter 'exit'. The schema merely states it is a required string with no description, and the tool description provides no hint about what 'exit' should be (e.g., an IP address, a country code, a proxy key?). This is a critical gap for an agent to correctly invoke the tool.

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 is exceptionally clear: it states the exact action (buy 5GB mobile proxy bandwidth), the carrier (Outremer Telecom / SFR Caraibe, AS20776), the delivery mechanism (proxy key valid 30 days), and the metering (per gigabyte). It distinguishes itself from sibling proxy tools by specifying mobile carrier IPs and the specific carrier, so an agent can readily differentiate it from proxy_5gb or mobile-proxy_1gb.

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?

The description explicitly provides a use case: 'For agents whose collection jobs are already failing on residential exits.' This implies when to use it (when residential exits fail) and indirectly contrasts with residential proxies. It doesn't name specific alternatives like 'use proxy_5gb instead', but the context among siblings makes the intent clear. A small deduction for not naming explicit alternatives or exclusion conditions.

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?

No annotations are provided, so the description carries the full burden. It clearly discloses the no-charge condition ('if no mobile exit is verified live, you are not charged'), the 10-minute probing of carrier/ASN/uptime, the dedicated physical SIM/client/address model, and the $10/call x402 payment. These are substantive operational behaviors beyond a simple 'rents a proxy' statement.

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?

The description is dense but efficient: each sentence adds meaningful information about duration, carrier, data cap, dedicated line, monitoring, charge policy, or price. It is front-loaded with the core purpose and does not contain wasted filler, though it is somewhat long and slightly promotional.

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 paid one-off proxy rental with no output schema and no annotations, the description covers many operational facts: duration, location, carrier, data, dedicated line, monitoring, and pricing. However, it leaves the required 'exit' parameter ambiguous and does not explain how the rented port or key is delivered or consumed, which is needed for an agent to fully use the 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?

The only required parameter is 'exit', and the input schema gives no description (0% schema coverage). The description mentions 'qualify the exit against your own target' but never defines what value should be passed, whether it is an IP, URL, hostname, or something else. With zero schema coverage, the description fails to compensate for the missing parameter definition.

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 opens with a specific verb and resource: 'Rent a dedicated mobile port for 24 hours on a real mobile carrier IP in the French West Indies.' It further distinguishes this from longer rentals ('before committing to a week or a month') and from shared pool products ('not a slice of a shared pool'), making its identity clear relative to siblings.

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?

The description explicitly frames the tool as an 'entry ticket' to 'qualify the exit against your own target before committing to a week or a month.' This tells an agent when to use it and points to the longer-duration alternatives. It also states the dedicated-use case versus shared-pool proxies.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does a solid job: it reveals that the line is dedicated, one physical SIM with one client, the address stays yours for the term, and rotating pools behave differently. It also states price and payment method. It does not cover operational details such as provisioning time or cancellation behavior, but the core behavioral traits are clearly disclosed.

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?

The description is economically written with no filler. Each sentence adds distinct value: duration and location, data cap, dedicated-line model, contrast with rotating pools, and pricing/payment. Key differentiators are front-loaded, making it quick for an agent to parse.

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?

The description gives strong selection context but is incomplete for invocation. The one required parameter is undocumented, and there is no output schema or hint about what a successful call returns. The core service model is clear, but an agent would still be unsure how to supply the required 'exit' parameter.

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%, and the description never explains the required 'exit' parameter. While the description mentions 'one address that stays yours,' it does not clarify whether 'exit' is that address, a port identifier, or something else, nor how its value should be obtained or formatted. The description fails to compensate for the schema's lack of parameter meaning.

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 states a specific action (rent), a specific resource (dedicated mobile port for 30 days), and rich identifying context (real mobile carrier IP, French West Indies, Outremer Telecom / SFR Caraibe, 100 GB included). It clearly differentiates from sibling proxy products by emphasizing the dedicated, non-rotating, 30-day nature and its use case for persistent sessions and long crawls.

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?

The description gives clear contextual guidance: use this when you need a stable, dedicated address that remains coherent for logged-in sessions and long crawls, and it contrasts itself with rotating pools that reassign addresses. However, it does not explicitly name sibling alternatives like proxy_port_1d or proxy_port_7d or state when those should be chosen instead.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses pricing, payment method (x402/USDC), dedicated versus shared nature, sticky address, live carrier/ASN/uptime checks, and the real-world consequence of blocking shared mobile IPs. It omits provisioning time and lifecycle details, but the key behavioral and financial traits are visible.

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?

The description is a dense but well-organized paragraph that front-loads the core purpose, then adds relevant differentiation, operational details, pricing, and a caveat. Every sentence contributes useful context, though the risk note about shared mobile IPs could be trimmed without losing essential meaning.

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 tool with one required parameter, no output schema, and no annotations, the description should explain how to invoke it. It thoroughly describes the product's network and pricing characteristics, but the total absence of guidance for the 'exit' parameter leaves a critical gap: the agent still does not know what value to supply.

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?

The input schema has one required parameter, 'exit', with 0% schema description coverage, and the description never mentions this parameter or its expected format. An agent cannot determine whether to pass a country code, an IP, a carrier identifier, or something else. The description adds no meaning beyond 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 opens with a specific verb and resource: 'Rent a dedicated mobile port for 7 days on a real mobile carrier IP in the French West Indies on Outremer Telecom / SFR Caraibe (AS20776), up to 25 GB included.' This clearly identifies what the tool does and distinguishes it from sibling tools like proxy_port_1d, proxy_port_30d, and shared mobile proxy options.

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?

The description provides clear context for when this tool is appropriate: a dedicated, non-shared mobile line with a sticky address for a 7-day term, which implies a niche different from shared pool proxies. It does not explicitly name alternatives or state when not to use this tool, so it falls just short of full routing 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?

No annotations are provided, so the description carries the full burden. It discloses that the request goes through a French residential IP and a real Chromium instance, which are key behavioral traits. However, it does not mention potential issues like timeouts, errors, or limitations for heavy JavaScript sites. The pricing detail is extra but not a core behavioral fact. Overall, it adds meaningful context but leaves some behavioral gaps.

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?

The description is concise, with two sentences that frontload the core action and then provide operational context. The extra details about pricing and IP are useful but not essential. No redundancy or filler. It earns a high score for efficiency, though slightly longer than strictly needed.

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?

The description explains the return value ('complete HTML') and the mechanism (JavaScript execution). It also mentions the payment model, which is relevant for usage. However, it does not cover error scenarios or output format details, but since there is no output schema, some gaps exist. For a simple single-parameter tool, it is largely complete.

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 only one parameter (url) and schema coverage is 0%. The description adds meaning by stating the URL is what gets sent and the result is the HTML. It clarifies that the parameter is central to the tool's operation, which goes beyond the bare schema definition. Even though the schema shows required=0, the description implies a URL is necessary, adding semantic value.

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 clearly states the action: 'Send a URL and receive the complete HTML of the page after JavaScript execution.' It distinguishes itself from siblings by specifying the mechanism (real Chromium, French residential IP) and the use case (resolving SPAs, bypassing datacenter blocks). This is a specific verb+resource with clear differentiation.

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?

The description provides clear context for when to use this tool: when you need the HTML as a browser would see it, especially for single-page applications or when datacenter IPs are blocked. It implies alternatives like screenshot for visual output but does not explicitly name them. No explicit 'when not to use' is given, but the context is strong enough to guide tool selection.

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?

With no annotations, the description carries the burden and discloses meaningful behavior: JavaScript is executed, lazy-loaded content is resolved, the request exits through a French residential IP, and the call is paid via x402. It does not describe failure modes or what happens with invalid URLs, but it offers substantial behavioral context.

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?

The description is compact and well-ordered: it leads with the core action, then rendering behavior, then use cases, then pricing. Every sentence adds distinct, useful information without fluff.

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?

The tool is simple and the description covers value proposition and behavior well, but the complete absence of 'fullPage' semantics plus no output schema leaves an important invocation detail unresolved. An agent cannot reliably call the tool with the intended full-page behavior.

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%, so the description must compensate. It explains the high-level 'url' concept but does not define the 'fullPage' parameter at all, leaving an agent unsure whether it accepts 'true'/'false', a page name, or something else.

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 clearly states the verb and resource: 'Send a URL and receive a PNG screenshot of the fully rendered page.' It differentiates via the use of a real Chromium browser and a French residential IP, but it does not explicitly contrast itself with siblings like 'render' or 'unblock'.

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?

It provides clear use cases: verifying a page visually, archiving evidence of a listing/price, or handing a rendered view to a vision model. It does not explicitly state when NOT to use the tool or name alternatives, so it stops short of a 5.

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?

No annotations provided, so description must disclose all behavior. It reveals pricing, result structure, and that it uses Serper for Google results. However, it lacks information on rate limits, error handling, or whether any side effects exist.

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?

Description is relatively short and front-loaded with key info: what it returns, cost comparison, query format. Every sentence adds value, though the query format hint could be more precise.

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?

Given the simple schema and no output schema, the description covers purpose, output structure, and pricing. However, it omits details about result limits, pagination, and the meaning of gl/hl parameters, leaving gaps.

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% and the schema only includes parameter 'q'. The description mentions parameters 'gl' and 'hl' not present in the schema, causing confusion. It adds some meaning for 'q' as query but introduces inconsistency.

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 clearly states it performs web search using Serper, returning top 10 organic results, answer box, and knowledge graph. It distinguishes from sibling tools like search_news by specifying it's a general web search.

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?

It indicates when to use (cheaper than Exa /search) and provides pricing details, but does not explicitly state when not to use or mention alternatives for specific search needs like news.

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?

With no annotations, the description carries the full burden. It discloses the external source (Google News via Serper), freshness, output fields, and the per-call cost paid via x402 (USDC). This is meaningful behavioral context beyond the schema. It does not mention rate limits or pagination, but for a simple paid search tool the disclosed traits are substantial.

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?

The description is compact and front-loaded with purpose, followed by a target use case, query format, and pricing. Each clause adds useful information with little or no filler. It is appropriately concise for the tool's simplicity.

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 low-complexity tool, the description covers purpose, output fields, pricing, and payment method. However, because there is no output schema and no parameter descriptions, the agent is left to infer the exact format of q and whether gl/hl are usable within the single q field. The core invocation is understandable but has clear gaps.

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?

The schema has 0% description coverage and only one required string parameter 'q'. The description's 'Query: ?q=&gl=&hl=' hints at underlying query parameters but does not explain what 'q', 'gl', or 'hl' mean, how they relate to the input schema, or what values are expected. The description adds minimal semantic value over the raw 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 clearly states a specific resource and action: 'Fresh news search (Google News via Serper): latest headlines with source, date, snippet.' This is unambiguous and tells an agent what the tool returns. However, it does not explicitly differentiate from sibling tools like 'search' or 'extract', 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?

'Great for crypto/market/current-events agents' gives a clear target use case and implies when to use the tool. But there is no explicit when-not guidance or mention of alternatives among the large sibling set, so usage guidance is implied rather than fully specified.

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?

With no annotations, the description carries the disclosure burden. It goes beyond the basic 'read' operation by explaining the physical-SIM architecture, the structured response, and the per-call cost via x402 (USDC). It does not address retention, idempotency, or message consumption, but the disclosed behavioral and commercial context is still useful.

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?

The description is compact and front-loaded with the core action, then adds relevant operational context (physical SIM, pricing). The first sentence is somewhat long, but every sentence earns its place and 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?

Because there is no output schema and no annotations, the description is the only guide for calling this tool. It covers purpose, returned fields, and cost, but leaves the required 'since' semantics and phone number format unspecified—a significant completeness gap for an agent making a real 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 description coverage is 0%, so the description must explain both parameters. It clarifies that 'phone' is a number rented through /v1/sms/number, but the required 'since' parameter is left completely unexplained—an agent cannot tell whether it expects a date, timestamp, or message ID, nor what format to use.

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 states a specific verb and resource: 'Read the messages received by a phone number rented through /v1/sms/number.' It also names the concrete data returned (sender, body, reception time) and the intended use case (extracting a verification code), which together clearly distinguish this from the sibling tools such as sms_number.

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?

The description gives clear situational context: this tool is for reading SMS received by a rented physical-SIM number, including from senders that reject virtual lines, and for agent-driven verification-code extraction. It does not explicitly say when not to use it or name alternatives, but the context is specific enough to guide selection.

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?

With no annotations provided, the description carries the full burden. It discloses that the operation costs money and is paid per request via x402, which is important for an agent to know. It also clarifies that it is a real physical SIM, not virtual, which affects reliability. However, it does not state whether the number is temporary or how long it lasts, but it does mention the session for reading messages.

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?

The description is informative but not overly lengthy. It front-loads the primary purpose and key benefit (physical SIM), then mentions the return and complementary tool, and finally pricing. Each sentence adds value, though the pricing could be considered a minor detail; still, it is concise and structured logically.

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 tool with no parameters and a single action, the description is complete. It tells the agent what it will receive (number and session ID), how to read messages (pointing to sms_inbox), and the cost. There is no additional complexity to document, and the output schema is absent, but the description sufficiently covers the expected behavior.

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?

Since there are 0 parameters, the baseline is 4. The description provides no parameter details because none exist. It does not confuse the agent with parameter explanations; the tool is self-contained, and the description adequately explains what happens when called.

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 clearly states the tool's purpose: rent a real mobile number to receive SMS or one-time passwords. It distinguishes itself from virtual/VoIP numbers by emphasizing the physical SIM and handset, which is a specific and differentiating detail. It also mentions the return of a session identifier, clarifying the resource. This distinguishes it from siblings like sms_inbox, which reads messages.

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?

The description implies when to use it: for agents that must complete phone verification autonomously. It contrasts with disposable numbers, suggesting use when carrier checks are an issue. It references the sibling sms_inbox for reading messages, but it does not explicitly state when not to use it or provide 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?

With no annotations, the description carries the full burden, and it provides substantial behavioral detail: ranking by expected net margin and success rate, execution, fallback on failure, and returning result plus routing. It also transparently discloses the per-call cost and x402/USDC payment mechanism, which is critical for a paid endpoint.

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?

The description is dense but earns its length: it covers the core mechanism, preview endpoint, capabilities list, and pricing in a compact paragraph. It is front-loaded with the key concept, though the pricing and endpoint details could arguably be trimmed.

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?

Given no output schema and no annotations, the description covers the essential operational contract: what happens, what you get back (result plus routing), how to preview, and what it costs. It does not describe the exact result shape or all-fallback-failure behavior, but it is reasonably complete for 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?

The input schema only defines 'task' as a string with no description and 0% schema coverage, so the description must compensate. It adds meaningful guidance by saying the task can be plain words or a capability-plus-input, but it leaves ambiguity about requiredness, format, and examples.

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 states a specific, intentional purpose: a single gateway that resolves any capability from a plain-language task. It clearly distinguishes itself from the many specialized siblings by claiming to handle 'any capability' and describing the full resolve-rank-execute-fallback flow.

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?

It explains when to use the tool: when you have a task in plain words or can name a capability and its input. It also points to the preview endpoint for planning and price checks, and to GET /v1/capabilities for discovery, though it stops short of explicitly saying 'use a specialized sibling instead when one clearly applies.'

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?

With no annotations, the description carries the full transparency burden and exceeds it. It discloses that audio is downloaded and run through Whisper large-v3, uses residential IPs to bypass datacenter blocklists, works without captions, returns text plus sentence timestamps, and states the pricing model and payment method. This is unusually complete behavioral disclosure.

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?

The description is longer than average but every sentence carries distinct information: operation, differentiation from caption scraping, platform coverage, technical method, IP provenance, return format, and pricing. It is front-loaded with the core purpose and then expands into necessary details, 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?

Despite having no output schema and no annotations, the description tells an agent everything needed to invoke the tool correctly: what input to provide, what happens during execution, what the output will contain (full text plus sentence timestamps), and the commercial terms. The residential IP detail also explains why certain network scenarios are handled. Nothing critical is missing for a one-parameter 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?

There is a single URL parameter with 0% schema description coverage, so the description must compensate. It effectively does so by specifying that the URL must point to a YouTube, TikTok, or Instagram video, which is the key semantic constraint beyond the bare schema type. It does not detail URL formats, but given a single obvious parameter, this is sufficient.

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 opens with a specific verb and resource: transcribe the actual audio of YouTube, TikTok, or Instagram videos. It explicitly contrasts with caption scraping and names the exact platforms, making the tool's function unmistakable even among many diverse siblings.

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?

The description explains when this tool is appropriate: for videos without subtitles, in any language, and for platforms with no caption track. It implicitly tells the agent to use this when actual audio transcription is needed rather than caption extraction, though it does not explicitly name sibling alternatives or provide exclusion criteria beyond 'not caption scraping.'

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?

With no annotations, the description carries the burden of behavioral disclosure. It contributes context about the source (Companies House), authority ('authoritative record rather than a scraped copy'), and per-call pricing/payment. However, it does not reveal input restrictions, response format, rate limits, or any edge-case behavior.

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?

Three compact sentences: the first front-loads the full data payload, the second states the data-quality positioning, and the third gives target use cases plus pricing. No wasted words.

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 one-parameter lookup with no output schema, the description covers most key facts: output fields, source, use cases, and cost. But it omits the crucial input semantics (whether 'q' is a company name, number, or both) and does not route to sibling tools for related data like officers or PSC.

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?

The schema has one required string parameter 'q' with 0% description coverage, and the tool description never explains how to pass the company (e.g., registered name vs company number). Since the description does not compensate for the missing schema documentation, an agent may not know what value to provide.

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 clearly names the resource (UK company from Companies House) and enumerates a precise set of fields: registered name/number, company type, incorporation date, office address, SIC codes, filing dates, and status. It doesn't explicitly differentiate from sibling tools like uk_officers or uk_psc, 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?

The description gives concrete use cases: vetting British counterparties, onboarding suppliers, and enriching a CRM with verified company data. It does not mention when to choose alternative UK-focused sibling tools or when not to use this one, 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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It discloses the consolidated scope and per-call pricing, and 'check'/'lookups' imply a non-mutating read operation. However, it does not explain the output format, data freshness, or what an 'insolvency indicator' looks like, leaving some important behavioral gaps.

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?

The description is compact and front-loaded, leading with the main purposeholistic risk checkthen use case and pricing. Each sentence adds useful context, and it avoids fluff while still conveying scope.

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 consolidated lookup with one undocumented parameter and no output schema, the description lists the data categories returned, which is helpful. It falls short only on q's accepted format and on how to interpret the insolvency indicator, so an agent would need to make some inference before calling the 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?

The schema has one required string 'q' with 0% documentation coverage, so the description must compensate. It only indicates that q refers to a UK company, without specifying whether q should be a company number, name, or both. An agent would still have to guess the accepted identifier format.

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, compound purpose: a consolidated risk check on a UK company, and enumerates the covered data domains (identity/status, directors, PSC, filings, insolvency). 'Replaces four separate Companies House lookups' clearly differentiates it from single-purpose sibling tools like uk_officers or uk_psc.

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?

Explicitly scopes the tool to vetting a British supplier or client before signing a contract High-value usage signal. It also tells the agent that this replaces four separate lookups, correctly steering toward the consolidated option. It does not explicitly say when a single lookup would be more appropriate, but the use case is clear.

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?

With no annotations, the description carries the behavioral burden. It adds meaningful context by stating the data source (Companies House), that it includes both current and resigned officers, and the per-call cost/payment method. It does not cover pagination or response structure, but for a straightforward read-style tool the key behaviors are disclosed.

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?

The description is concise and front-loaded, with the first sentence stating the core resource and fields. The second sentence adds rationale and use cases, and the third addresses cost/payment. No sentence is redundant, though the pricing detail is auxiliary to selection and invocation.

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 one-parameter tool, the description provides strong context: data source, returned fields, use cases, and cost. However, it does not explicitly define the required 'number' parameter, and because there is no output schema, it also does not describe the response format or error behavior, leaving a noticeable gap.

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?

The input schema only defines a required string 'number' with no description, and the tool description never explicitly explains that this is the Companies House company number or how it should be formatted. With 0% schema coverage, the description should compensate, but it only implies the parameter through context, leaving ambiguity.

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 states clearly that the tool returns directors and officers of a UK company from Companies House, listing specific fields such as names, roles, appointment and resignation dates. This distinguishes it by content from siblings like uk_company and uk_psc, though it does not explicitly name those alternatives.

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?

The description gives concrete use cases: compliance checks, mapping decision-makers, and detecting governance changes. It also notes that the tool covers both current and former officers, which helps an agent understand when it is appropriate, but it does not explicitly state when not to use it or how it compares to sibling tools.

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?

No annotations are provided, so the description carries the full burden. It discloses the data content and adds the cost and payment method ($0.030006/call via x402 USDC), which is a valuable behavioral trait. It does not mention side effects (likely none) but is a read-only data fetch, so the disclosure is adequate. No contradiction with 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 sentences with no waste. The first sentence front-loads the data returned and the source, the second covers the use case and cost. Efficient and well-structured.

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?

The description is mostly complete for a simple single-parameter data fetch. It covers the returned data, use case, and cost. The main missing piece is the exact meaning of the 'number' parameter, which is a minor but notable gap. No output schema exists, but the description gives enough context about the content.

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?

The only parameter 'number' has zero schema description coverage, and the tool description does not explicitly explain that it is the UK company registration number. It says 'UK company' but doesn't connect it to the parameter. Since the description must compensate for the missing schema, this is a significant gap for an agent to know exactly what to pass.

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 clearly states the specific resource (Persons with Significant Control from Companies House) and the data returned: beneficial owners, nature of control, ownership bands, and registration dates. It distinguishes itself from sibling tools like uk_company and uk_officers by focusing on the ultimate beneficial owner record, and even ties it to AML checks, making the purpose unmistakable.

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?

The description explicitly states when to use it: for AML/KYB compliance and onboarding on British entities. It provides clear context but does not mention exclusions or alternative tools, though the purpose is so specific that an agent would naturally route to it for PSC data. Slight gap: no 'when not to use' 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?

With no annotations, the description carries the burden and does a good job: French residential IP, real Chromium, JavaScript execution, and anti-bot bypass behavior are disclosed, plus per-call billing via x402. It does not mention limits such as timeouts, response size, or error behavior.

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?

Four sentences with no filler; the action, routing behavior, fallback trigger, and cost are all front-loaded or placed in a natural order. Every sentence adds useful 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 one-parameter, no-output-schema tool, the description covers the purpose, network routing, JavaScript handling, fallback conditions, and payment. It is slightly light on failure modes and response-size/status behavior, but no critical call-blocking information 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?

The only parameter, url, is self-evident and the description ties it to the intended target ('page that blocks you'). It does not explicitly state URL format or protocol constraints, and since schema coverage is 0% the description provides only modest compensation.

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 action ('Fetch a page that blocks you, and get the HTML back') with a clear resource and output. The mention of HTML and a real Chromium browser distinguishes it from screenshot or render siblings.

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 triggers: use as a fallback when a normal fetch returns a challenge page, empty shell, or access-denied response. It lacks explicit when-not-to-use or alternative routing, but the fallback context is clear.

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?

With no annotations provided, the description carries the full burden. It discloses that one call returns a summary with citations, key points, unsettled questions, and accompanying identity/financials/filings. It also mentions pricing and payment method (USDC over x402, no account/API key). These are useful behavioral traits beyond the schema. It could be more explicit about potential rate limits or data freshness, but the coverage is strong for a no-annotation scenario.

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?

The description is long and dense, with multiple clauses and a mix of marketing and technical details. It front-loads the core value ('answer, not raw filings'), but the sentence is heavy and includes extraneous details like pricing breakdowns and payment methods that could be structured more concisely. It is not efficient, and the length may dilute key 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?

Given the tool's moderate complexity (simple single parameter) and complete absence of annotations and output schema, the description compensates well. It covers the input, the output structure (summary, citations, key points, unanswered questions), the bundled data (identity, financials, filings), and the commercial model. It lacks explicit instructions on ticker format (e.g., exchange suffix) or edge cases like invalid tickers, but these are minor for a single-parameter lookup 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?

The schema has one parameter 'ticker' with no description, and schema coverage is 0%, so the description must explain its meaning. The description implies 'ticker' is the US public company's ticker symbol by saying 'Ask about any US public company', but it doesn't explicitly state 'ticker' as a stock symbol or provide examples (e.g., 'AAPL'). The inference is clear for an agent given the context, but explicit clarification would push it to 5.

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 clearly states the tool answers questions about any US public company and returns a summarized answer with citations, not raw filings. It distinguishes itself from related tools like us_filings and us_financials by emphasizing the 'answer, not the raw filings'. However, it does not explicitly name a specific sibling tool, so it slightly misses the top score.

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?

The description implies when to use this tool: when you want a concise, cited answer about a US public company, versus raw filings. It contrasts itself with buying identity, financials, and filings separately, which suggests it's a replacement. However, it does not explicitly state when not to use it or name alternatives like us_filings or us_financials, leaving the agent to infer the decision boundary.

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?

No annotations are present, so the description carries the behavioral disclosure burden. It discloses the authoritative SEC EDGAR source and the per-call pricing/payment method via x402 (USDC). It does not explicitly state that the operation is read-only or describe error/rate-limit behavior, though the profile semantics make mutation unlikely.

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?

The description is compact and front-loaded with the core purpose, then lists output contents, positioning, intended workflow, and pricing. Every sentence adds information, and 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 only one required parameter and no output schema, the explicit field list partially substitutes for the missing output schema. It also covers source, pricing, and workflow placement. It could be more complete by naming sibling tools and describing failure behavior, but for a simple one-parameter profile lookup it is largely sufficient.

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 the description must compensate for the lone `ticker` parameter. It adds useful context by tying the ticker to US public companies and SEC EDGAR, but it does not explain expected format, casing, or exchange-suffix handling, and the phrase 'company name' concerns the workflow rather than the actual ticker input.

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 clearly identifies the resource: a US public company profile from SEC EDGAR, and enumerates the specific fields returned (legal name, CIK, tickers, exchanges, SIC, address, filer status). It also positions itself as the authoritative regulatory record rather than an aggregator copy, which distinguishes it from other data-provider tools.

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?

It gives a clear use case: resolving a company to its regulatory identity before pulling financials or filings. This implies sequencing against downstream tools like financials/filings, but it does not explicitly name sibling tools or state when not to use this tool, so it stops short of full alternative 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?

No annotations are provided, so the description carries the burden. It does disclose the data source, output fields, covered form types, and even the cost model. However, it does not explain how many filings are returned, the recency window, or any behavioral differences for different type values, leaving some uncertainty for an agent invoking it.

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?

The description is compact and well-organized: core purpose first, coverage second, use cases third, and cost last. Every clause adds useful context. It is not maximally tight because the pricing sentence could be optional, but it is still efficiently structured.

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?

There is no output schema and no annotations, so the description must fully describe inputs and outputs. It does describe the output fields and use cases, but it leaves parameter semantics under-specified and does not mention result count or date-range limits. For a simple two-param tool this is reasonably complete but still has noticeable gaps.

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%, so the description must compensate. It partially explains the 'type' parameter by listing covered categories ('annual and quarterly reports, current reports and insider transactions') and implies 'ticker' via 'US public company.' But it never explicitly states that ticker is a company symbol or gives exact accepted type values, leaving meaning partly inferred.

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 clearly identifies the resource ('regulatory filings of a US public company from SEC EDGAR') and lists the returned fields (form type, dates, accession number, direct link). It is specific enough to distinguish from siblings like us_financials or us_snapshot, though it lacks an explicit verb such as 'list' or 'get' and does not name a sibling it is not.

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?

The description gives concrete use cases: 'monitoring disclosure, detecting material events as they are filed, or retrieving the source document behind a figure.' This tells an agent when to use the tool. It does not provide exclusions or direct comparisons to alternatives, but the context is clear.

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?

No annotations are provided, so the description carries the burden. It discloses the data source (SEC EDGAR XBRL), the nature of the data (structured numbers as filed), and the pricing model ($0.050003/call via x402 USDC). It does not disclose potential limitations such as coverage gaps, filing lag, or whether data is normalized/restated, which would be useful for a financial-data 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?

The description is compact and front-loaded with the core purpose, followed by use cases and pricing. The em-dash pricing note is slightly tangential but useful for an agent deciding whether to invoke a paid tool. No wasted words, though the pricing detail could be considered secondary.

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 single-parameter tool with no output schema, the description gives a good sense of what data comes back (revenue, net income, assets, liabilities, equity across periods). However, it lacks details on period granularity, number of periods returned, currency formatting, and ticker format nuances. The pricing and use cases help, but an agent might still be unsure about the exact response shape.

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%, so the description must compensate. It names the single parameter implicitly by saying 'US public company' and the tool name is us_financials, but it does not explicitly explain what ticker formats are accepted (e.g., 'AAPL' vs 'BRK-B' vs 'BRK.B'). The description adds context about the data content but leaves the ticker parameter's format and edge cases undocumented.

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 clearly states the tool returns financial statements (revenue, net income, assets, liabilities, equity) for a US public company from SEC EDGAR XBRL data, as filed with the regulator. It distinguishes itself from siblings like us_filings and us_snapshot by emphasizing structured numbers rather than documents, and by naming the specific financial statement items.

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?

The description gives explicit use cases: fundamental screening, comparing reported performance across periods, or feeding audited figures into a model. It does not explicitly name alternatives or state when not to use it, but the use-case framing plus the structured-vs-document distinction implies when it is appropriate relative to document-oriented siblings like us_filings.

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?

With no annotations, the description carries the burden of explaining behavior. It discloses the paid-per-call pricing model and the general contents of the response, but it does not describe limitations, data freshness, ticker validity, or error/edge-case behavior. It is useful but not rich.

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?

Three sentences, all earning their place: first states the core behavior, second explains its value over alternatives, third adds pricing. It is front-loaded and free of 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?

For a single-parameter read tool with no output schema, the description conveys the major return categories (identity, financials, filings) and the target use cases. It lacks field-level detail and input formatting guidance, but it is sufficient for an agent to decide whether to call it and what to expect back.

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?

The only parameter is 'ticker', and the schema provides zero description for it. The tool description never mentions the input format or any ticker requirements, so it does not compensate for the 0% schema coverage. The parameter is inferable from the name and context, but the description adds no explicit semantic value.

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 ('snapshot of a US public company') and enumerates exactly what it returns: EDGAR identity, latest reported financials, and most recent filings. It also explicitly states that it replaces three separate lookups, which distinguishes it from siblings like us_company, us_filings, and us_financials.

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?

It gives clear use cases ('for screening or for briefing before deeper research') and says it replaces three separate lookups, so an agent knows this is the combined-data option. It does not explicitly list when to choose a sibling instead, but the sibling names and the 'replaces three separate lookups' phrasing make that context inferable.

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