mcp-server

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new operational context: that the same key implies both similar name AND similar address (a conjunction, not either/or), and the per-call cost of $0.01 USDC via x402, which matters for an agent deciding whether to batch. It does not discuss rate limits or key format, keeping it short of a 5.

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

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

Three sentences, each doing work: purpose, matching semantics, cost. The use case and the key behavioral claim are front-loaded, and 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?

With no output schema, the description carries the return-value burden and does so adequately: the output is a single combined similarity key, and equality of keys means a match on both name and address. What is missing is whether the key is a string/hash and whether a numeric score is also returned, but the essential contract 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?

Schema description coverage is 100%, with both parameters documented and exemplified ('100 Main Street', 'James Johnston'). The description only restates that the inputs are a full name and a street address, adding no format, normalization, or international-handling guidance beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource: it generates one combined similarity key from full name plus street address, framed as household/contact deduplication. This implicitly distinguishes it from single-field siblings like interzoid_fullname_match and interzoid_address_match, though it never names those alternatives. Clear enough to act on, but sibling differentiation is left to inference.

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

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

Usage is implied through the framing 'for high-precision contact and household matching across customer, donor, and marketing lists', which tells the agent the domain but not when to prefer this over interzoid_company_and_fullname_match or the single-field match tools. No exclusions or preconditions are 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 read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context: the AI-powered similarity logic, the grouping use case, the precision benefit of ZIP, and the cost ($0.01 USDC via x402). It doesn't cover rate limits or error behavior, but the added cost and key-generation details are meaningful 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?

Front-loaded with the core purpose, followed by usage guidance and cost. Every sentence adds value with no redundancy or fluff.

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

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

No output schema exists, but the description explains that the return value is a similarity key and how to use it for grouping. Combined with the simple 3-parameter schema and the annotation set, the definition gives enough context to call the tool correctly. Only minor gaps (e.g., no mention of error modes) remain.

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 all parameters are already documented. The description mentions that ZIP is optional but recommended for precision, which matches the schema's own description. The 'algorithm' parameter is not mentioned in the description, but the schema covers that. 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?

States a specific verb and resource: 'generates an AI-powered similarity key for a street address.' The 'US' scope and 'similarity key' concept implicitly distinguish it from siblings like interzoid_global_address_match and interzoid_address_parse, but no sibling is explicitly named.

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?

Explains the primary use case clearly: 'Group on the key to find duplicate addresses, households, and locations.' It also notes that an optional ZIP improves precision. However, it does not state when to prefer this over alternatives (e.g., global_address_match or address_parse), so exclusions are missing.

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 readOnly, idempotent, openWorld, and non-destructive status, so the safety profile is settled. The description adds genuinely new behavioral context — the $0.01 USDC x402 cost, which affects invocation decisions — though it doesn't state what happens on an unparseable address.

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

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

Front-loaded with the core operation, followed by the component list, use cases, and cost. Every clause earns its place with no 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?

With no output schema, the enumerated component list effectively serves as the return-value description, and the cost note is included. Only failure/edge-case behavior (e.g., partially parseable addresses) is unaddressed for a simple one-parameter tool.

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

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

Single required parameter with 100% schema description coverage and a worked example, so the schema carries the semantics. The description's enumeration of components implies the parsing scope but adds no parameter syntax details, which is acceptable at this coverage level.

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 ('splits a full address string into its components') and enumerates the component set returned. An agent can distinguish this from the many address-matching siblings (address_match, global_address_match) 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?

It gives clear use contexts ('address cleansing, standardization, geocoding preparation, and loading structured address data'), which tells an agent when this tool fits. It does not, however, explicitly distinguish itself from match/standardize siblings or state when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the description correctly need not restate safety. It does add genuinely new behavioral context: US-only scope and a $0.25 USDC cost via x402, which matters for an agent deciding whether to call. It leaves out failure behavior for an unmatched or non-US address and does not say whether results are cached.

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, front-loaded with the returned payload, then use cases, then price — a sensible order with no filler. The 11-field enumeration is long but each item is informative field-coverage, not 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?

With annotations carrying the safety profile and no output schema, the description substitutes a field list for the missing return documentation, and adds the pay-per-call cost. An agent has enough to decide and to call it; only error/empty-result behavior on an unresolvable address is unaddressed.

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 enum is fully documented in the schema, so the baseline is 3. The description adds only the US-address scope constraint ('any US property address') and never mentions the optional language parameter, so it adds a little meaning but no syntax 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 gives a specific verb+resource: a commercial building profile keyed to a US property address, and it enumerates the returned fields (building class, year built, RSF, tenants, ownership, etc.). It doesn't name the nearby siblings it is not — interzoid_property_history or interzoid_facilities_profile — so an agent must infer the boundary, but the purpose itself 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?

It gives three concrete contexts (CRE research, brokerage prospecting, property due diligence), which is real usage guidance rather than a restatement of the name. It offers no exclusions or named alternatives for cases like 'I want transaction history instead', which keeps it below 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered structurally. The description adds genuinely new behavioral context: the call costs $0.25 USDC via x402 and works for both public and private companies. It omits any mention of failure/not-found behavior or latency.

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 tight sentences: capability and returned fields first, then use cases, then cost. Every sentence carries information an agent needs and nothing is repeated.

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

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

There is no output schema, so the description's enumeration of returned fields (official name, website, HQ address, description, revenue, employee count, NAICS, top executive) is essential and present. Combined with cost and scope, an agent has enough to decide and call 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 both parameters are already documented, and the description's phrase 'by name, web domain, or email address' largely restates the schema's 'Company name, website, or email'. The optional language parameter and its price neutrality are not mentioned in the description, but the schema covers them. Baseline 3 applies.

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

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

States a specific verb (look up) and resource (any company) plus the three accepted identifier types (name, web domain, email) and enumerates the returned firmographic fields. That makes it clearly distinguishable from siblings like interzoid_official_name or interzoid_company_verification, though no sibling is named explicitly.

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

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

Names concrete contexts: lead enrichment, CRM enrichment, account research, and KYB checks, and states the coverage scope as public and private companies. It does not say when to prefer a sibling such as interzoid_business_info_name or interzoid_parent_company_info instead, so there are no 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 readOnly, idempotent, openWorld and non-destructive, so safety is covered; the description adds genuinely new behavioral detail in the explicit price ($0.10 USDC via x402) and the note that language choice does not change cost. It stops short of describing result shape or behavior when a lookup fails.

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, front-loaded with the core verb and resource, then use cases, then cost. Every sentence adds distinct information with no repetition of the schema.

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

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

With no output schema, the description carries the burden of explaining results and does so ('standard registered corporate name'), and it documents the global scope and language behavior. It leaves the response envelope and not-found handling unstated, a minor gap for a single-lookup tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by clarifying that the lookup accepts abbreviation, brand, ticker, informal name, domain, or misspelling and by showing the input-to-output transformation ('ibm' → 'International Business Machines Corporation').

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

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

States a specific verb and resource ('resolves ... to the standard registered corporate name') and enumerates accepted input forms, plus a concrete example. It does not, however, distinguish itself from near-duplicate siblings like interzoid_official_name, interzoid_org_standard, or interzoid_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?

Gives clear use-case context — record standardization, matching, deduplication, CRM and vendor master data — so the agent knows the domain where this belongs. It offers no when-not conditions and names no alternative even though interzoid_official_name appears to overlap heavily.

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, openWorldHint and destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds genuinely useful behavior not in annotations: a $0.25 USDC x402 charge per call, which affects whether an agent should invoke it speculatively. It says nothing about failure modes for unrecognized or ambiguous companies, or about latency/coverage limits.

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

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

Two dense sentences plus a short cost clause, with the payload contents front-loaded and the use cases and price trailing. Every clause carries information; nothing is restated from the name or schema.

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

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

For a two-parameter, no-output-schema tool, the description compensates well by enumerating return contents and disclosing the per-call cost. It is slightly incomplete on input robustness — nothing tells the agent whether the company name must be exact, whether private companies are covered, or what an empty result means.

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

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

Schema description coverage is 100% and both params are fully documented in the schema, including the language enum, so the baseline of 3 applies. The description mentions only the target company implicitly and adds no syntax, format, or ambiguity-resolution guidance 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 names the resource concretely and enumerates the signal categories returned (leadership changes, funding, hiring, expansion, tech changes, budget indicators, pain points) plus derived outputs like signal strength score and decision makers, so an agent knows exactly what it gets back. It stops short of explicitly routing away from overlapping siblings such as interzoid_recent_news or interzoid_tech_stack, so the differentiation is inferable rather than stated.

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

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

It gives clear usage context — sales prospecting, account-based marketing, lead prioritization — which tells the agent what task class this tool serves. There are no explicit exclusions or named alternatives, so an agent deciding between this and the news or tech-stack tools gets no direct 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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: the $0.01 USDC x402 payment cost and the fact that supplying state improves matching accuracy. These are real behavioral details, but there is no disclosure of failure behavior or return format, so a 3 is right.

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

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

