mcp-server

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

Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds value by disclosing the cost ($0.01 USDC via x402) and clarifying the semantic meaning of the generated key. It does not describe the output format, but since there is no output schema, a mention of the return value (a key) is implied by 'generate a single combined... key'.

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 concise sentences that each add distinct value: what it does, what the result means, and when to use it (plus cost). There is no filler, and the most important information is front-loaded.

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

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

For a tool with only two well-documented parameters and no output schema, the description covers all essential aspects: purpose, key semantics, use case, and cost. It clearly implies the return value (the similarity key), making it complete for an agent to decide whether and how 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?

Both parameters (address, fullname) are fully documented in the schema with examples and descriptions. The description only repeats that they are used to generate the key, adding no new information about formats, constraints, or edge cases. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the tool generates a combined similarity key from a full name and address, and explains what the key signifies (records with the same key share both a similar address and name). This explicitly differentiates it from sibling tools like interzoid_fullname_match (name only) and interzoid_address_match_advanced (address only).

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 specific use case ('high-precision household/contact-level deduplication') that implies when this tool should be used. It does not explicitly name alternatives or state when not to use it, but the combined name+address focus makes the intended scenario clear. Slightly more explicit guidance (e.g., 'for name-only matching use X') would earn 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the cost ($0.01 USDC via x402) and the 'advanced AI-powered' nature, which are useful behavioral/operational details beyond the annotations. It does not describe output format or failure modes, but for a read-only key-generation tool, the added cost and scope context justify a 4.

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

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

Two sentences with no filler. The core purpose is front-loaded, followed by the handled cases and the cost. Every sentence earns its place, and the description is appropriately sized for a simple 3-parameter 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 read-only, idempotent key-generation tool with 100% schema coverage and no output schema, the description is nearly complete. It covers purpose, scope, handled cases, and cost. The only minor gap is not describing the output format (e.g., what the similarity key looks like), but the annotations and schema already provide enough for an agent 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 100%, so the schema already documents all three parameters (address, zip, algorithm). The description adds that zip is 'optional but recommended for precision' and that algorithm is a variant, but these are minor additions. Baseline 3 is appropriate because the schema carries the parameter documentation burden and the description does not meaningfully extend it.

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

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

The description states a specific verb ('Generate'), a specific resource ('US street address matching'), and the key mechanism ('AI-powered similarity key'). It also lists handled cases (unit numbers, directionals, abbreviations), which distinguishes it from generic address tools. The title 'US Street Address Match Key' reinforces the purpose, and the sibling list shows it is distinct from interzoid_global_address_match and interzoid_address_parse.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool: when you need a similarity key for US street addresses, especially with unit numbers, directionals, and abbreviations. It does not explicitly state when not to use it or name alternatives, but the sibling list and the 'US' qualifier provide clear context. The optional zip recommendation gives a usage hint, but no explicit exclusion of global addresses or parsing 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the $0.01 USDC x402 cost, which is useful operational context, but it does not disclose edge-case behavior such as handling of malformed address strings.

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 pieces: the function statement and the cost. Both earn their place; no filler or repetition of schema 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 one-parameter read-only API with rich annotations, the description is nearly complete: it states input, expected output components, and cost. It only lacks details about error handling or output formatting, which are less critical given the simple contract.

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

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

Schema coverage is 100% and the single parameter is already described with an example. The description's component list clarifies the expected granularity, but it adds little meaning beyond the schema.

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

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

The description uses a specific verb ('Parse') and identifies the target resource ('full address string') plus the concrete output components (street number, name, unit, city, state, zip). This clearly separates it from the many sibling match/standard/info tools, even without naming one.

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: if the goal is to decompose an address into standard parts, this is the tool. However, it gives no explicit when-not-to-use guidance or mentions alternatives such as interzoid_global_address_match or address_match_advanced for matching/verification.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable context: it is a 'Premium API' with a specific cost ($0.25 USDC via x402), and lists the exact return fields. This goes beyond the annotations without contradicting them.

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, purpose front-loaded, with the cost and premium status at the end. The first sentence is long due to the data-field list, but each item is informative and not redundant. It is appropriately concise for the 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 single-parameter tool with no output schema, the description is complete: it states what is returned (the full field list), the cost, and the geographic scope. An agent can call it correctly with the provided example address and know what to expect in the response.

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

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

Schema coverage is 100% for the single 'address' parameter, which already includes a description ('US property street address') and an example. The description's 'for any US property address' restates the same scope without adding new semantics. Baseline 3 applies when the schema does the heavy lifting.

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 ('Retrieve') and resource ('commercial building profile'), and scopes it to 'any US property address'. It enumerates the specific data points returned, clearly distinguishing it from sibling tools like address matching or business info. The purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it—when building-level data is needed for a US address—but does not explicitly name alternatives or state when not to use it. With a large sibling list, explicit routing would be helpful, but the purpose is clear enough that an agent can infer usage.

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?

The annotations already establish read-only, idempotent, and non-destructive behavior enshrouded in the description. The description adds meaningful context beyond annotations by disclosing that this is a premium paid API with a specific cost and payment mechanism ($0.25 USDC via x402), which is highly relevant operational information.

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

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

The description is compact and front-loaded: the main purpose appears first, followed by the returned data categories and then the crucial cost detail. Every sentence earns its place with no padding.

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

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

For a simple read-only tool with one schema-covered parametermatic and no output schema, the description conveys the essential invocation details and cost. However, among dozens of specialized interzoid siblings, the absence of any selection guidance leaves significant ambiguity about when this broad 'business info' tool should be chosen over more targeted alternatives.

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 covers 100% of the single parameter, including its description and examples, so the description does not need to elaborate. It adds no new parameter semantics beyond describing the subject as a company, which is less specific than the schema's 'Company name, website, or email'.

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 ('Retrieve') and resource ('business intelligence for a company'), and enumerates deliverable data categories such as industry, revenue, employee counts, and executive info. It does not explicitly distinguish itself from closely related siblings like interzoid_parent_company_info or interzoid_company_verification, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given for when to use this tool instead of any of the many overlapping sibling tools, nor are any exclusions or alternatives named. The cost note is business context, not usage direction.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety and idempotency. The description adds valuable behavioral context by disclosing the premium cost ($0.25 USDC via x402) and payment method, which an agent needs to know before invocation. No contradiction with annotations.

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

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

The description is two sentences: the first is a concise statement of functionality with concrete examples, the second adds cost and payment info. Both are front-loaded and carry value; there is no filler 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?

The tool has only one parameter with full schema coverage, and the description lists the types of signals returned, giving the agent a clear expectation of the output content. It also covers cost and payment. Without an output schema, this is reasonably complete for a simple lookup tool, though it doesn't specify response structure or potential errors.

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 100% coverage with a clear parameter description ('Target company name to surface buying signals for') and an example. The description adds no additional parameter semantics beyond what the schema already conveys, so the baseline 3 is appropriate.

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

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

The description clearly states the verb ('Identify') and resource ('recent buying signals for a target company') and lists specific signal types (funding, leadership changes, expansions, hiring) and its use case (sales targeting). It does not explicitly contrast with siblings but the focus on buying intent is distinct from similar tools like 'interzoid_business_info' or 'interzoid_recent_news', though it could be clearer in differentiating.

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 via 'useful for sales targeting' but does not provide explicit when-to-use guidance, alternatives, or exclusions. Siblings like 'interzoid_private_company_deal_intel' or 'interzoid_competitor_analysis' might overlap, but no comparison is given, leaving the agent to infer 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds cost information ($0.01 USDC via x402) which is beyond annotations and very useful for an agent deciding whether to call. It also notes 'Handles abbreviations, alternate spellings, and local variations' which gives insight into processing behavior. No contradiction.

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

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

Three sentences with zero waste. The primary purpose is front-loaded. Cost information is useful and concise. Could have mentioned state explicitly but overall efficient.

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

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

For a read-only, idempotent tool with no output schema, the description covers purpose and cost. It doesn't mention return format or example output, but annotations and schema cover safety and parameters. Slightly incomplete for agent decision-making but adequate given the annotations.

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

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

Schema coverage is 100%, so parameters are documented. The description, however, doesn't add additional meaning beyond what the schema provides. It doesn't explain how 'state' helps or what 'algorithm' options exist, but schema has examples. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: standardizing city names to a canonical form. It mentions specific capabilities like handling abbreviations, alternate spellings, and local variations. However, it doesn't explicitly distinguish it from sibling tools like interzoid_country_standard or interzoid_org_standard, but those are different domains (country vs. organization), so the verb+resource+scope is clear enough.

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 for cleaning city data but doesn't explicitly state when to use this over alternatives or when not to use it. It mentions cost, which is practical. No explicit exclusions or alternative routing.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety. The description adds behavioral context about the output: the key indicates similarity, not exact match, and records with the same key 'likely share both a similar company name and address.' It also discloses the cost, which is useful operational info. This goes beyond annotations without contradicting them.

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. It front-loads the core function, then explains the output meaning, then gives the use case and cost. 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 two-parameter tool with no output schema, the description adequately explains what the tool does and what the output represents (a combined key). It mentions the cost and use case. It doesn't specify the exact response format, but the 'generate a key' phrasing implies the output. This is sufficient for a simple tool, so a 4 is appropriate.

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 already provides full descriptions and examples for both company and address, so schema coverage is 100%. The description does not add any parameter-specific details beyond what the schema provides; it merely restates the general purpose. Thus, it stays at the baseline of 3 for high 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's function: generating a combined similarity key from company and address. It also names the specific use case (business-location deduplication) which distinguishes it from siblings that handle company or address separately. The verb 'generate' and the resource 'combined key' are precise.

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 context: 'Ideal for business-location deduplication across vendor, supplier, and account datasets.' This tells the agent when to use it, but it doesn't explicitly mention alternatives or when not to use it. Since the use case is clear but no exclusions are given, it scores 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds the cost of $0.01 USDC via x402 and clarifies the output is a similarity key, providing context beyond the annotations. No contradictions with annotations.

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

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

