LinkedNav

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

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavior: it runs validation checks before activating and returns the updated campaign status. It does not explain the downstream irreversible effect (launching outreach) that destructiveHint implies, which is the remaining gap.

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

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

Three short sentences, front-loaded with what the tool does, followed by preconditions and the return value. No filler, no repetition of the title, and each sentence carries distinct 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?

There is no output schema, and the description compensates by stating that the updated campaign status is returned. Combined with the precondition list and full parameter coverage in the schema, an agent has what it needs to call this correctly; only failure behavior when validation rejects is unstated.

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

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

Schema description coverage is 100% and both parameters are documented there, including the conditional requirement on linkedinConnectionId. The description only alludes to the LinkedIn account via its validation sentence and adds no syntax, format, or default information, so the schema is doing all the work.

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 pair and resource ("Start or resume a LinkedNav campaign"), which is far more informative than the title alone and naturally separates it from pause_campaign, create_campaign, and delete_campaign. However, it never explicitly contrasts itself with those siblings, so it lands at clear-but-undifferentiated rather than top-tier.

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 real context for invocation: use it to start or resume a campaign, and it discloses the preconditions that gate success (LinkedIn account, prospect/post count, subscription limits). There is no explicit when-not guidance or named alternative, which keeps it 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 declare readOnlyHint=false and destructiveHint=false, so the write-but-non-destructive profile is already covered. The description usefully adds that contacts must be 'existing' and identified by ID, plus the 50-item ceiling, but says nothing about partial-failure behavior or permission requirements. It adds some context over annotations but not rich behavioral detail.

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

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

A single tight sentence with zero filler, front-loaded with the verb and scope. Every clause (bulk, up to 50, by IDs, one call) carries 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?

For a simple 2-parameter write tool with full schema coverage, annotations, and no output schema, the description is essentially sufficient. The only minor gap is that it doesn't disambiguate against the singular add_lead_to_campaign sibling, which an agent might otherwise hesitate between.

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

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

Schema coverage is 100%, so both parameters (campaignId, contactIds) are already documented, including the 1–50 bound. The description's 'by their IDs' and 'up to 50' largely restate the schema rather than adding format or constraint detail beyond it. Baseline 3 applies.

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

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

States a specific verb (Add), resource (contacts), and scope (up to 50, by IDs, in one call). The 'bulk' / 'up to 50' / 'in one call' phrasing implicitly distinguishes it from the singular add_lead_to_campaign sibling, though it does not name that sibling explicitly.

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

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

Usage is implied: the 'bulk / up to 50 / one call' framing signals this is the batch alternative to add_lead_to_campaign, but the description never names the alternative or states when to choose it over a single add. No exclusions or prerequisites are given.

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, destructiveHint=false, and openWorldHint=true. The description adds real behavioral context beyond them: creating via profileUrl performs contact-creation-in-one-step, overrides are content-only and do not alter which stages fire, and overrides are ignored when adding by contactId. That is meaningful side-effect and scoping disclosure the annotations don't provide.

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

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

Three sentences, front-loaded with the primary action, then the two input paths, then override semantics. Every clause carries load — the parenthetical 'content-only; the campaign still decides which stages fire' prevents a plausible misinterpretation.

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

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

No output schema exists, so the description should stand on its own for input semantics, which it largely does for a mutation tool. It covers creation side effects, override scoping, and path selection; it stops short of stating auth/permission requirements or return shape, but the essential call-time guidance is present.

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

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

Schema coverage is 100%, so baseline would be 3, but the description adds value by clarifying the mutually-exclusive relationship between contactId and profileUrl (either/or) and the conditional applicability of the override parameters, which helps the agent disambiguate the 14-parameter surface beyond the per-field schema text.

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

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

States a specific verb and resource ('Add a single lead to a campaign') and implicitly distinguishes itself from the bulk sibling add_leads_bulk_to_campaign via 'single lead'. An agent can immediately tell what this does and how it differs from the batch variant.

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 clear conditional routing between the two input paths: 'Provide either a contactId... or a LinkedIn profileUrl + name', and explicitly scopes when overrides apply ('only ... when creating via profileUrl'). It does not name the bulk alternative as an exclusion, but the context for using this tool is 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 only declare readOnlyHint=false and destructiveHint=false; the description goes far beyond them, disclosing skip-and-report behavior via `rejected`, intra- and cross-campaign de-duplication, plan caps, InMail double-send skipping, campaign resumption, and character clamping. This is exactly the behavioral context annotations cannot carry.

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 key constraint (which URL form each send mode requires) is front-loaded, but the block is very dense and repeats override semantics that the schema already documents verbatim (customMessage, customSubject, customFollowUp2/3). Several sentences do not earn their place against the structured fields.

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 accepts the full burden and covers resolution rules, rejection reporting, dedup, caps, and overrides. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real interpretation the schema lacks — how the three sources combine, why providerId is needed for InMail, and how overrides relate to messageSettings.template. It loses a point for restating several per-field semantics already spelled out in the nested 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?

States a specific verb and resource — 'Add recipients to a MESSAGE campaign — the people it will DM' — and immediately anchors it against the sibling add_lead_to_campaign for outreach. An agent can distinguish it from add_lead_to_campaign, add_post_targets, and add_monitor_targets without opening 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?

Explicitly names the three combinable input sources (urls, contactIds, listId) and conditions each on campaign send mode, including the managed-session exception. It also routes the agent onward to check_inmail_open_profiles, giving genuine when-to-use guidance.

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

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

With annotations only declaring readOnlyHint=false, destructiveHint=false and openWorldHint=true, the description carries real extra burden: URL validation rules, in-campaign AND cross-campaign de-duplication on the same LinkedIn account, per-campaign caps, credit/free-allowance economics, and the side effect that adding to a completed campaign resumes it. These are behavioral traits the annotations cannot express.

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-loaded with the action and target type, then constraints, then cost. The paragraph is long but nearly every clause carries a distinct constraint; the credit-economics sentence is the softest, though still relevant to whether the call will succeed.

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 mode restriction, validation, de-duplication, caps, cost, and the resume side effect — thorough for a two-parameter mutation with no output schema. It stops short of saying whether a partially invalid URL list fails the whole request or is filtered, which is the one decision an agent might still need.

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

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

Schema description coverage is 100%, so both parameters and the 1–200 bound are already documented, establishing a baseline of 3. The description reinforces the /in/ vs /company/ URL shape and the 'not a post URL' rule but adds no syntax or format detail beyond the 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?

States a specific verb (add) plus the exact resource (LinkedIn profile/company URLs as monitor targets) and the campaign mode it applies to. It explicitly positions itself relative to siblings by calling itself 'the monitor-mode analog of add_post_targets', so an agent can discriminate it from add_post_targets, add_message_targets and remove_monitor_targets without reading 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?

Provides a clear precondition ('Only comment campaigns created in monitor mode are supported') and a scope-escalation path ('create another monitor campaign to watch more'). It does not explicitly route the agent to alternatives for the non-monitor case (e.g. add_post_targets or add_message_targets), which is the only gap.

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

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

Annotations only declare it is a non-read-only, non-destructive, open-world mutation. The description goes well beyond that: exact accepted URL patterns and the profile-URL rejection, de-duplication both within the campaign and across the account's other comment campaigns, plan-based per-campaign caps, and the resume-completed-campaign behavior. These are exactly the side effects and constraints an agent needs before calling.

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-loaded with the action and target, then layered validation, de-dup, caps, and resume behavior in one dense paragraph. Sentence count is low relative to information delivered, though the parenthetical analog and the long validation clause make it slightly heavy to scan.

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

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

For a 3-param mutation with no output schema, it covers validation, de-duplication, plan limits, and the resume side effect. It leaves open what happens to an invalid or duplicate URL (hard error vs. silently skipped) and what the call returns, which is a minor but real gap for a batch operation accepting up to 200 URLs.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema — including the URL format list, which the description largely repeats. The description does add cross-campaign de-dup and plan-cap semantics for urls, but never mentions the watcher parameter's meaning or interaction. Per the high-coverage baseline, a 3 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?

Specific verb+resource ('Add LinkedIn post URLs to a COMMENT campaign') with scope stated immediately ('the posts it will auto-comment on'). It explicitly differentiates from siblings by framing itself as the comment-campaign analog of add_lead_to_campaign, and rules out profile URLs — an agent can place it against add_message_targets/add_monitor_targets without opening a schema.

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

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

Gives a clear when-to-use condition ('Only comment campaigns are supported') and names the outreach counterpart add_lead_to_campaign as its analog, plus a notable side effect (adding to a completed campaign resumes it if under the active-campaign limit). It stops short of explicitly routing the agent to remove_post_targets or the message/monitor target variants, so it is clear context rather than full when/when-not coverage.

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

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