Front-loaded with the core transformation, followed by the usage hint and cost note. No filler, no 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 read-only transformation tool with full schema coverage and annotations, the description supplies what's needed: what it does, when to use it, and cost. The only minor gap is that it never says what the response looks like, though the input schema suggests the return is the standardized city name.

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 city, state, and algorithm. The description only reinforces that state is optional but improves accuracy, and never mentions the algorithm parameter at all. Baseline 3 is appropriate when the schema carries the load.

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: converts abbreviations, nicknames, alternate spellings to the standard city name, with concrete examples ('San Fran', 'L.A.'). This clearly separates it from other Interzoid standardizers such as country_standard, state_abbreviation, and org_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?

Names use cases (address cleansing, geocoding preparation, consistent reporting) which gives the agent clear context for when to reach for this tool. It stops short of naming alternatives or stating when not to use it, so it falls short of a 5.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful context beyond annotations, including the AI-powered key semantics and the $0.01 USDC x402 cost, though it does not describe payment flow, rate limits, or exact return shape.

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, combined-key semantics, use cases, and cost appear in three efficient sentences. There is no redundant restatement of the tool name.

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

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

For a two-parameter read-only matching tool with full schema descriptions and rich annotations, the definition is largely complete. The only small gap is that it does not explain the returned key format or how matching thresholds work, though no output schema exists.

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 both parameters are already documented. The description reinforces that company and address are combined into one similarity key, but it adds little format or syntax detail 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 states a specific verb and resource: generating a combined similarity key for business location deduplication from company name plus street address. It clearly distinguishes this tool's scope from address-only or company-only matching siblings by emphasizing the combined company+address key.

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

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

It gives clear usage context: matching business locations across vendor, supplier, and account datasets. However, it does not explicitly name alternatives such as address-only matching, company-only matching, or advanced match-score tools, nor does it state when not to use this tool.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), yet the description still adds real value: it explains result semantics (same key = similar company AND similar person) and discloses a concrete cost ($0.01 USDC via x402). It stops short of stating determinism, key format, or whether a similarity score is included.

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: the mechanism, then the match semantics, with cost appended last. Front-loaded and no filler anywhere.

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

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

No output schema exists, and the description compensates by explaining what the returned key means. It leaves minor ambiguity about the return shape (bare key string vs. key plus score) and normalization expectations for input names, but the essentials for calling it correctly are present.

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

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

Schema coverage is 100%, so the baseline would be 3. The description earns a bump by clarifying that the two inputs are fused into a single key rather than scored independently — a distinction the schema alone cannot convey and one that changes how an agent interprets the call.

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

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

Names a specific verb and resource: generates one combined similarity key from company + full name for contact deduplication. The word 'combined' distinguishes it from the single-field siblings interzoid_fullname_match and interzoid_company_match_advanced without needing to open any schema.

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

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

Gives usage context ('contact-level matching in CRM, sales, and marketing datasets'), which is better than nothing, but never says when to prefer this over the many adjacent siblings (interzoid_company_and_address_match, interzoid_fullname_match, interzoid_company_match_advanced). The agent must infer the choice boundary itself.

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 readOnly, idempotent, openWorld and non-destructive, so safety is handled. The description adds genuinely non-obvious context beyond them: the paid cost ($0.01 USDC via x402) and the determinism contract that variations collapse to the same key. It does not discuss rate limits, auth expectations, or failure behavior for unmatched names.

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

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

Four tight sentences, front-loaded with purpose, then examples, then use cases, then the differentiator and price. Slight redundancy between "matching and deduplication" and the later duplicate/merge use-case sentence, but nothing that misleads or pads.

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 still conveys the essential return semantics (a similarity key you group on) and the key's core property (variants map to the same key). It never states the return type (string) or what happens for an unmatched/garbage input, which is the main remaining gap for a paid one-parameter tool.

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

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

There is a single parameter with 100% schema coverage, so the baseline is 3. The description illustrates what kinds of input strings qualify (abbreviations, full corporate names) but adds no format, length, or normalization guidance beyond 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 opens with a specific verb+resource ("generates an AI-powered similarity key for a company or organization name") and uses concrete examples ('Gen Electric Corp' / 'GE' / 'General Electric Company') to make the output semantics unambiguous. This clearly separates it from siblings like interzoid_org_match_score or interzoid_company_and_address_match, which score or combine entities rather than emit a grouping key.

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

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

It gives concrete when-to-use scenarios (group records to find duplicates, merge CRM/vendor lists, match accounts across datasets) and scopes the variant ("advanced algorithm for complex corporate name variations"). It does not name any alternative sibling or state when NOT to use it, which keeps it out of 5 territory.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond them: the exact 0-99 score output with AI reasoning, and the $0.25 USDC x402 payment requirement, which is critical for an agent to know before calling.

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

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

Two tight sentences: purpose and return value first, then use cases, then cost. Every clause carries information an agent needs, 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?

With no output schema, the description correctly compensates by describing the return value (0-99 score plus AI reasoning). Parameters are fully covered by the schema. Minor omission: no note on behavior for unknown or ambiguous company 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?

Schema coverage is 100%, and both parameters (lookup, language enum) are fully documented in the schema. The description mentions neither the company-name input nor the optional language parameter, so it adds no meaning beyond the structured fields; baseline 3 applies.

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

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

States a specific verb and resource ('checks whether a company or organization is real') and specifies the returned artifact: a 0-99 legitimacy score plus AI-generated reasoning. It distinguishes itself in substance from firmographic siblings like business_info by emphasizing verification, but it never names an alternative explicitly.

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

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

Enumerates concrete use cases — KYB, vendor/supplier onboarding, fraud prevention, B2B signup screening — which gives an agent a clear picture of when to reach for it. It stops short of stating exclusions or pointing to a sibling for adjacent needs (e.g., firmographic enrichment).

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds a genuinely useful behavioral fact not in structured fields: a $0.25 USDC x402 cost per call. It does not mention latency or whether the analysis is generated on demand, which keeps it at 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 tight sentences: the first front-loads what is returned, the second covers use cases and cost. Every clause earns its place with no filler or restatement of the 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?

There is no output schema, and the description compensates by enumerating the response fields (industry, market position, competitors, advantages/weaknesses, dynamics, outlook). Combined with the cost disclosure and fully documented parameters, an agent has everything needed to call this 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 both 'lookup' and the 'language' enum are fully documented in the schema, including the same-price-in-every-language note. The description adds no parameter-level meaning beyond that, 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 opens with a specific verb+resource ('Competitor analysis for any company') and enumerates exactly what the result contains: industry, market position, direct/indirect competitors, advantages, weaknesses, dynamics, and outlook. It is clearly distinguished from data-profile siblings like business_info or industry_classification, but never names an alternative, 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?

Use cases are listed ('competitive intelligence, market research, sales battlecards, investment research'), which implies when to reach for it, but there is no explicit when-not guidance and no named alternative among the 60+ siblings. The agent must infer that business_info or industry_classification is the narrower substitute.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: a monetary cost of $0.01 USDC via x402, which changes how an agent should budget and batch calls. It also enumerates the returned data fields, useful given there is no output schema.

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

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

The capability statement is front-loaded in the first sentence, followed by short purpose and cost sentences. The return-field enumeration is somewhat list-like but every element is substantive; 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 only two parameters, no output schema, and full annotation coverage, the description supplies what an agent needs: the standardized outputs to expect, the use cases, and the payment cost. Minor omissions remain — what happens for an unrecognized country and how the x402 payment is actually settled — but the definition is largely self-sufficient.

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

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

Schema coverage is 100%, so both parameters are already documented. The description reinforces the 'any language or format' semantics of the country input but says nothing about the 'algorithm' parameter, leaving its purpose to the schema. Baseline 3 is appropriate when the schema carries the load.

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 precise verb and resource — standardizes a country name and returns ISO 2/3-letter and numeric codes, currency, domain, calling code — which is far more informative than the tool name alone. The only gap is that a near-identical sibling, interzoid_country_standard, exists and the description does nothing to distinguish this tool from it.

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 lists broad application areas (address normalization, localization, payments, data enrichment), which implies when the tool is relevant. However, these are generic use-case labels rather than selection guidance, and with an obvious overlapping sibling (interzoid_country_standard) the description gives no rule for choosing between them.

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, openWorldHint and non-destructive behavior, so the safety profile is covered. The description adds genuinely new behavioral context not present in annotations: a per-call cost of $0.01 USDC via x402, which materially affects invocation decisions. It stops short of describing the response shape, but the core transformation outcome is stated.

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 sentences: purpose and examples first, then use cases, then cost. Nothing is redundant and the most decision-relevant facts are 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 simple two-parameter transformation tool with no output schema, the description conveys what goes in and what comes out (a consistent standard country name) plus the payment requirement. Only the 'algorithm' variant behavior is left unaddressed.

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 both parameters are already documented and the baseline is 3. The description's country examples add practical meaning to the 'country' input (loose variants accepted), but the optional 'algorithm' parameter is never mentioned and its variants/effect remain unexplained.

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 ('Country name standardization') and illustrates it with concrete input variations ('UK', 'Great Britain', 'uae') that make the transformation unambiguous. It is clearly distinct from the sibling 'interzoid_country_info' (info lookup) and 'interzoid_city_standard' (different resource), though it never names a sibling explicitly.

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

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

