LeadProof Sales Agent

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

With no annotations, the description carries the burden of disclosing behavior. It clearly states what the tool returns (0-100 risk score, missing safeguards, revenue-at-risk estimate, integration kit) and implies a non-destructive audit via the word 'audit' and 'returns'. However, it does not explicitly state that it does not modify data, nor does it mention any auth or rate-limit constraints. The output description is strong, but a small gap remains.

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 description is two sentences with no filler. The use condition is front-loaded, and the alternative tools are mentioned compactly in the second sentence. It is appropriately sized for the information it conveys.

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 8 parameters and no output schema, the description covers the purpose, usage, and high-level output but fails to explain the boolean parameters or the contents of the 'integration kit'. It also does not describe the response format. The description is adequate for routing but leaves gaps for an agent that needs to fill all parameters 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%, so the description must compensate. It mentions 'monthly lead volume' and 'customer value' which map to monthly_leads and average_customer_value, but it does not name the parameters or explain the boolean 'safeguards' fields (stack, idempotency, retry_policy, failure_alerts, dead_letter_queue, destination_verification). The agent is left to guess which booleans correspond to 'current safeguards', making parameter semantics vague.

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 clearly states a specific action (audit lead workflow) and its result (scored reliability diagnosis), and it differentiates from siblings by naming get_leadproof_evaluation_path and compare_leadproof_vs_in_house with their distinct use cases. This gives the agent enough to pick the right tool without ambiguity.

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 explicitly states when to use the tool (when buyer can provide monthly lead volume, customer value, and current safeguards) and gives explicit alternatives for other scenarios (general product tour, buy-or-build decision). This is a textbook example of usage 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions what the tool returns ('evidence-based comparison with the complete public example audit URL') and lists the topics covered, but it does not disclose the exact nature of the comparison (e.g., static vs. dynamic), any limitations of the evidence, or whether it requires external dependencies. This is adequate but not rich.

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

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

The description is two sentences, front-loaded with the primary use case, followed by a list of covered topics and a clear pointer to an alternative. Every sentence contributes, with no fluff.

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 description covers the what, when, and alternatives. It lists the topics covered (retries, idempotency, etc.), which gives a good sense of the output. However, it lacks details on the format of the output (e.g., is it a report? a URL? a list?) and does not mention any prerequisites or limitations that might affect the agent's expectations. Still, given the zero-parameter, static nature, it's reasonably complete.

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 has zero parameters, so the schema coverage is 100% by default. The description adds context about the tool's output scope, but since there are no parameters to explain, the description's job is minimal. A baseline of 4 is appropriate because the description provides useful context about what the tool returns, which aids the agent in understanding the tool's purpose.

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 clearly states the tool's purpose: comparing LeadProof against an in-house build for lead-delivery reliability controls. It specifies the resource and the decision context. However, it does not explicitly distinguish from siblings like evaluate_leadproof_fit or get_leadproof_plan_decision, which might also involve comparison or decision-making.

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 explicitly states when to use this tool: when the buyer is deciding between building internally or buying LeadProof. It also provides a clear alternative: 'For diagnosis of one live workflow, use audit_lead_workflow instead.' This is direct and helps an agent route correctly.

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 exist, so the description carries the full burden. It states the output categories but never discloses whether evaluation is read-only, requires authentication, invokes external systems, or has side effects; the only safety signal is the word 'recommendation.' Given the lack of annotations, this is a real transparency 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?

The main use-case sentence is front-loaded, and the three alternative routes are packed into one efficient sentence with zero filler. 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?

For a 4-parameter tool with no output schema and ten siblings, the description gives enough selection guidance and expected outputs to be usable. It falls short mainly on parameter detail and behavioral safety, which are captured in the other dimensions; the core decision context is otherwise complete.

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 25% (stack has a description; monthly_leads, workflow_problem, and average_customer_value do not). The description mentions 'specific stack or workflow problem' but does not explain units or how the required numbers feed the fit/ROI/integration/plan outputs, so it does not compensate for the schema's low coverage.

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

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

The description names a concrete use case ('specific stack or workflow problem') and the results produced ('LeadProof fit, ROI, integration, and plan recommendation'), and it explicitly distinguishes this tool from audit_lead_workflow, get_leadproof_integration, and get_leadproof_evaluation_path. The resource and output scope are clear enough that an agent won't confuse it with its 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?

It gives an explicit trigger condition and three direct alternative-routing instructions ('For detailed safeguard scoring, use audit_lead_workflow instead; for installation guidance only...; for general exploration...'). This is model behavior for when-to-use vs 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?

With no annotations, the description carries the behavioral burden. It clearly discloses the tool does not authorize or complete payment, which is critical safety context. The precondition about explicit buyer authorization also clarifies when the action is appropriate.

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 with no repetition or filler. The precondition is stated first, the core function second, and the alternative routing third, making each sentence earn 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?

For a single-parameter tool with no output schema, the description explains what it returns, when to use it, what not to do, and which alternative tools to use. 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 coverage is 0%, but the description connects the 'plan' parameter to the buyer's selection of Builder or Agency, mapping directly to the enum values. It adds process context beyond the raw enum, though it does not explicitly name the 'plan' parameter.

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

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

