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, 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 full burden. It discloses output contents ('size, age and current status'), the ranking intent, and even the cost model ($0.08/call via x402 USDC). It doesn't mention pagination or data freshness, but provides meaningful behavioral context beyond the 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?

The description is three tight sentences: function, use case, and pricing. It is front-loaded with the primary verb and contains no fluff, every sentence adds 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?

Given the simple 2-parameter schema, no annotations, and no output schema, the description covers purpose, use cases, output fields, and cost. The only notable gap is the lack of detailed parameter formats, but overall it provides enough context for an agent to select and invoke 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?

Schema coverage is 0% and the description offers some insight into the two parameters: q refers to the French company and zone implies the geographic area. However, it doesn't specify formats (e.g., SIREN vs. name, city vs. postal code), leaving some ambiguity for correct invocation.

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 ('Identify the competitors of a French company') and explains the method ('businesses sharing the same activity code within the relevant geographic area'). This clearly distinguishes it from sibling tools like fr_entreprise-360 or fr_bilans, which focus on company data or 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 explicitly lists applicable use cases: 'market analysis, competitive benchmarking or a sales territory plan on the French market.' While it doesn't mention alternatives or exclusions, the context is clear enough for an agent to decide when this tool is appropriate.

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 discloses that the tool returns verified data, includes the exact fields, and notes the cost ($0.08/call via x402). This provides useful context beyond a basic 'enrich.' It does not mention error handling, rate limits, or authentication, but the read-only nature is implied by 'returns' and 'registered-backed.'

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 plus a cost note, which is concise and front-loaded with purpose. The second sentence reinforces the use case but is somewhat redundant with the first. Overall, it earns its length without unnecessary 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, no annotations, and a 0% parameter description coverage. The description lists return fields but does not specify the return format, error cases, or clarify the mismatch between described inputs (SIREN/website) and the actual schema (name/city). This incompleteness is significant for a tool that requires cost and has many sibling tools, leaving an agent uncertain about 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 description coverage is 0%, so the description must explain the parameters. It mentions 'name, a SIREN or a website' but the schema only has 'name' and 'city' (both required). This creates confusion: the description suggests SIREN/website are inputs, but they are not in the schema, and the 'city' parameter is entirely unexplained. This inconsistency adds little value and may mislead an agent selecting or invoking 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 clearly states the verb 'Enrich' and the resource 'a French company record,' listing specific outputs (legal identity, activity code, headcount bracket, headquarters address, current status). This distinguishes it from sibling tools that may focus on other aspects, like fr_bilans or fr_score-entreprise. The phrase 'Turns a partial CRM row into a complete, registry-backed record' reinforces its unique value proposition.

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 a clear use case: when you have a partial CRM row and need to complete it with verified company data. It mentions inputs 'from a name, a SIREN or a website,' which suggests when to use it. However, it does not explicitly state when not to use it or mention alternatives like fr_entreprise-360 or fr_kyb, 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?

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 transparency burden. It discloses the data source (official INSEE Sirene registry), the nature of output (lite, partial), and the cost/payment method ($0.02 via x402). It does not mention error handling or return format, but for a simple read-only overview this is 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?

Two sentences convey purpose, scope, source, use case, and pricing, with each clause earning its place. The information is front-loaded and there is 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 description includes the key input, output data categories, data source, cost, and intended use, which covers most operational needs for a lightweight tool. It does not detail error or not-found behavior, but those are minor omissions for this simple lookup.

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 bare 'q' string with no description, but the description clarifies it accepts either a SIREN or a company name. This is crucial semantic information that goes beyond the schema, though it omits format examples or ambiguity guidance.

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 'Lite overview of a French company by SIREN or name' and lists specific data elements (legal identity, activity code, headcount bracket, administrative status), making the tool's function precise. It explicitly contrasts itself with the full 360 profile, distinguishing it from the most relevant sibling.

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 case: to confirm the right company before paying for the full 360 depth. This positions the tool as a pre-purchase validation step and names the alternative (full 360 profile), giving clear when-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 full burden. It discloses the data source (DVF), the return values, and even the cost structure ($0.05/call via x402). It also notes the reliability aspect via sample size. While it doesn't mention rate limits or auth, for a read-only estimation tool this is sufficient 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 front-loaded. It states the purpose in the first clause, adds useful distinctions, and includes pricing as a secondary note. Every sentence adds value without 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 simple tool with no output schema, the description covers inputs, data source, outputs, and reliability. It does not specify the format of the 'type' parameter or explicitly state the unit of surface area, but these are minor gaps. Overall, it provides enough context for an agent to invoke it effectively.

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 'address and surface area', which maps to adresse and surface, but does not explain the required 'type' parameter at all. Additionally, the format for surface (e.g., '50' vs '50 m²') is not specified. This leaves a significant gap for one of three required parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Estimate') and clearly identifies the resource ('market value of a French property') and key inputs (address, surface area). It distinguishes itself from sibling tools by specifying the DVF open dataset and contrasting with asking-price listings, making it unique among real-estate 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?

The description provides clear context for when this tool is appropriate: estimating value based on recorded sale prices rather than listings. It also explains the output includes sample size for reliability judgment. However, it does not explicitly name alternative tools for different scenarios (e.g., whether to use fr_seloger for listings), 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?

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?

With no annotations provided, the description discloses the dataset origin (DVF), the nature of the data (actual paid prices), and the cost ($0.03/call via x402/USDC). However, it does not mention response format, radius for 'around an address,' or any other behavioral traits like rate limits.

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, efficient sentence that front-loads the main purpose and adds a concise cost note. It avoids unnecessary details and is 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 provides a clear purpose and useful context (official dataset, not asking prices, cost), but it lacks details on how the parameters define the location and what the output shape looks like. Since there is no output schema and no annotations, this gap leaves the tool partially under-specified.

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 required parameters (city, cp) with no descriptions, and the description does not explain what these parameters mean or how they map to the 'around an address' concept. Schema coverage is 0%, so the description should compensate but does not.

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 provides recorded French property transactions from the official DVF dataset, including actual sale prices, dates, surface areas, and property types. It explicitly says 'these are prices that were really paid, not asking prices,' which distinguishes it from listing tools like fr_seloger or fr_leboncoin among 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 implies use when actual transaction prices are needed, but it does not explicitly state when to use it versus alternatives or mention any exclusions. It contrasts with asking prices but names no specific sibling tools or 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 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?

No annotations are present, so the description carries the burden. It discloses the return scope (existence, status, insolvency flag), pricing, and payment mechanism (x402 USDC). It implies a read-only operation but does not cover error cases or rate limits; still, for a lightweight KYB read it is sufficiently 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?

Three concise sentences, front-loaded with the core purpose, followed by usage guidance and pricing. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a single parameter and no output schema, the description gives a solid picture of what the tool returns and why to use it. It would benefit from explicit input format details, but overall is adequate for a lightweight check.

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 only 'q' with 0% description coverage, and the description never explains what 'q' should contain (e.g., company name, SIREN number). It only says 'on a French company', which barely hints at the parameter's 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 a specific verb ('check') and resource ('French company') with a precise scope: legal existence, current administrative status, and insolvency flag. It also distinguishes itself from the full fr_kyb tool via the 'Lite' label and the explicit upgrade path.

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 guidance on when to use this tool ('the minimum an agent needs to decide whether a counterparty is real and active before going further') and names an alternative for deeper checks ('Upgrade to /v1/fr/kyb for directors, beneficial owners and the full compliance dossier').

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 that datacenter traffic is blocked, so it uses a French residential IP and real browser, plus pricing via x402. This is valuable beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences. The first sentence states purpose and outputs; the second adds operational context and cost. No redundant 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?