Annotations already establish readOnly/non-destructive, and the description layers on substantive behavioral detail: results are judged against benchmark ranges, sample-size guards flag unreliable rates as insufficient-data, and promptComparison.best is the proven winner. This is real context beyond the 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?

A single dense paragraph, front-loaded with the tool's identity and trigger conditions before the return-value detail. It is long, but each clause carries selection-relevant information rather than 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 carries the burden of describing return values and does so thoroughly (funnel rates vs benchmarks, weekly trends, segment breakdowns, guarded prompt comparison, bottleneck stage, prioritized recommendations). Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the key nuance that funnel totals are lifetime while only the weekly trend honors the days window. The description adds no additional parameter meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource (expert analysis of outreach performance) and explicitly distinguishes itself from siblings: 'not raw stats' and 'For ranking the actual PEOPLE to contact, use analyze_pipeline instead.' An agent can select this over analyze_pipeline or get_performance_analytics without opening a 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?

Enumerates the triggering questions (how things are going, why results look that way, what to improve, best segment/industry, best prompt/message) and names the alternative tool for a related-but-different job. Both when-to-use and when-to-use-something-else are 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 only declare it is a safe, closed-world read. The description adds rich behavior beyond that: it discloses the ranking basis (AI-assessed conversion likelihood + ICP fit), the exact sections returned (waiting-on-reply, gone-quiet, warm bench, drafted-reply count), and that every row carries its evidence. With no output schema, this detail is essential and present.

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

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

Front-loaded with the primary scoping and intent examples, and every clause carries substantive content. It is dense and slightly run-on, but there is little genuine waste.

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 read-only analysis tool with no output schema, the description fully covers what is returned and how to act on it. Nothing an agent needs to call and interpret it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents limit, campaignId, and minIcpScore. The description references ICP fit and the 'ICP 8+' warm bench, which loosely aligns with minIcpScore, but it adds no explicit param syntax or mapping. Baseline 3 applies.

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

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

States a specific verb (ranks) and resource (the actual PEOPLE/opportunities to act on), and the all-caps 'DEAL-CLOSING VIEW' frames its distinct purpose against siblings like analyze_performance or analyze_relationship. An agent can tell it apart without opening a schema.

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

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

Explicitly names the user intents it answers ('who are my hottest/highest-ICP leads', 'help me close deals') and routes downstream actions to named siblings (get_unibox, send_unibox_reply, get_pending_replies). This is a clear when-to-use with alternatives.

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

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint false, openWorldHint), and the description adds substantial operational context beyond them: the ~20s LinkedIn re-sync latency, the daily caching rule when a prior re-sync found nothing, and the meaning of conversationCheck:'unverified'. These are real behavioral traits an agent cannot infer from 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?

It is front-loaded with a clear opening clause, and most clauses carry genuine information. However, the entire definition is a single run-on sentence with deeply nested parentheses (the conversation/InMail clause), which impairs parsing and makes the informative caveats hard to extract on a quick read.

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 must describe returns, and it does list the output fields (connection, invite, conversation, reply ownership, recent posts, next action). Latency and edge-case semantics are covered, but the response format/shape and how to read each field's values remain somewhat implicit.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description only restates the required input ('Pass the person's profile URL') and says nothing about connectionId or which sender's relationship gets analyzed. Baseline 3 is correct when the schema carries the semantics.

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

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

States a specific verb and resource ('analyze your relationship with ONE person') and enumerates exactly what it returns: connection status, pending invite, conversation/InMail, who owes a reply, recent posts, and a suggested next action. This makes it clearly distinguishable from siblings like get_conversation, get_linkedin_connection, or get_recent_posts, which each cover only a slice.

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

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

Explicitly positions itself as 'the one call to make before writing a personalized message or deciding how to follow up,' which gives a clear usage trigger. It also names an alternative behavior (get_conversation with refresh:true) for forcing a re-sync, but does not state when NOT to use this tool or how it compares to composing the individual sibling calls.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true and destructiveHint=true, so the write/irreversible profile is partly covered. The description usefully clarifies that approval queues the comment rather than posting it immediately, but it does not explain the destructiveHint=true consequence (public irreversible posting) or any auth requirements, leaving the most important behavioral trait undisclosed.

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

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

A single front-loaded sentence with no filler, which is good. It is arguably too terse for a mutation tool, but there is no wasted 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 mutating, irreversible-flagged tool with 0% parameter coverage and no output schema, the description omits the editedComment contract, what happens after approval, and any post-approval behavior. An agent cannot call this confidently without guessing at the edit path.

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 carry the parameter burden and does not. Crucially, it never mentions that editedComment lets the caller modify the AI text before approval — arguably the most important semantic of this tool — leaving both parameters undocumented.

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

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

States a specific verb (approve) and resource (AI-generated LinkedIn comment) plus the effect (queue to be posted), which distinguishes it from the reply-oriented siblings like approve_pending_reply. It does not explicitly name alternative tools, but the resource noun does the differentiation work.

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 no when-to-use guidance: nothing about the relation to get_pending_comments, deny_pending_comment, update_pending_comment, or retry_pending_comment, and no prerequisites (e.g., a connected LinkedIn account is needed to queue a post). Usage is only inferable from the tool name.

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 destructive/openWorld; the description adds the crucial facts an agent needs: the send is irreversible ('cannot be recalled'), the exact text is sent unless editedMessage is supplied, and the invite-limit case returns inviteLimitLocked with a reset time rather than failing. That is substantive disclosure beyond the structured fields and consistent 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?

Three sentences, front-loaded with the action and its irreversibility, then the edge case. No filler; each sentence carries a distinct constraint the agent cannot get elsewhere.

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 mutation with no output schema, the definition covers the safety profile, the content-override behavior, and the failure/lock mode with the corrective call. Nothing an agent needs in order 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 coverage is 100%, so baseline is 3; the description still adds real meaning by framing editedMessage as a replacement for the held text and tying sendWhenLimitClears to the specific invite-limit-locked scenario. pendingOutboundId's provenance is covered by both schema and description.

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

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

States a specific verb (approve), a specific resource (ONE held campaign message), and the effect (sent on LinkedIn), which cleanly separates it from approve_pending_comment and approve_pending_reply. The emphasis on 'ONE' also signals it is not a bulk operation.

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

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

It implicitly routes the agent from get_pending_outbound (named as the id source) and gives an explicit alternative path — re-call with sendWhenLimitClears:true instead of retrying blindly. It does not name deny_pending_outbound or update_pending_outbound as the alternative actions, so the when-not guidance is incomplete.

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 (readOnlyHint=false, destructiveHint=true, openWorldHint=true) already flag this as a mutating outward action, and the description usefully adds that the reply is queued for real sending plus the optimistic-concurrency safeguard ('never sent unseen'). It omits what happens on a version mismatch or the error surface, keeping it short of 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?

Two sentences: the action first, then the one parameter that needs explanation. No filler, and the safety rationale is attached directly to the parameter it governs.

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

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

For a 3-param mutation tool with annotations covering the safety profile and no output schema, this is close to complete. The remaining gap is the unmentioned editedMessage parameter and unspecified behavior when expectedVersion no longer matches.

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 carry the load, and it explains expectedVersion very well by tying it to the draft's `version` from get_pending_replies. However pendingReplyId is left bare and, more importantly, the optional editedMessage (maxLength 8000) is never mentioned, so the ability to approve with edits is invisible.

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

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

States a specific verb and resource ('Approve an AI-generated LinkedIn reply') and the resulting effect ('queue it to be sent'). This implicitly separates it from deny_pending_reply, update_pending_reply, regenerate_pending_reply and approve_pending_comment, but none of those siblings are named, so differentiation is left to the reader.

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

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

Usage is implied by the approval action and the guidance to pass expectedVersion, but the description never states when to choose this over deny_pending_reply, update_pending_reply, or regenerate_pending_reply. No exclusion conditions or prerequisites (e.g., account connection state) are given.

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?

Although annotations indicate destructive and open-world behavior, the description adds substantial operational detail: sends run automatically later, same checks and daily allowance apply, per-send skip rules, rescheduling when allowance is exhausted, reconnect waiting, and user notification. This is exactly the behavioral context an agent needs for a destructive approval tool.

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

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

The purpose is front-loaded in the first sentence, and the rest is relevant to a complex, destructive operation. It is somewhat dense and could be split more cleanly, but every major sentence carries operational meaning.

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

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

No output schema exists, and the description covers the approval outcome, automatic execution behavior, skip/reschedule/reconnect conditions, and notification path. Together with the schema and annotations, an agent has enough to invoke and reason about the 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 coverage is 100%, so parameter documentation is already strong. The description still adds meaning beyond the schema by explaining the confirm gate and its return behavior, and by tying approval to the exact list the user saw, which relates to revision.

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

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