Gives usage contexts ('data cleansing, address normalization, consistent reporting'), which implies when to reach for it. However, there is no guidance on when NOT to use it and no routing to the closest alternative (e.g., country_info for metadata vs. standardization), leaving the agent to infer boundaries from the 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 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new operational context: a $0.35 USDC x402 payment requirement, which an agent must know before invoking. It does not mention data freshness, rate limits, or what happens if the HS code or route is unknown.

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

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

Two dense sentences, front-loaded with the resource and scope, followed by use cases and pricing. The long enumeration of duty types is justified because there is no output schema, though it reads as a comma-list rather than structured 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 read-only lookup with no output schema, the description usefully enumerates the categories of data returned (MFN, FTA, anti-dumping/countervailing/Section 301, VAT/GST, de minimis, restrictions) and discloses the payment mechanism. Only the response shape and error/coverage behavior remain unspecified, which 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 coverage is 100%, with all four parameters — including the origin parameter's purpose for preferential FTA and trade-remedy rates and the language enum — documented in the schema itself. The description merely restates the field list already implied by the schema, adding no syntax or format detail, so baseline 3 applies.

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

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

States a specific verb and resource ('Import customs duty and tax rates for an HS code on a trade route') and enumerates the exact duty/tax components returned. It is clearly distinguishable from sibling rate tools like interzoid_eu_vat_rates or interzoid_sales_use_tax_rates by the HS-code-plus-trade-route scope.

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

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

Gives concrete use contexts (landed cost calculation, cross-border e-commerce, sourcing, trade compliance) so an agent knows when this is the right tool. However, it never names alternatives or exclusions — e.g., when to prefer interzoid_eu_vat_rates for plain VAT lookups — so it stops short of explicit routing.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior. The description adds genuine value beyond that: a specific cost ($0.01 USDC via x402) and the fixed set of possible classifications, including an explicit 'Unknown' fallback.

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

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

Three tightly scoped sentences with the classifications front-loaded and no filler. The middle sentence is mildly marketing-flavored rather than purely informational, but it still communicates the domain-type payoff.

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 classifier with no output schema, the description supplies the return categories and cost, which is what an agent needs. Only minor gaps remain, such as behavior on malformed or domainless inputs.

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 has 100% schema description coverage with a concrete example, so the schema does the heavy lifting. The description restates the input conceptually but adds no format or validation detail beyond it, matching the baseline 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?

States a specific verb+resource ('classifies the domain behind an email address') and enumerates the exact output categories, which clearly separates it from siblings like interzoid_email_trust_score (trust, not domain type). An agent can select it without opening the schema.

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

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

Lists concrete use cases (lead scoring, trial qualification, CRM enrichment, sales routing, fraud prevention) that give clear context for when to invoke. It stops short of naming alternatives or exclusions, e.g. when to prefer the trust score 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 read-only, idempotent, open-world, non-destructive semantics, so the description adds real value beyond them: the $0.25 USDC x402 cost and the 0-99 output range with AI-generated reasoning. It doesn't mention rate limits or error behavior for invalid addresses, which keeps it below a 5.

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

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

One dense sentence for the core behavior, one for use cases, one for cost — every sentence earns its place and the capability is front-loaded. No filler or repetition of the schema.

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

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

With no output schema, the description compensates by disclosing the 0-99 score range and the reasoning component. Cost is disclosed, which matters for a paid call. Response structure beyond the score is still only sketched, so it's solid but not exhaustive.

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 the required 'lookup' email and the optional 'language' enum are fully documented in the schema. The description adds no parameter-level detail such as format expectations or language behavior, so the baseline 3 applies.

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

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

States a specific verb and resource — scores an email address 0-99 and flags disposable addresses, suspicious patterns, and deliverability risk. An agent can tell what it produces. It doesn't explicitly contrast with the sibling interzoid_email_domain_type, so sibling differentiation is left implicit.

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?

Lists concrete use contexts (signup fraud prevention, lead quality scoring, list cleaning, trial abuse detection), which gives the agent a clear trigger for calling it. It stops short of exclusions or naming an alternative tool for adjacent needs like domain-type classification.

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 genuinely useful non-annotation context: the call is free/requires no payment, and it discloses the shape of what comes back (per-function inputs, output fields, price per record and per 100 records, language support).

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 tight sentences with no filler; the billing reassurance ('Free, no payment needed') is front-loaded ahead of the functional detail. The middle sentence is dense but earns its place by enumerating the catalog's contents.

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

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

There is no output schema, but the description compensates by specifying what the response contains (inputs, output fields, price per record/100 records, language acceptance) for both the all-functions and single-function cases. For a single-optional-param catalog tool, 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% and the single optional 'function' parameter already documents the enum, its example, and the omit-to-list-all behavior in the schema itself. The description repeats the same idea (a function name yields its full details vs. omitting lists all) without adding syntax or format beyond the schema.

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

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

States a specific verb+resource: it lists the enrichment functions available to interzoid_enrich_records, and enumerates exactly what each entry contains (output fields, inputs, price, language support). This clearly distinguishes it from the sibling per-function tools (e.g., interzoid_business_info) which execute a single enrichment.

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

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

Gives an explicit trigger: 'Call it to choose the right function before enriching records,' which positions it as a prerequisite/discovery step for interzoid_enrich_records. It does not state a when-not condition or name alternative discovery paths, but the sequencing guidance is unambiguous.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description layers on genuinely new behavior: x402 payment-required responses stating exact totals, per-record cost multiplication, pass-through of unrelated fields, automatic input-field matching, and an optional language parameter for premium functions. This is substantial context beyond structured fields.

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 core batching/cost/field-mapping guidance is front-loaded and tight, but the trailing enumeration of all 39 functions with per-record prices is long and largely duplicates what interzoid_enrich_functions is explicitly named to provide. It is useful cost data, yet it inflates the description well beyond what selection requires.

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 an 8-parameter, nested-object tool with no output schema, the description covers record shape and return behavior ('get every record back with the chosen function's output fields appended'), parameter roles, language scope, and cost/payment handling. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: the auto-detection rule for lookup_field ('Fields named after the function's inputs, usually "lookup", are used automatically; otherwise set lookup_field'), the pass-through behavior of other fields, and the up-to-12 cap on output_fields for custom.

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

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

States a specific verb and resource ('Enrich up to 100 records in one call') and explicitly contrasts with the single-record path ('Use this instead of calling a single-record tool once per record'). An agent can distinguish it from siblings like interzoid_business_info without reading 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?

Gives explicit when-to-use routing (batch over single-record), points to interzoid_enrich_functions to inspect inputs/outputs/prices, and adds a clear when-to-pause rule ('Check with the user before running premium functions on many records'). Alternatives and cost conditions are named, not implied.

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 readOnly, idempotent, non-destructive, and open-world behavior, so the bar is lower. The description adds a genuinely useful detail those annotations cannot convey: the $0.01 USDC x402 cost, which materially affects an agent's decision to call it.

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

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

Front-loaded with the core action and class list, then a single second sentence for use cases and cost. No filler, though the long enumeration makes the first sentence dense.

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

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

There is no output schema, so the description should indicate what comes back (a label? confidence score? a single class or ranked list?). It says what the tool decides but not the shape of the decision, leaving a real gap for a classifier with no structured return 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?

Only one parameter, and the schema already documents it at 100% coverage with an example ('Argentina'). The description's class list reinforces what 'classify' means for that value, adding modest 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 ('determines whether') on a specific resource ('a data value') and enumerates the candidate classes (person, organization, location, phone, email, website, number, other). That is enough to distinguish it from sibling classifiers like interzoid_email_domain_type or interzoid_identify_language, though it never explicitly contrasts itself with them.

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 names concrete usage contexts: data profiling, routing records to the right cleansing or matching step, and preparing data for AI. That tells an agent where the tool fits in a pipeline, but there are no explicit exclusions or named alternatives for the overlapping classification 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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-redundant behavior: a per-call cost of $0.25 USDC via x402, which is critical for an agent deciding whether to invoke. It omits failure/coverage behavior (e.g., what happens for an unknown or private company).

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 tight sentences: payload contents, use cases, price. No filler, and the core resource is front-loaded so the agent can stop reading after the first clause if needed.

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

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

With no output schema, the description compensates by enumerating the returned fields, and it discloses pricing — both essential for correct invocation. Minor gaps: no mention of data freshness/coverage limits or behavior when the company is not found, which matter for a paid open-world lookup.

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

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

Schema coverage is 100% and both parameters (lookup, language) are documented in the schema, including the enum list. The description adds nothing about parameter semantics — no guidance on name format for 'lookup' (ambiguity risk with company names) — so the baseline 3 applies.

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

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

