ApiOne B2B Enrichment (GCC and MENA)

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses latency (5-9 seconds), cost structure (5 credits, free on misses/errors/no-evidence), estimate-vs-fact semantics ('size, revenue and funding fields are estimates', missing evidence yields null), and where provenance lives (_meta.sources). These are operational traits an agent cannot get from the annotations or schema.

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

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

Purpose and scope lead, then the field inventory, then routing, then the operational caveats (latency, estimation, cost) — a deliberate front-loading order. Five sentences, each carrying distinct information, 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?

No output schema exists, so the description compensates by naming the returned fields and their reliability, and by explaining where sources are surfaced. Combined with the per-call cost and latency disclosure, an agent has everything needed to decide and invoke 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?

With a single parameter and 100% schema description coverage, the schema already carries the meaning; the description adds no extra syntax or constraint beyond what the schema's 'no path, no https://' note provides. Baseline 3 is appropriate for a fully documented single-param tool.

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

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

States a specific verb and resource ('Returns a firmographic profile for one company from its domain') and enumerates the concrete output fields an agent will get. It also names exactly which sibling handles each adjacent job (search, contacts, tech), so the tool is distinguishable 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?

Gives an explicit positive trigger ('when you have a company domain and need to qualify or segment the account, especially GCC and MENA companies') plus explicit exclusions routed to the correct alternatives (apione_company_search, apione_people_search / apione_email_find, apione_tech_detect). Nothing about when-to-use is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description goes beyond that by disclosing the cost model (3 credits per result, 75 per full page, no charge on empty results) and the 25-result cap, which annotations cannot express. It still does not describe the shape of returned company records, so it is not fully rich.

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

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

Front-loads the capability, then routes to the alternative, then states the filter requirement and cost. Every sentence carries distinct information (prerequisite, cap, pricing) with no filler.

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

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

For an 8-parameter, zero-required search tool with no output schema, the description covers usage, prerequisites, alternatives, result cap, and billing. The only material gap is what fields the returned company records contain, which an agent would need before chaining into enrichment.

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 50%, and the description compensates by enumerating every filter and adding format meaning the schema lacks: ISO-2 country codes with examples (SA, AE, QA), employee_range example '51-200', and the constraint that at least one filter must be supplied. It does not clarify city/industry/keyword matching semantics or whether filters AND together, leaving some ambiguity.

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

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

Opens with a specific verb+resource+scope: 'Finds companies that match filters and returns up to 25 results.' It explicitly distinguishes itself from the closest sibling by both naming apione_company_enrich as the enrichment follow-up and stating 'Not for looking up one known company (use apione_company_enrich).'

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 ('build a prospect list when you do not have domains yet'), the follow-on tool, a hard prerequisite ('Give at least one filter'), and a when-not-to-use case pointing to the alternative. Nothing is left to inference.

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

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

Annotations only declare readOnlyHint and openWorldHint, and the description adds genuinely new context: a 3-credit cost per call, free pricing on misses/errors/no-evidence answers, and the implicit caution that results need verification before sending. It does not describe the structure or count of the ranked candidates, which is the one remaining behavioral gap.

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

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

Four short sentences, front-loaded with the core capability before routing rules, cost, and the required input pattern. Every sentence carries 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 return-value burden and does so minimally ('returns ranked candidates'), and it fully covers usage routing, cost, and input patterns for a 4-parameter tool. A brief note on how many candidates come back or what a no-evidence result looks like would close the gap.

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

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

Schema coverage is 50% (first_name and last_name carry no descriptions), but the description compensates by stating the two input patterns: 'Provide first_name and last_name, or full_name.' That resolves the otherwise undocumented mutual-exclusivity relationship between the three name parameters.

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

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

States a specific verb and resource ('Finds the most likely work email for a named person at a company domain') plus the return shape ('ranked candidates'). It also explicitly contrasts itself with apione_email_verify and apione_people_search, so an agent can distinguish it from siblings 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?

Gives the triggering condition ('when you have a name and a domain and need an address to contact'), names both near-miss alternatives and the conditions that select them, and prescribes a follow-up step ('Check the result with apione_email_verify before sending'). Nothing is left to inference.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing latency (1-2 seconds), billing (1 credit per call), which outcomes are free (misses, errors, answers without live evidence), and an important semantic caveat that catch-all domains cannot have deliverability confirmed.

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

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

Front-loaded with purpose, then routing, then caveats and cost; every sentence carries distinct information. It is somewhat dense at five sentences for a one-parameter tool, but no sentence is filler.

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

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