The description provides output fields, IP routing, and pricing, which is helpful given no output schema. However, parameter mapping is incomplete and the 'category' mention is misleading. For a simple search tool, it covers most operational context but lacks parameter clarity.

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 explain parameters. It mentions 'keyword' and 'location' which loosely map to 'text' and 'city', but it also mentions 'category' which is not a parameter, causing confusion. The mapping is not explicit.

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 searches Leboncoin listings with specific output fields (title, price, location, date, link). It is distinct from siblings like fr_seloger by naming the platform.

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 explicit guidance on when to use this tool vs alternatives. It does not mention fr_seloger or other sibling tools for comparison. The context about IP routing is operational, not a usage criterion.

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 useful behavioral context including that results are structured data from official sources and that there is a cost per call via x402. It doesn't mention rate limits or pagination, but for a read-only search tool these are less critical.

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 efficient sentence that states the purpose, search criteria, returned fields, data source, and pricing. It is front-loaded and every segment adds 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 simple 2-parameter tool with no output schema, the description gives a good overview of the returned data and general use case. However, it lacks explicit parameter guidance and doesn't explain how 'buyer' maps to a parameter, leaving some ambiguity. Given the bare schema, a bit more detail on parameter formats 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 input schema has 0% description coverage, so the description must compensate. It mentions searching by keyword, buyer, or region, but doesn't explicitly map these to the two parameters 'q' and 'departement'. Some inference is needed, though the parameter names provide hints.

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 search tool for French public procurement notices, with specific search dimensions (keyword, buyer, region) and a list of returned fields. This distinguishes it from sibling tools focused on other French business 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 description provides clear context that this is for searching public procurement notices in France, including search criteria and output fields. However, it doesn't explicitly state when not to use it or name alternative tools, so it's clear but not exhaustive.

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 (official BODACC announcements), the pricing model ($0.03/call via x402), and the nature of outputs, which is helpful. However, it does not explain what 'synthetic status' means or how errors or missing companies are handled, leaving 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 a single, front-loaded question followed by a compact list of returns and pricing. Every clause adds value, with no wasted words or redundant repetition of schema fields.

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 1-parameter tool with no output schema, the description gives a good overview of what is returned and the cost. It leaves out details about the exact structure or possible values of the 'synthetic status' and how to interpret the full history, which could be important for an agent deciding whether the output meets its needs.

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 the only parameter is 'siren' with no description. The tool description mentions 'French company' but never explicitly states that 'siren' is the French business registration number. An agent unfamiliar with French corporate identifiers would not get enough semantic meaning from the description 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 states the tool's function with a leading question, 'Is this French company in insolvency proceedings?' and enumerates the specific outputs: synthetic status, full history of court judgments, and a deregistration flag. This distinguishes it from sibling French business tools focused on other domains like financials or real estate.

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 purpose inherently implies when to use the tool (checking insolvency status of a French company), but there is no explicit guidance about situations where it should not be used or compared to alternatives like fr_bilans or fr_entreprise-360. The context is clear but lacks exclusion 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?

With no annotations, the description carries the transparency burden. It discloses pricing ($0.12/call via x402 USDC), the filtering behavior ('already filtered'), and the output contents (verified registry identity, headcount bracket, age, solvency signals). It doesn't cover rate limits or explicit read-only status, but these are likely obvious.

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?

A single, front-loaded sentence packs the purpose, inputs, output fields, and outcome, followed by a concise pricing note. No filler words; every clause adds 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 simple two-string-param tool with no output schema, the description is fairly complete. It explains what the tool does, what inputs mean, what output rows contain, and the cost. It lacks detail on result limits/pagination, but this is acceptable for a lead-list 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 only lists 'activity' and 'location' as bare strings with 0% coverage. The description clarifies them as 'activity' (business activity) and 'territory' (geographic area), giving essential meaning. It doesn't provide examples or allowed formats, but the basic semantic distinction is there.

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+resource: 'Build a list of qualified French company leads from an activity and a territory.' It differentiates from siblings by emphasizing 'already filtered' and listing concrete output fields (verified registry identity, headcount bracket, age, solvency signals).

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 its context—prospecting for qualified leads by activity and location—but does not explicitly name alternatives or exclusions. It's clear enough for an agent to know when it's relevant, though not as explicit as naming 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?

With no annotations, the description carries the transparency burden. It discloses that the tool returns every other company where the person holds or held a mandate, includes each entity's status and activity, and reveals group structures/related parties/conflicts of interest. This is substantive behavioral context, though it omits potential limitations like data freshness 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?

The description is compact, front-loaded with the core action, and each sentence contributes: what it does, the value added, target use cases, and pricing. The pricing note is a single clause and does not bloat the text.

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 2-parameter tool with no output schema, the description covers purpose, use cases, and high-level output (status and activity). However, it lacks details on return format, pagination, or potential error conditions, which would be useful but not mandatory for a basic lookup.

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 (0%), and the description never explicitly explains 'nom' and 'prenom'. While the names imply last/first name, and the director context hints at their meaning, the tool does not compensate for the missing schema documentation, leaving the agent to infer parameter semantics.

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 action and resource: 'Map the network of a French company director' and clearly defines scope (every other company where the person holds or held a mandate). This distinguishes it from sibling tools like fr_entreprise-360 which target single-company lookups.

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 explicit use cases: 'For agents running compliance checks, fraud detection or acquisition research on French counterparties' and contrasts with a 'single-company lookup.' While it does not name alternative tools, it provides clear decision 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. It discloses the data sources (INPI, BODACC, company age, admin status), the output structure (score, level, factors), and even pricing ($0.08/call via x402). This goes beyond a simple action statement, though it omits details like 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?

The description is about three sentences, front-loaded with the core purpose, then methodology, output, use case, and pricing. It is succinct yet informative, 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?

Despite no output schema, the description explains what the tool returns (score, qualitative level, factors) and the use case. It covers key aspects like computation basis and commercial terms. It lacks detail on error conditions or exact parameter format, but for a single-parameter scoring tool, it is reasonably 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 only parameter 'q' has no description in the schema (0% coverage), and the description fails to explain what 'q' should be (e.g., SIREN number, company name). This is a critical gap because an agent cannot correctly invoke the tool without knowing how to identify the French company.

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: returns a solidity/risk score from 0 to 100 for a French company, with a defined methodology and output. It distinguishes itself from siblings by emphasizing the score, qualitative level, and explanatory factors, which is unique among the listed 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?