States a specific resource (ESG and sustainability profile for a company) and enumerates the exact contents returned: ESG risk rating, E/S/G scores, carbon emissions by scope, net-zero target, renewable energy share, controversies, reporting frameworks, reference URL. This is clearly distinguishable from siblings like interzoid_executive_profile, interzoid_stock_info, or interzoid_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?

Names three concrete use cases (ESG investing, supplier due diligence, sustainability reporting), which gives the agent a clear selection context. It does not state when-not to use it or point to an alternative sibling (e.g., executive_profile for leadership data), so it stops short of full routing guidance.

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

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

Annotations already establish read-only, open-world, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond annotations: the exact payment cost ($0.25 USDC via x402) and the breadth of returned data including registration thresholds and territorial exceptions.

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 efficient sentences, front-loaded with the core scope and content. Every sentence earns its place, including the cost note, 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?

Given full schema coverage and annotations, the description adds the key missing contextual pieces: geographic coverage, rate categories, registration thresholds, territorial exceptions, and cost. It does not describe the exact response shape, but the listed content categories give an agent sufficient confidence to call 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%, so both parameters are fully documented in the schema. The description adds no additional meaning about the 'lookup' field (e.g., that city/address input resolves to a country) or the 'language' option. 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 resource (current VAT rates) and its exact geographic scope (EU-27, EEA, UK, Switzerland, non-EU Europe), plus the rate categories returned. It does not explicitly distinguish itself from siblings like interzoid_sales_use_tax_rates or interzoid_customs_duty_rates, which is the only gap for 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?

It names relevant use cases ('cross-border e-commerce, invoicing, and VAT compliance'), giving implied usage context. However, it does not state when to prefer this over sibling tools such as sales/use tax or customs duty lookups, nor does it provide 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 declare readOnly, idempotent, openWorld, and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful context beyond annotations: the $0.25 USDC x402 cost and the concrete returned fields, which an agent needs before committing to a paid call.

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

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

Front-loaded with purpose and output fields, then usage, then cost. The purpose-fragment list ('For sales prospecting...') is slightly listy but each clause adds targeting value; nothing is 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?

Though there is no output schema, the description enumerates returned fields, discloses cost, and covers both parameters, so an agent has everything needed to decide and call correctly. Nothing material is missing.

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

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

Schema coverage is 100%, so both the combined 'lookup' string and the enum-constrained 'language' are fully documented. The description restates the company+title input with an example but adds little beyond the schema's own example and language enum, so baseline 3 applies.

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

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

States a specific verb and resource ('Executive and leadership lookup') and enumerates exactly what it returns: name, title, company website, LinkedIn URL, and biography source URL. That output shape distinguishes it from siblings like business_info or x_profile without opening any schema.

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

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

Provides clear when-to-use context ('sales prospecting, lead generation, account research, and finding decision makers') and an example input. However, it names no exclusions or alternative sibling tools for overlapping needs such as business_info or buying_signals.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds valuable non-schema behavior: the $0.25 USDC cost via x402, which is critical for an agent deciding whether to call. It doesn't say anything about latency, data freshness, or what happens for a company with no facility 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, front-loaded with the returned field list before use cases and price. The field enumeration is long but each item is informative; no filler or repetition 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?

With no output schema, the description carries the return-value burden and does so by listing the profile fields, and it discloses cost. What's missing is any sense of response shape/format, pagination, or behavior on no-match for a paid call – modest gaps for a lookup tool.

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

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

Schema description coverage is 100% and both parameters are documented in-schema (lookup company name, optional language enum). The description adds only that lookup works 'for any company' and that pricing is the same in every language, which is mildly useful but doesn't deepen parameter semantics beyond the schema.

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

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

States a specific verb+resource ('Corporate facilities and real estate footprint for any company') and enumerates the contents (HQ, facility count, square footage, owned vs leased, openings/closures, work policy), so an agent knows precisely what data comes back. It doesn't explicitly distinguish itself from near-neighbors like interzoid_building_profile or interzoid_property_history, which would be needed for 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?

Names concrete application contexts – 'commercial real estate prospecting, site selection, supply chain, and account research' – which gives clear when-to-use framing. There is no explicit when-not-to-use or named alternative among the 58 siblings, so it stops short of 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 readOnly, idempotent, non-destructive and open-world, so the description doesn't need to re-state safety. It adds genuinely new context: the output is a key that collapses name variations into a single value, and the call costs $0.01 USDC via x402 — cost disclosure is valuable for an agent deciding whether to loop this over records.

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 tight sentences: what it does, how to use the output, what it costs. The core purpose is front-loaded and nothing is redundant.

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

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

There is no output schema, but the description explains the return value (a similarity key that is stable across name variations) and how to consume it. For a single-parameter, read-only tool with full annotation coverage, nothing an agent needs in order 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% and there is one required parameter, so the baseline is 3. The description adds meaning beyond the schema by showing that reordered and abbreviated forms ('Smith, Robert J.', 'Bob Smith') are acceptable inputs, which the schema's single 'John C. Smith' example does not convey.

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

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

States a specific verb and resource: generates an AI-powered similarity key for an individual's full name for matching/deduplication. The phrase 'similarity key' plus the grouping instruction distinguishes it from score-returning siblings like interzoid_fullname_match_score and from the composite address/company+name matchers.

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

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

Gives a concrete usage recipe — group records on the returned key to find duplicate contacts and customers across CRM, marketing and customer datasets — which tells the agent exactly when this is the right tool. It stops short of naming the alternative siblings (fullname_match_score, company_and_fullname_match) or stating exclusion 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, openWorldHint, and destructiveHint=false. The description adds valuable behavioral context beyond those annotations: it specifies a 0-100 similarity output, matching behavior for name order/nicknames/initials/abbreviations, and a $0.01 USDC x402 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 compact and front-loaded: the core matching capability appears first, followed by usage context and cost. Every sentence adds useful information without 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?

This is a simple two-parameter read-only matching tool with no output schema. The description states the return range (0-100), the matching capabilities, the intended use case, and the cost, which is sufficient 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 both fullname1 and fullname2 are already documented with descriptions and examples. The description reinforces the comparison semantics with an example ('Robert Smith' vs 'Bob Smith Jr.') but does not add parameter-specific constraints or formatting details 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 gives a specific verb and resource: it compares two individual names and returns a 0-100 similarity score. It clearly distinguishes itself from address or company matching by specifying 'two individual names,' but it does not explicitly differentiate itself from the sibling tool interzoid_fullname_match.

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 usage context: confirming contact matches and resolving customer identities. However, it does not state when not to use it or name alternatives such as interzoid_fullname_match or interzoid_address_and_fullname_match.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the bar is lower. The description adds genuinely new context: the $0.01 USDC x402 payment requirement and that the result is probabilistic ('likely gender'), which matters for interpretation. It does not describe the return format or whether a confidence score accompanies the answer.

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 sentences with no filler: the capability is front-loaded in the opening clause, followed by use cases and cost. Nothing redundant with the title or schema.

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

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

For a one-parameter, read-only tool this covers purpose, audience, and cost. However, with no output schema, the description never states what comes back (e.g., 'male'/'female' label, confidence value, null handling for ambiguous names), leaving the return contract underspecified.

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 documented, so baseline is 3. The description adds real meaning beyond the schema: the schema says 'First name' while the description clarifies the tool also accepts full names and international names, widening the expected input.

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

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

States a specific verb and resource: 'determines the likely gender for a first or full name, including international names.' An agent can distinguish this from siblings like interzoid_name_origin or interzoid_fullname_match without opening the schema, though no sibling is named explicitly.

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

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

The use-case list (marketing personalization, demographic analysis, salutation selection) implies when the tool is appropriate, but there is no explicit when-not guidance and no routing against adjacent siblings such as interzoid_name_origin or interzoid_identify_language.

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

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

Annotations already declare readOnly, idempotent, openWorld, non-destructive, so safety is covered. The description adds genuinely useful non-schema context: deterministic key behavior (variations map to the same key) and a $0.01 USDC x402 cost per call. It stops short of describing the response shape or handling of unparseable addresses.

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 sentences, front-loaded with the core action and output concept, followed by the operational tip and cost. Nothing redundant.

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 does explain what is returned conceptually (a similarity key) and how to use it, and it discloses cost. Minor gaps remain around error behavior and the exact response field name, but an agent has enough 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?

Only one parameter and schema coverage is 100% (it documents 'Full international address string' with an example). The description's 'any country's format' reinforces locale-agnostic input but adds little beyond the schema's own wording; baseline 3 applies.

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

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

States a specific verb (generates a similarity key) and resource (global/international address), plus the deduplication purpose. The 'international / any country's format' framing implicitly separates it from domestic match siblings like interzoid_address_match_advanced, but no sibling is named explicitly.

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

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