The description is four sentences with no fluff. The core function is front-loaded, followed by the interpretation of the key, the ideal use case, and the cost. Every sentence contributes value, making it well-structured and efficient.

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

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

For a simple 2-parameter tool with no output schema, the description adequately covers purpose, use case, and cost. It explains the meaning of the output key and provides practical context. The main gap is a lack of explicit output format or error conditions, but annotations and simplicity mitigate this.

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

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

Schema description coverage is 100% for both 'company' and 'fullname' parameters. The description only restates the combined nature of the two inputs without adding new semantics such as formatting, length constraints, or relationship between parameters. Since baseline is 3 for high coverage, this is appropriate.

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

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

The description uses a specific verb 'Generate' and identifies the resource as a 'combined similarity key' derived from a company name plus full name. It explicitly explains the output's meaning and clearly distinguishes from sibling tools like interzoid_fullname_match and interzoid_company_match_advanced by emphasizing the combined nature.

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 ('Ideal for contact-level deduplication within CRM, marketing, and sales datasets') and implies when to use it via the combined key concept. However, it does not explicitly name alternatives or state when not to use it, leaving some inference to the agent.

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

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

Annotations already mark the tool readOnly, idempotent, and non-destructive; the description adds useful behavioral context: equivalent company names produce the same canonical key, and there is a $0.01 x402 cost. It doesn't describe the return format or rate limits, but with these annotations that gap is minor. No contradiction.

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 short, front-loaded sentences with no redundancy; every sentence earns its place: function, illustrative equivalence behavior, and cost.

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, annotation-rich tool, the description provides core purpose, an illustrative equivalence example, and pricing. It lacks explicit routing against sibling tools and a statement of the exact return payload, but the low complexity and readOnly/idempotent hints keep this from being a serious gap.

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

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

Schema coverage is 100%, so the schema already documents the `company` parameter. The description's examples ('IBM', 'International Business Machines', 'IBM Corp') reinforce acceptable input variants but don't add format constraints or defaults beyond what the schema provides.

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?

Description uses a specific verb ('Generate') with a concrete resource ('similarity key') and scope ('company/organization name matching'). It clearly communicates the tool's output and example equivalence, but it doesn't explicitly distinguish itself from similar sibling matching tools like interzoid_org_standard or interzoid_org_match_score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a use case ('deduplication and record linkage'), which gives some context, but it never says when to prefer this tool over nearby siblings or provides exclusions. Usage guidance is therefore implied rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds valuable behavioral context: it is a premium API costing $0.25 USDC via x402, and the output includes AI-generated reasoning about legitimacy. These details inform cost and output characteristics beyond annotations.

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

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

The description is two sentences, front-loaded with purpose and then cost. It contains zero redundancy and every clause adds value. The structure is efficient and easy to parse.

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

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

For a simple tool with one parameter and no output schema, the description covers the core purpose, the score range, the reasoning component, and the cost. It lacks explicit mention of error handling or edge cases, but these are not critical for a verification tool. The annotations cover safety, so nothing essential is missing.

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

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

The input schema already provides a full description for the only parameter ('Company or organization name to verify') with an example. The description adds no additional parameter-specific meaning, such as format nuances or constraints. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the tool verifies company existence and returns a verification score (0-99) with AI-generated reasoning about legitimacy. This is specific and distinguishes it from sibling tools like interzoid_business_info or interzoid_company_match_advanced, which focus on different aspects like business data or matching.

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 no explicit guidance on when to use this tool versus alternatives. It does not mention sibling tools, exclusions, or conditions for selecting this over similar options like interzoid_company_match_advanced. An agent must infer usage solely from the purpose statement, which is insufficient given the many related 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?

The annotations already signal a safe, read-only, idempotent call. The description adds valuable operational behavior beyond those hints: it flags this as a Premium API and states the exact cost and payment rail ($0.25 USDC via x402), which an agent must know before invoking it. It also previews the returned content categories, though it does not discuss rate limits or response 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 two short sentences: the first states what the tool does and what it returns, the second gives actionable cost/payment information. There is no filler or redundant restating of the title.

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

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

For a one-parameter lookup with rich annotations, the description is largely complete: it states the input, the output content, and a critical cost gate. It does not describe the output shape or list exact response fields, but with no output schema that would add value; still, the core information an agent needs to select and call the tool is 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 single parameter is already fully documented in the schema with a description and an example, so the description does not need to add much. It adds no new semantic detail beyond 'company name' and the output promise, which matches the schema coverage of 100%. Baseline 3 is appropriate.

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

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

