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

Annotations already declare readOnlyHint, non-destructive and closed-world, so safety is covered. The description adds non-obvious behavioral context: the credit accounting rule that one credit equals one record requested, which helps the agent reason about cost before invoking export tools.

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 return value first, then the practical usage tip. Every clause earns its place and nothing is repeated from the schema or annotations.

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

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

With no parameters, no output schema and safety fully covered by annotations, the description only needs purpose plus useful context, which it delivers. A brief note on the shape of the response (credit count vs. plan identifier) would make it fully self-sufficient.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies per the rubric for a no-parameter tool.

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

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

The description names the resource precisely — remaining credits plus current plan — which no sibling tool reports (all siblings are find/verify/export/enrich actions). It lacks an explicit verb like 'Returns', relying on a noun phrase, but the intent is unambiguous.

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

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

It gives a concrete usage cue: check before starting a large export. There are no real alternatives among the siblings to route against, so the absence of exclusions is not a gap.

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 it is a non-read-only, open-world, idempotent, non-destructive operation, so the safety profile is covered. But the description omits the operationally important traits: this consumes credits (the schema notes emails are billed), and wait_seconds implies an asynchronous job that may return a job id rather than results — neither is mentioned in the description.

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 compact sentence that front-loads the returned data. Nothing is wasted, but it is sparse enough that it reads more like a field list than a definition.

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 credit-consuming, open-world, potentially asynchronous enrichment call with no output schema, the description should say something about cost, job/id return behavior, and result shape. Instead it only lists four output fields, leaving the agent without the context needed to call it responsibly.

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 clear per-parameter docs for with_emails (billing), profile_urls, and wait_seconds (async fallback). The description adds no parameter meaning 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?

The description names the resource (LinkedIn profiles, keyed by profile URLs) and enumerates the returned fields (current title, company, location, experience), so an agent knows what it gets. It does not differentiate itself from siblings such as scrupp_find_decision_makers or scrupp_lookup_company, which also return people/company data.

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

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

There is no statement of when to use this tool versus the nine siblings, no prerequisites, and no exclusion criteria. An agent must infer from the name alone that this is the profile-enrichment path rather than the email-finding or search-export path.

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=false, openWorldHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context of its own: it does not mention that the run consumes credits (or that unused credits are refunded), that it may return a job id instead of results, or that it is a scraping operation subject to account/latency constraints — all of which are only hinted at in the parameter schema.

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

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

Two sentences, both earning their place: the first states the action, the second handles disambiguation. Routing information is front-loaded rather than buried.

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 5-parameter extraction tool with no output schema, the routing guidance is complete and the parameters are fully documented in the schema. The only gap is that the description never signals the async/credit-consuming nature of the run, which matters for an agent deciding whether to call it now.

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

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

Schema description coverage is 100%, so the schema already explains url, max, account, with_emails, and wait_seconds, including the credit-hold and job-id behavior. The description adds no parameter meaning beyond what structured data provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('Extract the people from a regular LinkedIn people-search URL'), and immediately scopes it against the Sales Navigator variant. An agent can distinguish it from scrupp_export_sales_navigator_search 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?

Explicitly names the URL pattern this tool handles (linkedin.com/search/results/people) and the pattern that should route elsewhere (linkedin.com/sales, Sales Navigator tool). Both the when and the when-not are stated in one sentence, leaving nothing to inference.

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

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

Annotations already cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuine value beyond them: the output contents (titles, companies) and the non-obvious default that verified work emails are included. It stops short of disclosing that this is a credit-consuming, possibly async job.

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

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

Two sentences with zero waste: the first front-loads what is extracted and returned, the second front-loads the trigger condition. Nothing needs trimming or reordering.

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

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

For an open-world, credit-metered job tool with no output schema, the description covers what the caller gets back and the main default, which is most of what is needed. It omits that the call may return a job id instead of records and says nothing about credit cost, though the schema's wait_seconds and max descriptions partially compensate.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters, including max's credit-hold/refund behavior and wait_seconds' job-id fallback. The description adds only a slight nuance ('by default' emails, 'verified'), which the schema's with_emails default already conveys. Baseline 3 is correct.

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

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