The description gives explicit context for use: 'for supplier vetting and credit decisions' and positions the tool as a replacement for a paid solvency report. It does not explicitly name alternatives, but the use case is clear enough for an agent to select this tool over others.

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 carrues the responsibility of disclosing behavior. It discloses the cost ($0.02/call), payment method (x402/USDC), and the limited scope of the lite version. It doesn't mention rate limits or error behavior, but for a read-only query, the key behavioral aspects are addressed.

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 long, with each sentence adding unique value: the output, the use case, and the upgrade path with pricing. It is well-front-loaded and contains no redundant or filler content.

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 tool, it covers the output details (rating, qualitative level, insolvency count) and the pricing, but it leaves the input parameter undefined and doesn't specify any error responses or output format. It is adequate for a lite tool but lacks full contextual 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 sole parameter q is described only as a string with no further details in the schema, and the description does not explain what q should contain (e.g., company name, SIREN, etc.). With 0% schema description coverage, the description entirely fails to compensate, leaving agent in the dark about how to 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 clearly states the tool returns a lite solidity score (0-100), qualitative level, and insolvency proceeding count for French companies. It also distinguishes itself from the sibling tool fr_score-entreprise by explicitly labeling itself as 'Lite' and pointing to the full version for more detail.

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 recommends use for cheap triage of company lists ('Enough for an agent to triage a list of companies cheaply'), and provides the alternative fr_score-entreprise for a factor-by-factor breakdown. This gives clear when-to-use and when-to-upgrade 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 compensates by disclosing anti-bot behavior (French residential IP, real browser) and pricing via x402. It doesn't mention failure modes or rate limits, but the search action is clearly read-only.

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 compact sentences: the first front-loads the action and expected outputs, the second adds essential execution and cost context. 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?

The description covers purpose, return fields, and proxy/payment context, but lacks parameter-level details (especially what cp means and why budget/type are mentioned but not in schema) and result-size or error behavior. It is minimally viable for a simple search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description only vaguely maps 'location' to city/cp while mentioning 'budget and type' which are not actual schema parameters. It fails to explain that 'cp' is a postal code or how the filters are expressed.

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 ('Search') and identifies the exact resource (SeLoger property listings) plus filters and returned fields, clearly distinguishing it from sibling tools like fr_leboncoin or fr_immo.

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 implies use for searching SeLoger listings by location/budget/type but gives no explicit guidance on when to prefer it over other French property tools or any exclusions. The second sentence provides operational context but not comparative usage guidance.

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

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

With no annotations, the description carries the full burden of behavioral transparency. It discloses the data source ('Draws on INPI accounting data rather than declarations'), output nature ('range with assumptions'), and monetary cost ($0.10/call via x402). It does not detail limitations or error handling, but for a read-only estimation tool, the key behavioral traits are covered.

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 (about 75 words) and front-loaded with the primary purpose, followed by data source, use cases, and cost. Every sentence adds essential 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?

For a simple one-parameter tool with no annotations and no output schema, the description covers the main purpose, usage contexts, and output nature. However, it omits any explanation of the 'q' parameter and does not mention potential limitations (e.g., reliance on latest filed accounts), so it is not fully 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 input schema has one required parameter 'q' with no description, and schema description coverage is 0%. The tool description does not explicitly explain what 'q' represents (presumably a company identifier), leaving the agent to infer from context. This is a significant gap for a single-parameter 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 clearly states a specific action ('Estimate the value of a French company'), the resource ('filed financial accounts'), the method ('applying sector multiples to revenue and earnings'), and the output ('returning the resulting range with the assumptions behind it'). This distinguishes it from sibling tools like fr_bilans (raw statements) or fr_score-entreprise (credit scoring).

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 use cases: 'screening acquisition targets, preparing a negotiation, or giving an owner an order-of-magnitude answer before engaging a formal valuation.' This gives clear context for when to use the tool, but it does not directly mention when not to use it or name specific alternative tools, stopping 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?

Annotations are absent, so the description carries the full burden. It discloses the tool's scope, lists the verification points, and adds the pricing model ($0.08/call via x402). It does not mention rate limits or whether the operation is read-only, but the verification nature and cost disclosure add meaningful context beyond a simple 'verify' 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?

Three concise sentences, front-loaded with the main purpose. The pricing note is relevant and included without bloat. 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?

For a simple tool with one parameter and no output schema, the description covers purpose, use cases, and cost. However, it omits input format requirements and return value details. The bare schema increases the need for parameter and output guidance, which is absent.

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 a string with no schema description (coverage 0%). The description does not explicitly explain what 'q' should contain (e.g., company name, SIRET number, query). The context implies it is a query for the professional, but the ambiguity is a significant gap for an agent trying 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?

The description clearly states the tool verifies a French craftsman or building trade professional, listing specific data points (legal existence, trade registration, activity code, company age, insolvency proceedings). This distinguishes it from broader sibling tools like fr_kyb or fr_entreprise-360 by focusing on artisan/building trade verification.

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 concrete use cases (marketplace/insurer vetting, onboarding trades on a platform, checking quotations) and implies when to use this tool. However, it does not explicitly name alternative tools or state when NOT to use it, 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?

With no annotations, the description carries the full burden. It discloses the method (combining reputation signals, domain age, hosting, known-abuse indicators) and the business constraint ($0.012/call via x402 USDC). This adds meaningful context beyond a simple 'check' and helps the agent anticipate cost and output format.

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, each earning its place: purpose, methodology, and pricing. It is front-loaded with the action and immediately communicates the tool's value. 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 single-parameter tool with no output schema, the description is almost complete. It explains what the tool does, how it works, and cost. It doesn't detail the exact verdict format, but that is not strictly necessary here. Minor gap: it doesn't mention if the check is synchronous or if there are failure modes, but that is acceptable for a simple 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 0% coverage, so the description must compensate. It does so by indicating that 'content' should be a domain, IP, or email, which clarifies the only parameter. While it doesn't explicitly map 'content' to those formats, the connection is strong and the parameter is simple.

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 with a specific verb ('Check') and resource types ('domain, IP address or email'), and explains the output ('single verdict with reasoning'). It is distinct from siblings, which are mostly data retrieval or proxy 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?

The description says to use it 'before your agent interacts' with a target, providing clear usage context. It does not explicitly mention alternatives or when not to use it, but the domain safety check is unique among the sibling tools, so the context is sufficient.

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 a key behavioral trait: 'rendered by a real browser first, so links injected by JavaScript are included.' It also mentions pricing and payment method. It does not cover failure modes or edge cases, but the disclosed rendering behavior adds significant value.

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 plus a pricing note, with no wasted words. It front-loads the purpose, adds a critical behavioral detail, and the pricing note is relevant for cost-aware agents. 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 tool with no output schema, the description covers the input, process, and key output details (absolute addresses, anchor text). It doesn't explicitly define the response structure, but it's adequate for a simple link-extraction tool. The mention of browser rendering adds important context.

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 parameter 'url' with zero description coverage. The description compensates by explaining that the URL is a web page to be fetched and processed, adding meaning beyond 'string'. It doesn't specify format constraints or requiredness, but the intent is clear from the sentence 'Send a URL'.

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 every hyperlink found on the page, resolved to absolute addresses and returned with its anchor text.' This is a specific verb+resource combination that distinguishes it from siblings like 'extract' or 'render'. The added detail about JavaScript-injected links further clarifies its unique 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 implies the usage context—when you need all hyperlinks from a rendered webpage, especially with dynamic content. It notes that a real browser is used, suggesting it is suitable for pages relying on JavaScript. However, it does not explicitly name alternatives or exclusion criteria, so it falls 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?

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?