Despite having no output schema, the description names the return fields (status, MX validity, catch-all detection) and covers cost, latency, and the catch-all limitation. An agent has everything needed to decide and invoke 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% for the single 'email' parameter, so the schema already documents the input including a format example. The description adds no syntax or format detail beyond what the schema provides, making the baseline 3 correct.

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 one email address is deliverable') and enumerates what it returns: status, MX validity, catch-all detection. It explicitly distinguishes itself from the sibling apione_email_find with 'Not for finding an address.'

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 ('Use before sending outreach, for example after apione_email_find') and when-not ('Not for finding an address'), naming the sibling that covers the excluded case. Nothing is left to inference.

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

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

The annotations only cover read-only and open-world traits; the description adds the material operational facts: the exact supported boards (Greenhouse, Lever, Ashby, Workable, SmartRecruiters, Recruitee, schema.org), the miss behavior ('when none is found the result says so and is not charged'), and the billing model (3 credits, misses/errors free). Those are exactly the behaviors that determine whether an agent should 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?

Five short sentences, front-loaded with the return contract before the routing rule and cost. No sentence is filler: the board list, the miss-billing rule, and the sibling exclusion each change agent behavior.

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 enumerates the return payload, covers the empty-result case, and discloses cost and coverage. An agent has everything needed to decide to call it and to interpret the response.

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

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

Schema description coverage is 100% for the single 'domain' parameter, so the schema already carries the syntax. The description adds nothing parameter-specific beyond the literal example already present, which is the baseline-3 case where structured data does the lifting.

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

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

It names a specific resource and verb ('Returns live open roles for a company') and enumerates exactly what comes back: count, departments, locations, and a role list with links. It also explicitly separates itself from the sibling apione_signals, so an agent can disambiguate without opening either schema.

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

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

It states the use case directly ('Use to see whether and where a company is hiring') and gives an explicit negative boundary with the alternative ('Not for funding or expansion news (use apione_signals)'). When-to-use, when-not, and the fallback tool are all present.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the return contents (score 0-1, verdict, core names compared, transliteration variants) and the billing model ('1 credit per call', with misses, errors and unevidenced answers free). This is exactly the operational context an agent needs and cannot 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?

Four tight sentences, front-loaded with the core decision and scoping, then routing, then the caveat, then cost. No sentence is filler; each adds a distinct 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, the description takes on the return-value burden and does so (score, verdict, compared core names, transliteration variants). Annotations cover the read-only/open-world profile and the description adds cost and cross-language caveats, leaving no significant gap for calling the tool correctly.

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

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

Schema description coverage is 100% and both parameters are documented as 'Arabic or English', so the schema already carries the parameter semantics. The description adds context about legal-form handling but no per-parameter format, syntax, or edge-case detail beyond what the schema states, 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 ('Decides whether two company names refer to the same name across Arabic and English spellings') with explicit scope including legal forms like LLC and شركة. It is immediately distinguishable from the sibling apione_name_normalize, which is named as the single-name alternative.

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

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

Gives a concrete use case ('Use to dedupe or join company lists in GCC and MENA data'), names the alternative for a different task ('To clean one name, use apione_name_normalize'), and states a boundary condition ('It compares names, not entities, so confirm with the domain before merging records').

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), so the description's added value is the cost model (1 credit, free on misses/errors/no live evidence) and the shape of what comes back. It stops short of stating rate limits, auth needs, or latency, but the credit model is genuinely useful behavioral context 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 sentences, each earning its place: capability + outputs, usage and sibling routing, then cost. The core capability is front-loaded 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 compensates by naming the return fields, and it adds a cost model plus the sibling alternative. An agent has everything needed to decide to call it and to interpret the result.

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

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

There is a single required parameter with 100% schema description coverage, so the schema already documents the input including Arabic/English examples. The description restates the Arabic/Latin scope but adds no format or syntax detail beyond what the schema provides, making 3 the correct baseline.

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

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

States a specific verb and resource (normalize a company name), scopes it to GCC/MENA, and enumerates the outputs (core name, match key, Arabic and Latin variants). It is immediately distinguishable from apione_name_match, which it names 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 usage contexts (clean a name before a search, a dedupe or a CRM import) and an explicit alternative with the condition that selects it: 'To compare two names directly, use apione_name_match.' Nothing is left to inference.

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

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

Annotations cover the safety profile (readOnlyHint, openWorldHint), but the description adds genuinely non-redundant operational context: a cost of 5 credits per call and that misses, errors and evidence-free answers are free. That pricing/enforcement detail is not derivable from annotations or schema, though it stops short of describing latency, freshness, or the exact response 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?

Three dense sentences, front-loaded with the outcome, then usage, then exclusions and cost. No filler, no repetition of the name or title, and the most decision-relevant information (what it returns, when to use it) comes first.

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

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

