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

Annotations already flag destructive and open-world behavior; the description adds the meaningful consequence that switching accounts changes outreach identity. It does not elaborate on side effects of unlink or refresh_tier, but the annotation coverage lowers the burden.

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?

Tight and front-loaded: the main purpose is stated first, the accounts-vs-account distinction takes one sentence, and the args are compactly listed. No filler or redundancy.

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

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

Covers core usage, the key sibling distinction, and relies on an existing output schema. However, action semantics are under-specified: what 'switch' versus 'switch_to' means, what 'refresh_tier' does, and which actions require account_id are left to inference.

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 provides no descriptions or enum values, but the description lists the allowed action values and notes account_id is used for switch_to. This meaningfully compensates for the schema, though the difference between 'switch' and 'switch_to' and the meaning of 'refresh_tier' remain unclear.

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?

Description uses specific verbs ('switch', 'unlink', 'connect') and names the resource (active LinkedIn account). It also explicitly distinguishes itself from the 'accounts' sibling by noting listing is the accounts tool, so an agent can tell which tool handles mutation vs listing.

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 that the active account determines who outreach is sent as and points to the accounts tool for listing, giving clear context for when to use this tool. It does not spell out exclusions or conditions, but the main alternative is named.

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 readOnlyHint annotation already covers the 'Changes nothing' aspect, so the description adds no new behavioral disclosure beyond that. It does not mention rate limits, response size, or other side effects, but for a simple list operation the annotation suffices.

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 short sentences plus a minimal Args block. The purpose is front-loaded, and every sentence earns its place, with no redundant words.

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 tool is very simple (one optional parameter, no required fields) and has an output schema, so the description doesn't need to explain return values. The combination of the purpose statement, the Args hint, and the annotations fully equips an agent 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?

The schema provides only a title and default for the action parameter, with zero description. The description compensates by specifying action="list" and clarifying that other account actions belong to the account tool, giving the agent enough context to invoke it correctly. It doesn't explicitly state the parameter is optional, but the schema default covers that.

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 clear verb+resource: 'List the LinkedIn accounts connected to this HeyLead.' It immediately clarifies the tool's scope and read-only nature with 'Changes nothing.' This distinguishes it from the singular 'account' sibling by pointing out that account management actions belong elsewhere.

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 names the alternative tool 'account' for switching, unlinking, and connecting email, telling the agent when not to use this tool. The instruction in the Args block reinforces that only the 'list' action is intended here, leaving no ambiguity about which operations belong to this tool.

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

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

Annotations already mark the tool as read-only and open-world, and the description adds useful behavior beyond that: hosted accounts receive a dashboard link and snapshot card, the link should be relayed, and some clients show the image only to the model. It also documents default behavior for empty parameters without contradicting the annotations.

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

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

The description is front-loaded with a one-line summary and then an organized Args block. The hosted-account image nuance is a valuable caveat that earns its place. It is slightly longer than strictly needed but contains 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 no output schema, the description still explains what each mode returns, export formats, parameter defaults, and the hosted-account rendering caveat. It omits error handling and permission notes, but for a read-only analytics tool the provided context is sufficient for an agent 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 0%, so the description carries the full burden. It documents all four parameters: action values, campaign_id defaulting to active, campaign_ids for compare mode, and format choices for export. This fully compensates for the bare 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?

