HirePulse

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered, and the description adds real behavioral value: the advisor is free, it reports the 'real cost', your 'free-call balance', and produces a 'ready-to-run request' rather than executing anything. It does not say whether the call itself consumes balance or how routing accuracy is bounded, which keeps it short of a 5.

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

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

A single front-loaded sentence with no filler: the tool's role and its outputs come first, followed by the covered goal domains. It is dense but every clause carries information, so it earns its length.

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

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

Because an output schema exists, return values need not be restated, and the annotations cover the read-only profile. Still, with 0% schema coverage the agent has no guidance on what to put in agent_goal, when domain_count or sample_domain matter, or how budget_usd influences the recommendation — a real gap for a four-parameter routing tool.

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

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

Schema description coverage is 0% across four parameters, so the description must carry the load and largely does not. 'Describe your goal' loosely maps to agent_goal, but budget_usd, domain_count, and sample_domain are never mentioned, and the goal categories listed are not tied to any parameter or format.

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

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

The description names a concrete verb and resource ('free advisor for AI agents') and enumerates the goal domains it handles (B2B leads, hiring signals, buying intent, tech stack, Google Ads, VC due diligence). It also states the deliverable — the right HirePulse tool, real cost, free-call balance, and a ready-to-run request — which clearly separates it from the lookup siblings like batch_lookup or detect_website_tech_stack.

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 tells the agent to 'describe your goal' and get routed, which implies this is the entry point before invoking concrete lookup tools, and the enumerated goal categories show the contexts it covers. However, it never explicitly says 'call this first' or states when NOT to use it versus going straight to a sibling tool, so one inference step remains.

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

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

Annotations already cover readOnlyHint and openWorldHint, and the description adds genuinely useful behavior beyond them: one-product-per-store sampling, an explicit non-goal (does not predict agent selection), and a per-call cost of $0.02 USDC via x402. The pricing and sampling traits are exactly the kind of context annotations cannot carry.

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 the action front-loaded and no filler. The cost and limitation notes each carry weight; 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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. The description still supplies cost, sampling behavior, and scope limits, leaving little an agent needs missing to invoke it correctly.

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

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

Schema description coverage is 50%, and the schema already documents the domain format ('public domain without scheme, path or port') and the array bounds. The description maps concepts to parameters (brand=domain, up to 3 competitors=competitor_domains) but adds no format or syntax detail beyond the schema, so baseline 3 is appropriate.

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

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

States a specific verb (compare) and resource (a brand vs up to 3 competitors as machine-readable shopping schema), and enumerates the compared dimensions: prices, ratings, availability, shipping, return evidence. It is clearly a comparison/audit tool, though it does not name a specific sibling to contrast 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?