States a specific verb and resource: 'Returns the official Stripe checkout URL.' It also differentiates from siblings by explicitly saying it 'never authorizes or completes payment' and by pointing to get_leadproof_trial and get_leadproof_plan_decision for other situations.

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 explicit preconditions: use only after the buyer selected Builder or Agency and explicitly authorized a paid checkout. It also names alternatives when the buyer has not evaluated the product, giving the agent clear routing logic.

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 exist, so the description carries the full burden. It clearly discloses that the tool returns a no-purchase sequence, lists its components, and implies no workflow data or authorization is required—contrasting with the checkout tool. No hidden side effects are suggested.

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: when to use, what it returns, and what to use instead for other needs. Every sentence earns its place; the primary use case is front-loaded and there is no redundant phrasing.

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 zero-parameter tool with no output schema, the description fully covers usage scenario, return content, and alternatives. It also clarifies authorization requirements for the related checkout tool. 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?

The tool has zero parameters and the schema is empty with 100% coverage. Per the baseline for 0-parameter tools, the description need not add parameter detail. It does add context about when to invoke, which is sufficient.

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 clear purpose: returns the official no-purchase evaluation sequence for buyers exploring LeadProof without workflow data. Uses specific verbs ('Returns') and names the content, and explicitly distinguishes itself from sibling tools by naming 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?

Explicitly instructs when to use it first (buyer exploring without workflow data) and provides exclusions with alternatives: audit_lead_workflow for scored diagnosis, get_leadproof_replay_trial for replay testing, and get_leadproof_checkout only after authorization. This is exceptional 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?

With no annotations, the description carries the full burden. It discloses that the tool returns only public evidence, explicitly excluding customer records, and implies a read-only nature. However, it does not explicitly state side effects, authentication requirements, or any potential limitations beyond the exclusion of customer records. This is a minor gap given the parameterless nature of the 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 description is two sentences: the first front-loads purpose and return contents, the second provides exclusions and alternative routing. Every sentence earns its place, with no wasted words. It is concise and well-structured.

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 parameterless tool with no annotations and no output schema, the description fully explains what the tool does, what it returns, what it excludes, and when not to use it, including specific alternatives. There is nothing an agent needs to know to call it correctly that 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?

The input schema has zero parameters, so the baseline of 4 applies. The description does not need to add parameter meaning since there are none. The description effectively covers the tool's behavior without referencing parameters, which is acceptable for this parameterless 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 clearly states the tool is for due diligence and verifying LeadProof claims with public evidence, and lists specific outputs (live checks, contracts, buyer protections, limitations). It also explicitly differentiates from siblings by naming what it does NOT do and pointing to alternatives. The verb-resource pair is precise and 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?

Explicitly states when to use ('Use for due diligence or to verify a LeadProof claim with public evidence') and when not to ('Do not use to select a plan or start a trial'), naming the exact alternatives (get_leadproof_plan_decision, get_leadproof_trial). This leaves no ambiguity about selection.

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 provided, so the description carries the full burden of behavioral disclosure. It describes a read-only operation (matching and returning) and implies no side effects. While it doesn't explicitly state read-only or discuss edge cases, the 'returns' language and the nature of the tool make the intent clear. This is adequate 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?

Three concise sentences: the first gives the trigger condition, the second explains the action and output, and the third names alternatives. Every sentence earns its place with no redundancy or fluff.

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

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

For a single-parameter lookup tool with no output schema, the description is complete: it covers intended use, behavior, and alternatives. Nothing an agent needs to call 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 description coverage is 100%, so the schema already fully documents the single 'stack' parameter. The description restates the stack types but adds no new semantic detail beyond what the schema provides. Baseline 3 is appropriate when the schema carries the descriptive 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?

The description clearly states the tool matches a named stack against 53 published LeadProof guides and returns canonical paths and concise steps. It also explicitly distinguishes itself from audit_lead_workflow and evaluate_leadproof_fit, which focus on reliability/ROI, so an agent can easily tell them apart.

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 explicitly says 'Use when the buyer names an automation, form, AI voice, ad, or CRM stack and needs implementation guidance' and then directs to alternatives for reliability scoring or ROI. This is a clear when-to-use and when-not-to-use with named sibling 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses a key constraint: 'permits paid checkout only after human or principal authorization,' which informs the agent about an approval requirement. It also states it 'Returns exact plan boundaries,' giving a sense of the output. However, it does not explicitly clarify whether the tool is read-only or mutating (e.g., whether 'permits' implies a state change), leaving some ambiguity about side effects.

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 description is two sentences with zero fluff. The first sentence front-loads the primary purpose and usage condition; the second sentence provides the exclusion and alternative tools. Every word earns its place, and the structure is easy to parse.

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 zero-parameter tool with no output schema and no annotations, the description is fairly complete: it covers purpose, usage timing, exclusions, and a key authorization condition. It mentions 'exact plan boundaries' but doesn't elaborate on what those boundaries might be, which is a minor gap. Still, an agent can confidently decide whether to call this tool and what to expect at a high 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?