The description clearly identifies the tool as campaign analytics with reports, comparisons, and exports, which distinguishes it from sibling tools like campaign or show_status. It lacks a direct action verb, but the resource and available modes are specific enough to avoid tautology.

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 Args section gives mode-specific usage context: report, compare, and export, along with defaults for empty campaign_id and campaign_ids. However, it never explicitly states when not to use this tool or names alternatives among the large sibling set, leaving some 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 flag destructiveHint=true and readOnlyHint=false, and the description adds meaningful behavioral detail: 'reply' and 'approve_draft' SEND a LinkedIn message and cannot be undone. It does not explicitly state whether discard_draft is also irreversible, which is the only small 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 description is compact: a one-line purpose, a warning about irreversibility, a sibling routing note, and a clean args list. It front-loads the most important facts and has 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, not explaining return values is acceptable. The description covers actions, target, content, and irreversibility, but it leaves the send_message sibling unaddressed and does not clarify whether text is required for reply/approve_draft, so an agent may need to infer those preconditions.

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%, yet the description documents all three parameters: action values ('reply', 'approve_draft', 'discard_draft'), chat_id as the conversation/draft, and text as the message or edited draft. This fully compensates for the sparse schema and adds allowed values via prose.

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?

Description opens with a concrete verb+object: 'Reply in a LinkedIn conversation, or approve or discard a drafted reply.' It clearly delimits three actions and distinguishes it from the inbox read tool ('Reading the inbox is the inbox tool'), so an agent can tell it apart from siblings like inbox.

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 provides explicit routing away from reading ('Reading the inbox is the inbox tool') and warns that reply/approve_draft send a message and cannot be undone. However, it does not address the sibling send_message tool, so the boundary between sending a fresh message and answering an inbox conversation is implied rather than stated.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the description doesn't need to restate that. It adds useful behavioral context: creates the event on the connected calendar, attaches a Google Meet link, and emails the attendee an invitation. It doesn't mention side effects like overwriting existing events or permission requirements, but the core behavior is disclosed.

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 well-structured with a clear opening sentence, a usage trigger, and a compact Args list. Every sentence earns its place. It could be slightly tighter, but it's appropriately sized for a 5-parameter tool.

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

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

Given the tool has an output schema and annotations, the description covers the essential behavioral context: what happens (event created, Meet link attached, invitation emailed) and when to use it. It doesn't mention failure modes or prerequisites (e.g., calendar must be connected), but the connected-calendar detail is implied. This is adequate for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description carries the full burden. It explains attendee_email ('Who to invite — the prospect who replied'), start ('When it starts, ISO 8601'), duration_minutes ('How long the meeting runs. Defaults to 30'), summary ('Event title. Defaults to naming the attendee'), and description ('Optional agenda or notes'). This adds meaning beyond the bare schema property names.

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 ('Book'), a resource ('a meeting on your Google Calendar'), and the action's purpose ('invite a prospect'). It clearly distinguishes itself from siblings like send_email or send_message by specifying calendar event creation with a Google Meet link and attendee invitation.

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 says 'Use this when a reply agrees to a call,' giving a clear trigger condition. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to select this tool over generic messaging 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 readOnlyHint=false and destructiveHint=true. The description adds useful behavior beyond that: the default campaign_id behavior ('Uses the active one if empty') and the confirm requirement for destructive actions. No contradiction with annotations.

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

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

The description is compact: two sentences of purpose/guidance followed by a tight argument list. It front-loads the primary verbs and then provides exact parameter semantics without redundancy. 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 3-parameter, 9-action tool with no output schema, the description covers the state-changing purpose, all action keywords, parameter defaults, and the confirm flag. It doesn't explain nuances like when to choose emergency_stop over pause, but these are not essential for a correct first 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 0% and there are no enums, so the description carries the full burden. The Args section lists every allowed action value, explains the campaign_id default, and clarifies confirm's role. This adds substantial meaning to the bare 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?

The description lists a specific set of verbs ('Launch, pause, resume, archive, delete or emergency-stop a campaign') applied to a resource, and explicitly distinguishes itself from the read-only sibling campaign_status. This makes the tool's scope clear and separates it from alternatives.

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 clear context: 'Every action here changes what happens next' and points to campaign_status for watching or reading history. It does not explicitly mention create/edit siblings, but the state-changing framing is enough to guide the agent toward when to use this tool.

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 read-only behavior is already declared via readOnlyHint=true, and the description reinforces it with 'Changes nothing.' It adds useful detail about the 'Uses the active one if empty' fallback, but reveals little else about behavior such as output format or operational constraints.

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 compact and front-loaded: the first sentence establishes purpose and safety, and the Args section is neatly structured. Every sentence contributes meaningful information with no filler.

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

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