Gives concrete when-to-use guidance: 'Group on the key to deduplicate international customer, supplier, and location records.' It does not exclude or route to alternatives (e.g. address_parse or address_match_advanced), so guidance is clear but not complete.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds genuinely new behavioral context: cost ($0.01 USDC via x402) and a detailed breakdown of what the response contains. It does not discuss failure/timeout behavior, keeping it below 5.

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

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

Three tight sentences: what it does first, what it returns second, use cases and cost last. Every sentence carries distinct information with no repetition of the title or schema.

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

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

With no output schema, the description usefully enumerates the return fields (total load time, HTTP status, phase timings, content preview), and the cost note covers billing. Only the absence of any error/timeout semantics keeps it from being fully complete.

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

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

Schema description coverage is 100%, so both 'url' and the 'origin' enum are already fully documented with defaults and examples. The description only paraphrases 'from a chosen global location', adding no syntax or constraints beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('measures real-world page load time for any URL') plus the scope modifier (from a chosen global location). The sibling tools are all data-enrichment lookups, so this performance-testing tool is unmistakable in the set.

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?

Names concrete scenarios — global latency monitoring, CDN validation, uptime and performance checks from multiple regions — which tells the agent when this tool fits. It stops short of explicit exclusions or pointing at an alternative, so it lands at 4 rather than 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered; the description's real contribution is the pricing disclosure ('$0.01 USDC via x402') and the 'live/current' freshness guarantee, both of which matter to a caller deciding whether to invoke. It stops short of saying what happens for an unrecognized city or how stale the data can be.

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

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

Three compact clauses, front-loaded with what the tool returns, then audience, then cost — a sensible ordering. The 'For travel, logistics, event planning' list is slightly promotional but functions as usable context rather than filler.

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

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

With no output schema, the description usefully enumerates the returned fields, and it discloses the payment model, which an agent needs before calling. Remaining omissions — units precision beyond F/C, error behavior for an unknown location, data freshness window — are minor for a one-parameter read tool whose annotations already cover safety.

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 'location' parameter is fully documented with examples, so the schema does the heavy lifting. The description only adds that any city worldwide is accepted, which is marginal but consistent with the schema's example list.

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

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

States a specific verb and resource ('Current weather for any city worldwide') and enumerates the returned fields (temperature F/C, conditions, humidity, wind, atmospheric data). No sibling tool covers weather, so the resource alone separates it cleanly from the address/company/profile family.

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?

Offers use-case framing ('travel, logistics, event planning, AI assistants that need live weather') but never states when not to use it or points to an alternative. The usage context is implied rather than operational, and the 'any city worldwide' scope is the only real selection signal.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the description's added value is the $0.25 USDC x402 pricing and the fixed data-source scope (SAM.gov, CAGE). That pricing and sourcing detail is exactly the extra behavioral context an agent needs; it stops short of stating behavior on unmatched companies or data freshness.

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?

One dense field-enumeration sentence, then use cases, then cost – front-loaded and free of filler. Every clause conveys either returned data or a decision-relevant fact.

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, enumerating returned fields is essential and done well, and cost is disclosed. Minor gaps: no note on empty/no-match results, US-only jurisdiction is implied but not called out, and the language option is unacknowledged.

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 both parameters (lookup, language) are already documented. The description adds nothing about expected lookup format (legal name vs. trade name) and never mentions the multilingual option, so it neither helps nor hurts beyond the schema baseline.

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

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

States a specific verb-resource pair ('US federal government contracts for any company') and enumerates the exact data returned (lifetime/TTM value, awarding agencies, set-asides, NAICS, CAGE). This clearly separates it from siblings like interzoid_private_company_deal_intel or interzoid_competitor_analysis.

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?

Names concrete use cases: GovCon sales, competitive analysis, teaming partner research, due diligence. It gives clear context for when to reach for it, but offers no explicit exclusions or pointers to which sibling to use instead (e.g. deal intel vs. contracts).

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 the safety profile (read-only, idempotent, non-destructive). The description adds important behavioral context: the cost ($0.01 USDC via x402) and the scope of supported languages. It does not mention return format or latency, but given the annotations, this is adequate.

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 core action, followed by use cases and cost. Every sentence earns its place with no redundancy.

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

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

For a simple one-parameter tool, the description covers purpose, usage, and cost. However, it does not describe the return value (e.g., language name or code), and there is no output schema to compensate. This leaves a noticeable gap in completeness.

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

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

With 100% schema description coverage, the single parameter 'text' is fully documented. The description adds no additional syntax or format details beyond what the schema provides, so 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 states a specific verb and resource: 'identifies the language of a text string across many world languages.' This is unambiguous and distinguishes it from siblings like translation tools.

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

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

It provides clear usage contexts ('routing support tickets, translation pipelines, and content moderation') but does not explicitly compare to alternatives or state when not to use it. However, the examples sufficiently indicate the tool's role.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds genuinely non-obvious behavioral context: a fixed per-call price of $0.25 USDC via x402. It does not describe failure modes (unknown company) or the confidence-score range, keeping it below a 5.

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

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

Two sentences, front-loaded with the resource and return contents, then use cases and cost. No redundant filler and nothing that repeats the schema.

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

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

There is no output schema, so the description usefully enumerates the returned fields (codes, titles, sector, subsector, definition, confidence). Combined with the cost disclosure and the fully documented schema, an agent has everything needed to decide and call 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 `lookup` and `language` are fully documented in the schema, including the enum and the 'same price in every language' note. The description adds nothing about parameters beyond what the schema provides, 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 names a specific verb+resource ('Industry classification for any company') and enumerates the exact outputs (NAICS/SIC codes with official titles, sector, subsector, definition, confidence score). This clearly separates it from enrichment siblings like business_info, company_verification, or esg_profile, though it never names an alternative explicitly.

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

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

It gives concrete use-case context (firmographic segmentation, territory/market sizing, compliance, underwriting) which tells the agent when the tool is appropriate. It stops short of stating when NOT to use it or pointing to a sibling alternative, so no explicit routing guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The one genuinely additive fact is the billing model ('Cost: $0.25 USDC via x402'), which tells the agent this is a paid call with an auth/payment requirement. Beyond that it says nothing about rate limits, failure modes, or whether results are cached.

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, front-loaded with the capability and output list, then use cases, then cost. Every sentence carries distinct information — no restatement of the tool name or filler.

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

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

With no output schema, the description correctly carries the return-field burden by enumerating the eight result categories. Combined with full schema coverage and annotations, an agent has enough to call it correctly. It omits pricing/error handling nuance and any hint of response structure, which keeps it from a 5.

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%: 'lookup' is documented as an IPv4/IPv6 address with an example, and 'language' is documented with its enum and default. The description only reconfirms that both IPv4 and IPv6 are accepted; it adds no format or edge-case guidance beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('IP address intelligence' for any IPv4 or IPv6 address) and enumerates exactly what comes back: geolocation, ASN, organization, CIDR, hostname, abuse contact, reputation. No sibling tool covers IP profiling, so the resource boundary is unambiguous even within a large family of '*_profile' 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?

Names four concrete use cases (fraud detection, security investigations, traffic analysis, visitor identification), which gives an agent clear positive routing signals. It stops short of stating when not to use it or naming an alternative for overlapping needs such as email trust or company 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 read-only, idempotent, open-world, non-destructive. The description adds valuable context annotations can't carry: the pricing model ($0.25 USDC via x402, i.e., a paid call), the governing method (Revenue Procedure 2019-48), and what values are returned. It doesn't cover failure behavior for non-CONUS or ambiguous lookups.

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

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

Two tight sentences: what it returns first, then use cases, then cost. Every sentence earns its place and the cost is front-loaded where the agent will see it.

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

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

Given no output schema, the description usefully says what comes back (high/low classification plus lodging and M&IE amounts) and discloses the paid-call cost. Minor gap: no mention that only CONUS locations are supported, which matters for invocation correctness.

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 both parameters are documented in the schema, including the enum and examples. The description adds no parameter-level detail beyond referencing 'any US location,' 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?

States a specific verb+resource: returns IRS per diem lodging and M&IE amounts for a US location under the high-low method. It names the classification outcome (high-cost vs low-cost) and cites Revenue Procedure 2019-48, distinguishing it clearly from siblings like sales_use_tax_rates or currency_rate.

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

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

Gives use cases (travel expense reimbursement, accountable plans, expense management) that tell the agent when this tool applies. It doesn't explicitly exclude alternatives or warn about CONUS-only scope in the description — the CONUS restriction only appears in the schema — so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety is covered. The description adds genuinely non-structured information: the $0.25 USDC x402 cost, which an agent needs before calling. It doesn't cover not-found behavior, but the core behavioral gaps are filled.

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 purpose and field coverage are front-loaded in one dense sentence, followed by use context and cost. The field enumeration is long but each item is informative rather than filler; there is no redundant restatement 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?