States a specific verb and resource: approving a scheduled-send plan created by schedule_sends. It clearly distinguishes approval from scheduling/listing by naming schedule_sends and list_scheduled_sends, so an agent can separate it from siblings.

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

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

Explicitly says to call it only after the user has said yes to the whole list as shown. It also gives the negative condition: without confirm:true it approves nothing and returns the list to show, which prevents accidental approval.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds value beyond them: it discloses the return shape (a 0-100 score plus gaps framed as what/why/how/action with the exact fixing tool call) and the intended workflow (read-only; apply fixes with the named tools after confirming with the user). That workflow and output detail is real added context.

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-loaded with the tool's essence, then dimensions, then triggers, then read-only workflow. Three well-formed sentences that each carry information. The 'EXPERT SETUP REVIEW' lead-in is slightly promotional, but it does not waste much space.

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

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

No output schema exists, and the description compensates by describing the return (0-100 score, gap list with what/why/how/action), the read-only constraint, and the follow-up path. For a single optional-parameter audit tool, nothing an agent needs to call it correctly is missing.

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

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

Only one parameter (setupId) with 100% schema coverage, and the schema already documents the key behavior ('Omit to audit the active setup'). The description adds nothing about the parameter, so the schema carries the full load, which matches the baseline-3 rule for high coverage.

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

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

States a specific verb ('grades'/'expert setup review') and resource (the AI setup), and enumerates the concrete dimensions graded: business-context completeness, ICP precision, goal wiring, message/sequence assets, and the LinkedIn sender. It is clearly distinct from campaign-oriented audit siblings, but it never names or contrasts with the closest siblings (full_audit, diagnose_campaign, get_account_health), leaving that differentiation to inference.

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

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

Gives explicit triggers: 'when the user asks to review/improve their setup, when results are weak, or before going live.' That is clear context for invocation. However, it offers no when-not guidance or named alternative (e.g., full_audit vs. this), so the agent must still guess which audit tool to reach for.

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 safety profile is covered. The description adds genuinely new behavioral context beyond the schema: the 500-contact ceiling and the hard requirement that confirm be true — the schema only shows confirm's default of false, not that it must be set. It still omits whether deletion is permanent or cascades to campaigns/lists, 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?

Two short sentences, no waste, with the destructive scope and the confirmation precondition front-loaded. Every clause earns its place.

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

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

For a 2-parameter destructive bulk tool with no output schema, the essentials (scope limit, confirm requirement) are present, and annotations carry the safety hint. However, it does not say whether deletions are irreversible or what side effects occur (campaign membership, list membership), which matters for a bulk destructive 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?

Schema description coverage is 0% for both parameters. The description recovers the semantics of confirm (must be explicitly true, not just the default false) but adds nothing about contactIds beyond the maxItems already in the schema, and nothing about ID format or validity. Partial compensation for a real coverage 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?

States a specific verb and resource ('Delete ... contacts') plus a batch scope ('up to 500') and a qualifier about the active setup, so an agent can distinguish this bulk operation from the singular delete_contact sibling. It does not explicitly name the single-delete alternative, so it falls short of 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?

The description gives one real prerequisite ('Requires confirm: true') and implies bulk context, but never states when to choose this over delete_contact or bulk_move_contacts, nor any exclusion conditions. Usage is implied rather than guided.

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 this is a write operation (readOnlyHint=false) that is not destructive and not open-world, so the safety profile is covered externally. The description adds useful scope context ('up to 500', 'active setup'), but omits what happens to the source-list membership, whether the move is atomic, and conflict handling for contacts already in the destination list.

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

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

A single tight sentence with the constraint and destination front-loaded and no filler. It is efficient, though its brevity is also what leaves behavioural and usage questions unanswered.

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 2-param mutation tool with no output schema, the description covers the essentials but not the consequences: nothing says contacts are removed from the source list or what the result contains. Adequate, but an agent would still be guessing about side effects at the 500-contact boundary.

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 50%: listId is documented in the schema, while contactIds carries only maxItems/minItems constraints. The description partially compensates by restating the 500-contact cap and the destination-list semantics, matching the baseline of 3 for a schema that does most of the work.

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

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

States a specific verb ('move') and resource ('contacts') plus scope ('up to 500', 'to another list'), so the operation is unambiguous. It does not differentiate itself from near-neighbours like bulk_delete_contacts, update_contact, or add_leads_bulk_to_campaign, so it stays below 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?

No when-to-use or when-not-to-use guidance is given. An agent gets no help deciding between this, update_contact (single-contact list change), or the bulk add/enrichment siblings, and no prerequisites are stated.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so safety profile is covered. The description adds a genuinely non-structured behavioral requirement — that confirm must be true — which is a mandatory confirmation gate the agent would otherwise miss (the schema only shows confirm with default false and no doc).

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

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

Two short sentences, action first, hard requirement second. No filler; every clause carries information the agent needs.

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-parameter mutation with no output schema, the description plus destructive annotations cover the essentials: what it does, what state it targets, and that confirmation is mandatory. The only missing piece is the provenance/format of taskId.

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% for both parameters, so the description must compensate. It does clarify that confirm must be set to true (a semantic constraint beyond the bare boolean), but it says nothing about taskId — where it comes from or its format. Partial compensation only.

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

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

States a specific verb (Cancel) and resource (background task) and narrows scope to tasks in 'pending or retrying' state, which distinguishes it from retry_task and get_tasks. It stops short of naming the sibling it is not, so it misses the top band.

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 state qualifier ('pending or retrying') implies when the tool applies, but there is no explicit guidance on when to cancel versus retry_task (a close sibling) and no when-not condition or prerequisite ownership note. Usage is inferable but not stated.

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

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

Goes well beyond the annotations (readOnly=false, destructive=false, openWorld=true) by disclosing approval-state side effects: an approved send stays approved because the user's change request counts as consent, while an unapproved plan still requires approve_scheduled_plan afterwards. It also flags edit validation ("checked like a new send") and the in-flight/sent lockout, which an agent cannot infer from 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?

Front-loads the core act and then walks the three actions in parallel structure, with zero filler sentences. The heavy parenthetical nesting ("action move + at, the user's local \"YYYY-MM-DDTHH:MM\"") makes it dense to parse on a first read, which keeps it just short of 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 7-parameter mutation tool with no output schema, it covers action routing, approval consequences, validation behavior, and failure conditions. Remaining gap is the response/effect surface (what comes back, whether the send ID changes on move) and no pointer to update_scheduled_send_status for status-only changes.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine cross-parameter semantics the schema only states piecemeal: which parameters apply to which action, the conditional planId-without-sendId cancel case, and the concrete "YYYY-MM-DDTHH:MM" local-time format for at. This resolves ambiguity an agent would otherwise have to assemble from seven separate field descriptions.

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

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

States a specific verb and resource ("Change a planned LinkedIn send") and immediately enumerates the three sub-operations with their action values, so an agent knows exactly what the tool does without opening the schema. It also names its source tool (list_scheduled_sends), which separates it from schedule_sends and update_scheduled_send_status.

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

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

Gives explicit per-action routing (move→at+time format, edit→text/note/subject, cancel→optionally plan-wide via planId with no sendId) and points to approve_scheduled_plan as the follow-up when the plan isn't approved. It also states the negative case: sends going out now or already sent can't be changed.

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 (readOnlyHint=false, openWorldHint=true, destructiveHint=false) are consistent with the described writes in mode 1. The description goes well beyond them, disclosing batching (up to 20), the account-safety rationale of one LinkedIn profile view per check, that answers are saved on the recipient, the free/no-credit nature, and the daily retry behavior.

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

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

Front-loaded with the core purpose before the mode details, and nearly every sentence carries operational value. It is dense and semicolon-heavy, and the final suggestion about remove_message_targets is slightly tangential, but there is little wasted text.

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?

There is no output schema, yet the description explains the relevant return signals (remainingUnchecked, stop) and where results are persisted (recipient openProfile). Given the tool's complexity, the definition supplies everything an agent needs to invoke and continue 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 coverage is 100%, so the baseline is 3, but the description adds genuine meaning: campaignId target selection is PENDING FIRST and saves results, profileUrls behaves differently with vs without campaignId, and senderConnectionIds affects source preference. It stops short of syntax details, but adds real behavioral context over the 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?

States a specific verb+resource (check which InMail recipients are LinkedIn open profiles) and defines the domain-specific term (people who accept InMail for free). It clearly differentiates its two modes and its function from siblings like get_message_targets and remove_message_targets, so an agent can recognize its role without opening the schema.

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

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

