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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose two traits beyond the name: output is approval-gated (drafts, not sends) and each message covers a single angle. It says nothing about whether LinkedIn data is scraped live, what happens on missing domain, whether drafts are persisted, or what the caller receives, all of which matter for a tool with external side effects and compliance risk.

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 sentence, front-loaded with the discovery action and then the drafting action, with no filler. It is efficient and readable; the only weakness is that brevity here comes at the cost of the missing parameter and behavior detail rather than being a deliberate trim.

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 annotations, no output schema, and 0% schema description coverage on three parameters, the definition should explain inputs and return shape. Instead it leaves the required role_title undefined and never states what a successful draft response looks like, which is a substantial gap for a multi-step generation 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 three parameters, so the description must compensate and does not. 'Target company' loosely maps to company_name, but role_title (a required parameter) and the optional domain are never explained — an agent cannot tell whether role_title is a filter for the decision-maker's title or the sender's, or how domain relates to company_name.

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

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

The description uses two concrete verbs with their resources: 'finds LinkedIn decision-makers' and 'drafts approval-gated single-angle LinkedIn outreach messages', and names the angle taxonomy (OPERATIONS, MARKETING, AI). It is clearly distinguishable from a pure lookup like waterfall_find_decision_maker because it produces drafts. It stops short of naming any sibling explicitly, so an agent must infer the boundary itself.

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

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

The phrase 'approval-gated' implies the tool stops at a draft and does not send, which is useful workflow context. However, there is no statement of when to choose this over waterfall_find_decision_maker or validate_outreach_payload, no prerequisites, and no indication of what happens after drafting. Usage must be inferred entirely from the name and the word 'approval-gated'.

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?

No annotations are supplied, so the description carries the full disclosure burden. 'Live scanner' implies real network calls against many boards but the description says nothing about latency, rate limits, per-board failure behavior, result volume, or whether the call is read-only and side-effect free. For a fan-out scraping tool with seven inputs and no safety hints, this leaves significant behavior undocumented.

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

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

It is a single sentence with no filler, but it is a keyword-stuffed fragment rather than a well-structured clause, and the most actionable information (board identifier format, when to use each mode) is absent. Short is good here, but brevity is achieved partly by omitting essentials rather than by tightening.

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 seven parameters, no annotations, no output schema, and zero schema descriptions, the description does far too little. An agent still cannot determine what a valid board string looks like, what the response contains, or how the OPERATIONS/MARKETING/AI tracks relate to inputs. Only the platform inventory is adequately covered.

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 compensate. It does partially: the six named ATS platforms map one-to-one onto the six `*_boards` array parameters, letting an agent infer which array feeds which platform. However, it never specifies the expected format of a board entry (slug, subdomain, or full URL), and `include_live_search` is only obliquely referenced via 'live ATS search discovery' without explaining its effect or default.

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 specific resource and scope: a live job-board scanner covering six named ATS platforms (Greenhouse, Ashby, Lever, Workable, SmartRecruiters, Recruitee) plus live ATS search discovery across OPERATIONS, MARKETING, and AI tracks. An agent can tell this is a multi-source job-posting aggregator. It does not differentiate itself from any sibling, though the listed siblings (markdown scraping, outreach validation) are unrelated enough that confusion risk is low.

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 guidance on when to use this tool versus alternatives, no prerequisites, and no statement of what happens when board arrays are omitted. The mention of 'live ATS search discovery' hints at an additional mode but never says when to enable or disable it, or that `include_live_search` defaults to true.

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?

With no annotations, the description carries the full disclosure burden; it does add real value by revealing that pages are JS-rendered (so dynamic content is captured) and that the output is normalized Markdown. It is silent on rate limits, API keys/auth for the Firecrawl/Jina backends, failure modes for unreachable URLs, and whether output is truncated or paginated.

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 packed sentences with zero filler; the capability is front-loaded and the concrete target sites follow immediately as supporting detail.

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

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

