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

Annotations already indicate read/write and destructive behavior, so the description doesn't need to restate that. It adds useful behavioral context beyond annotations: connect_email uses Unipile hosted auth, refresh_tier 'heals' stored tier flags, and unlink disconnects the current account. This gives an agent a clearer model of side effects 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 well-structured and scannable: a one-line purpose, formatted argument explanations, and a critical warning. Every line adds information, and the format makes the six action variants easy to parse without unnecessary prose.

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

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

For a multi-action tool with an output schema and rich annotations, the description covers all actions, argument requirements, the default behavior, and a hard constraint ('Never use Mail.app'). Nothing essential for calling the tool correctly appears to be 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 of explaining parameters. It fully enumerates all action values with plain-language meanings and explains account_id as the Unipile account ID with a clear required condition. This is exactly what the schema lacked.

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 action and resource: 'Manage your LinkedIn accounts' and enumerates concrete operations (list, switch, disconnect). The list of action values makes the tool's scope easy to grasp and distinguishes it from the many messaging/prospecting siblings, though the opening phrase doesn't mention the email-account aspect covered by connect_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 provides operational guidance for the action argument, notes that 'list' is the default, says account_id is required for switch_to, and warns 'Never use Mail.app'. However, it does not explicitly say when to choose this tool over alternatives or when not to use it, relying instead on the action list to imply usage.

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 declare destructiveHint=true and readOnlyHint=false. The description adds value by clarifying the destructive action is sending DMs and provides a dry_run safety mechanism. It does not contradict annotations and discloses the side effect clearly. It omits other behaviors like rate limits, but that is minor given the explicit safety control.

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 concise, with a clear opening summary followed by a bullet-style argument list. Every sentence earns its place; there is no fluff. The main purpose is front-loaded, and the parameters are logically grouped. It is appropriately sized for the tool's 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?

The tool has an output schema, so return values need not be described. The description covers the workflow (scan, classify, send), parameter semantics, and the dry_run/send_only usage pattern. For a tool with side effects and four optional parameters, this is complete. Nothing critical 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?