The tool takes zero parameters, and schema description coverage is 100%. The baseline for 0 parameters is 4, and the description doesn't need to add parameter semantics because there are none. It does add context about what the tool returns, which is useful but not parameter-related. Thus, a 4 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 clearly states the tool's function: 'Use when evaluation is complete and the buyer needs the official trial-first choice among the free trial, Builder, and Agency.' It specifies the resource (plan decision), the exact choices, and what it returns ('exact plan boundaries'). It also differentiates from siblings by explicitly naming alternatives ('use audit_lead_workflow or evaluate_leadproof_fit instead'), so an agent can distinguish it 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?

The description gives explicit when-to-use guidance: 'Use when evaluation is complete and the buyer needs the official trial-first choice.' It also gives when-not-to-use and alternatives: 'Do not use for workflow diagnosis; use audit_lead_workflow or evaluate_leadproof_fit instead.' This leaves no ambiguity about when the tool should be invoked versus its 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 behavioral burden. It discloses useful behavioral expectations: it returns a public procedure, a fictional example audit, exact prerequisites, and an attributed no-card production trial. The 'fictional' and 'no-card' qualifiers add transparency beyond a simple 'returns trial info' statement, though it does not explicitly state whether the tool has any side effects.

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 no filler. The use case is front-loaded, the deliverables are listed compactly, and the sibling routing is in a single closing sentence. Every sentence 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?

For a zero-parameter, informational tool with no output schema, the description fully covers what the agent needs: when to use it, what it returns, and which alternatives to choose. No critical detail 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?

The input schema is empty and schema coverage is 100%, so there are no parameters for the description to explain. Baseline for zero parameters is 4; the description needs no parameter-level detail.

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 specific scenario ('test duplicate-safe replay of failed lead deliveries before purchase') and a specific resource (replay trial). It explicitly distinguishes itself from get_leadproof_trial and get_leadproof_evaluation_path, so an agent can identify the correct tool without opening 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?

It gives a clear 'use specifically when' condition and names the two alternative tools with their exact selection criteria ('standard trial without replay guidance' and 'general exploration'). This is explicit when/when-not guidance, not just implied context.

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 behavioral burden. It discloses key trial conditions (25 live deliveries, 14 days, verified sign-in, no payment authorization), which helps the agent anticipate what starting the trial entails. It does not describe the return value or any follow-up side effects, but for a fixed-term activation tool the important traits are covered.

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 compact sentences with no wasted words. The when-to-use condition and core terms come first, and the alternative routing is placed at the end, making the most decision-relevant information immediately visible.

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 zero-parameter, no-output-schema tool, the description supplies everything an agent needs to select and invoke it correctly: the conditions, the exact trial terms, and the alternatives. Nothing essential 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?

The tool has zero parameters and schema coverage is 100%, so there is no parameter burden for the description to carry. The baseline of 4 applies because there are no parameters to document and no ambiguity to resolve.

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 the exact action ('start the standard no-card production trial') and the precise terms (25 live lead deliveries for 14 days, verified sign-in, no payment authorization). It also explicitly distinguishes itself from get_leadproof_replay_trial and get_leadproof_evaluation_path, so an agent cannot confuse it with 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?

It opens with the trigger condition ('Use when a buyer is ready to start...') and names alternatives for different scenarios. This gives the agent clear when-to-use and when-not-to-use guidance without needing to inspect other 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?

With no annotations, the description carries the behavioral disclosure burden. It does disclose that the tool creates a handoff, returns a plan, requires consent, and does not authorize payment. However, it does not clarify whether the act of calling the tool immediately triggers external contact, whether calls are idempotent, or what persistent side effects exist beyond creating the handoff.

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 most important condition, then the action, then the exclusion. Every sentence earns its place and there is no filler or redundant restatement 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?

The core call path is clear: when to use, what it does, what it returns, and what it does not do. However, with 8 parameters and no output schema or annotations, the description does not explain how optional inputs shape the recommended plan or whether any immediate external follow-up is triggered. This leaves meaningful gaps for an agent deciding how to populate the optional fields.

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 38%, so the description needed to compensate for the many undocumented parameters. It adds some context by tying email to 'authorized business email' and consent_to_contact to the consent gate, but these largely restate the schema descriptions. The optional parameters (plan, stack, company, monthly_leads, average_customer_value) receive no explanation of how they influence the recommended plan.

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 immediately states the exact trigger condition ('represented buyer explicitly asks for human follow-up and authorizes LeadProof to contact their business email'), the action ('creates a consent-based sales handoff'), and the return behavior ('returns the recommended plan'). It also explicitly contrasts itself with get_leadproof_* tools, making it easy to distinguish from 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?

The description gives an explicit when-to-use condition, an explicit when-not-to-use list ('self-serve evaluation, trial access, or checkout'), and names the alternative tool family ('corresponding get_leadproof_* tool'). This is model usage guidance.

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