HirePulse B2B Company Research

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

Annotations only declare readOnlyHint and openWorldHint; the description adds the crucial behavioral fact that the returned request is a preview and is not executed, plus that the advisor is free and that sample_domain draws on cached hints without running a new lookup. Those are exactly the traits an agent needs to avoid assuming a side effect.

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

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

Three sentences, front-loaded with the capability, then the routing rule, then the non-execution caveat. Every sentence carries distinct information with no repetition of the title.

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

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

An output schema exists, so return shape need not be explained; the description covers what is returned conceptually (tool, price, balance, request preview). With annotations, full schema coverage, and only one required parameter, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100% and all four parameters are documented there, so the baseline is 3. The description reinforces the intent (goal → tool + price estimate) but adds no format, syntax, or range detail beyond the schema.

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

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

States a specific verb and resource — a free advisor that maps a stated goal to the matching HirePulse tool along with price, free-call balance, and a ready-to-run request — and enumerates the goal categories it handles. It explicitly separates itself from the sibling get_company_profile, so an agent can pick between them without opening schemas.

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

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

Gives an explicit use condition ("when the right tool or expected cost is unclear") and an explicit alternative with its own condition ("go directly to get_company_profile for a known domain and a full company brief"). Nothing is left to inference about 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?

Beyond the annotations, it discloses the key behavioral traits an agent needs: one-time use, 25 successful calls, any single tool, not tied to IP, valid 30 days, and where to place the returned token. The readOnlyHint=false annotation is consistent with a claim action, and the description adds substantial operational 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 core offer, followed by the input rule and token-passing mechanics. Every sentence carries actionable information with no waste.

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

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

For a two-parameter claim tool with no output schema, the description covers what the trial provides, the mutually exclusive input rule, and how to use the token afterward. Nothing essential for calling it correctly is missing.

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

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

Schema coverage is 100%, but the description adds a constraint not expressed in the schema: submit exactly one of email or wallet. It also clarifies that no email is sent and how the resulting token is passed via params._meta or the X-Trial-Token header, which is valuable semantic guidance beyond the field descriptions.

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

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

The description states a precise verb and resource: claim a one-time trial pass of 25 free successful calls. It specifies scope (any single tool), duration (30 days), and non-IP binding, so an agent can tell exactly what the tool offers without opening the schema.

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

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

It gives a clear usage condition (claim a one-time trial) and an explicit input constraint: send exactly one of a Base wallet or a work email. It does not name when not to call it or any alternative path, but there is no obvious sibling alternative among the listed tools.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the cost model ($0.005 per result after 5 free calls a day), that blocked or empty sites are free, and that email/SPF/DMARC come from DNS rather than page scraping. These are decision-relevant facts an agent 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?

Two tight sentences: the first front-loads what is returned, the second handles cost and sibling routing. No filler, no repetition of the title, and the ordering puts the payload description before the caveats.

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?

Output schema exists, so return values need not be explained; coverage of categories in the description plus pricing and the no-result-free policy covers what an agent needs to call it responsibly. Nothing material is missing for a read-only, single-required-param lookup.

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

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

Schema coverage is 100%, so the domain format constraint ('without a URL scheme, path or port') and the context field are already fully documented in the schema. The description adds no parameter-level 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 resource and scope: tech stack for a company domain, then enumerates the categories returned (ad pixels, analytics, tag managers, CMS, e-commerce, hosting, payments, plus email provider/SPF/DMARC from DNS). This is specific enough that an agent can tell exactly what comes back and how it differs from profile-oriented siblings.

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

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

Explicitly gives both the when-to-use and the when-not-to-use with the named alternative: 'Use for technology-only research; use get_company_profile when hiring, ads and contacts are also needed.' The routing rule is stated, not inferred.

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), and the description adds genuinely non-obvious traits: which pages are scraped, that results are deduplicated, and that DNS records are included but mailbox verification is not. The billing model ('$0.01; nothing found is free') is valuable cost context an agent cannot get from structured fields; only rate limits and cross-page dedup rules are left unstated.

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 dense sentence that front-loads the core purpose, then the output inventory, then the exclusion, then pricing. Every clause carries information; nothing is redundant with the title or schema.

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

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

For a read-only, two-parameter tool with an output schema, the description supplies the remaining decision-relevant facts: source pages, result types, what is deliberately excluded, and the cost/failure pricing. An agent has everything needed to decide to call it and to interpret an empty 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 description coverage is 100%, with both the required `domain` and optional `context` fully documented in the schema, so the baseline is 3. The description adds only a light gloss on `domain` (public company domain whose contact pages are inspected) and says nothing about `context` beyond what the schema already states.

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

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

Names a specific verb and resource (published contacts for a company domain) and enumerates exactly what comes back: deduplicated emails, LinkedIn/X/GitHub links, and MX/SPF/DMARC checks. This clearly separates it from siblings like get_company_profile or private_blind_lookup 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?