Explicitly routes the agent between two modes: pass campaignId to check-and-save campaign recipients, or pass profileUrls without campaignId for a pre-check before building a campaign. It also gives continuation rules (call again when remainingUnchecked > 0, stop on stop: true) and names follow-up tools, leaving little 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, readOnlyHint=false, and openWorldHint=false, but the description adds real context beyond them: the full blast radius ('wipes EVERY collected lead in that intent bucket for the active setup'), the containment ('other buckets are left untouched'), and the reversibility profile ('cleared leads can be re-collected by future runs'). The confirm requirement is disclosed as well. This is exactly the kind of operational context annotations cannot carry.

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

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

Two sentences, front-loaded with the verb and scope, and every clause earns its place: blast radius, containment, reversibility, alternative, and precondition. No filler or restatement of the tool name.

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

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

No output schema exists and none is needed for a destructive clear, and the description covers the destructive scope, the containment guarantee, recoverability, the confirm precondition, and the alternative path. Nothing an agent needs to invoke this safely 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 50%: searchType is thoroughly documented in the schema, but confirm has no schema description at all. The description compensates by stating 'Requires confirm: true', giving the agent the semantics the schema omits, and characterizes searchType as a bucket selector. It adds meaning for the undocumented parameter but duplicates the bucket semantics already in the enum description.

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

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

States a specific verb (clear) and a precisely scoped resource (one Intent Signal Agent result bucket keyed by searchType, on /app/signals), and explicitly names the sibling it is not (delete_signal_leads). An agent can distinguish it from get_signal_agent_results and delete_signal_leads without opening either schema.

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

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

Routes the agent to the right alternative with the condition that selects it ('use delete_signal_leads to block specific leads from re-adding'), and clarifies the boundary condition that other buckets are left untouched. The confirm: true precondition is also stated, so the agent knows what is required before invoking.

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 openWorldHint=true, yet the description adds genuinely new behavioral facts: the action is irreversible, a closed posting is never reopened (a new one must be created), and each call consumes a 20/day quota. These are exactly the consequences an agent needs before invoking a destructive tool.

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

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

Four short clauses, front-loaded with the action and its effect, followed by irreversibility, the confirmation requirement and the quota. No sentence is redundant or restates the title.

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

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

For a destructive mutation with no output schema, the description covers irreversibility, quota and the user-confirmation gate, which is most of what an agent needs. It is silent on side effects for existing applicants and on the failure mode for an already-closed posting, both plausible given the presence of get_job_applicant and reject_recruiter_applicant siblings.

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

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

Schema description coverage is 100%, so jobId, service and connectionId are already documented in-schema, including where to obtain each id. The description adds no further meaning about parameter values or defaults, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Close ONE of your LinkedIn job postings') and immediately defines the observable effect: stops accepting applications and leaves LinkedIn's job search. That effect-based framing cleanly separates it from create_job_posting, edit_job_posting and publish_job_posting without needing to name them.

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

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

Gives an explicit procedural precondition ('Confirm with the user first') and budget context ('Counts against a daily allowance (20 a day)'), which tells the agent both to gate on user approval and to spend the call deliberately. It does not state when to prefer publish_job_posting/edit_job_posting or what to do if the posting is already closed, so it stops short of full when/when-not guidance.

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

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

Beyond the annotations, the description discloses that the comment is public as soon as sent and counts against a daily allowance (40/day). It also clarifies the max length and the 'ONE comment' constraint. It does not cover error handling or authentication requirements, but the added behavioral context is substantial.

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 essential action and constraints, followed by optional features and behavioral notes. It is slightly longer than necessary but each sentence contributes useful context; nothing is redundant.

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

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

Given 8 parameters with full schema coverage and no output schema, the description covers the core action, constraints, optional features, visibility, and rate limits. It is complete enough for an agent to invoke the tool correctly, though it could mention return behavior or error cases.

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

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

Schema coverage is 100%, so the schema already documents all eight parameters thoroughly. The description adds only marginal meaning, such as 'Pass replyToCommentId to answer a specific comment instead of the post,' but mostly restates optional capabilities already in the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Post ONE comment') and resource ('LinkedIn post') with scope ('from your own account, now'). It is clearly a commenting action, though it does not explicitly name sibling tools to differentiate from, e.g., scheduled or campaign-based commenting.

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 clear context for when to use this tool: immediate, public commenting from your own account or a company page, with an explicit option to reply to a specific comment. It does not state when-not-to-use or name alternatives, but the context is sufficient for an agent to select it appropriately.

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 openWorldHint=true, but the description adds substantial non-obvious behavior: it validates the cookie against LinkedIn before saving, enforces the plan sender limit, warns the cookie will expire, and describes the returned connectMessage + suggestions to relay. This is exactly the kind of mutation and lifecycle context the annotations do not carry.

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 core purpose and the preferred-alternative routing are front-loaded in the first two sentences, which is right. It is long and dash-heavy in the middle, with some repetition about 2FA and auto-refresh, but nearly every sentence carries actionable instructions rather than 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?

Despite having no output schema, the description explains what is returned (connectMessage + suggestions) and what they mean, and it covers validation, plan limits, and the cookie's expiry lifecycle. An agent has enough to call the tool and to relay results correctly.

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

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

Schema coverage is already 100%, so the baseline is 3. The description goes beyond the schema by explaining the operational trade-off of userAgent — why to ask for the real fingerprint (longest-lived cookie) and what to do when the user cannot supply it. It does not add field-level detail for country, proxyId, or label beyond what the schema states.

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

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

States a specific verb and resource: 'Add a LinkedIn sender by pasting its li_at session cookie.' It further distinguishes itself from the sibling connect_linkedin_with_credentials by explaining that the cookie variant is cookie-only and expires, so an agent can route correctly without reading both 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?

Explicitly names the alternative and the condition selecting it: 'Prefer connect_linkedin_with_credentials when the user can share their login' because a saved email+password enables silent cookie auto-refresh. It also gives an ordered fallback for the user-agent capture step, so the agent knows when-and-when-not at each decision point.

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 cover the write/open-world profile, but the description discloses that the server performs the login, stores the cookie and encrypted credentials, silently refreshes later, and even describes error behavior for push-to-phone 2FA. It also documents the return payload (connectMessage/suggestions/status/alwaysOnReady) used to detect a 24/7-ready account.

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 core action is front-loaded, but the 2FA explanation is heavily repetitive—the 'store totpSecret for 24/7' idea is restated three times, and the phone-push workaround is circled more than once. Sentences earn their place individually but the whole is longer than necessary.

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 7-parameter connect tool with no output schema, it covers the login flow, credential storage, 2FA handling modes, the failure case, and the returned fields an agent must relay. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds value by clarifying the totpCode-vs-totpSecret trade-off and that totpSecret is the durable, stored path. It goes beyond the schema descriptions, though it repeats much of what totpSecret's own schema text already says.

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

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

States a specific verb+resource: 'Add a LinkedIn sender by logging in with the account's email and password.' It also distinguishes itself from the sibling connect_linkedin_with_cookie and positions itself as the recommended path. An agent can select it without opening the schema.

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

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

Explicitly names when to use it (recommended connect path, no user-agent needed), the alternatives (connect_linkedin_with_cookie for phone-push 2FA), and the follow-up step (call get_linkedin_2fa_status). It also splits totpCode vs totpSecret usage by scenario.

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, openWorldHint=true, destructiveHint=false, so safety and openness are covered. The description adds important behavioral context beyond annotations: the count is free and doesn't cost credits, and it explains the revenue-band sampling limitation (up to 100 companies, revenueScope.complete false means a sample) plus the zero-result caveat. This is valuable operational transparency.

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?

Well-structured and front-loaded with the core verb and benefit, followed by usage strategy and filter list. The second half is dense and slightly long, but every sentence provides actionable information. Minor verbosity in the filter enumeration.

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 14 parameters and no output schema, the description covers the essential context: what it returns (a count), when to use it, how to combine filters, the sampling caveat, and the zero-result interpretation. An agent has enough to call it correctly 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 100%, so each parameter is already documented in the schema. The description enumerates the filter categories (keywords, titles, locations, etc.) and adds some naming/flow context (use companyIds from find_companies), which is minor since the schema already carries the detailed semantics. Baseline 3 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?

States a precise verb+resource+scope: 'Count how many LinkedIn people match a filter set'. It explicitly distinguishes itself from search_people by noting it should be used BEFORE it, and describes the exact nature of the count (free, instant, exact).

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

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

Gives explicit when-to-use guidance ('Use this BEFORE search_people to size a market'), prescribes a workflow (fan out several angles, union the ones that land), and explains why ('counting never costs credits, so go broad'). It also warns about a common pitfall (a zero from one filter is not an empty market, try another angle).

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, destructiveHint=false, and openWorldHint=true, so the mutation profile is covered. The description adds genuinely non-annotation context: quota limits per plan and the default that the setup is created in 'completed' state so it is immediately usable. It omits auth/permission requirements and error behavior when the quota is exhausted.

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

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