For a low-complexity two-parameter read tool with fully covered schema, the description supplies enough: what it fetches, that it handles JS-rendered content, and what it returns. The only omission is what max_chars truncation means for the caller, which is minor at this complexity level.

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

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

Schema coverage is 100%, so both parameters are already documented, and the description adds no format, syntax, or semantics beyond that. Baseline 3 applies since the schema, not the prose, 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: a web scraper that turns pages into clean Markdown, naming the underlying backends (Firecrawl / Jina Reader). It implicitly separates itself from the sibling set (outreach/decision-maker/ATS-ops tools) by being the fetch-and-convert tool, though it never names a sibling explicitly.

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

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

Usage context is implied through the target list — JS-heavy career pages, Ashby/Greenhouse/Workable boards, company sites — which tells an agent roughly when this is the right tool. There is no explicit 'use this instead of X' routing and no statement of when not to use it, so guidance stops at implication.

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?

With no annotations supplied, the description carries the full behavioral burden. It does disclose the concrete rule set being enforced, which is genuinely useful, but it never says what happens on a violation (throw, return a list, block sending), whether the call is read-only, or whether it mutates the payload.

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 the gate label first and the rule list after, with no filler. Dense but readable; it could be split so the outcome of a failed check is surfaced rather than crammed into the rule list.

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

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

For a 6-parameter validator with no annotations and no output schema, the agent still lacks the result contract: pass/fail shape, list of violations, and whether the caller should abort the send. The input side is reasonably covered by the enumerated rules, but the outcome side 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 schema gives only names and types. The description implicitly maps most inputs to rules — recipient_email via the info@/careers@ check, body/subject via the payload and {first_name} brace check, headline and company_name via the mismatch check. It still does not clarify which params are required, how contact_name relates to the brace check, or accepted formats.

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 (checks/validates) and resource (candidate email/DM payloads) and enumerates the exact rules applied: generic aliases, unreplaced braces, em-dashes, headline-to-company mismatches. The 'Hard Pre-Send Quality Gate' framing makes the intent unmistakable, though it never names or contrasts with the sibling prepare_linkedin_outreach_for_approval.

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?

'Pre-Send' implies the tool is invoked before dispatching outreach, which gives implied timing guidance. However, there is no explicit when-not condition, no statement of what to do with a failing payload, and no named alternative among the 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?

With no annotations, the description carries the full disclosure burden and does contribute real behavior: a four-stage provider sequence with explicit fallback order and a 'strict generic alias filtering' rule that signals results exclude info@/sales@ style addresses. It omits what happens on failure (empty result vs. error), whether the waterfall consumes paid API credits or is slow across four providers, and what the returned record looks like.

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 sentence with no filler, front-loaded with the tool's identity and then the stage chain. The nested parentheses and arrow notation are dense but every token conveys pipeline information; readability, not verbosity, is the only weakness.

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 multi-provider enrichment tool with no output schema and no annotations, the description should say what an agent receives (name only, name+title+email, multiple candidates?) and how to interpret a failed waterfall. Those omissions are material for a tool whose whole job is producing a contact record.

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 domain, company_name, and job_category are already documented in the schema at baseline 3. The description adds indirect context by naming 'Executive Name Lookup' as a stage, loosely mapping to the job_category default of 'executive', but it never explains how job_category changes the waterfall or which category values map to which providers.

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 tool as an 'OpenProspector 4-stage waterfall enrichment' and enumerates the providers and fallback chain, so the mechanism is specific. However, it never states the actual outcome (does it return a person's name, an email, a ranked contact list?), so an agent must infer the purpose from the tool name rather than the description.

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, when not to, or which sibling (scrape_clean_markdown, scan_live_ats_career_ops, validate_outreach_payload, prepare_linkedin_outreach_for_approval) it should be preferred over. The only implied usage is 'given a company, find a decision maker,' which 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.