No annotations provided, so description carries full burden. It discloses the model (DeepSeek v4 Pro), token limit (2000), no account requirement, and pricing model ($0.006/call via x402). It does not discuss rate limits or error behavior, but core behavioral aspects are covered.

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 pack all essential information: purpose, model, use case, token limit, body structure, pricing. No redundant 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?

No output schema or annotations. The description adequately covers input, behavior, and cost. Missing details on output format and error handling, but for a straightforward inference call, this is 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 has only 'prompt' with no description. The description adds that the body includes 'prompt', and optionally 'system' and 'max_tokens' (though not in schema), plus pricing per call. This provides meaning beyond the schema, compensating for 0% schema coverage.

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 performs 'Smart LLM inference (DeepSeek v4 Pro)' for 'stronger reasoning for hard prompts', differentiating it from a basic LLM tool (sibling 'llm'). It specifies up to 2000 output tokens, no account, and pricing.

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 indicates when to use this tool: for hard prompts needing stronger reasoning, with a token limit. It implies it should be used over simpler alternatives (like 'llm') for complex tasks, though does not explicitly state 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?

With no annotations provided, the description carries the full burden. It discloses the cost ($0.03/call), payment method (via x402/USDC), and the fact that it returns structured data without scraping, which gives useful safety and operational context. It does not mention rate limits or additional authentication, but the search operation is clearly read-only.

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-loads the main purpose and output. It also includes cost information without being overly verbose. The structure is efficient and each sentence adds value, though the second sentence is a bit long and mixes use cases with a note about scraping.

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 simplicity (2 parameters, no output schema), the description provides a good overall picture: it lists the return fields (name, address, coordinates, rating, etc.), states the primary use cases, and mentions pricing. It does not specify result limits or geographic scope, but these are minor omissions for a straightforward search 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 no parameter descriptions, and the description only partially compensates by indicating that 'activity' corresponds to q and 'location' to location. It does not provide examples or formatting details (e.g., whether location should be a city name or coordinates), leaving some ambiguity for an agent.

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 the specific verb 'Search' with a clear resource ('local businesses on a map') and lists the key output fields (name, address, coordinates, rating, etc.), making it easy to distinguish from general-purpose search tools like 'search' or 'search_news'.

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 clearly implies when to use the tool by stating use cases ('build a prospect list or verify a physical presence') and describes the input as 'activity and location'. However, it does not explicitly contrast with alternative tools or state when not to use it, so it falls just 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. It discloses that the page is rendered by a real browser, ensuring client-side tags are captured, and provides pricing/payment details. These are useful behavioral traits not visible in the schema. It does not cover failure modes or rate limits, but the core behavior is 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 purpose, and includes relevant pricing and rendering details without fluff. Every sentence adds value and is 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?

For a simple single-parameter tool with no output schema, the description adequately covers the core function, output fields, and rendering behavior. It lacks explicit usage guidance and parameter constraints, but given the low complexity, it is reasonably 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 has one parameter ('url') with zero description coverage. The description only rephrases 'send a URL' without adding constraints, formats, or edge cases. It does not compensate for the missing schema description, leaving room for ambiguity about URL requirements.

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: sending a URL and receiving metadata (title, description, Open Graph, etc.). It distinguishes itself from siblings like 'extract' or 'screenshot' by focusing specifically on metadata and using a real browser, which is a unique capability.

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 usage by mentioning the real browser rendering, which hints at handling client-side injected tags, but it does not explicitly state when to use this tool over alternatives or provide exclusions. No alternative tools are referenced.

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 key behaviors: the purchase nature ($7.00/call via x402), the 30-day validity, live verification of carrier and ASN, and the shared subscriber nature of mobile IPs. It stops short of describing the exact return payload or edge cases, but the core behaviors are 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 four sentences, front-loaded with the action and outcome. It includes only relevant details (carrier, price, payment method, verification) and avoids fluff, making it 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?