For a simple read-only tool with two optional parameters, the description is largely complete: it names both actions, explains defaults, and clarifies side-effect-free behavior. It loses one point because there is no output schema and the description does not hint at what the returned progress or history looks like, nor does it route the agent away from sibling status tools.

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

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

Schema description coverage is 0%, so the description carries the full burden of parameter documentation. It fully explains both parameters: action's allowed values ('monitor' vs 'status_history') and campaign_id's meaning plus default fallback behavior. This is exactly the compensation needed for a schema with no 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?

States a clear verb and resource: 'Watch a campaign run, or read its history of status changes.' It clearly identifies the tool's subject (campaign status) and read-only nature, but does not explicitly differentiate among sibling tools like scheduler_status or show_status.

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 communicates obvious contexts for use: monitoring active progress or reading status history. However, it does not mention when not to use it, prerequisites, or alternative tools, leaving usage guidance mostly implied.

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 goes well beyond the annotations by disclosing concrete side effects: marking invitations accepted, moving outreach to replied, storing messages, and setting opted-out in a way that stops all future outreach. It also explicitly states it sends nothing, which supports the readOnlyHint=false and destructiveHint=true annotations without contradicting them.

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 compact but information-dense: a one-sentence summary, a functional overview, and then the important side-effect and dependency details. Nothing is redundant, and the most critical behavioral constraints are front-loaded.

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

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

For a parameterless tool with an output schema, the description fully covers what the tool does, what it changes, what it does not do, and why it matters for follow-ups. The dependency warning about accepted invitations is especially valuable context an agent needs before invoking it.

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 carries no parameter semantics burden and the baseline is 4. The description notes no arguments and instead focuses on behavior, which is entirely appropriate for a 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 opens with a specific verb and resource: 'Read new LinkedIn replies and record what they mean.' It then details what it fetches, classifies, and lists, and distinguishes itself from siblings by noting it sends nothing and is the only path that notices accepted invitations.

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 clear context: this tool reads, records, classifies, and prioritizes replies, and is the only path that detects accepted invitations, making it essential for follow-ups. It does not explicitly name alternative tools or when-not-to-use conditions, so it stops short of full routing guidance.

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

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

Beyond readOnlyHint=true, the description discloses meaningful behavioral details: results are capped at 25 due to cost, nothing is filtered locally, and the distinction between 'no matches' and a failed search is explained. It also specifies that natural-language LinkedIn queries are passed through unchanged and usually return empty, which is critical for expected behavior.

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 front-loaded with the core purpose, then uses a clean 'Args:' block that maps directly to the schema. The longest section (query) earns its length by explaining the nuanced LinkedIn behavior. No sentences are 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?

The tool is complete for an agent: it explains when to use it, what it does not do, parameter semantics, error-reporting nuance, rate limits, and output formats. An output schema is present, so return values need not be described. The sibling routing is explicit.

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?

With 0% schema description coverage, the description compensates fully: all 10 parameters are documented. The query parameter receives extra depth, including literal LinkedIn keyword matching, example formats, a warning about natural-language queries, and cap behavior—all meaning beyond the schema's type and default fields.

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 opens with a specific verb and resource: 'Search, browse and read your contacts, and export them.' It also explicitly declares 'Changes nothing' and names the sibling with mutating operations ('Tagging, noting, re-staging and linking are update_contact'), making the tool's scope unmistakable.

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 routes mutations to a sibling: 'Tagging, noting, re-staging and linking are update_contact.' The read-only context is reinforced with 'Changes nothing.' While it doesn't say 'use this when you need to read contacts,' the inclusion of the alternative and the clear non-mutating scope leaves no ambiguity.

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?