The 'Use to compare...' opener gives implied usage context, and the description clarifies scope by stating it samples one product per store and does not predict agent selection. However, it names no alternative tool and gives no explicit when-not guidance, so an agent must infer positioning among the many trust/audit 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 declare readOnlyHint=true and openWorldHint=true, so safety is partly covered. The description adds useful context (it's free, and it surfaces 'the real cost' and 'your free-call balance', implying a rate/budget dimension), but it doesn't state whether the call itself consumes the free balance or whether the 'ready-to-run request' is executable.

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, front-loaded sentence that leads with the value proposition ('Free advisor for AI agents'). Efficient, though the long parenthetical list of goal types slightly burdens readability.

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?

An output schema exists, so return values needn't be spelled out, and the description does summarize the output. The remaining gap is the unexplained non-required parameters, which leaves an agent unsure how to tune cost or scope estimates.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, yet it only loosely explains agent_goal via the parenthetical goal list. budget_usd, domain_count, and sample_domain are never mentioned or given meaning, leaving three of four parameters undocumented.

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

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

States a specific verb+resource (advisor that takes a goal and returns the right HirePulse tool, cost, balance, and a ready-to-run request) and enumerates the goal domains it handles. This clearly distinguishes it from the sibling data tools it routes to.

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?

Strongly implies the use case – describe a goal when you don't yet know which sibling tool to call – and lists concrete goal categories. It does not, however, explicitly say when NOT to use it (e.g., when the correct tool is already known).

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

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

Annotations already mark it read-only and open-world. The description adds non-obvious epistemic rules (missing headcount/SEO is unknown, never a fabricated growth trend) and a cost condition ($0.10 USDC only when a useful assessment is returned), which materially affect how an agent should interpret and budget for the 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?

Three tight sentences: purpose/usage front-loaded, then caveat, then pricing. No filler; each 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?

With an output schema present, return values need not be explained. The description covers purpose, usage context, data reliability caveat, and payment condition, leaving little else an agent needs to invoke it correctly, though it could clarify the assessment's scope relative to sibling tools.

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 vendor_domain parameter is fully specified in the schema. The description adds no parameter-level 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?

Names a specific action (inspect) and two evidence sources (public vendor technology, current hiring evidence) with procurement context. However, it never explicitly states it evaluates vendor stability nor differentiates from single-signal siblings like detect_website_tech_stack or get_company_hiring_intent.

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

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

Explicitly says to use it 'before procurement,' giving clear context. No when-not conditions or alternative tools are named, 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 only declare readOnlyHint/openWorldHint, yet the description adds substantial behavior: a quote-then-pay flow, x402 payment on Base, exact quoted amount, rows without data never charged, a $1 cap, quote expiry of 15 minutes, and 3 free scans per IP per day. That is exactly the extra context annotations cannot carry.

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?

Dense but front-loaded: purpose first, then Step 1, Step 2, then caps/expiry. Nearly every clause carries operational information, though the pricing and rate-limit details could be tightened slightly.

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-phase paid tool with an output schema already defined, the description covers everything an agent needs to invoke it correctly: which mode to send, what payment follows, cost ceilings, expiry, and free-scan limits. 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 description coverage is 67%, and the description compensates by explaining the role of each parameter in the sequence: {tool, domains} for the free step, {quote_id} alone for payment, plus the 50-domain cap (33 for company-profile). Domain formatting is left to the schema, so it is not a full 5.

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

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

States a concrete verb and resource ('Bulk company lookup: run one tool ... on many domains with one payment') and names the five underlying lookup types, which cleanly distinguishes it from the single-domain siblings such as detect_website_tech_stack and get_company_open_jobs.

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

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

It clearly frames when this tool applies (many domains, one payment, one underlying tool) and spells out the two-step call sequence. It stops short of explicitly naming the single-domain siblings as alternatives, so the routing is implied 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 mark readOnly and openWorld. The description adds valuable context beyond annotations: it discloses the data source (homepage SEO metadata), that codes are unverified, and explicitly names unavailable channels. The per-result pricing is also stated, which is useful behavioral information.

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

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

Three compact sentences, front-loaded with the action and scope, then constraints, then pricing. No waste.

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

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

With an output schema present, return details needn't be repeated. The description covers source, limitations, pricing, and safety context well. The only gap is the undocumented 'product_category' parameter.

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

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

Schema coverage is 50%; the 'domain' parameter is documented in the schema, but 'product_category' has no description anywhere. The description does not compensate for this gap or add 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?

States a specific verb (extract) and resource (explicit coupon candidates from merchant homepage SEO metadata), which is clear. The 'checkout' context and mention of unavailable ad channels help distinguish it, though sibling differentiation could be sharper.

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

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

Explicitly says to use it 'during checkout' and clarifies what it does not claim (a code works at checkout) and what sources are unavailable. No direct naming of alternatives, but the scoping is clear.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description goes well beyond them: cost ($0.03 USDC via x402 on Base), the conditional billing rule (charged only when two of three checks return data), the free-daily-call accounting, and an explicit scope disclaimer (facts only, no revenue/burn/fraud estimates). These are exactly the behavioral traits an agent needs before invoking a metered tool.

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

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

The opening clause front-loads purpose and audience, and the signal list, output states, disclaimer and pricing each carry distinct information with no filler. It is on the longer side, but every sentence earns its place; only the audience enumeration is mildly expendable.

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?

An output schema exists, so return values need not be spelled out, yet the description still clarifies the found/not_found/unknown states. Combined with the billing conditions, free-call accounting and scope limits, an agent has everything needed to decide whether to call it and how 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 parameter with 100% schema description coverage, so the schema already explains that the domain must omit scheme, path and port. The description adds only 'for one domain', which conveys cardinality but no new format or constraint detail beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific resource (a company domain) and enumerates exactly what it reports: ad/analytics tags, job board activity, and Google Ads Transparency entries. It is far more than a restatement of the name. However, it never distinguishes itself from the siblings that cover the same underlying signals (detect_website_tech_stack, get_company_open_jobs, get_google_ads_by_domain), so it loses the top mark for sibling differentiation.

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

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

It names its target consumers (investment, due-diligence and vendor-risk agents), which implies the context of use, and the pricing/quota details help an agent weigh the call. But there is no explicit when-to-use versus when-not, and no routing guidance to the three sibling tools that surface the same signals individually.

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?

Beyond the readOnly/openWorld annotations, it discloses the exact data sources (home page HTML, headers, cookies, up to two public GTM containers), the method constraint (no headless browser), pricing and quota (5 free calls/day per IP, then $0.005 USDC via x402 on Base), and the billing edge case that no_signals results are never charged. This is unusually rich behavioral disclosure.

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

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

Front-loaded with the capability, then method, then cost. Every sentence carries information, though the long parenthetical enumeration of vendor names is denser than strictly necessary.

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?

An output schema exists, so return values need no explanation. Given that, the description covers scope of detection, method, latency expectation, quota, cost model, and the no-charge failure case — everything an agent needs to decide and safely invoke.

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 description coverage is 100%; the schema already states "public domain without a URL scheme, path or port." The description adds no format or syntax detail 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?

States a specific verb and resource (detect a company website's tech stack) and enumerates exactly what is detected: ad pixels, analytics, CMS, e-commerce, hosting, payment providers, email, DMARC/SPF. This clearly separates it from siblings like extract_company_contacts or verify_domain_legitimacy_and_security.

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 before qualifying or writing to a company" gives concrete workflow placement, which is real guidance absent from most siblings. It does not, however, name an alternative or state when this tool should NOT be used (e.g., overlap with verify_domain_legitimacy_and_security or get_google_ads_by_domain).

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

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

Annotations cover read-only and open-world, but the description adds real value beyond them: native MX/SPF/DMARC checks, the explicit caveat that MX availability is not mailbox verification, that email patterns are inferred only from observed examples, and the pricing rule ($0.01, no charge when nothing found). This preempts the two most likely agent misinterpretations. It stops short of return format/pagination or rate-limit details, so not a 5.

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

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

Very dense but front-loaded: identity first, then scope, then caveats, then cost. Every clause carries information - the MX, pattern-inference and billing clauses each prevent a distinct error. The semicolon-chained packing is slightly heavy to parse, keeping it from a 5.

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?

An output schema exists, so return values need no prose, and annotations already establish the safety profile. The description covers scope, caveats and billing, which is what an agent needs to decide and call correctly. The one remaining gap is the expected domain input format.

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 (domain), and schema coverage is 0% - the schema supplies just 'string, maxLength 253'. The description never clarifies expected input form (bare root domain vs. URL vs. subdomain), which is a real ambiguity for a web-extraction tool. The concept of a domain is inferable from the tool's framing, hence a 3 rather than lower.

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 ('Public company contact extractor') and immediately scopes it: which pages are scraped (homepage, about, contact, team, careers) and what comes back (deduplicated published emails, LinkedIn/X/Twitter/GitHub links). That is enough to distinguish it from siblings like company_footprint_check or get_company_profile 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?

Usage is implied rather than stated - the framing makes clear this is the tool for pulling published contacts from a company domain, and the billing caveat hints at when it is worth calling. However, it never names an alternative sibling or an explicit when-not-to-use condition (e.g. versus company_footprint_check or verify_domain_legitimacy_and_security), so routing 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; the description adds the material behavioral facts an agent needs — $0.25 USDC per hot company via x402 on Base, a 4-company / $1 cap per paid call, no charge when zero companies are hot, 15-minute quote expiry, and 3 free scans per day per IP. None of this is recoverable from 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 purpose is front-loaded in the first clause and the rest is a dense but ordered walkthrough of the paid flow. For a two-phase payment tool every sentence carries operational weight, though the run-on structure with inline pricing and caps makes it slightly harder to scan than it could be.

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?

An output schema exists, so return shapes need not be re-explained, yet the description still surfaces the key return behaviors (cold domains come back with intent_score, hot domains yield a company profile, overflow lands in more_hot). Combined with the payment, quota, and expiry rules, nothing an agent needs to invoke 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 67%, so the description must compensate and largely does: it explains the two mutually exclusive modes (domains alone vs quote_id alone), states the min_intent_score default of 70, and clarifies that quote_id is the artifact from step 1. It stops short of explaining the domain format constraints (no scheme/path/port, 253-char limit) beyond what the schema already says.

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 opening sentence states a specific verb and resource: 'Buying intent for a list of companies: find which of 2 to 25 domains are hiring hardest.' It scopes the input size (2-25 domains) and the outcome (hiring intent), which clearly separates it from siblings like get_company_hiring_intent or batch_lookup without needing their schemas.

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

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

The description gives an explicit two-step protocol: Step 1 is free (send domains, optional min_intent_score), Step 2 requires quote_id plus payment. That is clear when-to-use guidance for each mode. It does not, however, compare itself to any named sibling tool, so the agent still has to infer when find_hot_buyers beats get_company_hiring_intent.

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; the description goes well beyond by disclosing the pricing/rate-limit model (5 free calls per day per IP, shared with the other tools, then $0.01 USDC per result via x402 on Base) and the exact conditions under which no charge occurs. This is exactly the kind of operational context annotations cannot carry.

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 is front-loaded in the first clause, followed by outputs and then billing rules, so nothing is buried. It is dense (one long colon/semicolon-delimited paragraph) but nearly every clause carries actionable information, with only slight redundancy in the output enumeration.

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?

An output schema exists, so return values need not be explained, yet the description still enumerates the key outputs for ranking decisions. With annotations, schema, and output schema all present, the definition is complete for an agent to select and invoke this tool correctly.

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

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

Schema coverage is 100% and the single 'domain' parameter already has a description and example, so the schema does the heavy lifting. The description implies the domain is a public company domain but adds no format or syntax detail beyond the schema, making the baseline 3 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 ('turns a company domain into a hiring-based buying-intent score from its public job board') and enumerates the concrete outputs (intent_score 0-100, hiring_status, open roles, roles in last 30 days, hiring by function). This clearly differentiates it from the sibling get_company_open_jobs, which returns raw postings rather than a derived score.

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

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

Explicitly states the usage context: 'Use to rank or prioritize accounts before outreach.' It also gives a conditional rule for when the call is not billed (no job board, no open jobs, generic name-only match). It does not name alternative siblings to use instead, so it falls short of a full 5.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the 300-job cap, the confidence semantics ('high means the website links to the board; unverified means only the name matches'), rate limits, per-result pricing via x402 on Base, and a genuinely important billing nuance (no board or no open jobs is never charged).

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?

Dense but front-loaded, leading with purpose and source coverage before pricing and confidence caveats. Every clause carries information (sources, cap, diff behavior, pricing), though the pricing sentence is long and could be split for readability.

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 an output schema present, return-format details are unnecessary, and the description still supplies everything else an agent needs: cost model, caps, confidence interpretation, and diff mechanics. Nothing material is missing for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds relational meaning the schema does not fully express: the dependency that diff_only requires known_job_ids, and that supplying known_job_ids causes the response to list new and closed job IDs.

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 ('live open jobs for a company domain') and enumerates the exact board sources (Greenhouse, Lever, Ashby, Workable, Recruitee, SmartRecruiters), so the agent knows precisely what is returned. It does not, however, distinguish itself from the closely related sibling get_company_hiring_intent, leaving the agent to infer which 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?

Provides clear usage context ('hiring signals for sales, recruiting and research agents') and operational guidance for the diff workflow ('send known_job_ids to get new and closed jobs; diff_only returns only new ones'). It lacks explicit when-not/alternative routing versus sibling tools like get_company_hiring_intent or company_footprint_check.

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, but the description adds substantial behavior: per-result cost ($0.03 USDC via x402 on Base), the conditional billing rule tied to data availability, and that it consumes one of 5 free daily calls. This is exactly the kind of pricing, billing, and quota context the agent needs and cannot get 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?

Front-loaded with the core capability, then usage, then cost and billing rules. Every sentence carries distinct information (capabilities, use case, pricing, charging condition, quota) 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?

An output schema exists, so return values need not be explained; the description still summarizes the returned 'plain-language signals'. Combined with the pricing, billing, and quota disclosures, 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?

Only one parameter (domain) with 100% schema description coverage, and the schema already specifies format constraints ('without a URL scheme, path or port') and an example. The description adds no additional parameter-level meaning, so the baseline of 3 applies.

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

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

States a specific verb+resource ('Company enrichment API in one call') and enumerates exactly what it aggregates: tech stack lookup, hiring signals and buying intent, and Google Ads transparency. It distinguishes itself from siblings by being the combined 'one request instead of three' version of detect_website_tech_stack, get_company_hiring_intent, and get_google_ads_by_domain.

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

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

Explicitly gives the use case ('a full company research profile before outreach') and contrasts with the alternative of three separate requests. The charging rule ('charged only when at least two of the three sections have data; otherwise nothing is charged and the answer says which single tool has data') further routes the agent toward the single-section sibling tools when only one section applies.

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

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

Annotations only declare readOnly/openWorld, while the description adds substantial behavior: result cap (up to 40 ads), the returned fields (format, first/last shown dates, preview and Transparency Center links), the Google ad-count estimate, and a detailed pricing/rate-limit model (5 free calls per IP per day, then $0.01 USDC per result via x402 on Base, no charge when no ads are found). This is well beyond what annotations provide.

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

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

The content is front-loaded and every sentence carries real information (scope, output, pricing). It is dense and runs long in the middle listings, but there is little pure filler, so only mild trimming would be warranted.

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

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

For a paid, read-only external API with an output schema, the description supplies the critical extras an agent needs: cost/rate limits, the no-charge guarantee for empty results, region filtering, and the shape of the return (cap, formats, dates, links). Nothing essential for correct invocation 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 both parameters are documented in-schema, so the baseline is 3. The description restates the region filter and enum list already present in the schema and adds no new syntax or format meaning for 'domain', so it neither compensates nor exceeds 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 and resource ('Google Ads transparency API: is a company running Google Ads, and what does it advertise?') plus the exact lookup key (advertiser domain). It is clearly distinguishable from siblings such as get_company_profile or company_footprint_check because it names the data source (Google Ads Transparency Center) and the returned entity types.

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

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

Gives clear use context ('competitor research, ad-spend signals and sales personalization') and hints at the charging model, but never routes the agent to or away from a specific sibling tool, nor states explicit exclusions. Clear context without alternatives lands at 4.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine behavioral context beyond that: it returns a heuristic coverage score and prioritized fixes, and it discloses a cost ($0.01 USDC via x402), which is a material payment prerequisite for invocation.

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 it audits, followed by output nature and exclusions, and closing with cost. Every sentence carries distinct, non-redundant information.

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

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

An output schema exists, so return values need no explanation, and the description still summarizes the shape of the return (heuristic score plus prioritized fixes). With a single fully-documented param, clear scope, exclusions, and pricing disclosed, 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?

There is a single parameter with 100% schema description coverage, and the schema fully documents that domain must be a public domain without scheme, path, or port. The description adds no format or syntax detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (audit) and resource (store) and enumerates exactly what is checked: machine-readable product metadata, UCP/ACP discovery, payment hints, and robots.txt access. An agent can distinguish this from siblings like pre_purchase_merchant_trust_check or universal_product_url_to_json 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 'Use to audit...' phrasing gives clear context for invocation, and the explicit exclusion ('Not Meta certification or a live checkout test') tells the agent when this is not the right tool. It stops short of naming a specific sibling to use instead, so it is strong context rather than full 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 establish readOnlyHint and openWorldHint, so the bar is lower, and the description adds meaningful context beyond them: the lead-qualification rule (ad and SEO evidence required), the caveat that public emails are not verified decision makers, and the cost/payment model ($0.05 USDC per qualified result via x402). The pricing disclosure is unusually valuable behavioral context.

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

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

Three dense sentences, front-loaded with the imperative use case and followed by qualification logic and pricing. Little waste, though the packing of three evidence types into one clause makes it slightly busy.

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 an output schema present, return values need not be explained, and the description covers what is inspected, the qualification criterion, and cost. It is close to complete for a 1-param tool; only the relationship to overlapping siblings 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 'domain' parameter is fully documented in the schema (format, bounds, examples). The description adds no syntax or format detail beyond it, so the baseline of 3 is appropriate.

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

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

States a specific verb (inspect) and resource (store) and enumerates the three things checked: schema gaps, Google ad activity, and public business contacts. However, it does not distinguish itself from heavily overlapping siblings like muse_agentic_store_readiness_auditor, get_google_ads_by_domain, or extract_company_contacts, so an agent could confuse the coverage.

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 to inspect a supplied store..." implies when it applies, but there is no explicit when-not guidance and no named alternative, which is a real gap given the sibling overlap on schema, ads, and contacts. Usage context is present but 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses capability limits ('cannot certify safety or detect every scam'), what is returned (cautious evidence score, risk flags, limitations), and cost/rate-limit terms ($0.005 USDC via x402 after 5 free calls/day). This is substantive behavioral context that annotations do not cover.

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 packed sentences: use-case first, then return shape and limitations, then pricing. No filler, and the most decision-relevant information (when to use) is front-loaded.

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

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

An output schema exists, so return values need not be detailed, and the description still summarizes them well while covering cost and capability limits. The remaining gap is the undocumented optional parameters, which leaves an agent guessing about wallet and amount 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?

Schema description coverage is only 33% – only 'domain' is documented. The description says nothing about 'merchant_wallet_or_id' or 'transaction_amount_usd', leaving two of three parameters unexplained in both the schema and the description. It does not compensate for the coverage gap.

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

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

The description gives a specific verb and resource ('inspect public website evidence and missing trust signals') and a clear situational trigger (before purchasing from an unfamiliar merchant). However, it does not differentiate itself from the near-identical sibling x402_merchant_trust_check, which an agent cannot distinguish without opening both 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?

'Use before purchasing from an unfamiliar merchant' is a clear implied-use context, better than nothing. But it offers no exclusions, prerequisites, or named alternatives, and with a sibling of essentially the same name in scope, the routing guidance is 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?

Beyond the readOnlyHint/openWorldHint annotations, it discloses meaningful behavior: privacy scope (target stripped from x402 metadata but visible to HirePulse and destination), per-call pricing ($0.02, $0.04 bundle), a required header/tier precondition, and no settlement for empty results. This is unusually rich behavioral context, though return format is not described (output schema exists).

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 privacy premise is front-loaded, which is good, but the rest is a dense semicolon-chained block mixing pricing, tier logic, and a non-existent override parameter. It is compact yet hard to parse and doesn't clearly order the operational steps.

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?

An output schema exists, so return values needn't be explained, and pricing/tier rules are covered. However, for an 8-way dispatch proxy the description omits how the enum values relate to the sibling tools and gives no usable guidance for the undocumented target parameter, leaving gaps for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, but it only names two of the eight enum values (company_profile, due_diligence) and says nothing about 'target' format or constraints. It also references params._meta["hirepulse/private-tier"], a parameter the schema explicitly forbids via additionalProperties:false, so the guidance is partly unusable.

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 frames this as a 'Blind execution proxy' running a 'single check,' which conveys that it dispatches one underlying lookup, but it never plainly states that it executes the selected tool against the target. The privacy mechanism dominates the opening at the expense of a clear verb+resource statement, and it doesn't distinguish itself from siblings like get_company_profile or batch_lookup.

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 tier-selection guidance (company_profile and due_diligence require the bundle tier, choose tier before submitting) but offers no guidance on when to use this proxy versus the many sibling lookup tools or batch_lookup. The core 'when-to-use-this-vs-alternative' question is left unanswered.

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?

Beyond the readOnlyHint/openWorldHint annotations, it discloses the extraction method (JSON-LD, Microdata, OpenGraph, no browser), the null-on-missing-facts convention, the scope limitation ('checkout support is not assumed'), and a per-result cost with payment rail. This is exactly the operational context annotations do not carry.

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, each earning its place: purpose, method, data-quality semantics, cost. Purpose is front-loaded and there is no padding.

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

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

With an output schema present, return shape need not be described. The description still supplies method, null behavior, scope boundary, and pricing, leaving nothing an agent needs to invoke it correctly.

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

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

Schema description coverage is 0% for the single product_url parameter. The description adds the 'public' qualifier and the no-checkout scope, but leaves format/URI and maxLength entirely to the schema, so it only partially compensates.

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 (extract) and resource (product price, stock, variants, ratings, shipping) scoped to a public product URL. It is clearly distinguishable from sibling url_to_clean_markdown, which returns markdown rather than structured product facts.

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?

Opens with 'Use to extract...' and pins the input domain to a public product URL, which is clear context for selection. It does not explicitly name a when-not condition or a specific alternative sibling, 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?

Beyond readOnlyHint/openWorldHint it discloses stripping behavior (scripts, styles, nav, footer, ads), the security posture (SSRF and redirect protected), an output-size ceiling, and pricing including 'empty results free' — real operational context an agent can't get from annotations. It omits truncation semantics and failure modes (paywalls, robots blocks), so not a 5.

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

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

Three short sentences with the conversion purpose front-loaded, then what is removed, then guardrails and cost. Every clause carries information; no filler or restated 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 an output schema present it correctly avoids describing return structure, and it covers the decision-relevant extras an agent needs: input restriction (public), sanitization, SSRF protection, size limit, and cost. Nothing material for correct invocation 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 0%, so the description must carry parameter meaning; it states 'max_chars 1–100000 (default 15000)', but those bounds and default are already encoded in the JSON schema, so this mostly repeats structured data rather than explaining what gets truncated or how. The url parameter's semantics are only implied by 'public web page'.

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 ('Convert a public web page to clean LLM-ready Markdown') with the exact output payload named (title, meta description, token count). No sibling tool in the list performs content conversion, so the tool is unambiguous against its neighbors.

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 'public web page' implicitly excludes authenticated/private targets and the SSRF/redirect note reinforces that boundary, giving clear invocation context. It stops short of an explicit when-to-use/when-not statement or naming an alternative for non-public or non-HTML sources.

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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the semantics of the signature (proves HirePulse issued it, not ownership), the deliverable (expiry + public verification key), and a concrete cost ($0.005 USDC via x402). This is exactly the operational context an agent needs. The payment side effect is a mild tension with readOnlyHint but does not rise to a direct contradiction since the tool only computes/emits a document.

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 the primary purpose, then the crucial limitation, then deliverable and cost. Every sentence carries distinct, load-bearing 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?

With an output schema present, return values need not be restated, and the description covers purpose, scope limits, deliverable contents, and payment mechanism. Nothing an agent needs to invoke 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 description coverage is 100% and the single parameter already carries a precise description ('Public domain without scheme, path or port'). The description adds only the framing 'merchant domain', which is marginal value over the schema, so the baseline 3 applies.

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

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

The description states a specific verb and artifact ('generate a signed public-evidence statement for a merchant domain'), and it explicitly disambiguates from the trust-check siblings by stating it does not verify ownership, employees, or purchase safety. An agent can immediately tell this issues an evidence badge rather than performing an assessment.

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 to generate...' gives a clear trigger condition, and the scope disclaimer steers the agent away from treating it as a trust/verification tool. It does not, however, name an explicit alternative tool or state a when-not-to-use condition, 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 only declare readOnly and openWorld, but the description goes well beyond them: it discloses the paid x402/Base pricing at $0.03 USDC per result, the exact charging condition (only when at least two of three checks return data), and that the call consumes one of 5 free daily calls. It also explains the tri-state result semantics (found/not_found/unknown with underlying 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?

One front-loaded paragraph that leads with what the tool does before pricing and caveats; every clause carries information. Slightly dense with billing detail, but none of it is filler for an agent that must decide whether to spend a call.

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 an output schema present, the description needn't enumerate return values, and it already explains the tri-state signal model and the facts-only boundary. The one real gap is that it gives no hint about when to prefer the nearly identical sibling company_footprint_check.

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

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

Schema coverage is 100% and the single domain parameter is fully documented in the schema, including format constraints and an example. The description only adds the framing "for one domain," so the schema does the heavy lifting; 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: for one domain it reports which public operating signals exist (ad/analytics tags, job board, Google Ads Transparency), and it explicitly bounds the scope with "Facts only: no revenue, burn or fraud estimates." However, the tool name says "legitimacy and security" while the description delivers a factual footprint check, and it never distinguishes itself from the near-duplicate sibling company_footprint_check.

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 the intended audience ("investment, due-diligence and vendor-risk agents"), which implies the use case. But there is no explicit when-not guidance and no routing to overlapping siblings such as company_footprint_check, get_google_ads_by_domain, get_company_open_jobs or detect_website_tech_stack, which cover the same individual 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?

Beyond the readOnlyHint/openWorldHint annotations, it discloses a concrete latency budget (4 seconds), a cost model ($0.002 per completed report; unreachable targets free), SSRF protection, and an explicit accuracy disclaimer ('evidence-based heuristic, not certification'). These are exactly the operational traits an agent needs before spending money on a 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?

Two dense sentences, front-loaded with the core action and scope, followed by cost and caveats. No filler; every clause (latency, cost, SSRF, disclaimer) informs a decision about calling the tool.

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

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

The output schema covers return values, and the description still enumerates the checks performed (discovery, 402 terms, USDC prices, latency, injection flags) plus cost and safety posture. For a single-parameter, read-only scanner this is sufficient context 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?

There is one parameter with 0% schema description coverage, so the description must carry the burden. It implies the target is an HTTPS merchant URL but never states accepted formats, scheme requirements, or behaviour for non-HTTPS input — only the free-on-unreachable rule hints at failure semantics.

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

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

States a specific verb and resource ('Pre-payment HTTPS merchant scanner: checks public discovery, live 402 terms, comparable USDC prices...'), and the x402 payment context makes it reasonably distinct from generic siblings like verify_domain_legitimacy_and_security. It does not explicitly name or contrast with that sibling, so an agent must infer the boundary rather than read 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?

The 'Pre-payment' prefix implies the moment to use it (before paying an x402 merchant), and the 'not certification or a guarantee' caveat sets expectations. However, there is no explicit when-not guidance and no named alternative (e.g. verify_domain_legitimacy_and_security), leaving the routing decision to inference.

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