Three sentences, front-loaded with the core action and its gating condition, and no witnessed filler. Slightly verbose on the plan enumeration but each sentence carries 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?

For a mutation tool with 11 parameters, nested objects, zero required fields, and no output schema, the description is adequate but thin: it never says what happens on quota exhaustion, whether omitted nested objects are left empty or defaulted, or what the call returns (setup id?). The quota and default-status details are the useful additions; the rest relies on the 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?

With 11 parameters at 64% schema coverage, the schema does most of the explanatory work. The description's only parameter-relevant statement ('Creates a completed setup by default') merely restates the schema's status default and adds no new meaning for the nested signalAgents, businessContext, campaignSettings, or idealCustomerProfile objects.

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?

Specific verb + resource ('Create a new LinkedNav AI setup'), which cleanly separates it from update_ai_setup, get_ai_setup, and generate_ai_setup_icp. It does not name those siblings explicitly, but the resource and verb make the distinction readable 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?

Gives a concrete precondition ('when the account has an available setup slot') with plan-based quotas (Pro 3, Standard/free/trial 1), which is real when-to-use guidance. It stops short of naming alternatives (e.g. update_ai_setup for an existing setup, generate_ai_setup_icp for ICP drafting) or stating what to do when no slot exists.

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 declare readOnlyHint=false and destructiveHint=false; the description adds genuinely behavioral context beyond them: sendMode is IMMUTABLE after creation, Pro-only gating for AI/follow-ups/InMail, and that enabling follow-ups without Pro errors. It does not describe permissions, rate-limit behavior, or response shape beyond the ID, so it is strong but not exhaustive.

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 purpose and return value are front-loaded, then the mode taxonomy, and every sentence carries real content. It is a dense single block that repeats some sendMode/Pro-only detail already present in the schema, so there is minor redundancy, but nothing is 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 17-parameter tool with nested objects and no output schema, the description covers the two main creation flows, their gating rules, and the return value ('campaign ID'). It does not enumerate parameter defaults or the full follow-up structure, but the schema descriptions carry those, so coverage is adequate.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds cross-parameter logic the schema states only locally: campaignType determines which parameters matter, AI mode makes messageTemplate/inMailSubject optional, and promptId is ignored for outreach. That relational guidance raises it above baseline.

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 ('Create a new campaign in LinkedNav') and states the return value ('Returns the campaign ID'). It then distinguishes the two campaign types and routes the agent to the correct add-leads sibling for each (add_lead_to_campaign vs add_message_targets), so it is separable from create_comment_campaign, duplicate_campaign and other siblings.

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

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

It clearly explains when each campaignType applies ('outreach' vs 'message'), the two message send modes, and that AI mode/follow-ups/InMail are Pro-only, giving strong selection context. It stops short of naming explicit alternatives to avoid (e.g. duplicate_campaign, create_comment_campaign) or stating when not 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?

Annotations only say readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds valuable non-obvious behavior: campaign is created in DRAFT, sourceMode is immutable after creation, and Pro-only features. These are exactly the transaction-state facts annotations can't 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?

Front-loads the tool purpose and core mode distinction, then layers in constraints and next steps. Dense but nearly every clause carries a real constraint (immutability, Pro-only, draft state).

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 14-parameter creation tool with no output schema, the description covers the critical workflow (create draft, add targets, activate) and the two-mode model. It could note the approvalMode/scheduleSend interplay but the schema handles specifics well.

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 93%, so parameters are already well documented. The description reinforces the sourceMode/monitor mode distinction and the draft-then-add-targets workflow, but adds little parameter detail beyond what the schema already 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?

States a specific verb+resource (create comment campaign) and immediately distinguishes the two modes (posts vs monitor) that define this tool. It contrasts with sibling create_campaign by specifying COMMENT campaign and names activate_campaign as the follow-up step.

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?

Clearly explains the two sourceMode choices and what each requires, plus the Pro-only constraints. It names the next step (activate_campaign), but doesn't explicitly say when to prefer this over create_campaign or duplicate_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 declare a non-destructive mutation (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the bar is lowered. The description still adds genuinely useful, non-obvious behavior: silent skipping on duplicates and the dedup key (LinkedIn URL), plus what a contact becomes once in a campaign.

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-loads the action and target before the clarifying parenthetical. Dense but each sentence (identity, sibling equivalence, dedup) carries distinct information; the terminology digression is the only mild clutter.

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 25-param, no-output-schema tool, the description covers the important hidden semantics (dedup, record aliasing). It omits what a caller gets back on success versus skip, which matters slightly more because there is no 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 description coverage is 100% and the 25 parameters are richly documented in the schema itself, so baseline 3 applies. The description's only param-relevant signal is the profileUrl dedup key, which is behavioral rather than adding field-level meaning.

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

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

States a specific verb+resource ("Add one LinkedIn profile as a new contact") and grounds it in the product UI ("Contacts" page, /app/contacts). It explicitly names the sibling create_lead and declares equivalence, so the agent can distinguish it from other create_* tools without opening a 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?

Identifies the direct alternative (create_lead) and asserts they are identical, which helps selection. It also explains record identity (contact/lead/prospect) and silent-skip dedup, but gives no explicit when-to-use vs bulk siblings like create_leads_bulk or add_lead_to_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 only say readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds the facts an agent actually needs: nothing is public, nothing is charged until publish, the return is a draft id, and there is a hard 20/day allowance. That is substantial behavior disclosure 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?

Three sentences, front-loaded with the safety-critical 'draft, nothing public, nothing charged' fact, then id sourcing, then the operational constraints. No padding.

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?

Despite 11 parameters, nested objects, and no output schema, the description supplies the return value, the draft/charge semantics, and the rate limit. What it omits is the recruiter-posting path where the schema notes LinkedIn requires project, functions, industries, seniority and applyMethod — a meaningful gap for a complex create.

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 64% and the schema itself documents the id/free-text duality and the recruiter block. The description repeats the lookup_search_ids sourcing rule for three fields but says nothing about the recruiter-only requirements (project, functions, industries, seniority, applyMethod) or workplace/description/connectionId. Baseline 3 is right given the schema already carries most parameter meaning.

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

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

States a specific verb and resource ('Create ONE LinkedIn job posting') plus the crucial scope qualifier that it lands as a DRAFT on your own account. It explicitly separates itself from publish_job_posting, so an agent knows this alone does not make anything live.

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 clear prerequisites — ids for title/company/location must come from lookup_search_ids with named types, with a free-text fallback when no id exists. It also signals the create-then-publish sequence. It does not contrast against edit_job_posting or list_job_postings, which keeps it from 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 only show readOnlyHint=false and destructiveHint=false. The description adds important context beyond annotations: dedup by LinkedIn URL, silent skip on duplicates, and the semantic mapping of lead/contact/prospect. Lacks detail on permissions or side effects like campaign enrollment.

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

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

Three compact sentences, front-loaded with the core action and resource. 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?

Given 25 parameters covered fully by schema descriptions and no output schema, the description provides the essential conceptual context (lead=contact, dedup, silent skip) that an agent needs to use the tool correctly. Missing return behavior, but no output schema exists to carry that.

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

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

Schema description coverage is 100%, so the schema already provides rich parameter documentation. The description does not add meaning beyond what the schema covers. Baseline 3 applies.

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

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

Specific verb+resource ('Add one LinkedIn profile as a new contact in LinkedNav') and clarifies the domain concept that lead=contact=prospect. Also explicitly names the sibling create_contact and states equivalence, which helps the agent route correctly.

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?

Mentions it is 'Identical to create_contact' and describes the dedup behavior ('Skips silently if the profile already exists'). However, it doesn't say when to prefer this over create_contact, create_leads_bulk, or add_lead_to_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 only declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds genuinely useful behavior beyond that: the 50-item cap, the four possible per-lead statuses, silent de-duplication, and the 'Contact limit reached' skip reason. It omits auth/permission requirements, keeping it short of 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?

Two tightly written sentences with the key constraint (50, single call) front-loaded and the return/edge-case behavior following. Every clause earns its place.

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

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

With no output schema, the description usefully documents the per-lead return statuses, which is the main thing an agent needs to interpret results. It could say more about required fields or auth, but for a bulk create with a fully-documented schema it is largely 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 100%, so the nested lead fields and listId are already documented in the schema. The description adds nothing about parameter syntax or format beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Add up to 50 LinkedIn profiles as contacts/leads'), plus the batch scope ('in a single call'). The parenthetical '(the "Contacts" page)' hints at its distinction from campaign-scoped siblings like add_leads_bulk_to_campaign, but no sibling is named explicitly, so the differentiation is implicit rather than stated.

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 conveys the batching context and notes behaviors like duplicate skipping, but never says when to choose this over create_lead (single) or add_leads_bulk_to_campaign. Usage is only implied by the 'single call' framing.

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, destructiveHint=false, and openWorldHint=false, so the agent knows this is a non-destructive local write. The description adds only the "active setup" scoping detail, which is genuinely useful context, but says nothing about name-collision behavior, whether the list starts empty, or what identifier comes back.

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

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