Despite annotations providing readOnly and destructive hints, the description adds substantial behavioral detail: campaigns are drafts until explicitly launched, exclude_connections is ON BY DEFAULT with specific refusal behavior, the people path skips search and audit, and force overrides only mismatch verdicts. These are meaningful behavioral traits not visible in the schema or annotations, and they do not contradict them.

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 long but structured with clear paragraphs and an Args list, making it navigable. It front-loads the core behavior before diving into parameters. A few sentences are redundant or promotional ('Supports lead generation... AI-powered ICP-based targeting'), but overall length is justified by the tool's 13-parameter complexity.

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 the tool's complexity, the description covers prerequisites (project_brief on first campaign), defaults, combination rules, safety behavior (nothing sent until launch), and edge-case handling (force, partial verdicts, exclude_connections). An output schema exists, so return-value documentation is not required here. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 0%, so the description carries full responsibility for explaining all 13 parameters. It does so thoroughly: each parameter has a purpose, example, default, or constraint (e.g., target_description examples, voice_mode values, people format, exclude_connections inverse relationship to connections_only). This fully compensates for the schema's lack of 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 opens with a specific verb and resource: 'Create a LinkedIn outreach campaign from a natural language description.' It further clarifies the unique behavior—'saves a draft; nothing is sent until campaign(action='launch')'—which distinguishes it from send_message and edit_campaign. The scope is concrete and immediately understandable.

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 provides explicit use cases ('sales prospecting, recruiting...'), specific user-phrase triggers for parameter choices ('Use when user says "existing connections"'), and prohibitions ('Cannot be combined with connections_only'). It also names the generate_icp tool as an alternative source for icp_id, giving clear routing guidance.

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

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

Annotations provide readOnlyHint=false, destructiveHint=true, and openWorldHint=true. The description goes beyond these by clarifying the non-sending nature ('It edits settings only: it sends nothing and adds no prospects') and the temporal effect ('A change applies to the messages written from now on, not to ones already sent'). This adds meaningful context about side effects and scope without contradicting the annotations.

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

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

The description is long but appropriately so given 45 parameters. The opening is front-loaded with purpose and usage, and each parameter has a concise, meaningful explanation. While a few sentences could be tightened, every piece adds necessary value, so it earns a 4 rather than a 5.

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

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

Given the complexity (45 params, no schema descriptions, output schema exists but not detailed), the description is complete. It covers all parameters, usage, side effects, and cross-parameter interactions. 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 0% (no parameter descriptions in the schema). The description fully compensates by explaining each parameter's purpose, allowed values, defaults, and interactions (e.g., exclude_connections vs connections_only, campaign_type specifics, inmail_fallback tiers). This is far beyond the bare schema and provides critical guidance for correct invocation.

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 opens with a clear verb-resource statement: 'Change one running or drafted campaign's settings.' It also distinguishes itself from siblings by explicitly naming create_campaign for new campaigns and campaign(action=...) for launch/pause/stop. The scope is precise, and it differentiates from other campaign-related tools.

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 (rename, booking link, context, limits) and when not to: 'Use create_campaign for a new campaign, and campaign(action=...) to launch, pause or stop one.' It also clarifies the partial-update behavior and the side-effect boundary ('sends nothing and adds no prospects'), giving the agent clear routing guidance.

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

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