Schema coverage is 0%, so the description carries the full burden. It explains each parameter: limit (max conversations), dry_run (classify only, don't send), min_confidence (threshold for sending), and send_only (skip scan, process already-classified signals). This goes beyond the schema's bare names and defaults, making parameter usage unambiguous.

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 ('process'), a specific resource ('unreplied LinkedIn inbox messages'), and a specific outcome ('classifies each message and sends discovery DMs'). It clearly differentiates from siblings like check_replies by focusing on backfilling unreplied conversations. No 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?

The description gives explicit usage flow: run with dry_run to classify, then set send_only to send without re-scanning. It explains when to use each flag. However, it does not explicitly mention alternatives (e.g., 'use check_replies to just check replies'), so it lacks direct sibling differentiation. Still, the intended use is clear.

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 mark the tool as mutating, destructive, and open-world; the description adds meaningful behavioral context by specifying exactly which actions write to the profile and by documenting the local-posting limitation and cloud-owned-seat text-only constraint. It does not discuss reversibility or permissions, but the action list makes the mutating behavior clear.

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 justified by the breadth of actions. It is front-loaded with the core value proposition and organized as an Args block with useful details like folder naming conventions and cloud-vs-local behavior. The dangling 'makeover' mention adds minor confusion but does not undermine the overall structure.

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 complex multi-action tool with a bare input schema, the description covers almost everything an agent needs: action semantics, focus/photo reuse, folder naming rules, and an important posting caveat. It does not mention prerequisites like a connected LinkedIn profile or fully define the unreferenced 'makeover' flow, but output schema presence reduces the need for return-value detail.

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 carries the full burden of parameter meaning and mostly succeeds: action is documented as an enum-like set of behaviors, focus is polymorphically defined per action, and photo is explained as a file path or base64 value. The unexplained reference to a 'makeover' action that is not defined in the action list is a notable gap.

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 mission: analyze and improve the user's LinkedIn personal brand to drive leads. It enumerates concrete action modes such as analyze, plan, execute, and progress, making the tool's scope clear. However, it does not explicitly differentiate itself from nearby sibling tools like setup_profile or create_post.

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 implies use for personal-brand strategy work and provides useful internal routing guidance, such as using set_headline/set_summary when the user already decided the wording versus model-generated copy. It never names alternatives or states when NOT to use this tool, leaving tool-level boundaries to inference.

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

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

Beyond the annotations, the description reveals important behavioral traits: delete is permanent, emergency_stop pauses ALL active campaigns, repair_queue drops rows below min_fit_score, monitor sends nothing, and hosted accounts produce a dashboard link/snapshot that must be relayed. This is rich, non-obvious context with no contradiction to 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 every line earns its place: it front-loads the tool's purpose siege, includes a scannable action list, and adds only the hosted-account note and parameter details that are needed. The structure is clear and efficient 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 multi-action lifecycle tool with no output schema, the description is remarkably complete. It covers all actions, safety requirements, prerequisite scheduler calls, and even hosted-account behavior. An agent should be able to call this tool correctly across all listed scenarios.

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 has 0% description coverage and no enums, so the description carries the full burden. It documents every action value with operational meaning, explains campaign_id auto-selects when empty, and clarifies confirm is a safety guard for delete. This fully compensates for the bare input 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 uses a specific verb phrase, 'Control campaign lifecycle', and enumerates concrete operations such as launch, monitor, pause, resume, archive, delete, emergency stop, and retry failed. It also references create_campaign's draft state and scheduler requirements, which helps distinguish this tool from related 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 clear sequencing context: launch is required after create_campaign, hosted accounts need the cloud scheduler, monitor requires scheduler(action='observe'), and delete requires confirm=True. It does not explicitly state when to prefer edit_campaign or other siblings, but the action-by-action guidance is strong enough for correct invocation.

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 readOnlyHint=false and destructiveHint=true, and the description adds useful behavioral detail about sentiment classification and hot-lead surfacing. However, it does not disclose what destructive or state-changing behavior may occur—'conversation management' is vague and leaves the destructive hint unexplained. It does not contradict the annotations, but it undersells 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 first two sentences are front-loaded and informative. The third sentence, 'Handles inbox monitoring, lead response tracking, and conversation management,' repeats earlier ideas and introduces vague, low-actionability language. It is not overly long, but not 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 tool with an output schema, the description covers the primary purpose, scope, and key outputs. The main gap is clarifying the destructive consequences implied by destructiveHint=true; without that, an agent might assume this is a passive read-only checker. More explicit mention of side effects would make it 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 input schema has zero properties, so schema coverage is trivially 100% and there is no parameter burden for the description to carry. The tool takes no arguments, so a baseline of 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 opening sentence clearly states a specific verb ('Check') and resource ('new LinkedIn replies across all campaigns'). It also lists tangible outputs like sentiment classification and hot leads, so an agent can recognize this as an inbound-monitoring tool. It does not explicitly differentiate from sibling tools such as inbox or backfill_inbox, so it misses the top score.

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 implies the tool is for monitoring new messages and surfacing leads needing attention, which gives reasonable context. However, it never states when to prefer this tool over alternative siblings, nor does it mention exclusions or prerequisites. The usage guidance is implied rather than explicit.

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 far beyond the annotations, disclosing rate limiting and pacing behavior for linkedin_search ('spends up to a fixed wall-clock budget waiting between fetches... Expect tens of seconds'), the dry-run default and apply behavior for 'link', the cap on 'limit' at 25 for linkedin_search, and the edge case where connections synced before dates were recorded match neither date filter and are counted in the result line. It also explicitly states that an empty result and a failed search are reported in different words, which is crucial for interpreting results. No contradiction with the readOnlyHint=false, destructiveHint=true 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 lengthy but appropriately so for a tool with 11 actions and 14 parameters. It is well-structured with an opening summary followed by a clear Args block, and each line earns its place by adding operational detail. It could be slightly tighter, but the verbosity is justified by the complexity and the need to communicate important behavioral caveats.

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

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

Given the tool's complexity, the description is exceptionally complete. It covers all actions, all parameters, defaults, side effects, rate limiting, and edge cases. Since an output schema exists, return-value explanation is unnecessary, and the description focuses on what the agent needs to call the tool correctly. The only minor gap is that the 'enrich' action is not detailed beyond its query parameter, but this is negligible against the completeness elsewhere.

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 description coverage, so the description carries full responsibility for all 14 parameters. It does this thoroughly in the Args section: each parameter is explained with its purpose, defaults, and action-specific nuances, such as query being passed to LinkedIn as keywords, match supporting only 'name' with exact case-insensitive matching, dry_run defaulting to true and writing nothing, and connected_since/connected_before affecting only dated connections. 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 specific verbs and a resource: 'Search, browse, and manage your global contact base.' It then explains the unique value proposition: one master record per person across all campaigns, with full interaction history, tags, notes, lifecycle stages, and prospect pools, plus direct LinkedIn search without creating a campaign. This clearly distinguishes it from campaign-specific and other sibling 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 gives clear context for when to use each action, such as 'view' for full cross-campaign history and 'linkedin_search' for searching LinkedIn directly without a campaign. It implies alternatives between actions (e.g., 'search' for internal contacts vs 'linkedin_search' for external), though it never explicitly states 'use this tool instead of X' or lists exclusions. The action-level guidance is strong enough for an agent to pick the right route.

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 carry only readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the description carries the behavioral burden — and it delivers: drafts are saved and nothing is sent until launch; exclude_connections is ON by default with refusal-at-enrolment semantics; force can bypass an ICP audit mismatch while partial verdicts only warn; mode is always autopilot. Nothing in the description contradicts the annotations; the disclosed mutation aligns with destructiveHint=true.

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

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

Front-loading is strong: the first two sentences state the verb, resource, and the critical no-send safety fact. But the description pads with redundant material — 'Describe your ideal customers and HeyLead will find them on LinkedIn' is marketing filler that repeats the opener, and the capability list ('lead generation, prospect discovery, SDR automation…') substantially duplicates the earlier use-case enumeration. Not every sentence earns its place, though the sheer length is largely justified by a complex 12-parameter tool with zero schema coverage.

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 destructive, open-world, 12-parameter tool with 0% schema coverage, the description is remarkably complete: all parameters explained, safety behavior disclosed, prerequisites stated (project_brief required before launch), and the launch hand-off specified. The output schema covers return values, so nothing an agent needs to invoke this tool correctly is 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?

Schema coverage is 0%, so the description must compensate fully — and it does: every one of the 12 parameters gets meaning beyond name/type/default, with examples (target_description), cross-tool references (icp_id from generate_icp), interaction constraints (exclude_connections cannot combine with connections_only), trigger phrases ('DM my network', 'cold only'), and default behavior (exclude_connections ON BY DEFAULT). This is exactly the compensation the 0% coverage baseline demands.

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?

Opens with a specific verb+resource statement: 'Create a LinkedIn outreach campaign from a natural language description,' then immediately draws the boundary with 'saves a draft; nothing is sent until campaign(action="launch").' This cleanly separates it from send-type siblings like generate_and_send and send_message, and from the launch tool campaign, without needing to open any schema.

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

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

Provides concrete use cases (sales prospecting, recruiting, research, networking, vendor scouting, event invitations) and explains the draft-then-launch workflow, pointing at campaign(action='launch') as the follow-up step and generate_icp as an input source. It never explicitly states when not to use it or names alternatives such as edit_campaign or engage_prospect, so the guidance is clear context without formal 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 signal read/write and destructive behavior; the description adds valuable behavioral specifics: image is attached on LinkedIn only, a tweet is posted without it, file format/size limits, and mode 'autopilot' publishes immediately. This goes beyond the structured fields.

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

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

The main purpose is front-loaded and the Args block is scannable. The sentence 'Builds authority and drives inbound connections across platforms' is promotional rather than informative, but it is brief and does not obscure the operational details.

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 publish action, the description covers what to post, tone options, platforms, image behavior, and immediate publishing. An output schema exists, so return-value details aren't required. The only notable gap is the missing mode parameter in the schema, which leaves some ambiguity about whether that argument can actually be passed.

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 Args block compensates by giving valid tone values, comma-separated platform syntax, topic examples, and image constraints. However, it documents a mode parameter that is absent from the input schema, which could confuse invocation, so it's not a perfect 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?

Description opens with a specific verb-resource pair: 'Generate and publish a voice-matched post to LinkedIn, X/Twitter, or both.' This clearly distinguishes it from message/email tools and even names the target platforms, so the agent knows exactly what the tool is for.

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 ('Creates posts using your voice signature for social selling', 'Builds authority and drives inbound connections') and concrete topic examples for when to use it. It doesn't explicitly compare against sibling tools like generate_and_send or send_message, but the LinkedIn/X platform scope makes the context unambiguous.

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 write and destructive capabilities (readOnlyHint false, destructiveHint true), so the description's job is to add context. It does: it mentions 'Tracks sync status to avoid duplicates' (implying idempotency), 'Includes conversation history as notes' (additional side effect), and 'The key is saved for future syncs' (a persistent side effect). These go beyond the raw annotations, providing valuable behavioral disclosure 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 moderately lengthy but every sentence adds necessary information: purpose, behavior, setup instructions, and parameter details. The main action is front-loaded, followed by a structured args section. While slightly verbose, it is efficient and not tautological. It earns a 4 for clarity despite not being ultra-terse.

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 all essentials for an agent to call the tool: what it does, when to use it (CRM integration, pipeline sync, lead handoff), how to set up (public app token), and what each parameter means. Since an output schema exists, it need not describe return values. The only minor gap is not mentioning potential side effects on existing HubSpot data (e.g., whether re-syncing updates or overwrites), but the 'avoid duplicates' note partially covers this. Overall, it is complete enough for correct invocation.

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

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

Schema description coverage is 0%, so the description carries the full burden. It explains each parameter: campaign_id (defaults to most recent), filter (with 'won' default and enumerated options 'hot_leads' and 'all'), and hubspot_api_key (optional, only needed first use, saved). This exceeds the schema's bare defaults and types, giving the agent actionable semantics for invoking the tool 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 clearly states the verb 'Sync' and the resource: 'campaign contacts and deals to HubSpot CRM'. It goes further to specify the types of data pushed ('won deals, hot leads, or all contacts') and the target ('as contacts + deals'). This distinguishes it from sibling tools that might handle other CRM or messaging functions. The purpose is unambiguous and specific.

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 clear context on when to use: for CRM integration, deal pipeline sync, and lead handoff to sales teams. It gives setup prerequisites and specifies that the API key is only needed on first use. However, it does not explicitly name alternative tools or state when not to use this tool, which would be needed for a 5. It implies usage rather than contrasting with alternatives, so a 4 is appropriate.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true), the description enriches behavioral understanding with specific side effects: it notes that mode only supports 'autopilot' and that 'Copilot mode removed', explains mutual exclusivity between exclude_connections and connections_only, and details conditions like 'Required before launch, resume, or auto-send'. These are useful context not present in the structured 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?