States a specific verb (Extract) and resource (people from a LinkedIn Sales Navigator search URL) plus what is returned (titles, companies, verified work emails). It does not name or contrast the very close sibling scrupp_export_linkedin_search, so an agent must infer the Sales-Navigator-vs-LinkedIn distinction from the name alone.

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

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

Gives one when-to-use condition ('when the user has a Sales Navigator search they want as a list'), which is helpful. However, it never names the obvious alternative scrupp_export_linkedin_search or states when this tool should NOT be chosen, which is exactly the ambiguity a sibling set like this creates.

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 openWorldHint, idempotentHint, non-destructive and non-read-only, so the safety profile is covered. The description adds the return contents (names, titles, emails), but omits notable behavior: the async job model suggested by wait_seconds and the likely credit cost implied by scrupp_credits/scrupp_get_job siblings. The not-read-only hint also goes unexplained.

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

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

Two tight sentences, front-loaded with the core purpose and then the return shape. No filler, 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?

For a tool with no output schema and a non-read-only, externally-facing profile, the description covers purpose and return fields adequately. It is still thin on the asynchronous job behavior, credit consumption, and result limits (max up to 2500) that an agent would want before invoking.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description adds only the 'where found' caveat on emails and no extra syntax or format detail for find_by/companies, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific resource (decision makers) and the three lookup identifiers (domain, LinkedIn URL, name), plus what it returns. It is clear what the tool does, but it does not explicitly distinguish itself from close siblings like scrupp_find_emails or scrupp_lookup_company.

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 'a company you only know the domain, LinkedIn URL or name of' implies the eligibility condition for using it, but there is no explicit when-to-use vs when-not, and no sibling is named as an alternative for other cases.

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

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

The description usefully discloses an output-quality behavior: unresolvable addresses are returned marked rather than guessed. But it is silent on the operational realities implied by readOnlyHint=false and the wait_seconds parameter — that this submits an asynchronous job, may consume credits, and that results may come back as a job id.

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, zero filler, with the core purpose front-loaded and the caveat about unverifiable addresses placed second where it belongs.

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

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

With no output schema, the description carries the burden of explaining returns; it does partially (marked results) but omits the async job model and how to retrieve results, despite wait_seconds implying a job id may be returned instead of data. Sibling scrupp_get_job exists and is never referenced.

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?

At 50% schema coverage, the description names the three nested person fields (first name, last name, domain) but adds no format or constraint detail beyond the schema's domain example. It says nothing about the wait_seconds parameter or about passing multiple people in the array.

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 pair and resource ('find and verify work email addresses') plus the required inputs (first name, last name, company domain). However it does not distinguish itself from the sibling scrupp_verify_emails, which also deals with verification, so an agent can't tell them apart from the text alone.

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

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

No when-to-use or when-not-to-use guidance is given. The presence of 'verify' in the description while a sibling tool is literally named scrupp_verify_emails creates ambiguity that the description does nothing to resolve, and no alternative (e.g., scrupp_find_decision_makers) is mentioned.

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

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

Annotations already declare readOnly, non-destructive, and closed-world behavior. The description adds useful behavioral context beyond that: it indicates the tool returns job status, and records only after completion, implying a polling pattern.

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 tightly written sentences with zero waste. The core purpose and usage condition are front-loaded, making it easy to scan.

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

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

Given no output schema, the description adequately explains what is returned (status and records once finished) and when to call it. It could say more about status values or whether the call blocks, but it is complete enough for correct invocation.

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

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

Schema coverage is 100% and the single job_id parameter is fully documented in the schema. The description adds no additional parameter semantics, so the baseline of 3 applies.

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

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

The description states a specific resource and scope: a job's status and its records once finished. It clearly distinguishes this tool from the sibling extraction/search tools that start jobs, without needing to name them.

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

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