Annotations already mark readOnlyHint=false and destructiveHint=true, lowering the burden on the description. The description adds valuable behavioral detail beyond annotations: it explains that results are saved, can be reused via create_campaign(icp_id=...), and that decision_makers_only changes persona seniority levels. It does not clarify what destructive effect may occur, but it does not contradict the annotations either.

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 well structured, leading with the core purpose, then output characteristics, then reusable result, then a compact Args section. The only slight redundancy is the sentence listing overlapping capabilities such as 'buyer persona creation, ideal customer profiling, and B2B market research,' which adds retrieval keywords but little semantic value.

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 one required parameter, an output schema present, and moderate complexity, the description is effectively complete. It tells the agent what to pass, what each optional input does, what output to expect, and what happens to the result. The only minor omission is the unexpanded destructiveHint, but the annotations already flag that behavior.

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 carries the full burden, and it delivers. Every parameter gets a meaningful explanation with examples: target_description shows concrete phrasing, company_context explains its precision benefit, focus_query gives sample focus areas, and decision_makers_only spells out seniority levels plus when False is appropriate. This far exceeds what the bare schema provides.

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 a specific verb and resource: 'Generate a rich Ideal Customer Profile with buyer personas,' and goes further by specifying the shape of the output (2-4 personas with pain points, fears, barriers, LinkedIn search parameters, and confidence scores). It also distinguishes itself from siblings by noting the result is saved and reusable with create_campaign, so an agent can tell it apart from related tools like icp or campaign without inspecting 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 clearly communicates the broad applicability: buyers, candidates, research participants, hiring managers, investors, or partners. It also lists supported use cases like target audience analysis and customer segmentation. However, it does not explicitly state when not to use this tool or name alternative tools to prefer in specific situations.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces the read-only behavior by mentioning that drafted replies can be read and that write actions belong to answer_inbox. It adds useful behavioral context without contradicting the annotations, and no hidden side effects need to be disclosed for a read operation.

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 compact and well-structured: a direct purpose statement, a brief sibling-routing note, and a minimal argument list. Every sentence earns its place and there is no redundant 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?

All parameters are semantically documented, the read/write boundary is explicit, and the presence of an output schema means return values need not be described in prose. The only minor gap is the lack of detail on how chat_id and name interact or take precedence, but this does not prevent correct usage.

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 0% description coverage and no enums, so the description carries the full burden of explaining parameters. It defines all four: action with allowed values 'list', 'read', and 'comment_drafts'; chat_id as the conversation identifier; name for finding the conversation by person; and limit for display count. This fully compensates for the empty 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?

The description opens with a clear verb and resource: 'Read any conversation in your LinkedIn inbox, and the drafted replies.' It also explicitly distinguishes itself from answer_inbox, which handles replying, approving, and discarding drafts, so an agent can easily tell this tool apart from its closest sibling.

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 which actions belong to answer_inbox instead of this tool: 'Replying, approving a draft and discarding one are answer_inbox.' This gives a clear when-not-to-use condition and names the alternative, providing strong routing guidance without leaving the decision 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 indicate destructiveHint=truearen't a read-only tool. The description adds meaningful behavioral context beyond that: 'Closing with outcome="opt_out" stops all future contact' and 'confirm: Required where the action cannot be undone.' These are important side-effect disclosures. It does not detail exactly which actions are irreversible, so it is not a perfect 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?

The description is tight and well-organized: a leading summary sentence, a key behavioral caveat, a sibling disambiguation, then a compact Args list. There is no filler or repetition, and the most decision-relevant information appears first.

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 nine parameters and no schema-level descriptions, the description covers every parameter with at least some functional meaning, including active-campaign fallback and outcome-specific recording. It stops short of specifying which actions actually require confirm=true and leaves the skip-vs-dismiss distinction implicit, so some gaps remain for a fully autonomous agent.

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 carries the full burden of explaining parameters. It does this well with an Args section that glosses all nine parameters, including valid values for action and outcome)Skip: a 'skip', 'close' or 'dismiss'.

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 opens with a specific verb and resource: 'Skip a prospect, close one with an outcome, or dismiss it.' It clearly lists the three distinct actions the tool performs and explicitly distinguishes it from the read-only sibling: 'Reading a prospect is prospect_view.' This makes the tool's purpose 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?

The description names prospect_view as the alternative for reading, giving a concrete when-not-to-use hint. It also communicates the core use cases: skipping, closing with an outcome, or dismissing. It does not exhaustively compare against all sibling tools, but the primary ambiguity with prospect_view is resolved.

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

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