With no output schema, the description compensates by listing the returned data categories (ratings, debt, pension/OPEB, revenue sources, EMMA/MSRB links), which tells the agent what it will get. Cost and the optional language parameter are also addressed via the schema.

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 both parameters are fully documented in structured fields. The description's issuer-type enumeration loosely reinforces the 'lookup' parameter semantics but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource ('Municipal bond issuer research for any US issuer') and enumerates the issuer types covered, which lets an agent separate it from siblings like interzoid_university_info, interzoid_city_standard, or interzoid_gov_contracts without opening any schema.

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

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

The 'For muni bond research, credit analysis, and public finance' clause gives a clear use context, which most siblings lack. It does not name an alternative tool or state when-not to use it, so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description is free to add the genuinely new and decision-relevant fact: invocation costs $0.01 USDC via x402, meaning an agent must handle payment. That is meaningful context beyond structured fields. It still omits what the response looks like or how confident the origin inference is, keeping it out of 5 territory.

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 sentences, front-loaded with the core purpose, then use cases, then the critical cost note. No filler. The 'Name origin:' prefix lightly duplicates the title but serves as a scannable lead.

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, the description is close to sufficient, but with no output schema it should say what comes back — a country code, a cultural label, a confidence score — so the agent can chain correctly. That gap is the main 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?

Only one parameter and the schema documents it fully (100% coverage, with an example like 'Pierre Bonaparte'). The description adds no meaning beyond the schema — no guidance on name format, single vs. full name, or ambiguity handling. Baseline 3 is appropriate when the schema carries the load.

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

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

States a specific verb and resource: 'identifies the likely country or cultural origin of a person's name.' An agent can immediately tell this apart from siblings like interzoid_identify_language or interzoid_gender, though the description never explicitly contrasts with them.

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?

Names three application contexts (demographic analysis, localization, marketing segmentation), which implies when to reach for it, but gives no exclusions or named alternatives (e.g., when to use interzoid_official_name instead). Usage is inferred rather than directed.

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, openWorld, idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely new and important behavioral context: a paid call at $0.25 USDC via x402, which an agent must know before invoking. It omits result-count/radius behavior but otherwise adds value beyond the structured fields.

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 sentences, front-loaded with the capability, then use cases, then cost. Nothing is wasted, though the use-case clause is somewhat generic filler compared to the high-value cost disclosure.

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 covers what it does, what it returns at a high level, when to use it, and the payment requirement. It does not say how many results come back or whether the search radius is fixed, which is the only meaningful residual 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 there is only one parameter, already documented as "Reference address or location to find coffee shops near" with an example. The description's "near an address or location" restates the schema rather than adding format or syntax guidance, so baseline 3 applies.

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

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

The description uses a specific verb+resource ("Find coffee shops near an address or location") and states the payload contents (names, addresses, distances). No sibling tool in the list does POI/nearby lookup, so an agent can immediately tell this is the geospatial point-of-interest tool.

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

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

It gives concrete usage contexts ("travel, meeting planning, and location-aware assistants"), which tells the agent when to reach for it. It does not state exclusions or name an alternative, but among these siblings there is no plausible competing tool for nearby-place search, so the gap is small.

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 declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description's genuinely additive facts are the 0-100 score output and the $0.01 USDC x402 cost — useful, but it says nothing about latency, failure modes, or what a borderline score means, which matters for a paid scoring call.

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

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

Front-loaded with what the tool does and its return value, then uses, then cost. Dense but well-ordered; the only mild bloat is the triple use-case list.

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 two required string parameters and no output schema, the description supplies the missing return-value semantics (0-100 likelihood score) and the pricing model. An agent can call this correctly from the description alone; only sibling disambiguation 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%, so both parameters are already documented with examples. The description's example pair ('General Electric' vs 'GE Corp') only illustrates that abbreviations/aliases are acceptable inputs — a marginal add over the schema's own 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?

States a specific verb and resource ('compares two organization or company names') plus the output semantics (0-100 similarity score) and a concrete example pair. It does not distinguish itself from close siblings like interzoid_company_match_advanced or interzoid_company_and_address_match, so an agent can describe the tool but not tell why it beats those alternatives.

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

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

Names use cases ('verify record matches, resolve entities, review fuzzy matching results'), which implies when to reach for it. However, it never states when NOT to use it or points to the advanced/address-combined sibling variants, leaving selection among ~60 siblings 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 cover the safety profile (readOnly, idempotent, non-destructive), so the description's main added value is the pricing disclosure ('$0.01 USDC via x402'), which is genuinely useful for an agent deciding whether to call. It stops short of describing the return value or any failure modes, but that is a modest gap given the annotation 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?

Three tight sentences, front-loaded with what the tool does, followed by when to use it and the cost. No filler or redundancy; every sentence carries information an agent needs.

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

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

For a simple, single-input, read-only utility with rich annotations and full schema coverage, the description supplies purpose, example, use cases, and pricing. The only missing piece is what the standardized output looks like, which is minor without an output schema but not entirely negligible.

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 a single parameter and 100% schema description coverage, the schema already documents 'org' fully, including the B.O.A. example. The description repeats that same example rather than adding new semantics such as accepted input length, formats, or how ambiguous names are handled, so it stays at the baseline.

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

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

The description names a specific verb and resource ('converts an organization name to its standard form') and clarifies the normalization dimension with a concrete example ('b.o.a.' to 'Bank of America'). It does not, however, differentiate itself from close siblings such as interzoid_official_name or interzoid_company_verification, which an agent would need to choose between.

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 clear usage contexts: CRM and vendor data cleansing, deduplication, and consistent reporting. That gives an agent a solid sense of when to reach for it, but there are no explicit exclusions or named alternatives for overlapping tasks like matching or 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 cover read-only, idempotent, open-world, and non-destructive semantics, so the description's added value is the $0.25 USDC/x402 cost disclosure and the enumeration of returned attributes. It does not say what happens when no parent exists (standalone company) or whether results are cached, which are the remaining behavioral gaps.

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

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

Three sentences, front-loaded with the core behavior, then the canonical example, then use cases, then price. Nothing is redundant and no sentence could be removed without losing 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?

With no output schema, the description correctly compensates by enumerating returned fields and disclosing cost. The only missing piece for full completeness is edge-case behavior (no parent found, ambiguous matches) on a paid, open-world lookup.

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

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

Schema coverage is 100% and both parameters are fully documented in the schema, including the enum values and the default-English behavior. The description adds no parameter-level guidance beyond implying 'any company or subsidiary' is acceptable input, so baseline 3 applies.

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

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

The first sentence states a specific verb+resource: returns the parent company for a given company or subsidiary, along with location, website, description, and reference URL. The Instagram→Meta example makes the semantics unmistakable and clearly differentiates it in substance from siblings like interzoid_business_info or interzoid_official_name. It stops short of naming any sibling explicitly.

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

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

It gives concrete usage contexts (corporate hierarchy research, account rollups, KYB, supplier risk, sales territory planning), which tells an agent when the tool is appropriate. It offers no explicit exclusions or pointers to alternative tools when only basic firmographic data is needed.

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, open-world, non-destructive, so the safety profile is covered. The description adds two things annotations cannot: the per-call cost ($0.25 USDC via x402) and the concrete return payload. It does not describe failure behavior for invalid numbers or whether partial results are returned, which keeps it below 5.

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

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

Three compact sentences, front-loaded with the core purpose and output fields, then use cases, then cost. The field enumeration is long but justified because no output schema exists. No filler.

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

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

With no output schema, the description carries the return-value burden and does so thoroughly, plus adds the billing model. The only gap is error/invalid-input behavior and any rate consideration for a paid endpoint.

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 both parameters are documented in-schema (including the enum list and the note that language does not change price). The description adds nothing about accepted phone formats or default region handling, 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?

"Phone number intelligence: validates a phone number and returns its normalized international form, country, region, line type, carrier, organization, time zone, and risk assessment" is a specific verb+resource with an enumerated output. That clearly distinguishes it from the nearest sibling interzoid_ip_profile (IP-based geolocation) and the email tools, which cover related but different identifiers.

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

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

It lists target scenarios (fraud prevention, contact data verification, lead qualification, call routing), which implies when to call it. But there is no exclusion or alternative routing — nothing says what to do for email/IP/address lookups or when a cheaper sibling would suffice.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely non-schema behavior: a $0.25 USDC x402 payment requirement and the presence of 'data confidence notes' on the results — the cost disclosure is especially important for an agent deciding whether to call. It doesn't say what happens for an unknown/private company or how partial data is signaled.

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 core sentence front-loads the resource and the returned fields, followed by a short use-case clause and a cost clause — no filler. The field enumeration is a long run-on list, but it earns its place because there is no output schema to convey what comes back.

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 must convey return content, and it does so thoroughly, plus it flags cost and confidence notes. Remaining gap is edge-case behavior (company not found, ambiguous names, private vs. public distinction) given the openWorld annotation.

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 `lookup` (company name, with an example) and `language` (enum with default and note that pricing is uniform) are fully documented in the schema. The description adds nothing about parameters, 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 opens with a specific resource ('Private company deal intelligence') and enumerates the exact data returned: funding rounds, valuation, investors, revenue estimate, growth, headcount, deals/exits, comparables, industry, founding year, HQ. That field list distinguishes it from generic siblings like interzoid_business_info or interzoid_company_verification. It stops short of naming a sibling to explicitly differentiate from.

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 names concrete use contexts — venture capital, private equity, M&A research, investor prospecting — which tells an agent when this tool is the right pick. It gives no exclusions or 'use X instead when...' routing against the many related Interzoid entity tools, so the guidance is clear but incomplete.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the bar is lower. The description adds meaningful context beyond them: the output is a deterministic similarity key rather than a score, and each call costs $0.01 USDC via x402 — a real invocation consideration. Auth mechanics beyond the payment mention are left implicit.

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

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