The description opens with a specific verb-resource pair ('Identify and analyze a company's primary competitors') and enumerates the comparison categories (market positioning, products, competitive advantages), making its function unambiguous. Among the large interzoid sibling set, this is clearly a competitor-analysis lookup rather than a match, verification, or enrichment API.

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 intended use—provide a company name and receive competitor analysis—but it never explicitly states when to prefer this tool over alternatives or mentions any exclusions. Given many interzoid_* siblings, some routing guidance would strengthen it, but the purpose alone gives reasonable 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds a meaningful operational detail: the cost of $0.01 USDC via x402, which an agent must know before invoking a paid call. It doesn't describe response format or edge cases, but with strong annotations that is acceptable.

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, information-dense sentence that front-loads the action and output list, then ends with cost. Every clause earns its place and there is 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?

No output schema exists, but the description summarizes the key return fields (ISO codes, currency, internet code, calling code) and cost. The schema documents the required and optional parameters. This is sufficient for an agent to invoke the tool correctly, though a formal response shape is not provided.

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

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

Schema description coverage is 100% for both parameters ('country' and 'algorithm'), so the description adds no parameter-level meaning beyond what the schema already provides. Baseline 3 applies.

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

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

The description names a specific verb ('Standardize') and resource ('country name') and enumerates distinct return fields ('ISO codes (2/3-letter, 3-digit), currency details, internet code, and calling code'). This clearly differentiates it from sibling interzoid_country_standard, which does not promise comprehensive info.

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 when-to-use or when-not-to-use guidance is given. The description doesn't name the sibling interzoid_country_standard or other alternatives, nor does it state criteria for selecting this tool over simpler country normalization or currency-specific tools. The output list implies comprehensive use, but the selection logic is left to inference.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is known. The description adds the cost ($0.01 USDC via x402) and the handling of variations, which are useful. However, it does not describe the output format, potential error conditions, or rate limits. It adds some context but not rich behavioral disclosure beyond the annotations.

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

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

The description is two sentences with no redundancy. The core purpose is front-loaded in the first sentence, and the second adds examples and cost information. Every sentence contributes value, and it is appropriately compact for a simple 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?

The tool is simple with only two parameters and no output schema. The description covers the purpose and examples, but it omits any mention of the output format (what the canonical form looks like) and does not explain the optional 'algorithm' parameter beyond the schema's minimal note. While annotations cover safety, the lack of return-value description and algorithm guidance leaves moderate gaps for an agent to fully understand the tool.

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

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

Schema description coverage is 100%: country is 'Country name to standardize' and algorithm is 'Algorithm variant (optional)'. The description adds examples of country variations ('Great Britain', etc.) but does not clarify the 'algorithm' parameter (e.g., when to use 'ai-medium' vs default). It adds marginal value over the schema, which already explains both parameters. Given the high coverage, a baseline 3 is appropriate.

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

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

The description clearly states the tool standardizes a country name to a canonical form, with concrete examples ('Great Britain', 'UK', 'United Kingdom') that illustrate the transformation. This is specific and unambiguous. However, it does not explicitly differentiate itself from sibling tools like interzoid_country_info or interzoid_official_name, which might also handle country names, so it loses a point for missing sibling distinction.

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 no guidance on when to use this tool versus alternatives. It does not mention that it is for normalization specifically, nor does it contrast with country_info (for detailed data) or official_name (for official nomenclature). No exclusions or preferred contexts are given, so an agent must infer usage purely from the purpose.

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

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

Annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds meaningful behavioral context by specifying that rates are 'current mid-market rates' and disclosing the exact cost of $0.01 USDC via x402. This goes beyond the annotations without contradicting them.

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 short sentences with no filler. The core purpose is front-loaded, followed by output type and cost. Every sentence contributes actionable 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 read-only tool, the description provides the essential information: what it does, what it returns, and what it costs. There is no output schema, but the phrase 'returns current mid-market rates' gives enough guidance about the result. It could mention the response format, but this is a minor gap given the tool's 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 input schema fully documents both parameters with descriptions and examples, so the description does not need to add much. The description does not discuss parameter semantics beyond the schema, but the baseline of 3 applies because schema coverage is 100%.

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 and resource: 'Get live currency exchange rates between two currencies.' It also clarifies the output as 'current mid-market rates,' leaving no ambiguity about what the tool does. No sibling tool appears to offer the same function, so no explicit differentiation is required.

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 statement implies when to use the tool: whenever a live currency exchange rate between two currencies is needed. However, it does not state exclusions or alternatives, such as not being suitable for historical rates or currency conversion calculations. This is adequate but relies on inference.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds useful context beyond the annotations: it is a premium API, cost varies by model, and results are returned as a JSON object with self-defined fields. There is no contradiction with the annotations.

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

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

The description is compact, front-loaded with purpose, and includes a concrete example and cost caveat. There is minor redundancy among 'Custom, Self-Defined,' 'Define your own,' and 'self-defined fields,' but every sentence contributes.

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

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

For a 4-parameter tool with no output schema, it explains the data flow, gives a usable example, and warns about premium cost and model variability. Remaining gaps such as error handling and absent-field behavior are partially covered by the openWorldHint and the tool's self-describing output.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's example mirrors the schema's own examples and adds little new meaning about the parameters or their interaction beyond what the schema already provides.

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 action and resource: define your own data API by supplying topic, lookup, and output fields, and receive real-world data as a JSON object. It also separates this tool from the many specialized Interzoid siblings by emphasizing self-defined/custom 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 implies when to use it—for flexible, self-defined data enrichment—but it does not explicitly name alternatives or state when not to use it. Given the large sibling set, explicit routing guidance would improve the definition.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable behavioral context: it explicitly states this is a 'Premium API' with a cost of $0.35 USDC via x402, which is not in the annotations. It also enumerates the types of data returned (MFN rates, FTA rates, VAT/GST, etc.), giving the agent a clear expectation of the response contents without needing an output schema.

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

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

The description is a single, information-dense sentence that leads with the core action ('Retrieve import customs duty rates') and then lists the specific rate types and the cost. It is concise and front-loaded, with no filler words or redundant phrases. It could be slightly shorter by omitting the exhaustive list, but that list adds value by setting expectations for the response.

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

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

For a read-only rate retrieval tool with full parameter documentation and safety annotations, the description is nearly complete. It covers the purpose, the type of data returned, and the cost. There is no output schema, but the description compensates by listing the expected data categories. It doesn't mention rate limits or authentication, but the annotations cover idempotency and safety, and the cost mention implies payment requirements. Overall, it gives the agent enough to call 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 description coverage is 100%: both 'hscode' and 'lookup' have clear descriptions with examples (e.g., '8471.30' and 'Germany'). The description adds minimal new parameter semantics—it repeats that any HS code and any country are accepted, which is already implied by the schema. Since the schema fully documents the parameters, a baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Retrieve' and the specific resource: import customs duty rates for any HS code entering any country. It lists the specific types of rates and duties included (MFN, preferential FTA, VAT/GST, additional duties, de minimis, non-tariff restrictions), which fully distinguishes it from sibling tools like currency_rate, eu_vat_rates, and sales_use_tax_rates. The name and description together leave no ambiguity about what this tool does.

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 implicitly indicates when to use this tool—whenever customs duty rates are needed for a given HS code and destination country. It does not explicitly name alternatives or state when not to use it, but given the unique subject matter among the siblings, an agent can easily infer its use case. The cost mention (Premium API) also suggests it may be used selectively, though it doesn't contrast with cheaper 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?

Annotations already mark this as read-only, idempotent, open-world, and non-destructive, so the description doesn't need to restate safety. It adds valuable behavioral context: the result includes a 0-99 score and AI-generated risk analysis, it checks deliverability and disposable addresses, and it is a premium paid API costing $0.25 USDC via x402. No contradiction with annotations.

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

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

The description is three short sentences with no filler. The primary action and key output are front-loaded, followed by useful validation behaviors and pricing. Every sentence contributes information an agent needs.

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

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

For a one-parameter read-only lookup with no output schema, the description gives enough to call it correctly: the score range, the nature of the analysis, the validations performed, and the cost. Nothing critical for selecting or invoking this tool is missing.

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

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

The schema has 100% documentation coverage for the single parameter, and the schema's description already explains that 'lookup' is the email address to score. The tool description does not add meaningful parameter-level detail beyond that, so the baseline score of 3 applies.

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

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

The description opens with a concrete verb and resource: 'Get an email trust score (0-99)' along with the AI-risk-analysis output. This clearly identifies what the tool does and sets it apart from the many interzoid_* sibling tools, none of which target email trust or deliverability.

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 makes the intended use obvious through 'email trust score', 'validates deliverability', 'identifies disposable addresses', and 'assesses legitimacy'. It does not explicitly name an alternative or say when not to use it, but the scope is clear enough that an agent can route email-validation tasks here without confusion.

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

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

Annotations already communicate readOnly, idempotent, openWorld, and non-destructive behavior. The description adds valuable beyond-annotation context by disclosing the monetary cost ($0.01 USDC via x402), which is a meaningful operational constraint. It also implies the output shape by listing the possible entity types.

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 no redundancy. The main purpose is front-loaded, and the cost note is separated cleanly at the end. 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, read-only classification tool with no output schema, the description covers the core what, the categories, and the cost. It is slightly thin on output format details, but the implied return values (person/org/location/other) are sufficiently clear for correct invocation.

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

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

Schema coverage is 100% and the schema already documents 'text' as 'Text data value to classify' with an example. The description adds contextual meaning by explaining that the value will be classified into one of the listed entity categories, but it does not need to compensate for schema gaps since there are none.

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 and resource ('Determine the entity type of a data value') and explicitly enumerates the classification categories: person, company/organization, location, or other. This makes the tool's purpose clear and distinguishes it from sibling tools like interzoid_industry_classification or interzoid_identify_language, which target different classification dimensions.

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 is given about when to use this tool versus alternatives, nor are any alternative tool names or exclusion conditions mentioned. The only additional context is the cost line, which is useful but does not help the agent choose this tool over a sibling.

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

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

Annotations already cover readOnlyHint, openWorldHint, and idempotentHint, so the description does not need to restate those. It adds meaningful behavioral context by labeling the tool as a 'Premium API' with a specific cost and payment method ('$0.25 USDC via x402'), which is not captured by the schema or annotations.

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

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

The description is two efficient sentences: the first states the action, resource, and included content, and the second adds the pricing/payment constraint. It is front-loaded with the core purpose 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?

For a single-parameter lookup with strong annotations, the description is sufficient: it names the input type, previews the response content, and flags the cost. It does not describe output format, but that is more acceptable given no output schema and the simplicity of 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 owns parameter documentation: 'lookup' is described as 'Company name to retrieve ESG profile for' and includes an example. The tool description adds little beyond repeating that it is for a company, so it does not materially enhance the schema's already-complete 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?

Description uses the specific verb 'Retrieve' and identifies a clear resource: 'ESG (Environmental, Social, Governance) and sustainability profile for a company.' It further lists the content areas (initiatives, ratings, controversies, reporting frameworks), which distinguishes it from sibling tools like business_info or executive_profile.

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 makes the intended use clear—retrieve an ESG profile for a company—but it does not explicitly state when to choose this tool over siblings or when not to use it. The premium-pricing note adds practical conditions, but routing guidance is only implied by the tool's domain-specific name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it is a 'Premium API' with a specific cost ($0.25 USDC via x402), which is important for an agent deciding whether to invoke a paid tool. It also discloses the breadth of the lookup (country name, ISO code, city, or address) and the richness of the response categories.

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 core purpose before adding cost and scope details. Every sentence earns its place: the first defines the tool's function and scope, the second discloses the premium cost. It is slightly dense with the long list of categories, but that list is genuinely useful for distinguishing the tool's output.

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

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

For a single-parameter read-only lookup tool with no output schema, the description is quite complete. It covers what the tool returns (VAT rates by category, thresholds, exceptions), the geographic scope, and the cost. The only minor gap is that it doesn't describe the exact response format, but with no output schema and a simple lookup parameter, the description provides enough for an agent to call 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 100%, so the schema already documents the 'lookup' parameter well, including examples. The description adds meaning by clarifying that the lookup accepts country name, ISO code, city, or address, and by explaining what the returned data will contain (category breakdown, thresholds, exceptions). This goes beyond the schema's minimal 'Country name, ISO code, city, or address'.

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

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

The description states a specific verb ('Retrieve'), a clear resource ('current VAT rates for any European country'), and a detailed scope (EU-27, EEA, UK, Switzerland, non-EU Europe). It also lists the category breakdown (standard, reduced, super-reduced, zero-rated, exempt) plus registration thresholds and territorial exceptions, which distinguishes it from sibling tools like interzoid_sales_use_tax_rates or interzoid_customs_duty_rates.

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 clearly implies when to use this tool: when European VAT rates are needed, and the scope statement helps an agent select it over tax-related siblings. It does not explicitly name alternatives or state when not to use it, but the geographic and category specificity provides strong contextual 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable non-schema context by disclosing this is a 'Premium API' with a specific cost ('$0.25 USDC via x402'), which is an important constraint for an agent deciding to invoke it. It also describes the kind of data returned, adding transparency beyond the annotations.

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

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

The description is two short, front-loaded sentences. The first sentence states the core purpose, and the second covers the premium/cost information. Every word earns its place; there is no redundant filler or abstraction.

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 is largely sufficient. It explains what data is returned (leadership, roles, background), notes the cost, and the schema fully documents the parameter. Missing are only minor details like response format or error behavior, which are not critical for invoking 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 description coverage is 100%: the 'lookup' parameter already has a clear description and example ('Company name and job title (e.g. 'Coinbase CEO')'). The tool description does not add new meaning to the parameter; it only restates the general purpose. Per rubric, when schema coverage is high, a baseline of 3 is appropriate.

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

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

The description uses a specific verb 'Retrieve' with a clear resource: 'executive profile information for a company.' It enumerates what is included ('leadership details, roles, and professional background'), which distinguishes it from sibling tools like business_info or company_verification. The tool name and description align perfectly, leaving no 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 implies when to use the tool—whenever an executive profile is needed—but gives no explicit guidance about alternatives or when not to use it. There is no mention of sibling tools or exclusion criteria, and the 'for a company' phrasing only loosely frames the use case. The agent must infer usage from the purpose alone.

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

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

Annotations cover read-only, idempotent, and non-destructive traits. The description adds 'Premium API' and cost ($0.25 USDC via x402), which are behavioral traits not present in annotations. It also clarifies the scope of the returned data. However, it doesn't mention rate limits or data availability limitations, so it's not fully exhaustive.

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

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

Two sentences with no padding. The main action and scope are front-loaded, and cost/payment info is placed at the end. Every word 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 single-parameter lookup with no output schema, the description adequately explains the return concept ('profile' with facility types). It doesn't detail response structure or error conditions, but the annotation's safety profile and simple input make this acceptable.

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

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

Schema coverage is 100% and the schema already describes 'lookup' clearly as a company name. The tool description adds no parameter-level semantics beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource: 'Retrieve a profile of a company's corporate facilities' and enumerates location types (headquarters, regional offices, etc.). This clearly distinguishes it from sibling tools like interzoid_building_profile (single building) and interzoid_business_info (general business info).

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 no guidance on when to choose this tool over alternatives. It does not mention interzoid_building_profile for single-building queries or any exclusions. The implied use case is clear, but the agent must infer it; no explicit when/when-not 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context: the operation costs $0.01 USDC via x402 and produces the same key across common name variations. It also does not contradict any annotation.

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 carry the full message: purpose first, then concrete examples and cost. There is no filler or 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 one-parameter tool with no output schema, the description provides the core purpose, valid input variations, expected normalization behavior, and cost. The read-only and idempotent traits are already supplied by annotations, so nothing operationally critical is missing.

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

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

The schema already documents the single required 'fullname' parameter with an example, and coverage is 100%. The description enriches the parameter's meaning by showing accepted formats like 'Bob Smith', 'Robert Smith', and 'Smith, Robert J.', which clarifies that name order and format variations are valid 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 opens with a specific action and artifact: 'Generate an AI-powered similarity key for individual/person name matching.' It also illustrates the normalization behavior with concrete name variations. It does not explicitly name a sibling alternative, but the 'similarity key' phrasing helps separate it from tools like interzoid_fullname_match_score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The examples imply the intended use case: turning differently formatted person names into the same key for matching. However, it gives no explicit when-to-use or when-not-to-use guidance and does not point to sibling tools such as interzoid_fullname_match_score or interzoid_company_and_fullname_match, so an agent must infer the right 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?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral details beyond annotations: the 0-100 score range, handling of name order/nicknames/abbreviations, and the $0.01 USDC cost via x402. It does not describe potential failure modes or rate limits, but for a simple read-only API this is strong.

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 plus a one-sentence cost note. It front-loads the core purpose and output, then adds useful behavioral and cost information 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 simple two-string tool with no output schema, the description is largely complete: it explains the input, the returned score, key normalization behaviors, and cost. The only notable gap is the lack of any distinction from the sibling interzoid_fullname_match, which could cause selection ambiguity in a crowded tool list.

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 100% description coverage with clear labels and examples for both parameters. The description adds genuinely useful parameter semantics by noting that name order, nicknames, and abbreviations are handled, implying the two name strings may be swapped or stylistically different. This goes beyond the schema's basic 'first full name' and 'second full name' definitions.

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 compares two individual/person names and returns a 0-100 similarity score, naming the resource and expected output. However, it does not explicitly differentiate itself from the closely named sibling interzoid_fullname_match, so it stops short of full sibling distinction.

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: use this when comparing two individual/person names rather than addresses or companies. It also implies suitability for names with order variations, nicknames, and abbreviations. It does not explicitly name alternatives or state when not to use the tool, 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?

Annotations already indicate readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the tool is clearly safe and non-mutating. However, the description adds only the cost of $0.01 USDC via x402, which is a payment detail, but it does not explain potential outcomes like whether the tool might return 'unisex' for ambiguous names, the confidence level of the result, or what happens for names not recognized. It also doesn't mention any external call or latency implications beyond cost.

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 exceptionally concise: two sentences that state the purpose, mention international support, and include cost information. Every sentence provides value and is front-loaded with the core purpose.

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, a clear schema, and comprehensive annotations (readOnly, openWorld, idempotent), the description is mostly adequate. However, it lacks details on output format or potential ambiguity in results, which could matter for an AI agent interpreting the response. Also, the openWorldHint suggests the tool may have variable behavior, but the description doesn't hint at what. Still, the simplicity of the tool keeps the completeness at a reasonable level.

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 100% coverage with a clear description and example for the 'name' parameter. The description adds the context of international name support, but that's minimal added value. Since schema coverage is high, baseline is 3, and there's no significant additional semantics provided in the description beyond what's in 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 purpose with a specific verb ('Determine') and resource ('likely gender associated with an individual name'). It also mentions support for international names, which distinguishes it slightly from name-related siblings like interzoid_name_origin, though it doesn't explicitly contrast with any 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?

The description implies the tool is for determining gender from a first name, and notes it supports international names, giving clear context. However, it does not explicitly state when to use this tool versus alternatives like interzoid_name_origin or interzoid_fullname_match, nor does it provide exclusions or guidance on selecting it among the many name-related 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?

Annotations already cover read-only, non-destructive, idempotent behavior. The description adds valuable context beyond annotations by clarifying that the tool generates a similarity key, works across international formats, and explicitly discloses a cost of $0.01 USDC via x402. This helps the agent anticipate side effects and expectations.

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 at three sentences, front-loaded with the core action, then the behavioral scope, and finally the cost detail. Each sentence earns its place with no redundant filler or repetition of schema 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 single-parameter tool with full schema coverage and annotations describing safety, the description covers purpose, international scope, and cost. The absence of an output schema means the exact return shape is not described, but 'similarity key' sufficiently implies the output for correct invocation.

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

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

Schema description coverage is 100%, with the single parameter 'address' already documented as a 'Full international address string' and an example provided. The description adds no further parameter-specific semantics, so the baseline of 3 is appropriate.

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

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

The description uses a specific action ('Generate') and resource ('AI-powered similarity key') with an explicit scope ('global/international address matching'). This distinguishes it from siblings like interzoid_address_match_advanced and interzoid_address_parse, and the title 'Global Address Match Key' reinforces the unique focus.

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 phrase 'Handles international address formats and variations across countries' clearly signals when this tool is appropriate—for non-domestic or cross-country address comparison. It does not explicitly name alternatives or exclusions, but the global/international framing provides sufficient context 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?

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds valuable context beyond the annotations by detailing the exact return shape (total load time, HTTP status, phase-by-phase breakdown, content preview) and disclosing a monetary cost of $0.01 USDC via x402.

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 earning its place: core action, return value breakdown, applicable use cases, and cost. The most important information is front-loaded, and there is no redundant or filler 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 two-parameter tool with a comprehensive schema and robust annotations, the description covers purpose, output shape, use cases, and cost. The only minor omission is explicit handling of edge cases like unreachable URLs or non-200 responses, but the provided detail is sufficient 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 description coverage is 100%, with both url and origin fully documented including default values and the origin enum. The description's phrases 'any URL' and 'chosen global location' merely restate the parameters without adding syntax, defaults, or format details beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description states a specific verb and resource: 'Measure real-world page load performance (response time) for any URL from a chosen global location.' It also enumerates the returned data and mentions use cases. No sibling tool covers latency or performance measurement, so it is clearly differentiated from the other interzoid 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 usage context via 'Useful for global latency monitoring, CDN validation, and uptime/performance checks,' which tells an agent when to use it. It does not explicitly name an alternative or describe when not to use it, but since no sibling covers this domain, the guidance is sufficient without exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context by disclosing the cost and payment mechanism, '$0.01 USDC via x402,' and specifies the response content categories. It does not, however, describe error or rate-limit behavior, though those are less critical for a read-only 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 a single compact sentence that leads with the core purpose, then lists output fields, then gives cost. Every clause adds useful information and no words are 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 one-parameter, low-complexity tool with no output schema, the description provides sufficient context: what the tool does, where it applies, what it returns, and that it costs money. It does not detail the exact JSON return shape or error behavior, but the included output fields are enough for an agent to use the result 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 has 100% coverage: the single 'location' parameter is described with examples. The description reinforces that the location is any city name but does not add meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description begins with a specific action and resource: 'Get current weather for any city worldwide.' It enumerates the key outputs (temperature in F/C, conditions, wind speed), making the tool's function unmistakable. Among the many sibling tools, it is clearly the weather lookup tool, so no confusion remains.

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 phrase 'current weather for any city worldwide' establishes when the tool is appropriate and makes its scope clear. It does not explicitly name alternatives or exclusions, but no sibling tool provides weather data, so the context is sufficient for an agent to select 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description goes further by disclosing that this is a paid Premium API with a concrete cost via x402, and by indicating the output scope (contracts, agencies, values, award history), which is useful behavioral context.

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

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

Two sentences with zero filler. The first sentence states what the tool does and what it returns; the second gives essential commercial terms. The most important information is front-loaded.

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

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

The tool is simple (one required parameter), annotations cover read-only/idempotent behavior, and the description lists the main return categories despite no output schema. It does not specify exact response formatting or data freshness caveats, but for a single-field lookup this 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?

With one parameter and 100% schema description coverage, the schema already defines 'lookup' as the company name. The description does not add extra parameter guidance, so this is at the schema-covered baseline of 3.

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 ('Retrieve') and resource ('US government contract information for a company'), and lists concrete data categories: active contracts, agencies, contract values, and award history. This clearly differentiates it from the many sibling tools focused on addresses, company matching, or stock 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 clearly establishes that this tool is for retrieving US government contract details for a company, and adds the premium billing context. It does not explicitly name alternatives or exclusions, but the domain is specific enough that an agent can judge when 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about cost ($0.01 USDC via x402) and breadth of language support, but does not disclose potential input limits, error behavior, or output format details. No contradiction with annotations.

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

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

The description is two short sentences with no filler. The core purpose is front-loaded, and the cost detail is a meaningful operational fact that 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 simple one-parameter, read-only tool, the description combined with the schema and annotations is nearly sufficient. The main gap is the absence of output format details (e.g., whether it returns a language code, name, or confidence score), since there is no output schema to fill that gap.

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

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

Schema coverage is 100% and the text parameter already has a clear description and example. The description adds no additional parameter-level meaning beyond restating that a text string is the input, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Identify the language of a given text string.' It clearly conveys the tool's function and implicitly distinguishes it from translation siblings such as interzoid_translate_to_english, though it does not explicitly name any alternative tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives like translate_to_any or translate_to_english, nor does it mention exclusions or edge cases. The only additional context is cost and broad language support, which does not help an agent decide between this and related 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?

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds value by noting it is a 'Premium API' with a cost of $0.25 USDC via x402, which is a behavioral trait beyond annotations. It also lists output fields, giving the agent an idea of what to expect.

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 outputs, and then adds cost and premium status. No wasted 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 tool is simple with one parameter, annotations cover safety, and the description clearly states the return fields (NAICS, SIC, sector, subsector, business activity, confidence) and the cost. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the parameter 'lookup' is well described in the schema with an example. The tool description does not add extra parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool identifies and categorizes a company's primary industry classification, listing specific outputs (NAICS, SIC, sector, subsector, business activity, confidence). This is a specific verb+resource and distinguishes it from siblings like company verification or matching 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 does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. It implies the use case through its purpose but provides no direct guidance on selection among the many 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?

Annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds genuinely useful behavioral context beyond those annotations: it is a premium API with a specific cost ($0.25 USDC via x402) and it returns a defined set of data categories. No contradiction with annotations.

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

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

Two sentences with no filler: the first fronts the purpose and return categories, the second conveys the paid nature. Every clause adds selection or invocation 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, read-only lookup with rich annotations, the description is nearly complete: it names the input, the output categories, and the cost. It stops short of describing the exact response shape, but the listed profile categories give an agent enough expectation to invoke and interpret the result 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 100%, with the lookup parameter clearly documented as 'IPv4 or IPv6 address to profile' and an example provided. The tool description does not add parameter-level detail, but it does not need to because the schema already fully describes the only parameter.

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

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

The description uses a specific verb ('Get'), names the resource ('comprehensive profile for an IP address'), and enumerates the key output categories (geolocation, ISP, organization, CIDR block, reputation assessment). This makes the tool's purpose unmistakable and distinguishes it from the many sibling profile tools aimed at other entity 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 makes the usage context clear: use it when you need a profile of an IP address. It does not explicitly name alternatives or state when-not-to-use, but the resource type is specific enough that no sibling tool is a true substitute, so explicit exclusions are not necessary.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond those: rates are 'current', the tool implements a specific IRS revenue procedure, it classifies locations into High-Cost or Low-Cost, and it lists pricing/delivery details ('Premium API', '$0.25 USDC via x402'). No contradictions with annotations.

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

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

Three concise sentences deliver purpose, regulatory basis, output categories, and cost without redundancy. The most important information is front-loaded, and every sentence adds value beyond the schema or annotations.

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

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

For a single-parameter lookup tool with no output schema, the description sufficiently explains what the agent will get back (classification, lodging rate, M&IE rate), the supported input scope, and the pricing model. Nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, so the parameter is already fully documented with an example and a clear description. The tool description adds no new parameter-level detail, which is acceptable given the high schema coverage; the baseline of 3 applies.

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

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

The description names a specific verb ('Retrieve'), a precise resource ('IRS high-low method per diem rates'), and a geographic scope ('any US location'). It also includes distinctive output details (High-Cost/Low-Cost classification, lodging and M&IE components) that separate it from the many other Interzoid data-lookup 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 clearly frames when the tool is relevant: 'to support accountable-plan travel reimbursement (Revenue Procedure 2019-48)'. It does not name alternatives or state when-not-to-use, but no sibling tool appears to provide per diem rates, and the use case is specific enough to guide selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it is a premium API with a specific cost ($0.25 USDC via x402), which is important for an agent deciding whether to invoke it. It also discloses the breadth of the response (issuer type, credit standing, debt, pension exposure, etc.). No contradiction with annotations.

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

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

The description is a single, information-dense sentence that front-loads the core purpose and then lists the profile contents. The cost disclosure is a necessary addition. It is slightly long but every clause earns its place; 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 read-only lookup tool with one well-documented parameter and no output schema, the description covers the input, the output scope, and the cost. It does not describe the exact response format, but with no output schema and a research-profile tool, the listed content areas are sufficient for an agent to know what to expect. The cost disclosure is a notable completeness plus.

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

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

Schema coverage is 100% and the single parameter 'lookup' has a clear description and example. The tool description adds context about what the lookup value should be (a municipal issuer name) but does not add much beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Retrieve') and resource ('research profile on any US municipal securities issuer'), enumerates the issuer types and the profile contents, and distinguishes it from sibling tools by its domain (municipal securities). It is immediately clear what this tool does and how it differs from the many other interzoid_* 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 implies when to use it: whenever an agent needs a research profile on a US municipal securities issuer, and it lists the covered issuer types. It does not explicitly name alternatives or exclusions, but the domain is narrow enough that the usage context is clear. A small deduction for not explicitly saying 'use this instead of X'.

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?

The description adds practical behavioral details beyond the annotations: the 'likely' qualifier indicates a probabilistic result, and it discloses the cost ($0.01 USDC via x402), which annotations do not cover. It does not repeat the read-only, idempotent, and non-destructive hints already present.

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

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

Two sentences with no redundant words. The core purpose is front-loaded, followed by use cases and cost. 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?

Given the single parameter and the annotations that already cover safety and idempotency, the description is nearly complete. It could optionally describe the output format, but with no output schema, the return value of 'origin' is strongly implied by the tool name and description.

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 covers 100% of parameter meaning with the description 'Full name to determine origin for' and an example, so the tool description does not need to add more. It provides no additional parameter-level semantics, but by baseline rules for high schema coverage, a 3 is appropriate.

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

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

The description clearly states a specific action (determine) applied to a resource (individual name) with a well-defined result (likely cultural or geographic origin). This distinguishes it from sibling tools like interzoid_fullname_match (matching) and interzoid_gender (gender), which address different questions.

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 context for when to use the tool ('useful for demographic analysis and internationalization'), but stops short of explicit exclusions or alternative recommendations. The use cases are specific enough to guide selection without needing to name 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?

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context beyond annotations by specifying what results include and noting the premium API cost of $0.25 USDC via x402, which is a significant operational consideration.

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 short sentences, with the core purpose front-loaded and the cost/payment note appended without adding noise. 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?

The description explains the expected output scope and the cost, and with no output schema, it gives enough for an agent to decide and invoke the tool. It does not detail response structure or edge cases, but for a simple single-parameter read-only lookup this is acceptable.

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

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

Schema description coverage is 100% for the single `lookup` parameter, which is already described as a 'Reference address or location'. The description reinforces this by saying 'address or location' but does not add substantial syntax or format guidance beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb and resource ('Find nearest coffee shops') and enumerates the returned details (names, addresses, distances, basic details). It is clearly distinct from all sibling Interzoid tools, which are other data lookup utilities.

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?

Clear context is provided: this tool is for finding coffee shops near an address or location. It does not explicitly state when not to use it or name alternatives, but its purpose is sufficiently unique among the siblings that no exclusion is necessary.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds useful context (Premium API, use cases) but does not disclose potential behavioral traits like rate limits, required authentication, or error handling. Since annotations carry the safety profile, the description adds modest value without contradiction.

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-loading the core functionality and output fields, then adding use cases and pricing tier. It is efficient with no filler, though slightly dense. It earns a 4 for being well-structured and informative without unnecessary verbosity.

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 fully compensates by listing all returned fields and specifying input flexibility (typos, local languages, tickers). It also gives practical context (use cases) and notes the premium nature. Everything an agent needs to decide and call the tool correctly is 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 input schema fully describes the single parameter 'lookup' with examples and a description. The tool description essentially repeats the schema's parameter description (organization name in any form) without adding new semantic detail. With 100% schema coverage, the baseline is 3, and the description does not exceed it.

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 resolves any organization name to its official English legal name and lists a comprehensive set of output attributes (commercial name, legal form, country, registry ID, status, documentation URL). It also names concrete use cases (KYB, supplier verification, sanctions screening, dataset normalization), making it distinct from sibling tools like org_standard or company_verification by focusing on the 'official' name resolution.

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 intended use cases (KYB, supplier verification, etc.), giving clear context for when to use it. However, it does not explicitly compare to alternatives or state when not to use it, leaving some ambiguity relative to sibling tools that also handle organization names. It does mention it's a 'Premium API', hinting at cost but not contrasting with free 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?

Annotations already cover readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds valuable behavioral context by disclosing the cost of $0.01 USDC via x402 and the output as a 0-100 score, which is not present in annotations. This enriches the agent's understanding of side effects and expectations.

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 statement, front-loading the core action and output in the first sentence. It avoids redundancy and includes only essential information: purpose, output range, use case, and cost. This is a model of efficient prose.

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

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

With no output schema, the description correctly explains that the tool returns a match score from 0-100, covering the primary return value. It also mentions cost, which is relevant for invocation. Missing details such as response envelope or error behavior are minor for a simple comparison tool, so the definition is nearly 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 100% with both parameters described as 'First organization name' and 'Second organization name to compare'. The description only says 'two organization/company names' without adding additional semantic detail like normalization, matching algorithm behavior, or format preferences. Since the schema already documents parameters fully, the baseline of 3 is appropriate.

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

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

The description clearly states the tool compares two organization/company names and returns a 0-100 similarity score, naming the exact verb and resource. This distinguishes it from sibling tools like address matching or full name matching, and the phrase 'organization/company names' differentiates it from interzoid_company_match_advanced which implies broader company matching.

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 usefulness for determining if two company names refer to the same entity, providing a clear use case. However, it does not mention when to prefer this tool over alternatives like interzoid_company_match_advanced or interzoid_company_verification, nor does it specify any exclusions or conditions that would make a sibling more 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so safety is covered. The description adds valuable operational context: it discloses the $0.01 USDC cost via x402, a critical fact for an agent deciding to invoke a paid tool, and specifies the normalization scope (abbreviations, suffixes, formatting). No contradiction with annotations.

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

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

Two sentences, front-loaded with the core action and outcome. The example and cost are appended without fluff; every clause 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, read-only tool with rich annotations, the description covers purpose, input variants, example output, and cost. It does not describe the exact response shape, but in the absence of an output schema and for such a simple operation, the canonical-form outcome is inferable from the example. Minor gap: no failure/edge-case behavior (e.g., unknown org names).

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 fully describes the only parameter ('org') with an example, so baseline is 3. The description adds meaning by explaining what kinds of input are handled ('abbreviations, suffixes, and formatting') and reiterating the transformation with a concrete example, clarifying that period-laden forms like 'b.o.a.' are valid 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?

States a specific verb ('Standardize'), a clear resource ('an organization name'), and the outcome ('canonical form'). Gives a concrete example that disambiguates from sibling matching tools like interzoid_org_match_score. The title and description align, and the behavior is distinct from other entity standardization 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 the use case (normalizing messy org names) but never tells the agent when to prefer this over related siblings such as interzoid_org_match_score or interzoid_company_verification. No exclusions or alternative routing are provided. With over 50 siblings, explicit guidance would materially help 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds the premium API status and cost ($0.25 USDC via x402), which is useful operational context, but it does not disclose response behavior, rate limits, or data coverage.

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 crisp sentences with no filler. The first sentence states action and input scope; the second adds the ownership-hierarchy outcome and the cost. 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 low-complexity, single-parameter tool with full schema coverage and safety annotations, the description is largely complete: it states what the tool does, what input it accepts, and that it costs money. It could be stronger by naming sibling tools that cover other company data angles, but nothing essential to calling the tool is missing.

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

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

The schema description covers the lookup parameter 100% already, so the baseline is 3. The description adds that the input can be a company or subsidiary, which is mildly helpful, but it does not meaningfully expand on what the schema already states.

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

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

The description names a specific verb and resource ('Retrieve parent company information') and clarifies the domain with corporate ownership hierarchies and holding company relationships. It does not explicitly differentiate itself from sibling tools like interzoid_business_info or interzoid_company_verification, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear use context: it applies to a company or subsidiary and answers parent/ownership questions. It does not mention exclusions or explicitly route to alternatives among the many sibling tools, so it is clear but not fully explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it discloses that this is a 'Premium API' with a specific cost of $0.25 USDC via x402, which is critical for an agent deciding whether to invoke a paid tool. It also lists the output dimensions, giving the agent expectations about the response.

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

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

Two sentences with no filler. The first sentence front-loads the core purpose and output dimensions; the second adds the essential cost warning. Every word 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 read-only tool with full schema coverage and no output schema, the description is nearly complete. It covers what the tool does, what it returns, and the cost implication. The only minor gap is that it doesn't describe the response format or any error conditions, but with no output schema and a simple lookup parameter, this is acceptable.

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

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

Schema description coverage is 100%, so the schema already documents the single 'lookup' parameter with an example. The description adds the context that the parameter is a phone number to profile, but it does not add format details beyond the schema's example. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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

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

The description states a specific verb ('Get profile') and resource ('phone number'), and enumerates the exact data dimensions returned: carrier, line type, geographic location, validation status, and risk assessment. This clearly distinguishes it from sibling tools like interzoid_ip_profile or interzoid_building_profile, which target different entities.

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 context by naming the resource type and the profile dimensions, but it does not explicitly state when to choose this tool over alternatives, nor does it mention any prerequisites or exclusions. An agent can infer that this is for phone numbers, but there is no explicit routing guidance relative to the many 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?

Annotations already declare readOnlyHint and idempotentHint, and the description adds useful behavioral context about cost and payment: 'Premium API. Cost: $0.25 USDC via x402.' This is material information for an agent deciding whether to invoke the tool exactly as written. It does not contradict the annotations.

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

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

The description is two short sentences with no wasted words, front-loading the core function before the cost detail. Every clause adds useful information for selection or invocation.

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

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

For a simple one-parameter read-only lookup with high schema coverage and safety annotations, the description is nearly sufficient. It names the key data categories and the premium cost, but it does not describe return format, page limits, or auth details; these are minor given the low complexity.

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

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

The schema covers the single parameter comprehensively with 'lookup' described as 'Private company name' and an example ('Anthropic'). The description adds no parameter-specific detail beyond the overall scope, so the schema carries the semantic weight; baseline 3 applies.

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

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

The description uses a specific verb ('Retrieve') and names a concrete resource ('private company deal intelligence') followed by illustrative data categories such as funding rounds, valuations, investors, M&A activity, and ownership changes. This makes the tool's purpose clear, though it does not explicitly distinguish itself from sibling tools like parent_company_info or business_info.

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—when you need private company deal data—but it provides no explicit alternatives, exclusions, or comparison to other tools. There is enough context to infer usage, but no direct guidance on choosing between this and similar 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it's AI-powered, generates a similarity key (not a match decision), and discloses the cost ($0.01 USDC via x402), which is valuable operational information beyond the annotations.

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

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

Three sentences with no waste. The core purpose is front-loaded, followed by scope clarification and cost disclosure. The cost sentence is arguably extra but earns its place as operational context.

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

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

For a read-only, idempotent tool with 100% schema coverage and no output schema, the description covers the essential purpose, scope, and cost. It doesn't describe the return format, but with no output schema and a simple key-generation task, this is a minor gap.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds the context that the 'product' parameter can be a name, description, or model, which aligns with the schema's description. It doesn't add detail about the 'algorithm' parameter beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description states a specific verb ('Generate') and resource ('similarity key for product name matching'), and clarifies it handles variations in product names, model numbers, and descriptions. It doesn't explicitly distinguish from sibling tools, but the product-specific focus is clear enough among the many Interzoid 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 usage for product name matching and mentions the optional algorithm variant, but it doesn't explicitly state when to use this tool versus alternatives like interzoid_company_match_advanced or interzoid_org_match_score. No exclusions or alternative routing are provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the premium cost and payment method ($0.25 USDC via x402), which is critical for cost-sensitive agents. It also clarifies the lookup attribute is flexible (product, brand, or category). No contradiction.

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, concise and front-loaded with the main purpose. The cost detail is essential and placed at the end without extra fluff. Slightly more structure could be added, but overall it's efficient.

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

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

For a simple one-parameter tool with no output schema and full schema coverage, the description provides the necessary lookup flexibility and cost information. It doesn't detail the return format, but given the simple input and the annotations covering safety, this is adequate.

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

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

Schema description coverage is 100%, so the parameter is fully documented. The description adds semantic nuance by clarifying that the lookup can be a product, brand, or category, which broadens the agent's understanding beyond the schema's examples.

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

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

Clearly states the tool retrieves product recall information and specifies the key data returned (recall date, hazard description, remedy, regulatory authority). Distinguishes from siblings by its unique focus on recalls, especially from the many Interzoid data-lookup tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by allowing lookup of a product, brand, or category, but does not explicitly state when to prefer this over alternatives or mention any exclusions. Given the large sibling set, explicit guidance would be helpful, but the clear scope partially substitutes.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only nature is covered. The description adds meaningful context beyond annotations by disclosing that this is a 'Premium API' costing $0.25 USDC via x402, which is critical for an agent deciding whether to call it. It also enumerates what data is returned, adding behavioral expectations. It doesn't mention rate limits or failure modes, but with annotation coverage that's 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?

Two sentences, both information-dense. The output list in sentence one is long but every item is a specific data point an agent would want to know, and the cost disclosure in sentence two is essential. No filler or repetition.

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

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

With no output schema, the description's detailed enumeration of the returned data (last sale, prior transactions, ownership chain, deed types, mortgage history) serves as the output specification, which is good. It also covers the cost prerequisite. It doesn't discuss potential edge cases (unrecognized address, US-only constraints), but these are adequately implied by 'any US address' and the read-only annotations. Given the simplicity (1 param) and annotation coverage, this is nearly 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 already fully describes the sole address parameter with an example and explanation (100% coverage). The description only adds the phrase 'any US address,' which does not materially expand the meaning beyond the schema. Baseline 3 applies since the schema is doing the heavy lifting.

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: 'Retrieve property transaction history for any US address'. It enumerates the exact data included (last sale date/price, deed types, mortgage history, etc.), making it unmistakable from siblings like building_profile or address_parse. This is a textbook clear 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 defines the clear use case: property transaction history for a US address, and even constrains it to any US address. It does not explicitly name alternative tools or provide when-not-to-use guidance, so while context is clear, there's no explicit differentiation from 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?

Annotations already communicate read-only, idempotent, non-destructive behavior. The description adds valuable context beyond that: this is a premium API costing $0.25 USDC via x402 and uses AI-powered aggregation from multiple real-time sources. No contradiction with annotations.

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

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

The description is compact and front-loaded: purpose first, then source/quality details, then cost. Every sentence adds information an agent needs or benefits from, 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 single-parameter, read-only lookup with rich annotations, the description is nearly complete. It covers what to retrieve, the input scope, the nature of the data, and the cost. It does not describe the response structure, but the absence of an output schema and the simplicity of the tool make this acceptable.

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

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

Schema description coverage is 100%, so the lookup parameter is already documented with type, description, and example. The description merely echoes 'company or topic' without adding format, length, or usage details, earning the baseline score.

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 and resource: 'Retrieve recent news and developments for a company or topic.' It is distinct in intent from most siblings like stock info or company verification, though it does not explicitly name an alternative.

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 intended use is implied: call this when recent news about a company or topic is needed. However, it does not state when to prefer this over related sibling tools such as x_last_three_posts or competitor_analysis, nor does it provide any exclusions.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds valuable context about the premium nature and cost ($0.25 USDC via x402), which is a key behavioral disclosure for cost-sensitive agents. It also mentions the decomposition of the rate into components, which is a behavioral detail not in annotations or 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?

The description is compact, two sentences plus cost info. It front-loads the core purpose and input flexibility, then adds the accuracy tip and cost. It is not overly verbose but could potentially be trimmed, though the cost note is essential for a premium API.

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

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

With only one parameter, fully documented in schema, and read-only annotations, the description covers the essentials. It lacks explicit mention of the return format, but since there is no output schema, the description could benefit from stating what the response contains (e.g., breakdown object). However, for a simple lookup tool, the current completeness is adequate for most agents.

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 already thoroughly documents the 'lookup' parameter with a description and example. The description adds value by reiterating the accepted input formats and emphasizing that a full address yields better accuracy. Since schema coverage is 100%, the description's contribution is marginal but still helpful.

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 retrieves US sales and use tax rates and breaks down the components (state, county, city, special district, combined effective rate). It also specifies acceptable inputs (address, ZIP, city, state). This distinguishes it from tax-related siblings like interzoid_eu_vat_rates and interzoid_customs_duty_rates, which are different tax 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 explicitly recommends submitting a full street address for the most accurate rate assignment, guiding usage. It doesn't explicitly state when not to use it, but the distinction from EU VAT and customs duty rates is implied by the US scope and the nature of the taxes. No alternatives are named, but the context is clear.

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

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

Annotations already cover the safe read-only, idempotent, non-destructive nature. The description adds useful behavioral context beyond that: concrete input-to-output mapping examples and the per-call cost via x402, which is important for the agent to know before invoking.

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

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

The description is two short, focused sentences: the action in the first sentence, followed by concrete examples and cost in the second. There is no filler or repetition of annotation data.

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

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

Despite having no output schema, the description states the return shape ('full name plus abbreviation') and the example reinforces it. Cost, input variants, and basic safety are covered. It could be more complete by clarifying non-US/province input handling and what the optional algorithm parameter actually changes.

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 already documents both parameters with complete coverage. The description adds a modest amount of semantic detail about accepted state forms ('Calif', 'CA', 'Cal') and the output format, but the optional algorithm parameter is left entirely to the schema, which only identifies it as an optional variant.

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 ('Standardize') with a precise resource ('US state/province names') and names the exact output form ('full name plus abbreviation'). This makes it easy to distinguish from sibling standardizers like interzoid_city_standard or interzoid_country_standard.

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 use case is implied by the scope ('US state/province names') and the expected output, but there is no explicit 'use when' or 'use instead' guidance, and meaningful sibling tools are not mentioned. An agent can infer when to call it, but the description does not actively route between the standardization 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it is a premium API with a specific cost ($0.25 USDC via x402), which is critical for an agent deciding whether to invoke it. It also clarifies the output is AI-powered analysis, not just raw data.

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

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

Two sentences with zero waste. The core purpose is front-loaded, the return fields are listed compactly, and the premium/cost warning is placed at the end. 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 read-only tool with 100% schema coverage and no output schema, the description is nearly complete. It covers what the tool does, what data it returns, and the cost implication. The only minor gap is that it doesn't describe the return format or error behavior (e.g., invalid ticker), but the annotations and simple parameter schema make this a minor omission.

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

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

Schema description coverage is 100%, so the schema already documents the single 'lookup' parameter with examples and a clear description. The tool description adds the context that the lookup is a ticker symbol and that the analysis is AI-powered, but it does not add new parameter-level semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Get'), a specific resource ('AI-powered stock analysis for a ticker symbol'), and enumerates the exact data fields returned (price, market cap, P/E ratio, EPS, analyst assessment). This clearly distinguishes it from the many sibling tools, which cover addresses, companies, weather, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for stock ticker lookups and the input schema clarifies the lookup parameter, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions (e.g., unsupported tickers, delisted stocks). The context is clear enough for an agent to select it for stock-related queries, but no explicit when/when-not guidance 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the cost information ('Premium API. Cost: $0.25 USDC via x402') and details the categories returned, which is useful behavioral context beyond annotations. No contradiction.

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 zero waste. The first sentence front-loads the core purpose and enumerates the returned categories; the second states cost. Every word earns its place, and the structure is immediately scannable.

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 annotations covering safety and idempotency, and no output schema, the description fully covers what the tool does, its input, its output categories, and its cost. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%: the single 'lookup' parameter has a clear description ('Domain name or company website to identify the tech stack for'). The tool description reiterates this but adds no new semantic detail beyond the schema. Baseline 3 is appropriate given full 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 identifies the complete technology stack from a domain lookup, enumerating specific categories (CMS, frontend, backend, hosting, CDN, etc.). This verb-resource pairing is precise and differentiates it from the sibling tools, which mostly handle matching, verification, and information lookup for other domains.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it (need to discover a company's tech stack) and includes the required input type (domain name/website). It does not explicitly name alternatives or exclusions, but given its unique purpose among a large sibling set, the usage context is clear enough. A named alternative is not necessary here.

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

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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds the paid nature of the call ($0.01 USDC via x402) and the combined detect-and-translate behavior, which are useful beyond the schema/annotations. It does not detail output shape or failure modes, but the bar is lower given strong annotations.

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

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

Two short sentences with no filler; the core behavior is front-loaded and the cost is stated separately. Every word 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 two-parameter, read-only translation tool with no output schema, the description covers the core operation and cost. Minor gap: it doesn't state whether the detected source language is returned alongside the translated text, which could matter for callers expecting both outputs.

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

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

Schema description coverage is 100%, with examples and clear descriptions for both 'text' and 'to'. The description's phrasing 'input text' and 'any specified target language' merely echoes schema content and adds no new parameter-level 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?

States a specific verb ('Detect', 'translate'), the input ('input text'), and the capability ('any specified target language'). It distinguishes from the sibling interzoid_translate_to_english by emphasizing 'any target language' rather than English-only.

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?

Does not say when to choose this over interzoid_identify_language or interzoid_translate_to_english, nor does it provide exclusions or conditions. The only usage signal is the phrase 'any specified target language,' which implicitly suggests general use, but no alternatives are named.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond annotations: it reveals that the tool performs language detection as part of translation, and it discloses the cost of $0.01 USDC via x402. These are behavioral details not present in the structured data.

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 purpose, followed by a brief capability note and cost information. It is appropriately sized and every sentence adds value, though the 'AI-powered' phrase is somewhat generic. Overall it is efficient and well-structured.

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

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

The tool is simple (one parameter, no output schema) and annotations cover safety traits. The description includes purpose and cost, but does not clarify what the tool returns (e.g., whether it returns both the detected language and the translation). Given the tool's simplicity and annotation coverage, it is nearly complete, but a note on return value would close the gap.

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

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

Schema description coverage is 100% (the 'text' property is described as 'Text in any language to translate to English'). The description does not add any parameter-specific details beyond the schema, so it does not increase parameter understanding. Baseline of 3 is appropriate given full 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 explicitly states it detects the language of input text and translates it to English, which is a specific verb+resource. It clearly differentiates from the siblings interzoid_translate_to_any (translation to other languages) and interzoid_identify_language (detection only), so an agent can pick the right tool without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: if you need English translation of non-English text, use this tool. However, it does not explicitly mention alternatives or when not to use it, leaving the agent to infer from sibling names. No exclusions or direct comparison are provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds the premium API cost and the specific fields returned, which is useful but does not mention response format, error handling, or rate limits. The cost disclosure is a behavioral addition beyond annotations, but overall the description does not substantially expand on the behavioral profile given that annotations already cover the key 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?

The description is a single concise sentence that states the action, the resource, and the key output fields, followed by a cost note. It is front-loaded with the primary purpose and contains no redundant or filler text. Every word 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?

With no output schema, the description lists the expected data categories (location, type, enrollment, accreditation, notable programs, key statistics), giving the agent a good idea of what the response will contain. It does not specify the exact structure (e.g., JSON format) or mention fuzzy matching or required formatting for the lookup, but for a simple one-parameter tool this is largely sufficient. A 4 reflects that it is mostly complete but could include details on response structure or matching behavior.

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

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

Schema description coverage is 100%: the schema clearly states the parameter is a 'University or college name' with an example. The description does not add any extra detail about parameter formatting, matching behavior, or acceptable values. Per the rubric, with high schema coverage, the baseline is 3, and the description offers no added value for the parameter.

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

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

The description uses a specific verb 'retrieve' and a clear resource 'university or college', and lists the exact data fields (location, type, enrollment, accreditation, notable programs, key statistics). This is distinct from any sibling tool, as no other tool in the list pertains to universities. The purpose is unambiguous and fully specified.

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 makes the context obvious: it is for retrieving university/college information. However, it does not explicitly mention when not to use it or name any alternative tools. Since the tool is unique among siblings, the context is clear, but there is no explicit guidance on exclusions or alternatives, which would merit 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 already cover the safe read-only, idempotent nature of the operation. The description adds useful behavioral context beyond annotations by disclosing the return value (handle with confidence score) and the $0.05 USDC cost via x402.

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, action-first sentences with no filler. The description efficiently covers purpose, scope, output, and cost 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 low-complexity tool with one fully documented parameter and safety-providing annotations, the description supplies the essential missing details: the return format and the monetary cost. Nothing necessary for correct invocation 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?

Schema description coverage is 100%, and the schema already provides a clear description and an example for the single parameter. The description adds some synonym detail but no new formatting or usage semantics, so the baseline of 3 applies.

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

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

States a specific verb+resource ('Retrieve the X handle') and enumerates accepted entity types, clearly distinguishing it from related siblings like interzoid_x_profile and interzoid_x_last_three_posts. The scope is immediately understandable.

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 the core use case and implies when to use it, but provides no explicit when-not-to-use guidance or pointers to alternative tools. It leaves the agent to infer the right situation from the listed entity types.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful behavioral context beyond annotations: the concrete cost of $0.05 USDC via x402 and that the returned data includes full text content and date for each post.

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

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

Two short, information-dense sentences with no filler. The main operation and output are front-loaded, and the cost note is placed separately but still relevant to invocation.

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

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

The tool is simple, has one well-documented parameter, and the description covers both the input (handle) and the expected output (three post texts and dates). The cost is disclosed, and the annotations cover safety and side effects. Nothing essential for calling the tool is missing.

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

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

Schema description coverage is 100%, and the schema already documents the 'handle' parameter with an example and the note about the '@' prefix. The description does not add semantics beyond calling it an X handle, so the schema carries the parameter documentation burden.

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 ('Retrieve') and names the resource ('three most recent posts (tweets) from a given X (Twitter) handle'), plus the exact count and fields returned. This clearly differentiates it from sibling tools like interzoid_x_profile or interzoid_recent_news, even without mentioning them by name.

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 usage context: when an agent needs the three most recent posts and their text/dates for a given X handle. It does not explicitly name alternatives or exclusions, but the 'three most recent posts' phrasing is specific enough to guide selection.

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

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

Annotations already establish readOnlyHint and idempotentHint, so the description's job is to add context. It adds the cost ($0.05 USDC via x402) and the specific return fields, which are concrete and useful. It does not discuss potential errors or rate limits, but the annotations lower the bar; the added value is meaningful.

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

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

The description is a single, efficient sentence that front-loads the action and immediately lists the included fields and cost. No wasted words or repetition of schema details.

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

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

With no output schema, the description compensates by listing the fields returned. It also covers the cost. It omits error conditions or prerequisites, but for a read-only single-parameter tool, this is largely sufficient. Minor gaps do not hinder correct invocation.

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

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

The schema fully describes the handle parameter with an example and explanation of the @ prefix. The description adds no further parameter-level detail, so the schema carries the weight. Baseline 3 is appropriate given 100% 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 retrieves a comprehensive profile snapshot for an X handle and enumerates the specific data fields (display name, bio, follower counts, etc.). This distinguishes it from sibling tools like interzoid_x_handle and interzoid_x_last_three_posts, which focus on narrower subsets.

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 a full profile is needed ('comprehensive snapshot') but does not explicitly contrast it with the sibling X tools or state when not to use it. No alternative tool names are mentioned, so the agent must infer routing from the field list.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the cost detail ($0.01 USDC via x402), which is a meaningful behavioral disclosure beyond the annotations. It also clarifies the output scope (city, state, county, timezone, area codes, lat/long), giving the agent a concrete expectation of what the call returns.

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 that front-loads the core purpose and lists the return fields, followed by a concise cost note. Every word earns its place; there is no filler or repetition of the tool name.

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

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

For a simple one-parameter read-only lookup with a fully documented schema and safety annotations, the description is nearly complete. It states the input format, the output fields, and the cost. The only minor gap is that it doesn't specify behavior for invalid or non-existent ZIP codes, but this is a small omission 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?

Schema description coverage is 100%: the only parameter, 'zip', is described as 'US ZIP code (5-digit)' with an example. The description adds no new parameter semantics beyond what the schema already provides. Baseline 3 is appropriate because the schema fully documents the parameter.

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

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

The description states a specific verb ('Get') and resource ('detailed info for a US ZIP code') and enumerates the exact fields returned (city, state, county, timezone, area codes, lat/long). This clearly distinguishes it from sibling tools like interzoid_country_info or interzoid_state_abbreviation, which cover different geographic entities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it: when you need US ZIP code details. It does not explicitly state when not to use it or name alternatives (e.g., use interzoid_country_info for non-US locations). The context is clear enough for a single-purpose lookup tool, but there is no explicit exclusion or alternative routing.

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