Annotations already declare readOnlyHint=true, and the description's 'Changes nothing' is consistent without adding much new behavioral information. It does add the actionable detail that campaign_id falls back to the active campaign, which is a useful behavioral nuance beyond the 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?

The main behavior is stated in one sentence, followed by a compact Args list. Every line earns its place; no filler or repetition.

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 simple read-only tool with an output schema present, the description covers the action choices and the key campaign fallback. Minor ambiguity remains around what happens when outreach_id is empty, but overall an agent has enough to invoke the tool correctly.

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

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

Schema coverage is 0%, so the description must carry the parameter meaning, and it does: action gets explicit enum-like values ('conversation' or 'timeline'), and campaign_id gets default-fallback semantics. outreach_id's 'Which outreach' is terse but sufficient to identify the parameter's role.

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 read verb, a single resource ('message thread with one prospect'), and an alternative view ('their timeline'), which clearly distinguishes it from the mutation/send siblings like send_message and update_contact. The 'Changes nothing' clause reinforces that this is a pure read operation.

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 read-only wording and the 'one prospect' scope imply when to choose this tool, but the description does not name alternatives or state when not to use it. It provides context for usage (viewing a conversation or timeline) without explicit exclusions.

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

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

Annotations already establish that this is not read-only and has destructive potential. The description adds useful behavioral context beyond that: turning it off halts sending until re-enabled, and the cloud/host arguments act on different scheduler scopes. It does not fully explain what each action value does, but it does not contradict the annotations.

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

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

The description is compact and front-loaded: the main purpose appears in the first sentence, the key caveat and sibling alternative appear next, and the parameter documentation is a tight bullet list. No sentence is wasted.

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 six parameters, zero schema-level descriptions, no enums, and a destructive hint, this is mostly complete. It scopes local vs cloud, explains the read alternative, and covers all arguments at a usable level. The main gap is that some action semantics are left implicit, but an output schema exists and the description is strong enough for an agent to invoke it correctly in most cases.

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 carries the full burden for parameter meaning. It explains every parameter, including allowed action values, the enabled flag, cloud scope, host selection, reporting interval, and campaign ID. However, a few action values like 'observe' and 'backfill_cloud' are named but not deeply defined, which keeps this from a 5.

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

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

The description starts with a specific verb and resource: 'Turn the autonomous scheduler on or off, or change how it runs.' It also distinguishes itself from the read-only sibling by stating that reading state, logs, activity, or diagnostics is scheduler_status, so an agent can tell the tools apart immediately.

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 routes read-oriented requests to scheduler_status: 'Reading its state, logs, activity or diagnostics is scheduler_status.' It also clarifies a key consequence of use ('Off means nothing sends until it is on again'), giving the agent both a when-to-use and a when-not-to-use signal.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds context that 'cloud' targets the hosted scheduler versus the local machine, and it clarifies that the daily-report action is handled by another tool. It doesn't disclose response behavior, pagination, or any limits, but this is acceptable for a read-only tool with an output schema present.

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 a single front-loaded purpose sentence followed by a tight argument list. Each line in the list adds necessary information with no fluff. The structure makes it easy for an agent to scan the purpose and immediately find the parameter semantics.

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 and annotations covering read-only safety, the description's remaining job is to define the parameters and scope—which it does completely. The only possible gap, the exact return shape of each action, is presumably covered by the output schema. An agent has everything needed to invoke this tool correctly.

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

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