Two tight sentences, front-loaded with the core purpose and mechanism, followed by use cases and cost. No redundant restatement of the name or 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 2-parameter tool with no output schema, the description explains the return concept (a matching key) and the cost model, which is enough to call it correctly. It could say more about how to consume the key (e.g., equality comparison) but 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?

Schema coverage is 100%, so both parameters are already documented. The description reinforces what 'product' accepts (name, description, model numbers) but adds nothing about the 'algorithm' variant or when to choose one, so it sits at the baseline.

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

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

States a specific verb ('generates an AI-powered similarity key') and resource ('a product name or description'), and explains the mechanism (variations normalize to the same key). This clearly distinguishes it from sibling match tools that operate on addresses, companies, and full names.

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

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

Gives concrete use cases — matching products across catalogs/marketplaces/supplier feeds, deduplicating SKUs, and comparing prices — which tells the agent when this tool applies. It does not name an alternative or state exclusions (e.g., use address_match for addresses), so it stops short of a 5.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered structurally. The description adds real context beyond that: the response fields returned and the paid cost model ('$0.25 USDC via x402'), which is operationally important. It does not say whether multiple recalls are returned or how results are paged.

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 sentences, front-loaded with the capability, followed by use cases and cost. No filler or repetition; every clause carries information an agent can act on.

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 compensates well by enumerating the returned fields and disclosing cost. The only gap is result cardinality/pagination behavior, which is minor for a lookup tool.

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

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

Schema description coverage is 100% and the single 'lookup' parameter already documents 'Product name, brand, or category to check for recalls' with an example. The description's 'for a product, brand, or category' merely repeats that, adding no new format or syntax guidance, so baseline 3 applies.

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

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

States a specific verb+resource ('Product recall lookup') and immediately defines its inputs (product, brand, or category) and outputs (recall date, hazard, remedy, regulatory authority). No sibling tool in the list covers recalls, and the domain is explicitly named, so an agent can select it without 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?

Gives concrete use cases ('product safety checks, marketplace compliance, and consumer protection') that tell the agent when this tool fits. It stops short of naming alternatives or exclusions (e.g. versus interzoid_product_match for matching rather than recall data), so it is clear but not complete.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds two things annotations cannot: the ten-year lookback window on returned history and a hard cost of $0.25 USDC via x402, which materially affects whether an agent should call it. No error or coverage semantics are given beyond the US-only scope.

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 resource and its payload, closing with use cases and cost. No filler and nothing an agent must scroll past to reach the key facts.

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

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

With no output schema, the description carries the return-value burden and does so by enumerating the specific fields returned. Combined with full parameter documentation, the US-only scope, and the price, an agent has everything needed to decide and call 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 address param carries a formatted example and the language param enumerates every code with a note that pricing is identical across languages. The description adds nothing about either parameter, so the schema 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?

Specific verb+resource ("Property transaction history for any US address") followed by an enumerated payload: sale date/price, prior transactions, price-per-square-foot trajectory, ownership chain, deed types, mortgages, current owner. This is clearly distinguishable from sibling enrichment tools like interzoid_building_profile or 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?

"For real estate research, valuation, and due diligence" gives concrete selection context, so an agent knows the class of task this serves. It stops short of explicit exclusions (e.g., when to prefer interzoid_building_profile or address parsing instead), so it lands at 4 rather than 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-redundant context: the result is an AI synthesis of multiple real-time sources (freshness/aggregation behavior) and a $0.25 USDC x402 cost, which matters for an agent deciding whether to call it. It does not describe result shape or latency, keeping it below a 5.

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

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

Three compact sentences: what it returns, when to use it, then cost. Zero filler and the payload description is front-loaded ahead of the commercial detail.

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

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

For a one-parameter read tool with rich annotations, the description covers output nature, sourcing model, use cases, and the paid-call cost. No output schema exists, but framing the return value as an 'AI-powered summary' is sufficient 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?

Single parameter with 100% schema description coverage, so the schema already explains that 'lookup' is a company name or topic. The description's phrase 'a company or topic' echoes the schema rather than extending it (no guidance on ticker vs. legal name vs. free-form topic breadth), so the baseline 3 applies.

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

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

States a specific verb and resource: an AI-generated summary of recent news for a company or topic, sourced from multiple real-time sources. It is clearly distinguishable in substance from siblings like interzoid_buying_signals or interzoid_x_last_three_posts, but it never names an alternative, so the agent must infer the routing itself.

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?

Four concrete scenarios (account research, sales triggers, competitive monitoring, market intelligence) give an agent a clear sense of fit. There are no exclusion conditions or named sibling alternatives, so it stops short of full routing guidance.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior. The description adds the non-obvious economics — $0.25 USDC via x402 payment — and the shape of the returned rate breakdown, which the agent could not infer from structured fields.

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

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

Three compact sentences, front-loaded with what the tool returns, then the accuracy caveat, then use cases and price. 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?

With no output schema, the description correctly supplies the return structure (per-jurisdiction plus combined rate), and it covers the payment requirement and best-practice input. An agent has everything needed to decide and call correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds decision-relevant meaning: the lookup parameter accepts anything from a state down to a full street address, and precision of the input drives accuracy of the rate. The language parameter is not addressed here, but the schema fully documents 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?

Names a specific resource (current US sales and use tax rates) and the exact input surface (address, ZIP, city, or state), plus the granularity of the result (state, county, city, special district, combined). This clearly separates it from sibling rate tools like interzoid_eu_vat_rates and 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?

Gives explicit application contexts (e-commerce checkout, invoicing, tax compliance, accounting) and an accuracy rule: a full street address yields the most accurate rate. It stops short of naming when to use a sibling instead (e.g. EU VAT lookups), so no exclusion guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so credit here goes to two additions they don't: the per-call price ('$0.01 USDC via x402') and a hint at the output shape ('full name plus the standard abbreviation'). Missing only edge-case behavior for unrecognized or ambiguous input.

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 tight sentences: transformation, illustration, use cases, cost. Front-loaded with the core purpose and free of filler.

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

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

With only two parameters, full schema coverage, and no output schema, the definition covers purpose, input flexibility, output shape, and payment requirement. It stops short of describing failure modes for invalid or non-US input, which matters for an openWorld 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%, so the baseline of 3 applies. The description usefully shows the fuzzy input forms the 'state' parameter accepts, but says nothing about the optional 'algorithm' parameter or what variants like 'ai-medium' change.

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

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

States a specific verb and resource ('US state and province standardization') and illustrates with concrete input variations ('Calif', 'Cal', 'CA') mapping to full name plus abbreviation. The resource scope makes it distinguishable from interzoid_city_standard and interzoid_country_standard, though those siblings are never named or explicitly excluded.

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

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

It gives use-case context ('address cleansing, form normalization, consistent reporting'), which orients the agent, but offers no when-not guidance and never mentions the near-neighbor tools (city_standard, country_standard) that an agent might confuse it with.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open world), so the bar is lower. The description adds genuinely new behavioral context: the exact payload returned (including an 'AI analyst assessment') and, critically, 'Cost: $0.25 USDC via x402' — a payment requirement an agent must know before calling. It stops short of covering error behavior for invalid tickers.

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

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

Three compact sentences: what it returns, who it's for, what it costs — with the highest-value facts (fields, price) front-loaded. The audience sentence ('financial agents') is the weakest element but still carries mild routing 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 correctly shoulders the burden by enumerating return fields, and it discloses the paid-call model. Parameters are fully covered by the schema. Only minor gaps remain: no guidance on invalid/unknown tickers or on what the 'AI analyst assessment' contains.

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 both parameters are already fully documented, and the enum plus the 'same price in every language' note live in the schema. The description only restates the lookup key as 'ticker symbol' and says nothing about the optional language parameter, adding no meaning beyond the schema. 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?