Despite having no output schema, the description enumerates the return fields, names the deciding alternatives, and discloses cost. For a three-parameter read tool with full schema coverage, nothing an agent needs in order to select or call it is missing.

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

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

Schema description coverage is 100%, so the schema already documents name, domain and company, including the 'strongly recommended' note on domain. The description only restates that passing domain or company improves matching, adding motivation but no new syntax, format, or precedence rules beyond what the schema provides. Baseline 3 applies.

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

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

States a specific verb and resource ('Returns a professional profile for one named person') and enumerates the returned fields (title, seniority, department, experience, skills). It also names the two sibling tools it is not, so an agent can route 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?

Explicit when-to-use ('when you already have a full name and want to confirm or fill in role details') plus explicit exclusions with named alternatives: apione_people_search for finding people, apione_email_find for emails. Both the condition and the alternatives are spelled out.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), yet the description adds substantial context beyond them: the 25-result cap, the fact that work emails are deliberately omitted, and an explicit billing model ('3 credits per result... 75 for a full page') including the 'no results, no charge' guarantee. That cost and chaining information is exactly the kind of behavior structured fields cannot convey.

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

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

It is front-loaded with the core capability and return shape, then layers usage, exclusions, chaining, and cost in short declarative sentences. Every sentence carries actionable information with no padding 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?

Despite having no output schema, the description enumerates the returned fields (name, title, company, profile link), the result ceiling, the cost model, and the downstream call needed for emails. For a five-parameter search tool this covers everything an agent needs to invoke it correctly and budget the call.

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

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

With 60% schema coverage the description usefully reinforces filter semantics (country as ISO-2, count as a spend cap of 1-25) and adds a constraint absent from the schema: at least one filter must be supplied despite zero required parameters. The 'location' parameter is left unelaborated, so it stops just short of full coverage.

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

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

The description opens with a specific verb and resource ('Finds people') plus the exact filter dimensions and the four returned fields, so the agent knows precisely what it gets. It explicitly distinguishes itself from siblings, naming apione_email_find and apione_people_enrich with the conditions that select 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 states the intended use ('identify who to contact at a company'), the excluded use ('Not for details on one named person'), and routes to the correct alternatives for emails and enrichment. It also gives operational guidance ('Give at least one filter', 'Set count to cap spend'), leaving nothing 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 declare readOnlyHint and openWorldHint, and the description adds operational traits the annotations cannot convey: ~8-10 second latency, 3-credit cost, and free billing on misses/errors/no-evidence. It also previews output shape (strength, date, source hint, intent score). Not a full 5 only because it doesn't describe depth/freshness limits of the underlying sources.

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

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

Front-loads what the tool returns, then how to call it, then the exclusion, then cost/latency. Every sentence carries distinct information with no repetition of the title or 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?

With no output schema and zero required parameters, the description compensates by describing the payload fields (strength, date, source hint, intent score), both optional input modes, latency and credit economics. An agent has everything needed to call it correctly and interpret the result.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds relationship semantics the schema does not: content is an alternative to domain rather than a supplement ('instead of a domain'), and signal_types is a filter. This is meaningful guidance on how the params interact even though syntax is schema-documented.

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 (detects) and resource (recent business signals) and enumerates exactly what those signals are: funding, expansion, hiring surges, tech adoption, leadership changes. It also names the sibling it is not (apione_hiring), so an agent can route without opening either 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 explicit use context ('decide when and why to contact a company'), two concrete invocation paths (domain for live research, content for article text), and a negative exclusion pointing to apione_hiring for open roles. When-to-use and when-not are both covered.

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?

Adds substantial behavioral context beyond the readOnly/openWorld annotations: homepage-only scope, the fetched:false marker on fetch failure, and a precise billing model (4 credits per call, free on misses, errors, and answers without live evidence). It does not describe the return structure, but the billing and failure semantics are unusually well disclosed.

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

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

Sentences are ordered by importance: purpose and scope first, then the exclusion and alternative, then cost. Every clause carries operational information with no filler.

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

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

For a single-parameter read tool with no output schema, the description covers scope limits, failure behavior, pricing, and sibling routing. Nothing an agent needs to decide and invoke 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?

Only one parameter exists and the schema documents it fully at 100% coverage (domain, with an example). The description reinforces that it must be a public homepage domain but adds no format or syntax detail beyond the schema, so the baseline 3 applies.

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

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

Names a specific verb (detects) and resource (technologies on a company's public homepage) and enumerates the categories covered (CRM, analytics, infrastructure, frameworks, marketing, e-commerce). It is clearly distinguishable from sibling enrichment 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?

Gives positive usage ('Use for technographic targeting') and an explicit exclusion with the alternative named ('Not for company facts (use apione_company_enrich)'), plus a scoping caveat that only the homepage is read, so back-end tools are invisible.

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