Schema description coverage is 0%, so the description carries the full burden—and it succeeds. Every one of the five parameters gets a concrete semantic definition: action lists its allowed values, cloud explains local vs. hosted, hours defines the lookback window, and event_type/campaign_id specify filtering behavior. This is exactly the kind of compensation needed when the schema provides only titles and defaults.

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 opens with a specific verb and resource: 'Read the scheduler: status, logs, activity, diagnostics...' This clearly identifies the tool's scope and enumerates the sub-information it exposes. It also distinguishes itself from the sibling 'scheduler' tool by explicitly stating that the daily report belongs to that tool, eliminating confusion.

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 clearly explains the action parameter's valid values and the intended use case for each. It explicitly names the sibling scheduler tool as the correct alternative for daily-report toggling, providing a when-not-to-use note. However, it does not mention how this tool relates to other sibling read/status tools like show_status or campaign_status, so the guidance is not exhaustive.

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

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

Annotations already mark destructive and open-world effects, but the description adds concrete behavior: delete is limited to messages sent within 60 minutes, inmail fails closed if preconditions aren't met, text auto-generates if empty, and empty campaign_id uses the active campaign. These details go well beyond what annotations 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?

The description is organized into a clear Args block with each parameter on its own bullet and action-specific notes. Although detailed, every sentence carries task-relevant information and there is no filler or redundancy.

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

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