States the intended input context (a public company domain's home/about/contact/team/careers pages) and explicitly excludes a neighbouring use case with 'not mailbox verification', which prevents the agent from expecting deliverability results. It stops short of naming an alternative tool for mailbox verification or for non-public contact discovery, so it is clear context rather than full when/when-not 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 only cover readOnly/openWorld; the description adds the non-obvious commercial and epistemic facts: $0.01 per result, free when there is no board or no open jobs, and that the score is a heuristic rather than confirmed purchase intent. Cost and reliability caveats are exactly the context 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?

Three short sentences, each load-bearing: what it returns, what it costs, when to use it and what to use instead. The core value proposition is front-loaded in the first clause.

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?

Output schema exists so return values needn't be explained, yet the description still names the score components, the data source, and the cost model. For a 2-parameter read-only lookup this is everything an agent needs to call it correctly.

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

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

Schema coverage is 100% and the domain parameter is fully documented in the schema (format, maxLength, example); the description adds no further syntax or constraint detail. Baseline 3 applies since the schema carries the parameter burden.

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

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

States a specific verb-like operation and resource: a hiring-based buying-intent score (0-100) for a company domain sourced from its public job board, with the result's components enumerated. It explicitly distinguishes itself from get_company_open_jobs and get_company_profile, so an agent can pick it without reading sibling schemas.

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

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

Gives a positive use case ("prioritize a known company by hiring signals") plus explicit alternatives with the condition that selects each (role listings vs. combined research). Nothing is left to inference about when this tool is the right call.

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 cost ($0.01, free when no board or no open jobs), the 300-job cap, and the diff semantics of known_job_ids returning new and closed jobs. Cost and truncation limits are behavioral traits the annotations do not carry, and there is no contradiction with readOnlyHint=true.

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 carrying load: capability+providers+fields, then limits and pricing, then routing to siblings. Slightly dense in the first sentence but front-loaded with the core verb and resource, 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?

An output schema exists, so return values needn't be explained, and the description covers everything else an agent needs: data sources, field set, result cap, diff workflow, cost, failure/free case, and sibling alternatives. Nothing material is missing for a read-only lookup tool.

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

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

Schema coverage is 100%, so all four parameters are already documented, and the description mostly restates what the schema says about known_job_ids ("returns new and closed jobs") and diff_only. It adds no syntax, ID format, or example 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?

States a specific verb+resource ("Live open jobs for a company domain") and names the six source providers (Greenhouse, Lever, Ashby, Workable, Recruitee, SmartRecruiters) plus the fields returned. It is clearly distinguishable from get_company_hiring_intent and get_company_profile, which are named explicitly.

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

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

The final sentence gives an explicit routing rule: "Use for individual role listings; use get_company_hiring_intent for a hiring score or get_company_profile for combined company research." Both alternatives and the condition that selects them are stated, 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?

Beyond the readOnly/openWorld annotations, it discloses price ($0.03), the conditional billing rule (charged only when at least two of four sections have data), the free-tier consumption (one of 5 daily calls), parallel execution, and the estimation caveat on growth signals. That's exactly the kind of cost and output-reliability context an agent can't infer from annotations.

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

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

Front-loaded with the core purpose and output list, and every sentence adds routing, pricing, or caveat value. It is dense — pricing, quota, and caveat details are packed into a single long span — but little could be cut without losing decision-relevant 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?

Given an output schema exists, the description doesn't need to explain return shapes; instead it covers cost model, quota impact, estimation disclaimers, and sibling routing. Nothing an agent needs before calling is missing.

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

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

Schema coverage is 100% and the schema already documents the domain format and the optional context field; the description only implies the domain input without adding format or validation detail. Baseline 3 is appropriate since the schema carries the parameter burden.

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

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

States a specific verb and resource ('One-call company profile for a domain') and enumerates exactly what it returns (tech stack, hiring intent, Google Ads, published contacts). It also names the narrower siblings it supersedes, so it's unmistakable in the toolset.

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 start here for a single company across all four signals, then routes to single-signal tools for narrower research, batch_lookup for several known domains, and company_footprint_check for found/not_found only. Both when-to-use and when-not-to-use are covered with named alternatives.

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

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

Beyond readOnlyHint/openWorldHint, it discloses the data provenance (public Ads Transparency Center), a hard result cap (up to 40 ads), and a cost model ($0.01 per result, no ads free) — all things annotations cannot convey. It doesn't cover pagination or failure behavior when a domain is unknown, so it stops short of a 5.

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

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

Three sentences, front-loaded with what you get, then the scope caveat, then the routing hint. Every sentence carries distinct information — data source, cost, and alternative — 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-value detail is unnecessary, and the description still covers cost, source, result cap, privacy scope and the alternative tool. For a 3-parameter read-only lookup with full schema coverage, nothing an agent needs before calling is missing.

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

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

Schema coverage is 100% and the schema already documents domain format, the region enum, and the context field, so the schema carries the load. The description only restates that region is an optional filter, adding no new semantics such as default region behavior or whether region also narrows the ad count estimate.

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/resource ('Google Ads for a company domain') plus the exact data source (public Ads Transparency Center) and enumerates the return contents: advertising status, ad count estimate, up to 40 ads with format, dates and links. It is clearly separable from get_company_profile, which is named as the broader 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?

It gives an explicit use case ('public competitor advertising evidence'), an explicit exclusion ('does not access a private Google Ads account'), and an explicit alternative ('Use get_company_profile for combined research'). Nothing about when to select this tool 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.