Despite being long, the description is tightly structured: a one-sentence summary followed by a consistent bullet list of arguments. Every sentence earns its place because each parameter requires explanation; there is no fluff or repetition. The formatting (Args with code-style parameter names) improves scannability and makes the tool practical 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?

For a tool with 45 parameters)Skip pre-existing chunks of text. For a tool with 45 parameters, no schema descriptions, and a destructiveness annotation, the description is exceptionally thorough. It covers every parameter, including valid values, defaults, cross-parameter dependencies, and contextual prerequisites (e.g., project_brief required before launch). An output schema exists, so return-value documentation is not needed here.

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, so the description carries the entire burden for 45 parameters. It does so comprehensively: each parameter lists allowed values, defaults ('Leave empty to keep current'), example formats, and behavioral nuances (e.g., 'When off, campaign only DMs existing connections'). 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 action-resource pairing ('Edit a campaign's name, mode, booking link, or context fields') and is clearly distinct from sibling tools like create_campaign. It explicitly names the resource ('campaign') and the operation ('edit'), with no ambiguity about what the tool does.

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 implies its use for modifying existing campaigns, but it does not explicitly state when to prefer this tool over alternatives like create_campaign or campaign. It provides no exclusion conditions or 'use this instead of X' guidance, leaving the agent to infer the intended scenario from the 'edit' verb.

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 this is not read-only and has destructive potential. The description adds valuable behavioral detail beyond that: it generates a voice-matched comment, sends reactions, and explains that follow/endorse trigger LinkedIn notifications. This gives an agent a realistic sense of external 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 well-structured: a one-line summary, a behavior overview, usage context, and a clear Args section. It is somewhat long, but nearly every sentence adds necessary information since the schema itself provides no parameter documentation.

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 three optional parameters, the description covers all parameter semantics, core behavior, action variants, and the intended social-selling context. An output schema exists, so return-value documentation is not required from the description.

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 parameters. It clearly explains campaign_id, outreach_id, and every action value including edge behavior like 'auto' choosing comment vs reaction and 'Uses active campaign if empty.' 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 leads with concrete verbs tied to a clear resource: 'Comment on, react to, follow, or endorse a prospect on LinkedIn to build trust.' This clearly distinguishes engage_prospect from sibling tools like send_message or send_email, which are about direct messaging rather than public LinkedIn engagement.

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 for when to use the tool: 'Great for social selling, warm-up engagement, and building familiarity before cold outreach.' It also explains different action modes and their purposes, but it does not explicitly name alternative tools or state when not to use this tool, so it stops short of a 5.

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 the operation as destructive and not read-only; the description adds meaningful operational detail: it sends automatically after validation, never sends failed-validated messages, and may queue for review. This gives the agent a clear behavioral model beyond the simple send intent.

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, with the core action in the first sentence and supporting behavior (validation, queueing, campaign selection) in short follow-ups. No sentence is wasted, and the Args block is clearly separated.

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 tool with an output schema and destructive annotations, the description covers the essential workflow: generation, sending, validation, and campaign selection. It does not explain what 'queue for review' entails or how to choose between this and sibling send tools, but these are secondary to making the call.

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 only parameter, campaign_id, has no schema description, leaving 0% schema coverage. The description's Args section fully compensates by stating what it selects and what happens when empty (uses the active campaign), which is exactly the behavioral nuance 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 action: generate and send a personalized LinkedIn message, with an explicit queue-for-review option. It clearly covers cold outreach, connection requests, and invitations, but it does not name or contrast sibling send tools like send_message or send_email, so differentiation is implicit rather than explicit.

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

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

The description implies when to use the tool: when you want a generated LinkedIn message sent automatically after validation. However, it provides no when-not-to-use guidance or alternatives, which is a notable gap given a large sibling set that includes send_message, send_email, and create_campaign.

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 state readOnlyHint=true and openWorldHint=true, but the description adds meaningful behavioral detail beyond that: it creates no campaign, no outreach records, and no contacts; it always fetches one full page from LinkedIn regardless of limit; and goal_match runs no search at all. These details are not derivable from the annotations or schema and materially shape invocation expectations.

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 a short use-case sentence, then a compact args list. Every sentence earns its place: even details like 'the search always fetches one full page regardless' and 'Leave empty to list your saved ICPs' add operational value. The structure separates prose from parameters cleanly, making it scannable 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?

For a two-action tool with six parameters, the description covers all invocation paths: preview behavior, goal_match behavior, optional campaign_id, fallback target_description, empty icp_id behavior, and per-action outputs. An output schema exists, so return-value documentation is not necessary. There are no missing operational details that would prevent an agent from invoking 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 for all 6 parameters. It does this thoroughly: action has both values explained, icp_id notes that it may be empty to list saved ICPs, persona has a 1-based default and explains multiple personas, limit constrains range and behavior, and campaign_id and target_description are gated to goal_match with fallback semantics. This 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 opens with a specific verb-resource pair: 'Preview a saved ICP against LinkedIn, or audit it against a campaign goal, without creating anything.' It clearly distinguishes itself from create_campaign by explaining it runs the same search but creates no campaign, outreach records, or contacts. The two actions, preview and goal_match, are explicitly defined.

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 it when the targeting is unproven or when someone asks for example profiles for an ICP.' It also names create_campaign as the alternative tool and explains the key difference: this tool does not create anything, so ICPs can be checked and rejected without cleanup. This effectively tells an agent when not to use the mutation 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?

Despite annotations marking destructiveHint=true, the description goes further: it discloses that every row gets a disposition, partial imports are never reported as success, csv_data silently loses data that doesn't fit, and dry_run skips LinkedIn enrichment while still reading the connection list. This adds significant context beyond the annotations and prepares the agent for failure modes.

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 with a clear intro paragraph followed by a bulleted Args list. Every sentence serves a purpose: it explains the import pipeline, the disposition guarantees, and the parameter semantics. The structure front-loads the core purpose and then drills into specifics, with 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?

The tool has an output schema (not shown here) that presumably covers return values, so the description doesn't need to detail them. For everything else an agent needs to call this correctly, the description covers: input formats, column requirements, deduplication behavior, dry-run semantics, and the trade-offs between csv_data and file_path. It is complete for a complex import operation.

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 entire burden for parameter meaning. It does so thoroughly: each parameter (campaign_id, csv_data, linkedin_enrich, file_path, sheet, dry_run) gets a purpose, a default, and usage nuance. For instance, it clarifies that csv_data is ignored if file_path is given and that sheet defaults to the first worksheet. 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: 'Import prospects from a CSV/XLSX file into a campaign.' It then explains the full pipeline (parse, dedupe, score, add) and distinguishes itself from siblings by focusing on bulk ingestion. This leaves no ambiguity about what the tool does.

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 clear guidance on parameter choices: 'prefer file_path' over csv_data, csv_data for 'a handful of rows', and dry_run for previewing without side effects. It does not explicitly name alternative tools for other use cases, but the context of campaign management makes the intended usage clear. The exclusion of large paste-through is explicit ('must never be pasted').

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 includes actions that send messages (reply, approve_draft) and discard drafts, which are clearly mutating operations. Yet the annotations declare readOnlyHint=true, which contradicts the described behavior. This is a serious inconsistency that undermines trust in the tool's safety profile.

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 with a clear action list and parameter explanations. It is somewhat long but every sentence adds value, and the main purpose is front-loaded. The structure makes it easy to scan and reference.

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 all actions and parameters, including special cases like drafts. It also clarifies the tool's scope. Given the presence of an output schema, it does not need to describe return values. It is sufficiently complete for an agent to invoke correctly, aside from the annotation contradiction.

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 fully compensates by explaining each parameter's role and constraints. For example, chat_id is defined as 'Chat ID to read (from list output). For 'read' and 'reply' actions. For 'approve_draft' and 'discard_draft', the draft id.' This adds crucial meaning beyond the bare schema 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 clearly states the tool browses and reads LinkedIn inbox messages, and enumerates specific actions (list, read, reply, comment_drafts, etc.). It distinguishes from the general inbox concept but does not explicitly compare to sibling tools like backfill_inbox, so it is not a full 5.

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 context that it works on any conversation, not just campaign contacts, which hints at scope. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it. The action-specific notes (e.g., drafts require approval) are useful but do not constitute tool 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 declare readOnlyHint=true, and the description strongly reinforces this with 'never writes' and 'does not send, book, replan, or change outreach state.' It adds material behavioral context beyond annotations: the data source is the local log, and the 'journal' action has a self-hosted vs. cloud distinction. No contradiction exists.

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 tightly organized: a front-loaded summary, explicit exclusions, then a structured Args block. Every action entry earns its place because it maps directly to a use case. No fluff or repetition is present.

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 eight distinct display modes and the presence of an output schema, the description is complete. It covers each action's contents, filter semantics, limits, defaults, and even the self-hosted caveat. There is no missing operational context an agent would need 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 full responsibility. It explains every parameter: 'action' with all eight enumerated values and meanings, 'campaign_id' and 'outreach_id' as optional filters, and 'limit' with range and default. This fully compensates for the sparse 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 precise verb and resource: 'Read-only digest of what the in-process agents decided.' It immediately distinguishes itself from sibling tools by stating 'never writes' and enumerating the exact decision types it surfaces (holds, replans, closer decisions, skips, jobs). An agent can tell this apart from tools like show_status or analytics 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 provides explicit when-to-use guidance: 'Use it when someone asks what the agents did, who is held, why a reply was skipped, or why a campaign is not sending.' It also gives clear exclusions: 'It does not send, book, replan, or change outreach state,' which prevents misuse. This is exemplary 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 only flag readOnlyHint=false, destructiveHint=true, and openWorldHint=true. The description goes far beyond this: it details deletion of sources, background vs. blocking refresh behavior, a backend restriction on sync scope 'all', the need to re-run list to see chunk counts, and the effect on agent claims. 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 well-organized, front-loaded with purpose, then structured as a clear Args list. Every sentence provides actionable information; no filler or redundant phrasing. It is long because the tool is complex, but each line 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?

With 11 parameters, zero schema descriptions, an output schema present, and complex behavioral nuances, this description covers all bases: parameter semantics, edge cases (blocking sync restriction), and expected follow-up actions. Nothing an agent needs to invoke the tool correctly is missing.

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

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

Schema coverage is 0%, so the description carries the entire semantic burden. Every one of the 11 parameters is explained with its role, valid values (for action, scope, kinds), requirements (text required for 'add'), defaults (top_k=6 clamped to 1-50), and behavior (sync false queues background job). 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 specific verb+resource combination: 'Curate the knowledge base that grounds generated messages.' It enumerates the four kinds of sources and explains their role, distinguishing this tool from all siblings (scheduler, send_message, etc.) 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?

The description gives clear context by stating that message generation quotes the knowledge base, implying when curation matters, and enumerates five action verbs covering the main use cases. It does not explicitly name alternatives or provide 'use this instead of X' guidance, but none of the sibling tools overlap with this functionality, so a 4 is appropriate.

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 destructiveHint=true and readOnlyHint=false, so the mutating nature is covered. The description adds useful behavioral context by explaining that watchlists are monitored on LinkedIn and auto-created with ICP generation. However, it does not spell out the consequences of actions like 'remove' or 'pause' beyond their names, but the annotation set 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?

The description is front-loaded with a crisp summary, followed by a short context paragraph and a well-organized Args list. Every line provides useful information without filler. It is somewhat long but justified by the tool's six parameters and the need to compensate for empty schema descriptions.

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 six parameters and all five actions are covered, including which parameters apply to which action. The context about LinkedIn monitoring and ICP auto-creation is helpful. It does not explicitly state defaults or edge-case behavior, but an output schema exists and the parameter guidance is otherwise comprehensive.

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 block carries the full burden. It explains every parameter, maps each to the relevant actions, enumerates valid values for action and watch_type, and gives a concrete keywords example. 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: 'Add, remove, and list signal keyword watchlists.' It clearly defines what watchlists are, what they monitor, and how they relate to ICP generation. This makes it easy to distinguish from sibling tools like generate_icp or signals.

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 clear context for when the tool is relevant: managing watchlists that monitor LinkedIn buying signals. It also notes that watchlists are auto-created during ICP generation, which helps an agent understand when manual management is needed. It does not explicitly name alternative tools, but the domain context is strong enough to guide 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?

The description discloses reciprocity requirements, membership gating, refusal of members-only actions, the consequence of opt_out, admin-only capabilities, and the fallback to the workspace's own seat. These details go well beyond the annotations and explain how the tool's side effects and access constraints actually manifest.

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 it earns its length: the concept is front-loaded, the action list is organized, and each argument is tied to specific actions. It avoids filler while covering a genuinely complex 15-action, 10-parameter API surface.

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?

Together with the existing output schema, the description provides everything an agent needs to decide membership status, join/leave the pool, and invoke the correct members-only action with the right parameters. Edge behaviors like non-member fallback to the workspace's own seat are also covered.

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

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

Schema description coverage is 0%, but the description's Args section fully compensates by explaining all 10 parameters, enumerating every action value, and adding useful format details such as comma-separated LinkedIn IDs, industry:seniority segments, confidence range 0.0-1.0, and cache-refresh behavior.

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 defines this as an action dispatcher over a reciprocal LinkedIn network pool, with a precise list of 15 actions spanning membership, admin, and members-only intelligence operations. It goes far beyond the generic tool name and establishes a distinct resource that no sibling appears to duplicate.

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 strong usage context: members-only actions are refused until joining, joining requires opt_in then sync, and status reports participation. It does not explicitly name sibling alternatives, but the action-level guidance and membership precondition are clear enough for an agent to know when and how 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 annotations already indicate readOnlyHint=false and destructiveHint=true; the description adds one useful behavioral fact (switching organizations does not sign the user out). However, it does not explain consequences of destructive actions such as remove_member, and it omits details about what gets deleted or changed beyond the action names.

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 with the purpose, followed by a short usage context and an Args list. Every line conveys a distinct fact with no filler, making it easy for an agent to parse quickly.

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 polymorphic tool with 5 parameters and 0% schema coverage, the description covers all actions and parameter semantics, and there is an output schema to handle return values. It is slightly ambiguous about which parameters are ignored for each action and what the 'members' action requires, but it is otherwise sufficiently 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 coverage is 0%, and the description fully compensates: the Args block explains each parameter's role, valid action values, and conditional requirements (org_id required for switch, email doubles as invitee email or new org name, role is editor/viewer, user_id is for remove_member). This gives an agent everything needed to assemble a correct call.

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 specific actions ('List, switch, or manage hosted HeyLead organizations') and an explicit action list, so an agent can identify the resource and main operations. It does not explicitly contrast itself with sibling tools like account or contacts, and 'manage' is broad, so it is clear but not a 5.

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 explains when to use the tool: 'Use this to work across client workspaces' and clarifies that the person stays signed in while the active organization changes. It does not mention alternative tools or exclusion conditions, so it stops short of a 5.

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 non-read-only and destructive; the description adds important side-effect context by disclosing auto-sent email reminders with an escalating cadence (1, 3, 7, 14, 21 days). It also distinguishes 'complete' from 'cancel', though it does not specify whether cancel permanently deletes data.

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 opens with a one-line purpose, adds a focused context paragraph, and then uses compact bullet-style Args entries. It is reasonably long but every line contributes necessary dispatch information.

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

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

Covers all nine parameters, all six actions, and the key side effect of auto-reminders, so an agent has enough to invoke the tool correctly. Since an output schema exists, not detailing return values is acceptable.

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 carries the full burden and provides an action-by-parameter mapping (e.g., partner_id for update/complete/snooze/cancel, next_followup defaulting to tomorrow). It explains defaults for next_followup and days, but 'days Default 7' conflicts with the schema's default of 0, preventing a perfect score.

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 purpose: tracking and managing follow-ups for non-prospect relationships, with clear examples of the target audience (API vendors, investors, co-founders). The explicit 'non-prospect relationships' framing distinguishes it from sibling tools like prospect.

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

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

Gives a clear scope for when this tool applies and breaks down each action with its intent. It does not explicitly name an alternative tool for prospects or state exclusions, but the context is strong enough to route an agent 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds substantial behavioral detail: it is local-only, requires a HeyLead .git checkout, cloud workers and other installs refuse, and it never runs automatically. It also details the action semantics (status vs tick) and that request is required for tick. This goes well beyond annotation hints, fully disclosing side effects and 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: a front-loaded purpose sentence, two exclusion/constraint sentences, and a structured Args block. Every sentence earns its place—purpose, usage constraints, and parameter details. No fluff, and the most important constraint (local-only) is stated 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 the tool's complexity (a local patch/PR agent) and the presence of an output schema (not shown but indicated), the description covers everything an agent needs: purpose, constraints, exclusions, parameter semantics, and when to invoke. There is no missing information that would prevent correct invocation, especially since return values are presumably covered by the output schema.

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 explain the parameters. It does: action is described as '"status" (default) or "tick"' and request is 'What to change. Required for action='tick'.' This adds critical meaning (allowed values, defaults, and requirement rules) that the schema alone (with only defaults) does not convey.

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 'Local-only product agent — patch this HeyLead git checkout or open a PR,' which clearly states the verb (patch/open PR), the resource (local git checkout), and the scope. It explicitly excludes what it does not do ('Does not send LinkedIn, email, or calendar'), distinguishing it from communication siblings like send_email or book_meeting. This is specific 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?

The description provides explicit context on when to call it ('call it explicitly') and when not to (cloud workers and non-.git installs refuse, and it does not send messages). It states the coordinator never starts it, so the agent must invoke it directly. While it doesn't name a specific alternative, the exclusions and explicit-call instruction give clear usage guidance, just short of naming a direct sibling.

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, signaling mutating and potentially destructive behavior. The description adds context by explaining that profile edits are tracked and can be rolled back, and by outlining the restore action. It does not explicitly warn that restoring overwrites the current profile irreversibly, but the destructive annotation covers the main risk, so the description adequately complements 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 opens with a concise one-line purpose, followed by a short explanatory sentence, the supported-fields list, and a clearly formatted Args block. Every part is functionally useful and there is no fluff. The Args block is somewhat long, but that is justified for a tool with four parameters and multiple actions.

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 four parameters are explained, including defaults, allowed action values, and the condition requiring change_id. An output schema exists, so return-value details are unnecessary. The description does not discuss explicit side effects beyond the destructiveHint annotation or address pagination beyond the limit parameter, but it provides enough information for an agent 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 description coverage is 0%, so the description carries the full burden of explaining parameters. It does so thoroughly: action is described with its three allowed values, field is illustrated with concrete examples, change_id is marked as required for restore, and limit has its default stated. This fully compensates for the absent schema 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: 'View and restore LinkedIn profile change history,' which clearly identifies the tool's domain. It lists supported fields and three concrete actions (history, restore, current), making it easy for an agent to distinguish it from profile-editing tools like setup_profile, even though no sibling is explicitly named.

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 action descriptions provide concrete use cases: 'history' to list changes, 'restore' to revert by change ID, and 'current' to show the cached snapshot. The description also notes that change_id is required for restore. However, it does not explicitly state when not to use the tool or point to alternatives like setup_profile for editing, so usage guidance is implied rather than fully explicit.

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 carry the safety profile (readOnlyHint false, destructiveHint true, openWorldHint true), so the description does not need to restate those. It adds useful behavioral context about preview mode, exact LinkedIn school name lookup, and LinkedIn recall queries, which goes 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 description is compact, front-loaded with purpose, and uses a scannable Args block. Every sentence earns its place, including the alternative-tool routing and parameter clarifications.

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

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

With an output schema present, return values are already covered. The description rounds out the remaining context: action modes, examples, preview semantics, and the boundary with campaign tools. Nothing critical is missing for an agent to select and 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 for parameter semantics—and fulfills it. It explains action values, provides examples for request, marks profiles_json as 'preview only,' and clarifies that titles and location_codes are comma-separated.

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 combination: 'Compile a targeting request into LinkedIn recall + profile evidence.' It further clarifies the purpose by stating it is for seeing how HeyLead looks for country ties and interests on full LinkedIn profiles, and explicitly distinguishes it from generate_icp/create_campaign.

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 when to use this tool ('Use this to see how HeyLead looks for...') and when not to use it ('Campaigns still go through generate_icp / create_campaign'). It also documents the action variants (compile, preview, schools), giving the agent concrete usage options.

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=true and openWorldHint=true, but the description adds substantial behavioral context: dismiss closes as lost and reduces Hot Leads count, confirm is mandatory, and the difference between evidence-based reason codes ('not_a_fit', 'negative_reply') versus fact-based ones is clearly explained. It also notes that skip has no side effects beyond the current campaign, and that stop affects all outreach. These details go well beyond the annotations and give the agent a clear picture of side effects and side 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 efficiently structured: a one-line summary, a two-line conceptual distinction that resolves a common ambiguity, then a bulleted list of arguments with terse explanations. Every sentence earns its place – the skip/stop clarification prevents misinterpretation, and the parameter list is dense but scannable. The use of code formatting and indentation improves readability without padding. For a tool with nine parameters, the length is proportionate and well organized.

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 (9 parameters, multiple distinct actions, side effects on campaigns and leads), the description covers all necessary context: action semantics, parameter requirements, defaults, and consequences. The presence of an output schema means return-value details are not needed here. The description also addresses edge cases like auto-selection of outreach_id and the preview behavior of dismiss. An agent would have sufficient information to invoke the tool correctly for any of the five actions without consulting additional 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 coverage is 0% – the schema provides no property descriptions – so the description fully compensates. Every parameter is explained: action lists all six values with specific behaviors, outreach_id auto-selects if empty except for conversation/timeline, campaign_id defaults to active for skip, outcome defaults to 'won' but explained, meeting_link is clarified for 'won', confirm must be True for dismiss, and reason_code enumerates valid values with targeting implications. reason_note is described as free text. No parameter is left opaque.

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 pairing ('Manage prospects') and enumerates five specific actions: skip, close, dismiss, view conversation, or timeline. It distinguishes skip from stop/close with a precise semantic difference, making the tool's purpose unmistakable and differentiating it from vague alternatives. The description goes beyond a generic summary by specifying exact behaviors for each action.

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 guidance on when to use each action, especially the critical distinction between 'skip' and 'stop' (close with opt_out), including the workspace-wide effect of stop and the targeting feedback implication. It also specifies that 'dismiss' requires confirm=True and previews on first call. However, it does not explicitly name alternative sibling tools or state when those should be used instead, though the action-level guidance is thorough enough for most usage decisions.

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?

Even though annotations mark destructiveHint=true and readOnlyHint=false, the description adds crucial behavioral context: it specifies which actions are destructive (toggle can disable), distinguishes local vs. cloud behavior, explains 'backfill_cloud' is backend-mode only, and clarifies 'send_from' ensures only one side sends. This goes well beyond the coarse annotation flags.

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 lengthy but well-structured: it opens with a one-line purpose, then uses a bulleted action list with inline parameter explanations. Given the tool's complexity (7 parameters, 10 actions, context-dependent semantics), the length is justified and every sentence earns its place, though it could be marginally tightened by moving parameter notes to a dedicated section.

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

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

With an output schema present, return values needn't be described. The description covers every parameter, action, and interplay (e.g., cloud, enabled, host) plus edge cases like 'report' interval retention and 'send_from' ensuring mutual exclusivity. An agent can correctly invoke any action without external 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?

The schema provides zero descriptions for parameters (coverage 0%), so the description carries the full burden. It explains each parameter per action: e.g., 'hours' serves as lookback window for logs/activity but as report interval for 'report'; 'event_type' filters events but doubles as recipient email for 'report'. All parameters are fully and action-specifically clarified.

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: 'Manage the autonomous scheduler — view status or toggle on/off.' It then enumerates discrete sub-actions (status, toggle, observe, etc.) each with a specific purpose, making its scope unambiguous and distinct from sibling tools like 'show_status' or 'check_replies'.

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?

Every action is accompanied by explicit when-to-use guidance, including conditions and alternatives. For instance, it states that 'observe' is local-only and does not stop cloud scheduling, which must be disabled separately with a specific scheduler call. This leaves no ambiguity about selection among the available modes.

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; the description does not contradict these. It adds genuine behavioral context beyond annotations by disclosing the hosted-auth-link failure mode and the retry/account-setup follow-up, which an agent needs to handle the no-mailbox case gracefully.

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, followed by hard usage constraints, the auth-failure flow, and a compact Args block. Every sentence earns its place—there is no filler or re-statement of the schema titles.

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 mutation tool with an output schema and full annotations, the description is nearly complete: it covers purpose, exclusions, auth failure, and parameters. Minor omissions are details like success-path behavior and rate limits, but the output schema already carries return-value documentation, so nothing critical 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's Args block carries the full parameter-documentation burden. It explains all four parameters and adds meaningful notes beyond the bare titles: 'HTML is fine' for body and 'Optional' for to_name. Coverage is complete, though the individual descriptions are terse.

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: 'Send an email through the connected Unipile mailbox (Gmail/Outlook).' It also distinguishes itself from siblings by declaring 'This is the only supported way to send email,' separating it from tools like send_message and generate_and_send.

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?

Explicit when-not guidance is present: 'Never use Mail.app, osascript, mailto: handlers, or a local SMTP client.' It also provides a concrete alternative path for the unauthenticated case ('call account(action="connect_email") first') and instructs the agent to have the user open the hosted-auth link and retry.

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 signal readOnlyHint=false and destructiveHint=true; the description adds meaningful behavior context beyond those flags: 'website_setup — generates JS snippet to embed', 'feedback — improves future classification', and 'optimize_rollback — Rollback a specific optimization change'. It does not fully describe reversibility or side effects (e.g., what website_setup changes), so not a 5.

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

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

The description is front-loaded with a purpose sentence and then a well-structured Args list; each action and parameter line earns its place. It is long due to the genuine complexity of ten actions, but there is little redundancy; a 5 would require tighter grouping or more compact 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 high-complexity multi-action tool, the description covers all actions and parameters and cooperates with the annotations and output schema. It does not describe per-action return values or explicitly say which sibling tools to prefer, but the output schema likely covers returns and the action list is sufficiently 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 0%, so the description carries the full burden for parameter semantics, and it succeeds. Every parameter is explained: action has enumerated values with per-action meaning, signal_type has different meanings for 'show' vs 'optimize_history', status has example values, limit/days have defaults, and signal_id/feedback are scoped to specific actions.

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 'View and analyze buying signals from LinkedIn' and then enumerates ten distinct actions, giving a clear verb+resource map and concrete sub-purposes. It does not reach 5 because the opening phrase understates the mutation/optimization actions (optimize, rollback, website_setup) and does not differentiate this tool from siblings like profile_signals or analytics.

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 clear context for when to use each internal action via the Args list, including which parameters apply to which action (e.g., signal_id for feedback and optimize_rollback, days for report, signal_type variants for show vs optimize_history). It lacks explicit alternatives or when-not-to-use guidance relative to sibling tools, so it falls short of a 5.

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.