A single front-loaded sentence with no filler or repetition. It is tight, though arguably under-specified for a tool with a nested parameter object.

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 create tool with a nested object parameter, no output schema, and no annotations describing the result, the description should say at least what is produced or how the nested template is used. It leaves the messageTemplate semantics and the created list's identity unaddressed.

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

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

At 75% schema coverage the schema already documents name, color, and description, and the description adds nothing on top of them. The most complex input, the nested messageTemplate object with its static/personalized enum and customMessage/personalizedPrompt fields, has no explanatory text anywhere, and the description does not compensate.

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

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

The description names a specific verb and resource ("Create a new LinkedNav contact list") and scopes it to "the active setup", which separates it from sibling creators like create_campaign, create_contact, and create_lead. It stops short of naming the related list tools (update_list, delete_list, link_list_to_campaign), so sibling differentiation is only partial.

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

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

There is no statement of when to use this tool versus alternatives, no prerequisites, and no mention of related operations such as afterward linking the list to a campaign or updating/deleting it. An agent must infer usage purely from the name.

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?

Goes well beyond the annotations: public immediately, irreversible ('cannot edit or delete it afterwards'), counts against a 5/day allowance, and requires user confirmation. These are exactly the safety-critical traits an agent needs before calling a destructive, open-world write tool.

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

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

Front-loads the core action and constraint before enumerating optional capabilities, which is the right order. The long enumeration of optional features adds some density but each item maps to a real parameter, so little is wasted.

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

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

Covers irreversibility, confirmation, rate limits, and key options for a 10-parameter open-world mutation with no output schema. It does not say what a successful call returns (e.g. the new post id/URL), which an agent may need for follow-up calls, but otherwise it is 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 100%, so each parameter is already documented in the schema; the description's list of optional features (images, repost, mentions, job card, company page, audience) largely restates what the schema covers. Baseline 3 is appropriate since the schema carries the semantic load.

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

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

States a specific verb and resource ('Publish ONE post on your own LinkedIn profile, now') with scope that separates it from comment_on_post, repost, campaign/post-target tooling, and scheduled variants. The 'ONE' and 'own profile' qualifiers further distinguish it from bulk or third-party posting.

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 clear when-to-use context (immediate publishing) and a critical precondition ('show the user the exact text and get a yes first'), plus the 5-a-day constraint. It does not explicitly name sibling alternatives (e.g. scheduled posting via add_post_targets), so routing is implied rather than spelled out.

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=false, so mutation semantics are known. The description adds two genuinely useful behavioral facts beyond that: there is no prompt slot limit, and omitting sourceAiSetupId falls back to the active setup. It says nothing about duplicate-name behavior, validation failures, or what the call returns.

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

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

Three short sentences, purpose front-loaded, with the setup fallback placed last. "There is no prompt slot limit" earns its place as a planning constraint, though no sentence is wasted or padded.

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 18 parameters, a nested followUp object, three enums and no output schema, a three-sentence description leaves gaps: the agent is not told what is returned (e.g. the new prompt ID) or how to handle an existing name. The rich schema compensates for most parameter detail, but the create-and-return flow is under-described.

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 78%, well above the 50% threshold, so the schema already documents nearly every parameter including the legacy-vs-live content/context split and follow-up step modes. The description only restates the sourceAiSetupId default, adding little beyond structured data; baseline 3 applies.

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

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

Sentence one states a specific verb and resource ("Create a new LinkedNav prompt template"), which is clearly distinct from update_prompt, delete_prompt and get_prompt in the sibling list. It lacks any explicit differentiation sentence naming those siblings, so it stops short of 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?