It gives explicit when-to-use guidance: 'Use this for a job that was still running when the tool that started it returned.' This tells the agent the tool is for polling async jobs, though it does not mention when-not or alternative tools.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. However, the readOnlyHint=false combined with the schema's wait_seconds parameter signals asynchronous job creation that the description never mentions — it does not say results may come back as a job id rather than data, nor how batching across the companies array behaves. That is a meaningful behavioral gap for a lookup 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?

A single dense sentence that front-loads the returned data and then the accepted input forms. No filler or repetition. It is a fragment rather than a full sentence, but nothing wasteful is included.

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

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

With no output schema, the description usefully enumerates the returned fields, which compensates partly. But it omits the asynchronous job semantics implied by wait_seconds and the id-return behavior, which an agent calling a batch lookup tool would need to handle responses 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 each parameter is documented (including the enum for lookup_by and the default for wait_seconds), so the schema carries the weight. The description's listing of domain/LinkedIn/name mirrors the enum values already in the schema, adding no syntax or format detail beyond it.

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

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

The description names the resource (company data) and enumerates the specific fields returned (size, industry, location, website, LinkedIn), so an agent knows exactly what it gets back. It also states the three accepted input key types. It stops short of explicitly distinguishing itself from siblings like enrich_linkedin_profiles or find_decision_makers, but the resource is different enough to be distinguishable.

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 by the accepted lookup keys (domain, LinkedIn URL, name), which tells the agent what inputs are valid, but there is no explicit when-to-use guidance and no mention of when to prefer a sibling such as enrich_linkedin_profiles. Adequate but leaves routing to inference.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is largely covered. The description adds the auth prerequisite (connected Apollo account), which is genuine extra context, but omits credit consumption, the credit hold, and the async/job-id behavior that the schema's wait_seconds hints at.

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

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

Two short sentences, front-loaded with the action and minimized on filler. The second sentence is mildly redundant with the schema's own 'Required.' marking on `account`, but it is brief enough that it still earns its place as an auth caveat.

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

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

No output schema exists and the tool is asynchronous with a credit cost, yet the description says nothing about the return shape (people records vs. a job id when wait_seconds elapses) or that scrupp_get_job is needed to retrieve results after a timeout. For a five-parameter, credit-consuming, potentially async tool, this leaves material gaps.

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

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

Schema description coverage is 100%, so all five parameters including `max`, `with_emails`, and `wait_seconds` are already documented inline. The description only restates that `account` is required, adding no syntax, format, or defaults beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource: 'Extract the people from an Apollo search URL.' An agent knows this is an Apollo-sourced people extraction rather than a LinkedIn/Sales Navigator export, but the description never names a sibling tool, so the differentiation is implicit rather than explicit.

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 only usage context is the prerequisite 'Requires a connected Apollo account,' which is really an auth note. There is no when-to-use versus when-not, and no pointer to alternatives such as scrupp_export_sales_navigator_search or scrupp_find_decision_makers for other 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?

Annotations cover safety hints, but the description adds information they do not carry: the credit cost per address and the fact that find_emails output is already verified, which prevents redundant spend. It stops short of describing what the verification result looks like (status values, per-address outcome), leaving a modest gap.

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

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

Two sentences, no filler, with the purpose front-loaded and the cost/alternative caveat immediately after. Every clause earns its place.

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

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

Covers cost, eligibility, and avoidance of redundant calls for a paid, non-idempotent operation, and annotations carry the safety profile. With no output schema, it could still say what a verify call returns, but for a one-parameter tool this is close to sufficient.

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

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

Schema description coverage is 100% and the single emails parameter is fully documented with min/max items and format, so the baseline is 3. The description's 'one credit per address' is a billing note rather than added parameter syntax or 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 ('Check whether email addresses are deliverable') and explicitly frames the outcome (before sending to them). It also names the sibling tool scrupp_find_emails and explains the distinction, so an agent can route without opening either schema.

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

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

Gives explicit when-to-use ('addresses you already have') and when-not ('not on ones scrupp_find_emails just returned'), with the reason (those are verified already). This is exactly the alternative-routing guidance the dimension rewards.

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