For a 5-parameter tool with no required parameters and an output schema, the description covers all parameters, defaults, destructive behavior, and action-specific preconditions. It leaves no input ambiguity and the output schema handles return-value documentation.

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%, and the description fully compensates by explaining every parameter: action's allowed values, campaign_id defaulting, outreach_id requirement, format meaning, and text auto-generation plus delete overload. This is exactly the semantic enrichment an agent needs.

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 ('Send') and resource ('follow-ups, replies, voice memos, or InMail to prospects') and enumerates distinct actions with clear outcomes. The LinkedIn context and action list make it distinguishable from sibling messaging tools like send_email.

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 decision rules: InMail is only for non-connections and lists fail-closed preconditions, while 1st-degree connections should use followup/DM. It also specifies when outreach_id is required, how campaign_id defaults, and which format applies to followup/reply.

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 aligns with annotations (readOnlyHint=false, destructiveHint=true) and adds substantial behavioral context beyond them. It explains that the tool analyzes LinkedIn profile and writing style to create a 'voice signature,' and that it performs LinkedIn automation setup and SDR onboarding. It also discloses the authentication requirement via a backend_jwt token and clarifies that no API keys are needed unless providing a custom LLM key. This fully prepares the agent for the tool's side effects and dependencies.

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 well-organized and front-loaded. It opens with a one-sentence summary, then a bolded requirement, a short explanatory paragraph, a clear 'First-time setup:' section with steps, and an 'Args:' section with bullet points. Every sentence earns its place; no fluff or redundancy. The structure aids quick comprehension for an agent.

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 the tool's complexity (external login, token acquisition, multiple configuration options), the description is remarkably complete. It covers prerequisites, exact steps, parameter semantics, and the tool's role in the broader system. The presence of an output schema (indicated by 'has output schema: true') means return-value documentation is not required in the description. Nothing an agent needs to invoke 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 0%, so the description carries the full burden, and it excels. Each parameter is explained: llm_api_key as optional with purpose, llm_provider with explicit allowed values, backend_url with a default behavior, and backend_jwt as the authentication token with instructions on how to obtain it. This is more than sufficient for an agent to fill the arguments correctly.

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 clear specific purpose: 'Set up HeyLead by connecting your LinkedIn account and analyzing your writing style.' It further distinguishes this from siblings by detailing it handles 'LinkedIn automation setup, SDR onboarding, account connection, and voice analysis' and explicitly marks it as 'REQUIRED for first-time users — must be called before any other tool.' No ambiguity remains.

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 provides explicit when-to-use guidance: 'REQUIRED for first-time users — must be called before any other tool.' It also gives a step-by-step walkthrough: sign in at a specific URL, connect LinkedIn, copy the setup message, and call the tool with the token. It notes 'No API keys needed on the hosted backend,' which preempts a common question. There is no need for alternative tools since this is a mandatory one-time setup.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context by disclosing that hosted accounts receive a dashboard link and snapshot card, and that the link must be relayed because some clients show the image only to the model. This goes beyond the annotations without contradicting them.

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 well-structured and front-loaded with the core purpose. It includes a useful relay caveat and parameter documentation without excessive padding. The conversational phrasing ('Ask how's my outreach anytime') is functional but slightly loose, keeping it from a 5.

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

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

For a simple tool with one optional parameter and no output schema, the description covers the dashboard contents, hosted-account behavior, and parameter semantics. It does not describe the exact shape of stats or error cases, but these are minor for this simple read-only 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%, so the description must fully explain the parameter. It does: 'campaign_id: Show stats for a specific campaign. Shows all if empty.' This clarifies the optional single parameter's behavior and default semantics completely.

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 clear verb and resource: 'Show your outreach dashboard' with concrete contents like campaigns, stats, hot leads, and account health. It is more specific than the tool title but does not explicitly distinguish itself from the sibling 'analytics' tool, so it falls short of full differentiation.

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

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

The description gives clear usage context: the chat is the 'front door' to the dashboard and users can ask 'how's my outreach?' anytime. This implies broad, on-demand use but does not state when to prefer another tool or mention exclusions, so it lacks explicit routing guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, which cover safety. The description adds valuable behavioral details: hosted accounts receive a dashboard link and snapshot card, the link should be relayed due to client rendering, and recommendations follow an explicit priority order. This goes beyond the annotations without contradicting them.

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 appropriately sized, around 70 words, and front-loads the core purpose. The hosted-accounts caveat is necessary operational detail. There is slight redundancy between 'Analyzes all active campaigns' and 'Analyzes all active if empty,' but it does not hurt clarity.

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 one-parameter, read-only suggestion tool with no output schema, the description covers purpose, input semantics, prioritization logic, and output hints (dashboard link and snapshot card). It could more concretely describe the structure of the returned recommendation, but it is complete enough for an agent to invoke and interpret the result.

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

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

Schema description coverage is 0%, so the description must compensate. It fully does for the only parameter: 'campaign_id: Focus on a specific campaign. Analyzes all active if empty.' This defines both the parameter's meaning and its empty-value behavior, which is complete and actionable.

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 opens with a clear verb and resource: 'Suggest the best next action for your outreach.' It further specifies scope by saying it analyzes all active campaigns and prioritizes by impact. It does not explicitly contrast with sibling tools like scheduler or check_replies, so it stops short of full sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It explains behavior and the campaign_id parameter, but never states when to prefer this tool over siblings such as scheduler or check_replies, nor does it give any exclusion criteria. The only instruction, about relaying the dashboard link, is post-invocation rather than selection guidance.

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

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

Annotations already mark the tool as destructive (destructiveHint=true) and non-read-only, and the description adds the safety-relevant dry_run behavior: 'Show what would change without changing it.' It does not contradict the annotations and provides useful context beyond them.

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 compact and front-loaded: first the purpose, then the routing instruction, then a terse Args block. No redundant preamble or repetition of the schema's default values.

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 8-parameter mutation tool with an output schema and a destructive annotation, the description covers the core decisions: which action, which contact, and dry_run semantics. It falls slightly short on explaining the 'enrich' action and the behavior of 'match', leaving some agent uncertainty for those less common cases.

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 Args list is essential; it explains all 8 parameters and enumerates the allowed action values, which the schema leaves as a bare string. The main weakness is that 'match' is only glossed as 'How to match when linking' and 'enrich' is not explained, but the description still compensates for the schema's lack of parameter 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 opens with a specific verb and object—'Change one contact'—and enumerates the five supported mutations (tag, note, stage, link, enrich). It also explicitly contrasts itself with the read/search workflow by naming the contacts sibling tool, 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?

It gives a clear when-not instruction: reading and searching contacts is the contacts tool, not update_contact. It does not spell out additional exclusion conditions relative to other mutation siblings such as edit_campaign, but the routing context is sufficient for the common case.

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