The description gives one conditional usage rule: when sourceAiSetupId is omitted the active setup is used. It does not say when to call create_prompt versus update_prompt, whether an AI setup must exist first, or what happens if a prompt with the same name already exists.

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 safety profile is covered. The description adds real value beyond that by disclosing permanence and collateral damage ('including the user's notes on it'), telling the agent exactly what else is destroyed. It stops short of stating irreversibility or whether the action can be undone.

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

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

One sentence, front-loaded with the destructive action, then scope, then the collateral effect. No filler; every clause earns its place.

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

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

For a single-parameter destructive tool with no output schema, the description covers the action, the identifier source, and the side effect on notes. Minor gaps remain around irreversibility/recovery and behavior when the key doesn't exist, but nothing essential to correct invocation is missing.

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

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

Schema coverage is 100% and the schema already documents the key format (normalized LinkedIn URL or lowercased name), so the baseline is 3. The description adds provenance ('as returned by crm_list_cards'), which helps the agent locate a valid key rather than guessing one.

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

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

States a specific verb+resource ('Permanently delete one CRM board card') with explicit scope ('one ... by its key'), and names the sibling (crm_list_cards) that produces the key. An agent can distinguish this from crm_upsert_cards or bulk_delete_contacts immediately.

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

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

The description tells the agent where the key comes from ('as returned by crm_list_cards'), which implies the correct workflow, but gives no explicit when-to-use/when-not guidance and no alternatives for other deletion paths. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint/openWorldHint=false/destructiveHint=false, so safety is covered. The description adds genuine operational nuance the annotations do not: that the response is compact with conversations stripped, and the pitfall that the linkedinUrl key is lowercased and must never be used to construct a link.

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

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

Three dense sentences, front-loaded with the core action and scope, then filters, then return-shape guidance. No filler, and the parenthetical warnings are placed directly next to the fields they qualify.

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

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

With no output schema, the description usefully discloses return fields (linkedinUrl, chats[].chatId) and the key-lowercasing gotcha. It omits list size, pagination or ordering behavior, which an agent listing cards might need to know.

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

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

Schema description coverage is 100% and the enum for stage is fully spelled out in the schema, so parameters are already documented. The description only restates 'filter by stage or by needsFollowUp' without adding format or semantics, which is the baseline-3 case.

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

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

States a specific verb+resource (list CRM board cards) and immediately scopes it as 'compact: no conversation', which separates it from conversation-fetching siblings like get_inmail_conversation and get_conversation. An agent can pick it correctly without opening the schema.

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

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

Gives the two optional filter conditions (stage, needsFollowUp) and routes the agent onward: read a thread with get_inmail_conversation, and 'no person lookup needed'. It lacks explicit when-not-to-use guidance relative to non-list CRM siblings (crm_upsert_cards, crm_delete_card), 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 declare destructiveHint=true, and the description earns that by spelling out exactly what is destroyed: supplied fields overwrite stored values, and messages/callNotes REPLACE the stored arrays entirely. It also discloses the protective exceptions (the user's own notes are never touched; a hand-set stage is preserved unless forceStage is true), which the annotations cannot express.

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?

Four tight sentences, front-loaded with the identity/matching rule, then overwrite semantics, then the two exceptions. No filler and nothing restated from the title without added 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?

For a destructive bulk upsert with no output schema and one top-level array parameter, the description covers identity, limits, overwrite behavior, and the stage-lock exception — the information an agent most needs before writing. It omits any mention of failure handling or partial-success behavior across a 50-card batch, which is the remaining gap.

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

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

Schema coverage is 100%, so field-level documentation is already carried by the schema; the description adds the cross-parameter semantics that matter most — key normalization fallback, array replacement vs field overwrite, and the stage/forceStage interaction. This is meaningfully more than the schema alone.

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

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

States a specific verb pair and resource ('create or update CRM board cards'), gives the cardinality rule (one per person, up to 50 per call), and the identity rule (matched by key). An agent can immediately distinguish it from siblings like crm_list_cards and crm_delete_card.

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 matching rule implies when this tool is appropriate (when you have card identities and want to upsert), but there is no explicit when-to-use vs crm_delete_card / crm_list_cards guidance and no stated prerequisites. Usage is implied rather than directed.

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 safety profile is known; the description adds real value beyond that by disclosing the blocking precondition and the confirm requirement. It stops short of saying whether the deletion is reversible or what happens to the setup's artifacts.

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

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

Three short sentences, each earning its place: what it deletes, the precondition, and the required flag. The scoping and gating information is front-loaded 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 destructive two-parameter mutation with annotations covering the safety hint and no output schema, the description supplies the key operational facts (precondition, confirm flag). Minor gaps remain on reversibility, failure behavior, and setupId sourcing, but nothing essential is missing.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does clarify that confirm must be true (the schema only shows default false), but says nothing about setupId — where to obtain it or what it identifies — leaving half the parameters unexplained.

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

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

States a specific verb (Delete) and resource (AI setup), and narrows scope to 'a draft or completed AI setup'. The resource is clearly distinct from the other delete_* siblings (campaign, contact, list, prompt) and from get_/update_/select_ai_setup, so an agent can route without opening a schema.

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

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

Gives an explicit precondition — deletion is 'Only allowed when no scoped campaigns, lists, or contacts remain' — which tells the agent when this call will fail. It does not, however, name the alternative path (e.g., removing dependent campaigns/lists first, or using update_ai_setup), leaving the remediation 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, so the safety profile is covered. The description adds real value beyond that by disclosing the cascade effect (removing campaign membership from contacts) and the confirm:true requirement, which are not visible elsewhere.

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

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

Two tight sentences, front-loading the action and side effect, with the invocation requirement last. No filler, nothing redundant.

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 two-parameter destructive tool with annotations covering the safety profile and no output schema, the description covers the main behavior and invocation requirement adequately. It could add whether deletion is permanent, but that gap is minor.

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 load. It explains the confirm parameter's meaning (must be set true to proceed) despite the schema marking it optional with default false — a valuable clarification — but says nothing about campaignId beyond its name.

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

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

States a specific verb and resource ('Delete a campaign') plus the notable side effect of removing campaign membership from contacts. This clearly distinguishes it from create_campaign, update_campaign, and pause_campaign, though it does not name a specific sibling to differentiate scope from remove_leads_from_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?

Provides a precondition ('Requires confirm: true') that the agent must satisfy to invoke it successfully, which is useful. However, it offers no when-to-use versus alternatives (pause_campaign, update_campaign) and no explicit statement that the action is irreversible.

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?

Goes well beyond the destructiveHint annotation by naming what is destroyed (the conversation on LinkedIn itself), that it is irreversible, and that it consumes a scarce daily allowance (100/day). Those facts materially change an agent's decision to call it.

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

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

Three short sentences, front-loaded with the destructive action and scope, followed by consequence and quota. No filler or repetition of the title.

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

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

Annotations already declare the destructive/open-world profile and the schema documents both params, so the description only needed consequence and quota context — which it supplies. A note on downstream effects (e.g. whether the thread also vanishes from unibox) would have closed the last gap.

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

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

Schema coverage is 100% and both parameters are documented there, including where chatId comes from (list_chats) and the connectionId fallback. The description adds nothing to parameter meaning beyond emphasizing a single chat, so baseline 3 applies.

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

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

Specific verb 'Delete' plus precise resource and scope: 'ONE of your LinkedIn conversations from your inbox'. The 'ONE' emphasis separates it from bulk operations like bulk_delete_contacts, and 'conversation' separates it from delete_message.

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 precondition ('confirm with the user first') and a quota constraint, which is strong operational context. It stops short of naming the sibling alternative (e.g. delete_message for a single message) for an agent that wants a narrower deletion.

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, readOnlyHint=false and openWorldHint=false, so the safety profile is covered. The description adds a concrete precondition the annotations do not: the call requires confirm: true, a behavioral gate the schema only hints at via default: false. It still omits irreversibility and what gets removed alongside the contact.

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

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

Two short sentences, both front-loaded and load-bearing: scope first, then the required flag. 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 destructive mutation with no output schema and no schema parameter docs, the description covers the confirm gate but leaves gaps: what deletion actually removes, whether it is reversible, and how to obtain a valid contactId. An agent can call it, but without full confidence about side effects.

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 carry the burden. It explains confirm fully ('requires confirm: true') but says nothing about contactId — no ID format, source, or example. It compensates for one of two undocumented parameters.

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

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

States a specific verb and resource ('Delete one contact') and the qualifier 'one' implicitly separates it from the sibling bulk_delete_contacts. It does not name the alternative explicitly, but an agent can tell single-delete from bulk-delete from the wording alone.

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

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

The word 'one' implies this is the single-record path versus bulk_delete_contacts, and the confirm requirement is stated, but there is no explicit when-to-use/when-not guidance or prerequisites (e.g., permissions, cascading effects on campaigns/lists).

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 real value beyond them: it discloses the side effect that contacts are moved to the setup default list (not deleted), and that confirm must be true. It stops short of stating irreversibility or permission requirements, but the contact-migration disclosure is exactly the kind of context annotations cannot carry.

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

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

Three short sentences, each earning its place: what is deleted, what happens to contacts, and the required flag. The destructive side effect is front-loaded where the agent will see it 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?

For a two-parameter destructive tool with no output schema, the description covers the essential context: scope constraint, side effect on contacts, and the confirmation precondition. Missing only minor details such as irreversibility or error behavior when the target is a default list.

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 burden. It clarifies the semantics of the confirm boolean ('Requires confirm: true'), which is genuinely useful, but says nothing about listId beyond its name, leaving half the parameters undocumented in both schema and description.

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

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

States a specific verb (Delete) and resource (a non-default list from the active setup), with a scope qualifier that pins down exactly what can be targeted. An agent can immediately tell this apart from create_list/update_list and understands the default list is off-limits.

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 'non-default' qualifier implicitly excludes default lists and 'Requires confirm: true' states a call precondition, but there is no explicit when-to-use guidance or named alternative (e.g., bulk_delete_contacts, update_list). Usage is implied rather than stated.

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

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

Annotations already declare destructiveHint=true, but the description adds the details an agent actually needs: deletion is visible to everyone in the conversation, is irreversible, is time-boxed to 60 minutes, and consumes a 100/day allowance. Rate limit and irreversibility are not encoded anywhere in the annotations or 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?

Four short sentences, front-loaded with the action and scope, then the hard constraints in descending order of importance. 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 destructive two-parameter tool with strong annotations and no output schema, the description covers scope, irreversibility, time window and quota. Minor gap: it does not say what happens if the 60-minute window has lapsed (error vs. silent no-op).

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

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

Schema coverage is 100%, so both messageId and connectionId are already documented in the schema. The description adds only the implicit constraint that messageId must reference a message the caller sent; it clarifies nothing about connectionId or ID sourcing beyond the 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?

States a specific verb and resource ('Delete ONE message you sent on LinkedIn'), plus scope qualifiers (one message, sent by you, for everyone in the conversation) that separate it from delete_chat and edit_message in the sibling list.

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 clear gating conditions — only messages you sent, only within 60 minutes — which effectively define when the call can succeed. It does not explicitly name alternatives (e.g. edit_message or delete_chat), so it stops short of full when-not routing.

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, but the description adds substantial beyond-schema detail: ACTIVE campaigns are auto-paused with a specific reason, queued sends are cancelled, and the template-only campaign exception is called out. This is exactly the context an agent needs before a destructive cascade.

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-loaded with the core action, then the destructive consequences, then the exception, then prerequisites. The parenthetical aside is dense with useful information and earns its place; no padding.

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

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

No output schema exists, so the description carries the return/effect burden and does so fully by describing the cascade side effects. Everything an agent needs to invoke this destructive tool correctly is present.

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

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

Schema coverage is 100%, so both promptId and confirm are documented in the schema itself, including confirm's 'must be true' semantics. The description restates 'Requires confirm: true' without adding meaning beyond the schema, so baseline 3 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?

States a specific verb (Delete) and resource (LinkedNav prompt template) with the identifier scope ('by ID'). Clearly distinguishable from sibling delete tools like delete_campaign, delete_contact, delete_list, and delete_ai_setup.

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

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

Explicitly directs the agent to call get_prompt first to inspect campaignCount before deleting, and states the confirm prerequisite. It lacks an explicit 'when not to use' framing, but the cascade warning effectively tells the agent when this is dangerous.

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 real value beyond them: deleted intent leads are permanently blocked from being re-added by daily runs, and the call requires confirm: true. It leaves some gaps (what happens to non-intent deleted leads, behavior when a URL is unmatched), keeping it short of 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?

Three sentences, none wasted, with the core action and agent scope front-loaded before the identifier sourcing and the confirm requirement. Tight, though the third sentence carries several distinct facts at once.

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 tool with no output schema, the description covers the input source, agent scoping, the re-add blocking side effect, and the confirm gate — essentially everything needed to invoke it correctly. Minor omissions (per-agent irreversibility, partial-failure behavior) are the only gaps.

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

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

Schema coverage is 67% and the confirm parameter has no schema description at all; the description compensates by stating 'Requires confirm: true' and by clarifying that linkedinUrls accepts vmids or company IDs for the intent agent. This meaningfully extends the schema rather than restating it.

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

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

States a specific verb and resource ('Delete collected signal-agent result leads') and scopes it to exactly one agent, enumerating the three agent types. An agent can distinguish it from siblings like clear_signal_agent_results or get_signal_leads without inspecting 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?

Tells the agent where the identifiers come from ('Pass the lead linkedinUrl values returned by get_signal_leads') and notes the intent-specific alternatives (vmids or company IDs), which is clear invocation context. It does not, however, contrast itself with the sibling clear_signal_agent_results or state when deletion should be preferred over clearing all results, so no explicit alternatives/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 declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds the useful fact that both pending and failed comments can be denied and that the outcome is suppression of posting, but it omits whether the denial is reversible, what happens to the underlying comment, and any permission requirements.

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

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

A single front-loaded sentence with no filler; the effect is stated immediately after the action.

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 one-parameter mutation with annotations covering destructiveness and no output schema, the description conveys the action, the eligible states, and the result. The remaining gap is the source/format of the ID, which is minor.

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% for the single required parameter, and the description adds nothing about pendingCommentId — no format, no note that it comes from get_pending_comments or get_pending_comments_count. It fails to compensate for the coverage 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?

States a specific verb (deny) plus resource (pending/failed AI comment) and the resulting effect ('so it will not be posted'), which cleanly distinguishes it from approve_pending_comment and retry_pending_comment. It does not explicitly name those siblings, so it falls short of 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?

The phrase 'pending or failed AI comment' implies the applicable state, so usage is inferable. However, no alternatives are named and no when-not condition (e.g., use retry_pending_comment to regenerate instead) is given.

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 openWorldHint=true; the description adds real semantic context the annotations lack: the denial is permanent for that step, and it explains downstream meaning for invitations vs. follow-ups. It stops short of stating undo/recovery options or what the call returns.

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

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

Two compact sentences, front-loaded with the core action and followed by consequences. The parenthetical examples earn their place by clarifying the two-domain semantics.

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

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

For a single-parameter destructive mutation with no output schema, the description supplies the key behavioral facts (permanence, per-step effect, invitation/follow-up outcomes). A note on whether the denial can be reversed or the message re-queued would close the remaining gap.

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

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

Schema coverage is 100% and the single parameter is documented there, including its provenance ('from get_pending_outbound'). The description adds no further syntax or identifier-format detail, so baseline 3 applies.

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

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

States a specific verb+resource and a scope ('Decide NOT to send ONE held campaign message'), clearly distinguishing it from approve_pending_outbound and update_pending_outbound. The permanence qualifier further narrows it.

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 clear decision context (deny vs. send a held message) and consequences that help the agent choose. It does not explicitly name approve_pending_outbound as the alternative or state exclusions, but the implied contrast is strong.

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 disclose destructiveHint=true and readOnlyHint=false, so the mutation profile is known. The description adds real value beyond that: it explains the optimistic-concurrency guard via expectedVersion, warning that a draft rewritten since being shown will not be denied unseen.

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

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

Two tight sentences, front-loaded with the action and then the safety-catch rationale. No filler text.

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, no-output-schema mutation, the description covers the effect on the reply and the version-safety behavior. It omits what happens on a version mismatch or whether the denial is reversible, but is otherwise sufficient to invoke correctly.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It explains expectedVersion's source ('the draft's `version` from get_pending_replies') and its purpose as a staleness guard, though pendingReplyId is left to inference from its name.

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

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

States a specific verb (deny), a specific resource (pending or failed AI reply), and the concrete outcome ('so it will not be sent'). This clearly separates it from siblings like approve_pending_reply, retry_pending_reply, and update_pending_reply.

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?

Implies when to use it (to prevent an AI reply from being sent) and adds explicit guidance on the expectedVersion argument's role in avoiding denial of a stale draft. It does not, however, name an alternative tool or state 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 declare readOnlyHint/destructiveHint, and the description goes well beyond them with status-aware branching: drafts yield activation blockers matching the checks activation enforces, paused campaigns yield pause reason + reason-specific fix + resume viability, active campaigns yield silent-stop detection plus next send time in Eastern time. It also discloses the blocker output format (what/why/how/action with the fix tool), which is substantial behavioral disclosure not available in annotations or 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?

Front-loads the trigger phrase ('use whenever...'), then behavior, then the output contract. Dense and information-rich, with every sentence contributing, though the long compound trigger sentence and 'CAMPAIGN DOCTOR' branding add slight bulk without new 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?

There is no output schema, so the description must carry return semantics, and it does: it explains what is returned per campaign status and the what/why/how/action structure of each blocker. An agent has everything needed to call it 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 coverage is 100% and the single campaignId parameter is fully documented in the schema (including the omit-to-auto-pick fallback logic). The description adds nothing about the parameter, so the baseline of 3 applies where the schema does all the work.

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

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

States a specific verb+resource (diagnose a campaign) and frames it as a 'CAMPAIGN DOCTOR', which clearly separates it from data-fetching siblings like get_campaign/get_campaigns and from state-changing siblings like activate_campaign/pause_campaign. An agent can tell what this does without opening 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?

Gives unusually rich trigger conditions: 'use whenever the user asks why a campaign won't start, can't activate, is paused, stopped sending, isn't working, or what's wrong with its settings.' It does not, however, name explicit alternatives (e.g., get_campaign for raw config) or state when NOT to use it, so it falls just short of the when/when-not/alternatives bar.

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 say readOnlyHint=true/destructiveHint=false, and the description reinforces rather than contradicts that ('SAVES NOTHING AND POSTS NOTHING'). It then adds behavior annotations can't express: it is stateless and requires the caller to pass back usedShapes, it returns up to three targeted questions instead of a draft when material is missing, and it refuses to fabricate years, numbers, names or events.

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-loaded with the core purpose and the not-a-publisher warning, then the shape rotation, then the missing-material protocol. Dense but every block carries operational information; there is minor redundancy between 'leaning on what their best posts did' and 'The first draft is in the way of their best posts', which repeats the same idea.

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

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

No output schema exists, and the description compensates fully by specifying both possible return shapes (a draft, or up to three questions with example answers) and the loop that follows each. It also covers statefulness, language defaulting, and the terminal publish step, so an agent can drive the whole interaction without guessing.

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 already 100%, so the schema documents each parameter's format. The description still earns extra credit by explaining the usedShapes rotation contract and by mapping the opaque enum values (their_own_way, story_lesson_advice_you, low_to_high, timeline, starting_line) to human-readable shapes, plus clarifying that 'details' should carry the user's answers to prior questions.

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

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

States a specific verb and resource — 'drafts ONE LinkedIn post in the user's own voice' — and immediately differentiates itself from create_post by declaring it saves and posts nothing. The voice-mimicry mechanism (reads their recent posts, leans on best-performing shapes) makes the resource unambiguous even among 200+ 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?

Explicit positive guidance ('Use this instead of writing a post yourself'), explicit negative guidance ('For small edits the user asks for, change the draft yourself — calling again moves to the next shape'), and explicit handoff to a sibling ('publish it with create_post only after the user says yes'). The follow-up-call protocol and the writeAnyway escape hatch are both defined.

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=false, so the safety profile is covered. The description adds real behavioral content beyond that: prospects are copied conditionally, and message campaigns carry settings only, requiring add_message_targets for recipients. It does not say whether the duplicate starts paused/active or what it returns.

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

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

Two tight sentences, zero filler, with the core action and the conditional copy behavior front-loaded before the add_message_targets pointer.

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

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

No output schema exists, so the description should say what a successful duplicate yields (new campaign ID, initial state), which it does not. For a mutation tool with several sibling campaign tools, that return-value gap is the main missing piece.

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 carry parameter meaning. It explains copyProspects well (default false, prospects excluded unless true), but leaves name and campaignId entirely uninterpreted, so only one of three parameters gets semantic help.

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

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

States a specific verb+resource (duplicate a campaign configuration) with the scoping qualifier 'in the active setup', which separates it from create_campaign and update_campaign in the sibling list. It does not explicitly name those siblings, so it stops 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?

Gives a clear selection rule: prospects come along only when copyProspects is true, and names add_message_targets as the tool to use when adding recipients to a message campaign instead. It does not address when to duplicate versus build a campaign from scratch with create_campaign, but the context given is solid.

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 declare destructiveHint=true and openWorldHint=true, and the description adds substantive behavior on top: on a published posting the edit becomes public immediately, so the user must see the change first, and there is a 20/day quota. That is exactly the kind of consequence and rate-limit context the annotations cannot 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?

Two compact sentences with the partial-update rule front-loaded, followed by the visibility consequence and the quota. No filler, and every clause carries operational weight.

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 12-parameter nested mutation with no output schema, the description covers the risk profile (public, immediate), the caller's obligation (preview), and the throttling limit. It leaves the recruiter-vs-standard posting distinction and per-field semantics to the schema, which is a small remaining gap rather than a blocker.

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