Names a specific verb and resource ('Stock analysis by ticker symbol') and enumerates the returned fields, so the agent knows exactly what this produces. It does not explicitly distinguish itself from the nearest sibling, interzoid_business_info, which also returns company name/website/description — a one-line contrast would have earned 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 phrase 'For investment research, financial agents, and portfolio screening' implies when the tool fits, but there are no explicit exclusions or named alternatives (e.g., use business_info for private companies without a ticker). Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety and determinism are covered elsewhere. The description's real contribution is the pricing disclosure ('$0.25 USDC via x402'), which is valuable for an agent deciding whether to call. It adds nothing about latency, rate limits, or behavior when a domain has no detectable stack.

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 front-loaded sentences: capability first, then use cases, then cost. The technology enumeration is long but earns its place by telling the agent what comes back in the absence of an output schema. Slight cost for list density given that sibling names and descriptions could imply some categories.

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 emits a multi-category result but has no output schema, so the description's enumeration of detected technologies effectively doubles as a return-value overview, which is the right call. Pricing is disclosed. The only gap is what happens on a domain with no stack detected, which would help the agent interpret empty results.

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

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

Schema description coverage is 100%, and both parameters carry descriptions plus an example and a full enum. The description only restates 'from a domain' and says nothing beyond the schema about format expectations (e.g., bare domain vs URL) or how the language option affects output. Baseline 3 applies.

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

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

States a specific verb+resource ('Website technology stack detection: from a domain, identifies...') and enumerates the detected categories (CMS, frontend, backend, web server, hosting, CDN, analytics, security, e-commerce). No sibling tool covers technographics, so the tool is easily distinguished from business_info or competitor_analysis.

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?

Names concrete use cases (technographic lead targeting, competitive research, sales prospecting), which gives the agent a clear reason to select it over adjacent enrichment tools. It stops short of explicit when-not-to-use guidance or naming an alternative 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 declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious context beyond that: a $0.01 USDC charge via x402, which matters for cost-aware tool selection. It stops short of noting length limits or failure behavior.

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

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

Three short sentences, front-loaded with the core action and ending with the cost disclosure. Mild redundancy between 'any language' and the parenthetical examples, but nothing that wastes real space.

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 two simple parameters and no output schema, the description is nearly sufficient, but it never says what comes back (translated text only, or detected source language too). For a paid call, knowing the response shape before spending $0.01 would be valuable.

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 both 'text' and 'to' are already documented with examples in the schema. The description restates the target-language idea with sample values ('Japanese, French, or Spanish') but adds no format constraints, case rules, or BCP-47 style guidance 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 states a specific verb and resource ('Translate text to any language') and adds that source language is auto-detected while the target is user-specified. It does not name the close siblings interzoid_translate_to_english or interzoid_identify_language, so the agent must infer the split rather than being told.

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

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

Use cases are listed (localization, multilingual apps, global communications), which implies when to reach for it. There is no explicit when-not guidance and no mention of interzoid_translate_to_english as the alternative when English is the target.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral facts: automatic source-language detection and a per-call cost of $0.01 USDC via x402, which matters for an agent deciding whether to call it.

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

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

Three short sentences, front-loaded with what the tool does, followed by use cases and pricing. Every sentence carries information an agent would act on, with no repetition of the schema.

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

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

With no output schema, the description does state what comes back (an English translation) and that source language is detected. It stops short of saying whether the detected language is returned in the response or how errors/unsupported input are surfaced, a small gap for a paid API call.

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

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

Schema coverage is 100% with a single documented "text" parameter, so the schema carries the parameter burden. The description adds only the loose constraint that the input may be in any language, which the schema already says; no format, length, or encoding guidance is offered.

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

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

States a specific verb and resource ("Translate any language to English") plus the implicit detection step, so the operation is unambiguous. It does not explicitly contrast itself with the sibling interzoid_translate_to_any, leaving the agent to infer the direction difference from the name alone.

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

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

Use cases are given ("multilingual support, content analysis, normalizing international data"), which implies when the tool fits. However, there is no explicit when-not guidance and no reference to the closely related interzoid_translate_to_any or interzoid_identify_language, so the agent must guess at routing.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely new operational context: the $0.25 USDC x402 payment cost, which an agent must know before calling a paid endpoint. It does not mention throttling, failure modes, or lookup ambiguity handling, keeping it below a 5.

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

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

Front-loaded with the lookup purpose, then the return-field inventory, then use cases, then price — a sensible order. The long comma-separated field list is dense but earns its place given there is no output schema. Slightly heavy but no filler sentences.

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 enumeration of returned fields is the only signal of what an agent gets back, and it covers that well; the pay-per-call cost is also disclosed. Remaining gaps are minor — no note on partial matches, unknown institutions, or whether incomplete records return nulls.

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 having an example ("Ohio State") and 'language' enumerating all 16 accepted codes — the schema does the heavy lifting. The description adds no syntax guidance for the lookup string (fuzzy vs exact, abbreviation handling) or extra meaning for the language 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?

States a specific verb and resource — 'University and college lookup' — and enumerates exactly what comes back (official name, location, type, founding year, enrollment, tuition, endowment, conference, programs, website). No sibling in the long Interzoid catalog covers higher-education institutions, so an agent can disambiguate from business_info, city_standard, or country_info on the resource alone.

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?

Names concrete use cases — education research, admissions tools, and enriching student, alumni, and recruiting records — which gives a clear selection context. It stops short of when-not to use it or naming an alternative (e.g. company enrichment via interzoid_business_info), so it is context-rich but not exclusionary.

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, open-world, non-destructive behavior, so the description isn't burdened with the safety profile. It adds genuinely new context: results carry a confidence score, and each call costs $0.05 USDC via x402 — important pre-invocation cost information the annotations do not convey. It doesn't say what happens when no handle is found, keeping it below 5.

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

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

Purpose, use cases, output shape, and cost are delivered in three front-loaded clauses with no filler. Nothing in the text is redundant with the name or schema.

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

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

For a two-parameter lookup with no output schema, the description covers purpose, entity scope, confidence score, language support pricing, and the payment model — enough to call it correctly. Only the no-match/failure behavior is left unstated.

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 both parameters are documented (including the language enum), so the baseline is 3. The description adds value by showing the lookup accepts loose descriptive phrases like 'sf 49ers' rather than requiring exact names, which is semantics beyond the schema's 'Amazon CEO' example.

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

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

States a specific verb and resource ('X (Twitter) handle lookup: finds the X handle') plus the range of entity types it accepts, which cleanly separates it from siblings like interzoid_x_profile and interzoid_x_last_three_posts. The parenthetical example ('sf 49ers' to @49ers) makes the input-to-output mapping concrete.

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

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

Gives named use cases (social media enrichment, influencer and brand research, contact enrichment) that tell the agent when this tool fits. It does not explicitly exclude alternatives such as interzoid_x_profile or interzoid_x_last_three_posts or state when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered; the description adds the genuinely new disclosure of a $0.05 USDC x402 cost and the shape of the result (three posts with text and date). It does not mention rate limits, payment failure behavior, or handling of nonexistent/protected handles.

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 sentences, front-loaded with what is returned, followed by use cases and the cost caveat. Every sentence contributes and nothing is padded.

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

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

For a one-parameter tool with no output schema, the description covers return contents, intended use, and pricing, which is nearly everything an agent needs. Minor gaps remain around edge cases (handle not found, protected accounts) and payment mechanics.

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 required handle parameter, including the '@-prefix optional' note, so the schema carries the semantics. The description adds nothing about format or normalization beyond saying posts come 'from a handle'. Baseline 3 applies.

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

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

States a concrete verb and resource: returns the three most recent posts from a handle, with full text and date. The scope (exactly three posts) is precise. It stops short of distinguishing itself from nearby siblings like interzoid_x_profile, interzoid_x_handle, or interzoid_recent_news, leaving the agent to infer which X/News endpoint to pick.

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?

Lists scenarios (social monitoring, brand tracking, news alerts, AI agents needing current posts), which gives implied usage context. It never says when to prefer this over interzoid_x_profile or interzoid_recent_news, and gives no exclusions or prerequisites beyond the handle.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious context beyond that: the $0.05 USDC x402 payment cost, which affects whether an agent should call it speculatively. It stops short of saying what happens for a nonexistent or suspended handle.

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 sentences with no filler: the return payload is front-loaded, then use cases, then cost. The use-case list is slightly boilerplate but earns its place as routing signal.

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 compensates by enumerating the returned fields, and it discloses the per-call cost. For a one-parameter read tool this is close to complete; only error/empty-result behavior for invalid handles is left unstated.

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

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

There is a single required parameter with 100% schema description coverage, and the schema already explains that the @ prefix is optional. The description only says "for a handle" and adds no format, casing, or lookup-failure semantics, so the schema does all the work — 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?

Names a specific verb and resource ("X (Twitter) profile lookup") and enumerates exactly what is returned: display name, bio, follower/following counts, post count, website, location, creation date. This clearly separates it from interzoid_x_last_three_posts, but it never acknowledges interzoid_x_handle, which sounds closely related and would be the main sibling to disambiguate against.

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?

Lists plausible scenarios (influencer research, social listening, audience analysis, account verification), which implies when to reach for it. However, it gives no explicit when-not-to-use guidance and does not route the agent to interzoid_x_handle or interzoid_x_last_three_posts for adjacent needs.

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