Despite the absence of an output schema and annotations, the description explains the purchase flow, the key validity, the verification, and pricing, which is sufficient for a simple 0-parameter tool. However, it could explicitly mention the response format (e.g., JSON containing the key), leaving a small 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 has zero parameters, so the description is the sole source of semantics. It explicitly specifies the quantity (1 GB), the duration (30 days), the carrier (Orange, France/Guadeloupe), and the price, adding meaning well beyond the empty 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 action (buy), the resource (1 GB of mobile proxy bandwidth on a real 4G/5G carrier IP), and the output (proxy key valid for 30 days). It distinguishes this from sibling proxy tools by specifying the mobile carrier and the exact size (1 GB).

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 usage context: mobile IPs are hard to block, making this suitable for evading blocks. However, it does not explicitly compare to alternatives or state when not to use it, though the differentiation from other proxy tools is implicit through the mobile-specific wording.

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 fully discloses key behavioral aspects: it is a paid purchase ($30.00/call), payment method (x402/USDC), validity (30 days), live verification of carrier/ASN/uptime, and the shared nature of the IPs. This gives the agent a comprehensive understanding of the transaction's effects and requirements.

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, well-organized paragraph, front-loaded with the core action and then details. Every sentence adds value: what is bought, delivery format, IP characteristics, verification, use case, and pricing. No redundancy or 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 simple purchase tool with no parameters and no output schema, the description is complete. It covers all necessary aspects: product, price, payment, duration, IP type, verification, and ideal usage scenario, enabling the agent to decide 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 tool has zero parameters, so the input schema provides no semantics. The description compensates by explaining exactly what the user receives (5GB mobile proxy bandwidth, proxy key, 30-day validity) and the cost, providing full meaning for the action.

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: 'Buy 5 GB of mobile proxy bandwidth' with specific details about the carrier (Orange, France and Guadeloupe, AS16028) and delivery as a 30-day proxy key. This distinguishes it from sibling proxy tools by specifying the mobile network, size (5GB), and unique carrier identity.

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: 'Suited to agents running sustained collection against sites that already reject residential exits.' It explains why mobile IPs are advantageous, but does not explicitly name alternative tools 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 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 provided, the description carries the full burden of behavioral disclosure. It reveals the key format, 30-day validity, metered per-gigabyte usage, residential IP exit, and the $3.50/call cost via x402. This is substantive transparency, though it omits details like setup time, response structure, or what happens when the bandwidth is exhausted, preventing a higher 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 three sentences long, with the first sentence front-loading the core purpose and deliverable. Each subsequent sentence adds distinct value: the residential IP advantage, target users, and 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 tool with no parameters, no output schema, and no annotations, the description provides a comprehensive picture: what is delivered, how it is delivered, its validity, metering, and cost. It could be more complete by specifying how the key is returned (e.g., in the response body) or any limitations, but it covers the essential details for an agent to decide and invoke 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 input schema has zero parameters, so the description is not required to explain parameter meanings. The baseline for no parameters is 4. The description adds context about the deliverable and pricing, which is sufficient given the tool's simplicity.

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: buying 1 GB of residential proxy bandwidth for scraping and agent traffic. It specifies the deliverable (a key in the http://buyer:KEY@host format), the size (1 GB), and the use case, distinguishing it from sibling proxy tools that offer different sizes or types.

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 the tool ('Built for crawlers and autonomous agents that need a trustworthy exit rather than a cloud address') and notes that it can access sites rejecting datacenter IPs. However, it does not explicitly mention alternatives or provide exclusions, such as when a larger quota or mobile proxy would be more appropriate, leaving the choice among sibling tools somewhat ambiguous.

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 by disclosing pricing, payment method (x402 USDC), metering, 30-day validity, and the residential IP benefit. It lacks details on key delivery or failure modes, but the core transactional behavior is 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 a compact paragraph where every sentence adds unique value: price, capacity, validity, residential IP advantage, use case, and billing terms. It is well-structured and front-loaded with key purchase 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?

The description covers the product, price, use case, and business terms comprehensively for a simple purchase action. The only gap is the lack of information about how the proxy key is returned in the response (no output schema), but this is minor for a buy 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 tool has zero parameters, so the schema coverage is trivially 100% and description adds no parameter explanations. Baseline 4 is appropriate since parameter semantics are not applicable.

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: buying 20 GB of residential proxy bandwidth at a specified price, delivered as a proxy key valid for 30 days. It distinguishes itself from siblings like proxy_1gb and proxy_5gb by emphasizing size, price per GB, and residential IP type.

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 mentions the intended use case (long crawling campaigns, continuous monitoring) and highlights the rate advantage, giving clear context for when to use it. However, it does not name alternative tools or state when not to use it, so it stops short of full 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 transparency burden. It discloses key behaviors: the proxy key validity (30 days), residential IP exit, no account requirement, no monthly commitment, and payment via x402 (USDC). It also states the price. However, it does not describe the exact response format or what happens upon bandwidth exhaustion, which is a minor gap.

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 four sentences, each adding value: purchase details, technical benefit, cost comparison, and ideal use case. It is front-loaded with the core action and does not waste words. The pricing comparison is useful for decision-making and remains concise.

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 zero-parameter purchase tool, the description covers the essentials: what is bought, pricing, validity, payment method, and when to use. It does not describe the response structure (e.g., the proxy key format), but given the simplicity and lack of output schema, it is sufficiently complete. A perfect score would require more detail on the exact return value.

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 parameters, so the baseline is 4. The description adds no parameter-specific details because there are none. It does clarify the meaning of the purchase (5GB bandwidth, 30-day key) which is inherently tied to the tool's purpose, satisfying the semantic need.

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: 'Buy 5 GB of residential proxy bandwidth at 2.40 USD per gigabyte and receive a proxy key valid for 30 days.' It also explains the benefit ('Traffic exits through a real residential IP address') and distinguishes it from siblings by size and pricing. This is a specific verb+resource with clear 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 provides clear context for when to use: 'Suited to agents running sustained crawling or data-collection jobs where a datacenter IP would be blocked on the first request.' It also implies the alternative of cheaper per-GB pricing. However, it doesn't explicitly mention when not to use or directly compare with sibling tools like proxy_1gb or proxy_mobile_5gb, 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?

With no annotations provided, the description carries the full burden and does well: it discloses carrier-driven rotation (six IPs in an hour), the shared-IP nature, resilience to blocking, and the x402/USDC payment method. It omits how the proxy access is delivered (endpoint/credentials), but the key behavioral traits are clearly explained.

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 action, explains the key technical behavior in the second sentence, gives the benefit in the third, and ends with pricing. Every sentence earns its place 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?

For a zero-parameter purchase tool with no output schema, the description covers what is bought, network details, rotation behavior, and pricing. It lacks explicit mention of what the response contains (e.g., proxy credentials), but the context is strong enough for an agent to select and invoke 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 tool has zero parameters, so the baseline is 4 per the rubric. The description adds product context (1GB, mobile, rotating, Orange France/Guadeloupe) but there are no parameter semantics to document.

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 ('Buy'), the resource ('1 GB of rotating mobile proxy bandwidth'), and the use case ('for scraping and agent traffic'). The 'mobile' and '1gb' qualifiers distinguish it from sibling proxy tools like proxy_1gb and proxy_mobile_5gb.

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 frames when to use the tool: for scraping and agent traffic where residential/datacenter IPs fail, due to mobile IPs being shared by real subscribers. It provides a clear use context but does not name specific sibling alternatives or exclusions, 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 provided, the description carries the full burden of behavioral disclosure. It explains that IPs are shared by thousands of subscribers, that the proxy key is valid for 30 days, is metered per GB, and that carrier/ASN/uptime are verified live. It also states the price and payment method. Minor gaps remain around delivery mechanics and potential usage limitations.

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 four sentences, with the main purchase information front-loaded. The second sentence about sites not blocking shared IPs is useful but slightly promotional. Overall, it is concise and well-structured, with no wasted content.

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 zero parameters and no output schema, the description covers the product, validity, metering, network details, target use case, price, and payment method. It would be more complete if it explicitly described how the proxy key is delivered or what the API returns, but for a purchase tool the key facts are present.

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 tool has zero parameters, so there is no ambiguity in the schema. The description still adds context about what the user receives (a proxy key with 5GB bandwidth) and the product's metering, which is appropriate for a parameter-free 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 clearly states the tool's purpose: purchasing 5GB of mobile proxy bandwidth on a real carrier IP (Orange, France/Guadeloupe, AS16028). It distinguishes from residential proxy alternatives with the note about failing on residential exits, but it does not differentiate from the similarly named sibling 'mobile-proxy_5gb', leaving some ambiguity.

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 target use case: 'For agents whose collection jobs are already failing on residential exits.' This implies when to use the tool over residential proxies, though it does not explicitly name alternatives or state 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?

With no annotations provided, the description carries full responsibility. It discloses key behavioral traits: 'one physical SIM, one client, one address for the full day' (dedicated), 'probed every 10 minutes' (monitoring), and 'if no mobile exit is verified live, you are not charged' (billing guarantee). It also specifies pricing and payment method ($10.00 via x402 USDC), offering exceptional transparency for a paid service.

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 every sentence earns its place: the first sentence states core purpose and specs, the second provides usage context, the third emphasizes the dedicated nature, the fourth covers monitoring/guarantee, and the final sentence gives pricing. It is front-loaded with the most critical information and contains 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?

Given there is no output schema and no annotations, the description fully covers the offering: duration, carrier, data cap, exclusivity, monitoring, billing guarantee, and payment methods. It even hints at the return value ('returned with the key') without needing a separate output schema. This is complete enough for an agent to select and invoke 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 tool has zero parameters, so the baseline is 4 per the rubric. The description does not need to explain parameter syntax, but it adds context about what the user receives (carrier, ASN, uptime) which is not in the empty schema. This is sufficient for a no-parameter 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 opens with a specific verb and resource: 'Rent a dedicated mobile port for 24 hours on a real 4G/5G carrier IP' with details like Orange, France/Guadeloupe, AS16028, and 5GB cap. It clearly distinguishes itself from shared proxies by stating 'not a slice of a shared pool' and from longer rentals via 'before committing to a week or a month'. This makes 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?

It explicitly positions the tool as an entry ticket or trial: 'qualify the exit against your own target before committing to a week or a month', directly telling the user when to use it and hinting at alternatives (7d/30d proxies). It also contrasts with shared pool products, providing an exclusion criterion for when not to use this 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 the full burden. It thoroughly discloses that this is a dedicated line with one physical SIM, one client, one stable address for the term, and includes 100GB. It also states pricing and payment mechanism. While it doesn't cover post-term behavior or credential delivery, the core behavioral traits are 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 description is compact and every sentence adds value: purpose, dedication/use case, contrast with rotating pools, and pricing. It is front-loaded with the key action and includes 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?

Given the tool has no parameters and no output schema, the description provides sufficient context: duration, data cap, carrier, IP stability, and pricing. It doesn't explain credential delivery or post-term process, but for a simple purchase tool this is arguably not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters, so per the rubric the baseline is 4. The description explains the product offering without needing to document parameter syntax, which is consistent with no-parameter tools.

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 starts with a specific verb+resource: 'Rent a dedicated mobile port for 30 days' on a real 4G/5G carrier IP. It clearly distinguishes this tool from rotating pools and siblings like proxy_port_7d by emphasizing 'dedicated' and 'not access to a shared pool.'

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 a clear use case: 'so logged-in sessions and long crawls remain coherent' and contrasts with rotating pools ('Rotating pools reassign you by design'). It doesn't explicitly name alternative tools, but the context makes the appropriate choice 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 full burden. It discloses pricing ($39/call), payment method (x402 USDC), exclusivity, data cap (25 GB), live verification of carrier/ASN/uptime, and the caveat that blocking shared IPs affects real customers. This is exceptionally transparent for a paid rental 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 front-loaded with the core purpose, followed by key differentiators and pricing. Each of the three sentences adds substantive value with no redundancy or filler. It is concise yet comprehensive.

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 essential decision-making aspects: duration, IP type, data, exclusivity, price, payment, and a risk warning. It lacks explicit mention of output (e.g., how the proxy details are delivered) and start time, but given no output schema, this is a minor gap. Overall, it is contextually complete for a rental 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 are zero parameters and schema coverage is 100%, so the baseline is 4. The description does not need to explain parameters; it instead clarifies the fixed terms (7 days, 25 GB, Orange IP). This is appropriate given the empty 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 'Rent a dedicated mobile port for 7 days on a real 4G/5G carrier IP' using a specific verb and resource, and it distinguishes itself from siblings by emphasizing exclusivity ('not a slice of a shared pool') and duration. This is a fully specified purpose.

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 dedicated, sticky mobile IP for 7 days is needed. It contrasts with shared proxies and notes the line is not shared. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, so it falls 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 provided, the description takes full responsibility for disclosing behavior. It reveals the use of a French residential IP, a real Chromium instance, SPA resolution, defensive bypass, and pricing ($0.005/call via x402). This goes beyond what the schema or annotations provide, though it omits details like timeouts and error responses.

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 and a price note. The first sentence states the core function, the second adds operational context and cost. No redundant 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?

The description covers the core function, execution environment, and pricing, giving an agent the key facts to invoke it. It doesn't specify response wrapper or error handling, but since the promise is 'complete HTML,' the output is clear. The absence of an output schema makes additional detail less critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only lists 'url' as a string with no description and no required flag. The description says 'Send a URL,' which confirms the parameter's purpose and implies it is necessary, despite the schema marking it optional. It adds minimal format details (e.g., protocol requirements are not specified), so it partially compensates for the low schema coverage.

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 clear verb+resource structure: 'Send a URL and receive the complete HTML of the page after JavaScript execution.' This explicitly states the tool's function and distinguishes it from sibling tools like screenshot (image output) or proxy (no JS execution).

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 context such as 'exactly as a browser would see it,' 'resolves single-page applications,' and 'gets past defences that block datacenter ranges,' which implies when to use the tool. However, it does not name alternatives or exclusion conditions, so it stops short of explicit 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 of behavioral disclosure. It transparently mentions the cost ('$0.01/call'), payment method ('x402 (USDC)'), the use of a French residential IP, and the rendering behavior (JavaScript execution and lazy-loaded content resolution). It does not disclose failure modes or output delivery format, but the provided traits are valuable and non-obvious.

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. The first sentence states the core purpose, the second adds behavioral detail, the third lists use cases, and the final sentence gives pricing. No superfluous words; 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 covers the tool's purpose, behavior, use cases, and cost effectively, but it leaves the 'fullPage' parameter unexplained and does not specify how the PNG is returned (e.g., base64, URL). Since there is no output schema, these gaps prevent the description from being fully complete for an agent deciding how to invoke and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It only implies the 'url' parameter ('Send a URL'), but the 'fullPage' parameter is entirely undocumented. No details on expected formats, defaults, or requiredness are provided. The description adds minimal semantic value for the majority of the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Send a URL and receive a PNG screenshot of the fully rendered page.' It specifies the resource (URL), output (PNG), and key differentiators (real Chromium, French residential IP, JavaScript execution). This distinguishes it from sibling tools like 'render' or 'pdf' by describing the exact output format and rendering behavior.

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 explicit use cases: 'verify a page visually, archive evidence of a listing or a price, or hand a rendered view to a vision model for analysis.' This gives clear context on when to use the tool, though it does not explicitly mention when not to use it or compare with alternatives like 'render' or 'pdf'.

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?

No annotations exist, so description carries full burden. It discloses cost ($0.003/call, x402 payment) and output type, but does not mention rate limits, authentication, result freshness, or error handling 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?

The description is a single sentence plus cost note, but the extraneous query string '?q=&gl=&hl=' adds unnecessary detail without schema support, slightly reducing conciseness.

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, description adequately covers main output (headlines with source, date, snippet), but lacks details on result count, structure, or pagination, which are important for 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?

Schema coverage is 0%, so description should compensate. It adds context (Google News, output format) but confusingly mentions optional parameters 'gl' and 'hl' not present in the schema, misleading an agent about available inputs.

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 is a fresh news search via Google News/Serper, listing output elements (source, date, snippet) and targeting crypto/market/current-events agents, distinguishing it from sibling tools like 'search' (general web search) and 'crypto_price'.

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 suggests use for crypto/market/current-events agents but lacks explicit when-not-to-use guidance or comparison to alternatives like the general 'search' or 'crypto_price' tools among the many 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?

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the number is a physical SIM in a handset, the read operation returns structured data, and there is a cost of $0.02/call via x402. It does not mention whether messages are deleted after reading or rate limits, but for a read operation the provided context (physical SIM, pricing, structured output) is substantial and adds value beyond a generic 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 three sentences, front-loaded with the primary action first. It covers purpose, key differentiator (physical SIM), and cost—all in a compact, efficient manner. No wasted words; every sentence adds meaningful context for an agent.

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 simplicity (2 params, no output schema), the description is remarkably complete. It explains what the tool does, what data is returned (sender, body, reception time), why the physical SIM matters, and the cost model. It also clearly states the use case (verification code extraction). This is sufficient for an agent to decide whether and how to invoke 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 schema has no parameter descriptions (0% coverage), so the description must compensate. It specifies that 'phone' refers to a number rented through /v1/sms/number, and 'since' is implied to be a time filter based on the mention of 'reception time'. However, it does not explicitly explain the format of 'since' or any constraints, leaving room for ambiguity. The description gives partial meaning but not enough to fully compensate for the missing schema descriptions.

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 reads messages received by a rented phone number, listing the specific data fields (sender, body, reception time). It distinguishes itself from the sibling tool sms_number, which presumably rents numbers, by focusing on inbox reading and even mentions the endpoint /v1/sms/number for context. The verb 'read' and resource 'messages' 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?

The description gives a clear use case: extracting verification codes without human help, and notes the number is a physical SIM that receives from senders refusing virtual lines. This implies when to use it (e.g., for strict senders) but does not explicitly state when not to use it or name alternative tools. It indirectly points to sms_number for renting, which is useful but not as explicit as the calibration example.

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 physical SIM nature, returns of number and session ID, the follow-up endpoint, and the $0.05/call cost via x402. It does not mention number expiration or message arrival delays, but reasonably covers the key behavioral traits.

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 focused sentences: purpose, operational detail, return/usage flow, and pricing. Every sentence adds new information and the key action is front-loaded. No redundant content.

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 0-parameter tool without an output schema or annotations, the description covers what it does, how it works, what it returns, how to follow up, and cost. It is sufficient to select and invoke the tool correctly, especially with the sibling sms_inbox context.

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 parameters, so the baseline is 4. The description adds no parameter-specific semantics (none needed), but it does explain the output (number and session ID), which is useful context beyond the empty 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 rents a real mobile phone number to receive SMS or one-time passwords, using specific verbs and a defined resource. It distinguishes itself from virtual/VoIP lines and from the sibling sms_inbox tool by explicitly pointing to /v1/sms/inbox for reading 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?

It gives explicit context: 'For agents that must complete a phone verification step autonomously.' It contrasts with disposable virtual numbers and directs to the separate inbox tool for reading messages, making usage alternatives 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 of behavioral disclosure. It covers the actual process (audio download, Whisper run), the output format (full text plus sentence-level timestamps), the network context (residential IP), and commercial terms ($0.02/call, paid via x402/USDC). This is far more transparent than most tool descriptions.

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 moderately long but every sentence adds meaningful context: the core action, the distinction from caption scraping, the residential IP advantage, the output format, and the cost model. It is well-structured and front-loaded, though the pricing and payment details 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?

The description is highly complete for a single-parameter tool with no annotations. It explains what the tool does, how it works, what it returns, and the cost. There are no obvious missing critical details that would prevent an agent from selecting and invoking 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 schema has only one parameter (url) with 0% description coverage, so the description must compensate. It does so by specifying that the URL must point to a YouTube, TikTok, or Instagram video and that the audio is processed. It doesn't provide exact URL format or constraints, but for a single direct parameter this is suitably informative.

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 ('Transcribe the actual audio') and a specific resource ('YouTube, TikTok or Instagram video') using a named model (Whisper large-v3). It further distinguishes itself from caption scraping, making the tool's purpose unambiguous and differentiating it from potential sibling tools like extract.

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 on when to use the tool: it works on videos with no subtitles, any language, and on TikTok/Instagram where no caption track exists. It explicitly contrasts with caption scraping, but does not name a specific alternative tool or state when not to use it, so it falls short of a full 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. It discloses that data comes from Companies House, is 'authoritative,' and mentions the cost: '$0.02/call, paid per request via x402 (USDC).' However, it does not state that it is a read-only operation, mention data freshness, rate limits, or error behavior. Some transparency is provided, but 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 well-structured: it starts with the core output specification, then adds a quality note, and finally lists use cases and pricing. Each sentence earns its place, and the tool is easy to scan. Slightly longer than some tools, but still 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?

The description provides a solid overview of the tool's return content and use cases, but it omits essential parameter semantics and does not differentiate from close sibling tools like uk_company-check, uk_officers, or uk_psc. The lack of an output schema means the description could have clarified return format, but it leaves that uncovered. It is moderately 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 input schema has a single required parameter 'q' with no description, and the tool description does not explain what 'q' should contain. The description mentions company name and number as part of the output, but it does not explicitly say that 'q' is a company name or registration number. With 0% schema coverage, 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 clearly states the tool provides a 'Full profile of a UK company from Companies House' and enumerates specific data fields (name, number, type, incorporation date, address, SIC codes, filing dates, status). It also distinguishes itself by calling the data 'The authoritative record rather than a scraped copy,' setting it apart from sibling tools. This is a specific verb+resource with clear 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 explicit use cases: 'vetting British counterparties, onboarding suppliers or enriching a CRM with verified company data.' It implies this tool is for authoritative, verified lookups but does not explicitly name alternatives or when not to use it. It provides clear context but no exclusions, hence a 4.

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 return content and adds a behavioral trait (cost per call and payment method via x402). However, it omits other relevant behaviors such as whether it is read-only, possible error conditions, or rate limits. The disclosure is adequate 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?

The description is a single dense paragraph, but each sentence adds value: what it includes, how it compares to alternatives, when to use it, and its cost. It is not overly verbose and is front-loaded with the core purpose, though the cost clause at the end is slightly tangential.

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 and no annotations, the description provides a solid overview of the return data but lacks critical input format guidance and does not address error handling or response structure. For a one-parameter tool, 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?

The schema has one parameter 'q' with no description, and the description does not clarify what 'q' should contain (e.g., company number, name, or other identifier). This is a significant gap that forces the agent to guess the input format. The description adds no parameter-level meaning beyond the tool name context.

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 ('Consolidated risk check') on a UK company and enumerates the included data points (registry identity, directors, PSC, filings, insolvency). It explicitly distinguishes from siblings by noting it replaces four separate Companies House lookups, making the tool's unique role obvious.

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 a clear use case ('vetting a British supplier or client before a contract is signed') and notes that it consolidates multiple lookups, implying when to use it. However, it does not explicitly state when not to use it or mention alternative tools by name, 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 burden, and it does add useful context: data source, key fields, and that it returns both current and former officers. However, it does not disclose response format, pagination, potential data delays, or error behavior, leaving 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 and front-loaded, with the core purpose in the first sentence. The use-case sentence and pricing note are somewhat extra but contribute context, so no sentence is entirely wasted.

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 with no output schema, the description covers purpose, data content, current/former status, and use cases. It lacks parameter clarification, but overall the context is sufficient for basic 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 parameter, required string 'number', is not explained in the description. With 0% schema description coverage, the description should clarify that 'number' is the UK company number; instead, it only says 'of a UK company', forcing the agent to infer the identifier.

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 returning directors and officers of a UK company from Companies House, with specific fields (names, roles, appointment/resignation dates, nationality, etc.). This distinguishes it from sibling tools like uk_psc or uk_company, which cover different corporate 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?

It states concrete use cases: compliance checks, mapping decision-makers, detecting governance changes. It does not explicitly mention when not to use it or alternatives, but the context is clear enough for 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?

Since no annotations are provided, the description carries the full burden. It discloses the nature of the output (owners, control types, bands, dates) and the commercial terms ($0.03/call, x402 USDC), which are important operational behaviors. It does not mention rate limits or auth requirements, but for a simple data lookup these are acceptable omissions.

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 entire description is two sentences, yet covers the resource, the use case, and cost. There is no redundant wording, and front-loading with 'Persons with significant control' immediately conveys the tool's topic.

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 parameter and no output schema, the description gives a clear picture of the return data and intended usage. The only missing element is the parameter definition, but the overall context is sufficient for an agent to make an informed choice.

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 never explains that 'number' refers to the Companies House company number. With 0% schema coverage, this is a notable gap; agents would need to infer from the company context, which may lead to misuse.

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 phrase 'Persons with significant control of a UK company' and enumerates the exact data points returned (beneficial owners, control nature, ownership bands, registration dates). It further distinguishes itself from sibling tools by identifying as the 'ultimate-beneficial-owner record' required for AML checks, clearly differentiating from corporate/company-level lookups.

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 targets 'agents running KYB and compliance onboarding on British entities,' which is a clear use context. It does not name alternative tools or state exclusions, so it falls short of a 5 but still provides actionable 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 full burden of behavioral disclosure and does so thoroughly. It reveals that requests are routed through a French residential IP with a real Chromium browser, executes JavaScript, and bypasses defenses that reject datacenter ranges and plain HTTP clients. It also states the cost model ($0.02/call via x402), giving the agent critical cost and execution 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 three sentences with no filler: the first sentence states the core action, the second explains the mechanism, and the third provides usage guidance and pricing. It is front-loaded and every sentence adds 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?

Given the tool's low complexity (one required parameter, no output schema), the description covers all essential aspects: what it does, how it works, when to use it, and associated costs. An agent has enough information to select and invoke the tool appropriately.

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 no description coverage (0%), but there is only one parameter, 'url'. The description clarifies its role by framing it as 'a page that blocks you' and 'your own fetch', making it evident that the URL is the target page to unblock. While no explicit format is given, the parameter name and usage context are sufficiently clear.

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 action and resource: 'Fetch a page that blocks you, and get the HTML back.' It clearly states what the tool does and its output. It distinguishes itself from sibling tools by emphasizing the residential IP, Chromium browser, and anti-defence bypass, making it clear this is for blocked pages rather than general fetching.

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 when-to-use guidance: 'Use it as a fallback whenever your own fetch returns a challenge page, an empty shell or an access-denied response.' It does not explicitly name alternatives or when-not-to-use, but the fallback condition clearly implies the tool should not be used when regular fetching succeeds.

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 authoritative regulatory source (SEC EDGAR), the data fields returned, and the pricing/payment method ($0.02/call via x402). It lacks explicit statements about read-only behavior or error handling, but the profile nature implies a safe lookup.

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 no filler. It covers what the tool does, key data fields, the unique value proposition, use case, and pricing in just three sentences, each earning 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 simple one-parameter tool without an output schema, the description provides a solid list of returned fields, the data source, and the intended use case. However, the lack of parameter clarification and the misleading company-name wording prevent it from being fully 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 coverage is 0% and the description does not explain the 'ticker' parameter format or provide examples. The phrase 'resolving a company name to its regulatory identity' is misleading because the only accepted parameter is a ticker symbol, and the description does not clarify that the input must be a ticker rather than a company name.

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 a profile of a US public company from SEC EDGAR, listing specific fields such as legal name, CIK, ticker symbols, and exchange listings. This distinguishes it from sibling tools like us_financials and us_filings by emphasizing the regulatory identity record.

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 case: 'For agents resolving a company name to its regulatory identity before pulling financials or filings.' This tells the agent when to use this tool and implies using other tools for financials or filings, providing clear context relative to 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?

With no annotations, the description carries the burden of disclosing behavioral traits. It explains what data is returned (form type, dates, accession number, link) and mentions coverage of specific report types, plus pricing. However, it does not clarify the recency window (how far back 'recent' goes), the number of filings returned, or any limitations, leaving notable 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 and well-structured, with each sentence serving a purpose: describing the output, stating coverage, providing use cases, and noting pricing. There is no fluff or repetition, and it front-loads the most critical information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool with no output schema, the description covers the key aspects: what data is returned, which filings are covered, and appropriate use cases. However, it omits details like parameter format, pagination/limits, and recency, which would make it more 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 input schema has two required parameters (ticker, type) with no descriptions, and schema description coverage is 0%. The description does not explicitly explain the 'type' parameter or acceptable values (e.g., '10-K', '8-K'), and it uses 'form type' in the context of the output, which could confuse agents. The coverage of report types implies possible values but does not provide concrete parameter guidance.

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's purpose: retrieving recent SEC EDGAR filings for a US public company, including specific fields like form type and dates. It distinguishes itself from siblings by explicitly mentioning EDGAR and the types of filings covered. However, it lacks a direct verb (e.g., 'retrieves' or 'lists'), reading more as a noun phrase than an action-oriented 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 provides specific use cases: 'For agents monitoring disclosure, detecting material events as they are filed, or retrieving the source document behind a figure.' This gives clear context on when to use the tool, but it does not explicitly mention alternatives or exclusions, so it falls 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 provided, the description carries the full burden. It discloses the data source (SEC EDGAR XBRL), the structured nature of output, and the cost ($0.05/call via x402/USDC), which are important behavioral traits. It does not mention limitations or error cases, but for a simple read-only data tool, this is above-average 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 front-loaded with the core purpose, followed by data items, use cases, and pricing. It is a bit dense but every clause adds value. Pricing and source details are useful. It could be slightly more concise, but it is well-structured and not wasteful.

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 only one parameter and no output schema, the description explains the content (financial statement fields), the format (structured numbers), and the use cases. It does not detail the exact response structure or period coverage, but it is sufficient for an agent to decide when and how to invoke 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 schema has one parameter 'ticker' with no description (0% coverage), so the description must compensate. It adds meaning by stating the tool is for a 'US public company' from SEC EDGAR, implying the ticker is a US stock ticker. However, it doesn't explicitly state the expected format or provide an example, so it's not fully explicit but still adds useful context.

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 provides financial statements of a US public company from SEC EDGAR XBRL data, listing specific items like revenue, net income, assets, liabilities, and equity across reported periods. This distinguishes it from siblings like us_filings (raw filings) and us_snapshot (likely a snapshot), and the phrase 'Structured numbers rather than a document to parse' further separates it from extraction 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?

The description gives explicit use cases: 'For agents doing fundamental screening, comparing reported performance across periods, or feeding audited figures into a model.' It also implies a when-not-to-use via 'Structured numbers rather than a document to parse,' but it does not explicitly name alternatives or exclusions. This is clear context but not a full 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 the description carries the burden. It discloses the one-call aggregation behavior, the data sources (SEC EDGAR), and pricing ('$0.06/call, paid per request via x402 (USDC)'). However, it does not discuss error handling, rate limits, or authentication, which prevents a higher 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 two sentences with the primary purpose front-loaded. It includes necessary commercial context (pricing model) and function without any fluff. 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 tool is a simple one-parameter snapshot with no output schema. The description gives a high-level overview of return contents (identity, financials, filings) and intended use cases. It lacks detailed response structure or edge-case behavior, but for a snapshot tool the description is reasonably 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 has one required parameter 'ticker' with no description (0% schema coverage). The description implies the parameter is a US company ticker via 'US public company,' but does not provide format, examples, or acceptance criteria. Given the obvious meaning of 'ticker', a 3 is appropriate, but it does not fully compensate for the lack of schema detail.

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: 'One-call snapshot of a US public company combining SEC EDGAR identity, latest reported financials and most recent filings.' It also distinguishes from siblings by saying it 'replaces three separate lookups and the work of joining them on the right identifiers.'

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 explicit use cases: 'For agents that need a company's regulatory and financial position in a single structured answer, for screening or for briefing before deeper research.' It implies alternatives by mentioning it replaces three separate lookups, but does not explicitly name sibling tools or state 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.