PoliteReach

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

Annotations already carry the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds genuinely useful behavior beyond that: DB-backed and instant, the worker sends these by itself (no manual send needed), and results are capped with a `truncated` signal. It stops short of describing row fields, but that is a minor 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?

Front-loads the core purpose, then timing behavior, then the alternative-tool routing, in compact sentences with no filler. Every clause carries information an agent would otherwise have to infer.

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 list tool with no output schema, the description still discloses result sizing (limit default 100) and the truncation signal, plus the routing to sibling tools. 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 description coverage is 100%, so the schema already documents limit, sessionId, and sessionLabel fully (including the default and how to resolve ids). The description restates the limit/truncated behavior but adds no syntax or format detail beyond the schema. Baseline 3 is correct when structured data does the heavy lifting.

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 with an exact scope: contacts whose invite was ACCEPTED but first message not yet sent (the Day-1 starter queue). It names the sibling it is not (li_due_messages for past-due openers) so an agent can disambiguate 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?

Explicitly routes to alternatives with the selecting condition: past-due openers go to li_due_messages, timed steps to li_scheduled_steps, and new acceptances are recorded via li_poll_acceptances. It also explains when rows naturally appear (connectionWaitHours / sending hours), which is the 'when this is normal' context an agent needs.

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 destructive/openWorld annotations: it discloses that the tool returns a job id without waiting and why, that non-connection invitations (newsletter/page-follow) are irreversible if wrongly accepted and are now refused by default, that confirmAccept=true is required for mutation, and that the run auto-writes triage memory decisions including failed-retry reasons.

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, scoping, and the confirmAccept requirement in the first sentence. It is long (five paragraphs), but with no output schema the outcome/triage detail is load-bearing rather than filler; only minor tightening is possible.

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?

Because there is no output schema, the description carries the full return contract: job-id async pattern, per-person outcome reasons, pageState diagnosability, the meaning of ok:false, and the triageMemory side effect. An agent can call and interpret this tool without further documentation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: why wait defaults false, how maxAccept defaults differ (profileUrls count vs 20 pending), what confirmAccept=false produces ('reads the page and previews'), and the irreversible consequence guarded by acceptNonConnection.

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 with explicit scope: 'Accept connection requests sent TO this account.' The 'TO this account' / inbound framing distinguishes it from outbound siblings like li_send_connection_now, and the CONNECTION REQUESTS ONLY constraint sharpens the boundary further.

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 guidance: pass profileUrls to target specific people, omit to accept all pending up to maxAccept, and 'Pass wait=true only for a handful of people.' It also routes retries to li_received_invitations onlyUnreviewed and reading to li_job_result. It does not explicitly name a near-alternative tool for the accept action itself, but the operational conditions are well specified.

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 readOnly/non-destructive/non-openWorld, but the description adds real behavioral context: work runs one browser session at a time so 'queued' is normal, the tool is DB/queue-backed and costs no browser time, and inviteHold/notes semantics are explained including LinkedIn's lack of a number. Only return shape for other fields is left implicit.

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?

Dense but front-loaded: the core picture comes first, then the stuck/idle guidance, then the sibling routing. It runs long as one paragraph, but nearly every clause 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?

With no output schema, the description compensates by describing the returned content (live.summary one-liner, notes, inviteHold) and the cost model. An agent has everything needed to call and interpret it.

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

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

Schema coverage is 100%, so both params are documented there; the description still adds useful meaning by stating that omitting the selector returns every visible account, which the schema does not convey.

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

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

States a specific verb+resource+scope: a live per-account picture of running, queued, and scheduled work plus invite/message counters. It explicitly distinguishes itself from li_list_accounts (configuration), li_daily_digest (day totals), and li_job_result (one job's outcome).

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 when-to-use rule ('Read this before telling the user an account is stuck or idle') and names the alternative tools for adjacent questions. It also states the default behavior when no selector is passed and the recovery tool for inviteHold.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Nothing here sends anything,' then adds substantial non-obvious behavior: which cohorts get dropped and counted in `excluded`, that `nextAction` flips from nudge to close when nudges run out, and that the send tools re-check every rule and refuse in words. This is meaningfully more than the annotations convey.

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

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

It is front-loaded with the one-line definition of the population, then structured into row-field, exclusion, and action paragraphs where each sentence carries information. It is dense and long, but nearly every clause earns its place; only marginal tightening is possible.

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 enumerates the returned row fields (name, company, bookingLinkSentAt, nextAction, thread, etc.) and explains their meaning, the exclusion accounting, and the follow-up tools. For a five-parameter read tool with annotations covering safety, 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 all five parameters (limit, sessionId, sessionLabel, sessionLabels, threadMessages) are already documented in the schema with defaults and bounds. The description adds field-level meaning via the `thread` / bookingLinkSentAt explanation, but says nothing about selector or limit semantics beyond what the schema provides, so the baseline 3 is correct.

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 precise population and scope: people who AGREED to a call, have not booked, and whose check date has arrived — the worklist for a booking routine. It explicitly distinguishes itself from li_replies_to_answer (those who wrote back) and from the case of someone only sent the link who never agreed, so an agent can separate it from siblings like li_bookings 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?

It routes the agent concretely: nudge via li_send_reply(bookingNudge: true) and close via li_send_reply(bookingClose: true), and points the excluded cohort at li_replies_to_answer. It doesn't phrase an explicit 'use this when X, not Y' rule, but the worklist framing plus named alternatives supplies clear usage context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description goes beyond that by disclosing the storage/performance profile ('DB-backed and instant'), the truncation behavior ('truncated when there are more'), the default status, and the returned fields — genuinely useful behavioral 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 purpose, then filtering/limits, then routing to sibling tools. It is dense but every clause carries information (returned fields, defaults, truncation, workflow), 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?

With no output schema, the description still tells the agent what comes back (calendarEventId, meetingStart, bookedAt, contact, account) and the truncation signal. For a read-only list tool with a rich schema, this is complete enough to call correctly.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description reinforces key semantics: the status default and alternative values, from/to filtering on meetingStart, and the limit default (100). It adds marginal framing beyond the schema rather than substantial new syntax.

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 (List) and resource (bookings) with scope ('accounts you can see') and enumerates the key returned fields. It distinguishes itself from relatives by naming li_booking_due and li_outcome_summary for adjacent needs, so an agent can route 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 explicit when-to-use via the booked-call routine ('reads this to spot a booking whose calendar event has vanished — then li_mark_booking_cancelled') and names alternatives with their distinct conditions (li_booking_due for nudges, li_outcome_summary for conversion rates). Both the action and the exclusions are 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 declare destructiveHint=true but say nothing about mechanics; the description fills that gap richly: substring-only matching with no undo because no prior text is stored, dryRun defaulting to true, per-step guards that refuse steps mid-send rather than overwrite, and no rescheduling. This is exactly the extra 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?

Front-loaded with the core action, then warnings in descending priority. Every warning maps to a real failure mode (regex assumptions, accidental writes, misreading contactsUnmatched, partial sweeps), so the length is justified, though the emoji-prefixed callouts make it denser than strictly 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?

With no output schema, the description takes on return-value explanation and does it well, naming contactsUnmatched, truncated, refused, and resumeAfterStepId and what each means. For a destructive 7-parameter bulk mutation, nothing an agent needs to call it 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 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the afterStepId re-run pitfall (re-reading the same window makes replaced lines surface as contactsUnmatched), the semantics of truncated vs a complete sweep, and that find/replace are literal. That materially improves correct invocation.

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

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

States a specific verb and resource: find an exact sentence across a campaign's UNSENT steps and replace it, campaign-wide in one call. It explicitly distinguishes itself from the sibling li_edit_step (per-person corrections), so an agent can route correctly 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?

Gives an explicit when-to-use rule (the SAME sentence across every prospect) and names the alternative (li_edit_step) with the condition that selects it. It also covers the operational follow-ups: dryRun must be passed false to write, and afterStepId is required to continue a capped sweep.

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 safety profile (readOnly), so the description carries the rest and does so richly: pagination semantics and the meaning of `truncated`, the three overlapping status vocabularies, the messageStatus correction rule, the two mutually exclusive failure stages with retry gating, compact-by-default behavior, and the seenByThemAt null caveat. This is exactly the beyond-annotations context the rubric rewards.

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?

Purpose is front-loaded and the paragraphing is logical, but the entry is very long for a 10-parameter read tool and duplicates the `text` mode explanation already fully present in the schema. The all-caps emphasis and repeated 'truncated' warnings are earned, yet the overall length is heavier 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?

No output schema exists and the tool is complex, but the description documents the return shape thoroughly (totalContacts/returned/offset/truncated, matchingContacts, csv dotted columns, stepCounts vs steps, conversation.state and outcome precedence). An agent can call this correctly and interpret the reply without further context.

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 semantics the schema does not: filters run over the whole campaign before the page is cut, the reply then adds `matchingContacts` and `truncated` refers to matches, and connectionStatus "none" means already-connected imports. That is genuine meaning beyond the per-parameter 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: it returns the contacts in a campaign, along with per-contact sequence progress, next action, conversation state and failure. It also positions itself against siblings, noting that with steps included the rows drive li_edit_step/li_cancel_steps 'rather than through a dossier per person' and pointing to li_list_campaigns for the id.

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 routing: 'For "how is this campaign doing", pass view="summary"' vs rows 'for acting on named people'; offset/nextOffset for paging; the filter list and what it filters over. Alternatives and the conditions that select them are named rather than implied.

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

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

Annotations already establish read-only, non-destructive, closed-world behavior, so the bar is lower; the description still adds that the call is DB-backed and instant and returns counts only, no people, which tells the agent about latency and payload shape. It stops short of any pagination or limit disclosure, but for a single-campaign counter that gap is minor.

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 answer (counts for one campaign), then notation of the extra fields, then routing to siblings. It is dense and long-winded in places, but every clause carries information an agent needs, particularly the status enumerations that substitute for a missing output schema.

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 return-value burden and does so fully: it enumerates connection and message statuses, names the extra attached fields, and clarifies priority semantics and what timezoneCoverage means. Nothing an agent needs to interpret or call the tool correctly is missing.

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

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

Schema description coverage is 100% for the single campaignId parameter, and the description's 'Get the id from li_list_campaigns' merely restates the schema's own note. No additional format or validation meaning is added, 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 precise verb+resource with scope: counts for ONE campaign across both connection and message stages, plus attached strategy, connectionWaitHours, ICP, priority and timezoneCoverage. The enumerated status vocabularies make clear exactly which counts are returned, so an agent can distinguish it from siblings 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 routes to alternatives by intent: li_campaign_contacts for the people behind the counts, li_scheduled_steps for what sends next, li_outreach_analytics for campaign comparison. It also names the prerequisite source for the id (li_list_campaigns), leaving nothing 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 only say destructiveHint=true; the description goes well beyond that by disclosing the resulting state ('stays listed there as `cancelled`'), the refusal condition, the explicit non-effect on live posts, and the cost profile ('no browser, instant'). It even states the return value, which no output schema provides.

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 scope, and each subsequent clause carries a distinct piece of information (state transition, refusal, side-effect boundary, return, latency). Slightly dense but no throwaway sentences.

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

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

For a one-parameter mutation tool with a destructiveHint annotation and no output schema, the description covers what changes, what is refused, what is untouched, and what is returned. Only auth/permission requirements are 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 coverage is 100% for the single `id` parameter and its description already says it comes from li_scheduled_posts, so the description's mention of the same origin adds little. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (cancel) plus a precisely scoped resource: 'Cancel ONE scheduled post that has not gone out yet, by its id from li_scheduled_posts.' It also distinguishes itself from the adjacent create/schedule/list siblings by clarifying this acts on the queue only and deletes nothing 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 a clear precondition (must not have gone out yet) and a refusal case (already published), and points to li_scheduled_posts as where the id comes from. It stops short of naming an explicit alternative tool for the already-published case, 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 already flag destructiveHint=true, but the description goes far beyond that: it discloses exactly which field is written, that no message/contact status or outcome is touched, the re-chaining of the next step, per-row refusal semantics, and the critical fact that the hold is irreversible. This is rich behavioral context the annotations alone 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?

Front-loaded with the core action and its scope before any of the comparison or caveat material. The length is largely justified by the irreversibility warning and sibling disambiguation, though the emphatic ALL-CAPS phrasing and emoji headers add some bulk that a tighter edit could remove.

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 the return surface (the `rescheduled` field and what its absence means) and covers edge cases an agent must know: batch partial failure, non-pending steps, invisible campaigns reported as 'Not found', and irreversibility. Nothing needed 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 meaning: step ids come from li_campaign_contacts or li_contact_dossier, multiple steps can be held in one call, and a step named later in the same call is never used as a re-chain target. The reason field's per-sequence (not per-step) timeline behavior is also clarified.

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

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

States a specific verb+resource with scope: 'Cancel specific scheduled sequence messages so they are never sent, and NOTHING ELSE,' then pins the exact state change (MessageStep.status = 'canceled'). It explicitly distinguishes itself from li_mark_stopped and li_mark_outcome, so an agent can route correctly 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 the triggering scenario ('hold tomorrow's Day-3, the wording is wrong'), names the alternatives (li_mark_stopped/li_mark_outcome for stopping entirely, li_edit_step for rewording), and states the ordering constraint ('reach for li_edit_step on it BEFORE holding it'). Both when-to-use and when-not-to-use are covered.

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 readOnlyHint/destructiveHint annotations by disclosing that it opens a browser session and queues behind other work, and by pre-empting a critical misread: ok:false with pendingListRendered:false means the sent list could not be read, NOT that nothing is pending. That is exactly the kind of behavioral context 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?

Front-loads the core purpose and then layers behavior, error semantics, and alternatives with no filler sentences. It is dense, but each clause carries distinct information an 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?

No output schema exists, so the description carries the return contract, and it does: the per-profile state enum, and the batch fields pendingInvites and connections as public-id lists with counts. Nothing an agent needs to call it and interpret results 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 semantic value by spelling out the behavioral difference between supplying profileUrl (single-person state, with an inline enum of connected|pending|not_connected|unknown) versus omitting it (batch pending/connection signals). Useful beyond the 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 ('Ask LinkedIn right now whether invites were accepted') and then precisely delineates the two modes from profileUrl. It distinguishes itself from siblings li_poll_acceptances and li_connections by name, 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?

Explicitly routes: use li_poll_acceptances to record acceptances and schedule first messages, and li_connections for already-recorded invites from the DB. Both the when and the when-not are stated with the selecting condition, leaving nothing to inference.

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) it discloses that no browser or LinkedIn traffic is involved, that the result is persisted on the proxy, that credentials never appear in error messages, and it enumerates the verdict semantics (pass/reject/review/failed). This is substantial behavioral context the 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?

Dense but front-loaded: the operator restriction and the core action come first, followed by verdict semantics and the parameter hint. Slightly long with some parenthetical asides, but nearly every 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?

With no output schema, the description compensates by defining all four verdict values and the failure mode, plus what the call does and does not touch. An agent has everything needed to invoke 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 parameter's description already covers the id-or-"default" contract, so the description adds no new syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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: it asks ipinfo through the proxy which IP the proxy really exits from and classifies that IP's network type. It is clearly distinct from the sibling li_proxies (which merely lists proxies), so an agent can pick between them 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?

Explicitly says OPERATOR ONLY, tells the caller to pass a proxyId from li_proxies or "default" for the install-wide env proxy, and instructs re-checking after any renewal. It even explains why the check is needed over the vendor's own label.

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 read-only and non-destructive, but the description goes far beyond them: it states it writes nothing, queues nothing and blocks nothing, documents collision-as-information semantics, invite-allowance costs, the bounded-by-visibility scope, result capping via peopleHidden, and default grouping. Rich context that annotations alone could never 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?

Strongly front-loaded (read-only guarantee first, then exclusions, then positive cases) and organized into clear sections. It is very long and includes illustrative tangents (56% size reduction, ~50s browser sessions, tier allowance bands) that are informative but not all essential to invocation.

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 fully carries the burden of explaining returns: it details every bucket, collisions/counts/fresh/summary, the view modes, the people table, otherCampaigns, batch.members, and the peopleHidden cap. Nothing an agent needs to interpret the reply 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 schema already documents each parameter; the baseline would be 3. The description adds genuine meaning on top, notably the consequence of passing campaignId (idempotent in_this_campaign vs overstated collisions without it), that groupByCompany costs extra queries, and how campaignNamePrefix marks batch members.

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 ('Read-only: who among these profile URLs has ALREADY been approached from the accounts you can see') and immediately distinguishes scope from siblings by naming li_ingest_prospects and li_create_campaign. An agent can tell exactly what this returns without opening anything else.

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?

Contains an explicit 'WHEN NOT TO CALL IT' section that names the alternatives (li_ingest_prospects, li_create_campaign), explains why they already do this check and why theirs is the better answer, and then states the positive cases (triaging a list, deciding whether a batch is worth researching). This is textbook when/when-not/alternatives guidance.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, and the description is consistent with them while adding real context the annotations cannot: the breaker's trigger condition (3 consecutive invites to different people failing the same way), which invite paths it suppresses and which it does not (messages keep going), the auto-expiry rules, the re-hold risk, and the return contract. No contradiction with structured data.

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

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

The action is front-loaded in the first sentence, followed by trigger mechanics, lifting rules, the safety precondition, and the return value. It is dense and multi-clause, but each sentence carries distinct operational information; only the 'says so in inviteHold on...' reference to sibling tools is slightly tangential.

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 closes that gap by stating the return value ('Returns the hold that was standing (null = there was none)'). Combined with the trigger, expiry, and precondition detail, an agent has everything needed to invoke this safely and correctly.

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

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

Schema description coverage is 100% and both parameters (sessionId, sessionLabel) are documented in the schema itself, so the baseline is 3. The description adds no identifier syntax or selection guidance 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 and object ('Lift the INVITE BREAKER's hold on one account') and immediately distinguishes it from state-of-the-world readers like li_campaign_status by naming those as the places the hold is reported, not cleared. An agent can tell this apart from siblings such as li_hold_sending or li_pause_account.

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 and when-not: self-lifting holds (LinkedIn email-request holds clear after a day) versus holds that wait for this call (SELECTOR_CHANGED, UNKNOWN, NOTE_LIMIT). It also prescribes a precondition ('Clear it only after someone has looked: open the account on LinkedIn and try one invite by hand, or read the saved screenshot') and names the consequence of misuse ('If the cause is still there, the next 3 failures hold it again').

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 (readOnly, non-destructive, not open-world), and the description adds substantial context on top: it is DB-backed and instant and does not query LinkedIn, rows are capped by limit with total as the full count, statsScope indicates whether stats are per-account or blended, and the 25% acceptance threshold is explicitly framed as an internal heuristic that pauses nothing. This is exactly the kind of behavior an agent needs and cannot infer from annotations.

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

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

Front-loaded with the core action, then routing, then output/limit semantics, then the policy caveat — a logical order with no wasted sentences. It runs five sentences and is denser than strictly necessary, but each one carries information an agent would otherwise lack.

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 explaining returns and does so: one row per connection, capped row count with a separate total, and a stats block (pending, rolling weekly sent, 14-day acceptance rate) whose scope is reported via statsScope. It also flags the cross-account scoping caveat, so an agent has what it needs to call and interpret the tool correctly.

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

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

Schema description coverage is 100%, so every parameter is already documented (limit default/max, status enum, sessionId/sessionLabel scoping, campaignId). The description restates the limit/total relationship and the per-account vs install-wide stats distinction, but the schema's own sessionLabel description already carries that meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('List the invites this system tracks, one row per campaign connection') along with the optional status/campaign filtering and the accompanying account-health stats. It also explicitly names the siblings it is not (li_pending_invites for LinkedIn's own list, li_poll_acceptances for recording acceptances), so an agent can distinguish it 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?

Explicit routing: use li_pending_invites for LinkedIn's own pending list including hand-sent invites, and li_poll_acceptances to record new acceptances first. It also states the operational policy context (the 25% threshold is 'OUR operating policy, not a LinkedIn-published rule') and how to report it, which is genuine usage guidance rather than filler.

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/destructiveHint/openWorldHint, but the description adds rich behavior beyond them: cache semantics (never re-fetched, no cost), unreachable flags (companyUnreadable, postsUnreadable), null-means-never-read distinctions, the seenByThemAt receipt ambiguity (mutual setting makes null indistinguishable), failure typing by stage, and the ~14 KB size/byte-cost tradeoff.

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 long, but the density is operational rather than filler: the identity of the tool is front-loaded, then the return-field semantics, then the size guidance. A few clauses (e.g. repeating unreadable/null rules) could be trimmed, keeping 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?

With no output schema, the description carries the full burden and discharges it — it maps every major return field (enriched and its fetchedAt, company vs companyPage, companyWebPages, posts and its three null states, conversation, conversationState/outcome/failure) and disambiguates each null. Nothing an agent needs to interpret results or 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 schema documents all three params. The description still adds meaning: fields narrows enriched to sub-blocks, profileUrl is 'the identity key', profileUrls resolves each independently so one refusal doesn't stop the rest, and it states default field subsets per call shape.

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+scope: 'the full DB record for one contact — or, with profileUrls, for MANY in one call'. It enumerates exactly which blocks come back (profile metadata, sequences+steps, events, conversation, enriched), so an agent knows precisely what this tool is versus the siblings it names.

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

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

Explicit when-to-use: 'This is the tool to open before drafting a reply — it is DB-backed and instant'. It also routes to alternatives by condition — li_read_conversation for a live thread, li_fetch_posts for posts never read, li_enrich_profiles to populate a missing employer — and explains the single-vs-many call choice and the fields filter.

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 readOnlyHint and destructiveHint=false already covering safety, the description goes well beyond: it discloses that history is written automatically and can lag, that an empty result means 'never read' rather than 'no reply', and it carefully disambiguates a null seenByThemAt as 'no receipt (or receipts off)' rather than 'unseen'. These are exactly the failure modes an agent would otherwise misread.

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 essential contrast and storage model, and every sentence carries operational weight. The final seenByThemAt passage is long, but it guards against a specific and serious misinterpretation, so it earns its length rather than being 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?

There is no output schema, so the description legitimately supplies return semantics: ordering (oldest-first), the seenByThemAt receipt field and its null ambiguity, and the write-back behavior. Combined with the 100%-covered input schema, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100%, so limit, profileUrl, and conversationUrn are already fully documented. The description adds no syntax or format guidance for any parameter; its extra detail is about returned fields (seenByThemAt), not inputs. Baseline 3 applies when the schema carries parameter 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 ('the saved LinkedIn thread with one person'), including scope ('THEIR messages as well as ours, oldest first') and storage backing ('DB-backed'). It explicitly differentiates from the sibling li_read_conversation, so an agent can choose between them 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?

Gives an explicit when ('Read this for context before drafting a reply') and a when-not with rationale ('li_read_conversation opens a browser session and takes minutes'). It also spells out the empty-result branch and the recovery action, so the agent knows exactly what to do on each outcome.

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 non-read-only, non-destructive, non-idempotent, closed-world. The description goes well beyond: it explicitly says nothing is sent, describes the 50-target cap shared across inputs, the collisions report as informative-but-not-refusing, do-not-contact suppression and outright refusal when all targets are suppressed, and the engage-before-invite timing and per-account reaction caps.

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 two hard constraints (50-target cap, no sending) before routing to alternatives. It is long and the engage-before-invite mechanics are largely repeated in the engagePostUrl schema description, which is the only real 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?

Despite no output schema, the description explains returns (result.collisions, result.suppressed with reasons) and covers the key edge cases an agent must handle: rejection on missing step text, suppression, the target cap, and engage-before-invite failure modes. Nothing material is left for the caller to guess.

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 cross-parameter semantics the schema cannot: every target needs step text for each post-acceptance strategy step, rows missing step text are rejected, profileUrl is required with connectionNote optional, and the JSON/CSV targets share the row limit.

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 a two-stage campaign from prefilled targets under a sending strategy') and immediately scopes what it is not: 'Does not send anything.' The empty-campaign behavior and the three input formats (JSON, CSV, both) let an agent distinguish it from li_ingest_prospects, li_check_targets, and li_move_contact 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?

Names alternatives and the exact conditions selecting them: split across calls under the same strategy or use li_ingest_prospects (>50), no need for li_check_targets before this, and li_react_to_post for immediate reactions. It also explains when to create an empty campaign to fill later via li_ingest_prospects or li_move_contact.

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?

Adds substantial behavior beyond the annotations: dry-run-by-default, the confirmCreate gate, that the confirmed call returns the new ICP with its `id`, team ownership of the created object, and the operator-credential edge case (must supply sessionLabel or shared:true, never published to every team by default). These are exactly the non-obvious traits an agent needs and none are derivable from the readOnlyHint/destructiveHint flags.

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

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

Front-loads purpose and the "only a label" scope, then proceeds to warnings and edge cases. It is dense and slightly long, but each sentence carries a distinct constraint (uniqueness, dry-run, ownership, operator handling), 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?

For a mutation tool with no output schema, the description supplies the missing return information ("returns the new ICP with its `id`"), the safety/confirmation model, and the credential-dependent ownership behavior. Together with the annotations, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter logic the schema states only piecemeal: it ties sessionLabel and shared:true together as the alternatives an operator with no team must choose between, and reinforces the uniqueness constraint on `name` and the write-gate on confirmCreate.

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 an ICP (ideal customer profile) label") and immediately explains its downstream purpose (attaching to campaigns so li_outreach_analytics(groupBy="icp") can compare audiences). The clarification "Only a label: it targets, filters and sends nothing" sharply distinguishes it from campaign/outreach 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?

Gives explicit preconditions and alternatives: "Check li_list_icps first — names are unique per team and a clash is refused" and "Dry-run unless confirmCreate=true." It names the sibling to consult and the exact gate that switches the tool from dry-run to a real write.

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 destructive/openWorld/non-idempotent, but the description goes further: publishing is public, the post cannot be deleted afterwards, the call waits for a result and returns result.postUrl, and content is never generated at send time. These are exactly the behavioral traits an agent needs to reason about an irreversible write.

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 its scope, and every clause carries distinct information (dry-run gate, source of text, irreversibility, alternative tool). It is dense and slightly run-on, but no sentence is wasted.

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

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

For a 5-parameter write tool with no output schema, the description covers the return contract (result.postUrl on success), the safety gate, the irreversibility, and the sibling alternative. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: text must be caller-supplied verbatim because the system never generates content at send time, and confirmPost's false branch is framed as a preview. sessionId/sessionLabel guidance is only echoed from 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 ('Publish ONE post ... to the sending account's own LinkedIn feed NOW'), including scope (own feed, single post, text + optional image). It explicitly distinguishes itself from li_schedule_post, so an agent can route 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?

Gives an explicit alternative and the selecting condition: 'Use li_schedule_post instead when a person chose a future time (it stays cancellable in li_scheduled_posts).' It also states the operational gate (confirmPost=true to publish, otherwise dry-run preview).

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 the write/non-destructive/non-idempotent/open-world profile, and the description adds substantial context beyond that: a hard cap of 4 messages with a fifth refused, dry-run preview semantics vs confirmed write, snapshotting onto prospects at import, team ownership rules, and the operator-only sessionLabel/shared behavior with the guarantee it is never published by default.

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 block that is front-loaded with the core action, then constraints, then routing, then ownership. Every sentence carries distinct information, though the run-on length makes it slightly harder to scan than an ideal definition.

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

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

For an 8-parameter creation tool with no output schema, the description covers return shapes (preview returns validated steps and errors; the confirmed call returns the new strategy with its `id`), downstream consumers, ownership defaults, and failure modes — 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 coverage is 100%, so the baseline is 3, but the description adds genuine meaning: the at-most-4 message cap, the requirement to start with 'first', connectionWaitHours semantics (wait after acceptance before the first message), and what confirmCreate actually gates (dry-run vs real write). It stops short of documenting every operator-only field, so 4 rather than 5.

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

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

The opening sentence gives a precise verb+resource ('Create a reusable sequence template') and immediately enumerates its constituents: steps, delays, and connectionWaitHours. It distinguishes itself from li_create_campaign, li_edit_step, and li_bulk_edit_steps by naming each and the condition that routes to 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?

Explicit when-to-use: check li_list_strategies first for an existing fit, dry-run unless confirmCreate=true, and fix already-queued copy via li_bulk_edit_steps/li_edit_step rather than creating a new strategy. Both alternatives and exclusions are named, leaving nothing 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 cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds genuinely useful context beyond them: it is DB- and Redis-backed, costs no browser time, is safe to call while campaigns are running, and leads with BLOCKED status. It does not, however, describe the response shape or any rate/recency caveats.

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 BLOCKED-status rationale early; every clause maps to a returned metric or a usage constraint. The metric enumeration is long but earns its place given there is no output schema, though the single run-on sentence is denser than ideal.

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 compensates by listing the report's contents in detail, plus notes on data source (DB/Redis, no browser), safety during running campaigns, the parallel Telegram delivery, and two sibling alternatives. 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 description coverage is 100% (both params documented, including the sessionId/sessionLabel relationship), so the schema carries the load. The description adds only a marginal note about defaulting to the default account and calling once per account, which is why the baseline 3 applies rather than higher.

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+scope ('One account's end-of-day picture in a single call') and enumerates the exact metrics returned: invites sent, acceptances, messages, replies, backlogs, cleanup spend, failures, finished campaigns. It also explicitly distinguishes itself from li_account_activity and li_outreach_analytics.

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

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

Explicit routing: 'For what is running right now use li_account_activity; for rates over time, li_outreach_analytics.' Also states the multi-account pattern ('call once per account for several') and that it defaults to the default account, so the agent knows both when and how to invoke it.

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 give readOnlyHint=false, openWorldHint=true, destructiveHint=false; the description goes well beyond by disclosing the side effect (stores what it establishes), the queueing/browser-session behavior, and the critical 'a wait timeout means it is still running, not that it failed.' It also disambiguates nulls in `facts` (page did not say) and `wrote: null` (nothing established, account untouched).

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 and effect, then timing, then return-value semantics. Every clause earns its place, though the first sentence is long and dense enough to slow parsing slightly.

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

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

With no output schema, the description still explains the return shape (`facts` vs `wrote` and their null meanings), the async execution model, and the alternative data source. Nothing an agent needs to call or interpret this tool 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 sessionId and sessionLabel are already documented (including the 'never guessed' constraint). The description adds no parameter-level syntax or format detail beyond referencing li_list_accounts as the id source, 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 ('Read one account's LinkedIn tier now') and enumerates the possible outcomes (verified / premium / new-unverified). It also explains the consequence of the value (invitation allowance and whether notes are delivered), and names li_list_accounts as where the stored value lives, which separates it from the read-only 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 routes the agent: the tier is re-detected daily and the stored value is in li_list_accounts, so 'call this only when you cannot wait for that tick.' It also pre-empts a search for a write alternative with 'There is no manual tier setter by design.'

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new context: it is DB-backed and instant, rows are capped by limit with a truncation signal, and each row carries prefilled send text. It does not say what happens to rows the worker has already claimed, which is the one remaining behavioral 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?

Front-loaded with the definition of 'due', then row contents, then operational notes, then sibling routing. Five dense sentences with no filler; each sentence adds a distinct fact.

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 naming the row fields (profileUrl, account, step kind, prefilled text) and the truncation flag. Combined with the sibling disambiguation, an agent has everything needed to call this correctly and interpret a response.

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 goes slightly beyond by restating the limit/truncated contract and by signaling that account scoping (sessionId or sessionLabel) is needed when multiple accounts exist. The sessionId/sessionLabel disambiguation is largely carried by the schema text, so this lands just above baseline rather than at full credit.

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 with precise scope: contacts whose next message step is DUE now, defined mechanically as scheduledAt ≤ now and still pending. It further names the two nearest siblings (li_scheduled_steps and li_accepted_pending_message) and the boundary condition that distinguishes each, 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?

Explicitly frames both consumers ('the worker auto-sends these; a routine can also pull them to bulk-send') and draws hard exclusions: future send times belong to li_scheduled_steps, accepted people with no opener belong to li_accepted_pending_message. When-to-use and when-not-to-use are both 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 only give the safety profile (readOnly=false, destructive=false, idempotent=true); the description adds far more: two hard refusals with reasoning, the rename→by-name-import side effect that creates duplicate campaigns, priority's in-place invite reordering without touching caps, and dryRun/resnapshot semantics. 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?

Primary purpose and priority semantics are front-loaded, and the warnings/refusals are grouped with bullet-like structure. It is long and dense, but nearly every sentence carries non-obvious operational detail; only slight trimming seems possible.

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

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

For a multi-field mutation tool with no output schema and 10 parameters, the description covers refusals, side effects, preview behavior, resnapshot preconditions, and where to get the id. Nothing an agent needs to call it safely appears 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, but the description adds real meaning: icpId null-vs-omitted distinction, priority's precise effect, and that sessionId/sessionLabel are accepted only so account-move attempts can be refused in words. It goes beyond restating the schema descriptions.

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

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

States a specific verb and resource ("change a running campaign's NAME, its ICP label, or its invite PRIORITY") and immediately distinguishes itself from near-siblings li_bulk_edit_steps, li_edit_step, li_create_campaign and li_move_contact. An agent can identify the scope 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 states when to set priority ("only when the user asks for a campaign to go first"), when not, and names the alternative tools for cases it refuses (li_bulk_edit_steps, li_edit_step, li_move_contact, and li_ingest_prospects with campaignId). The empty-vs-populated campaign branching is 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?

The annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds substantial behavioral detail beyond them: per-row refusal behavior, which step states are editable, that non-visible campaigns are reported as not found, and that scheduling is unchanged.

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

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

The description is long but well structured, front-loading the core action before caveats and alternatives. The bullets make refusal behavior easy to scan, though a few sentences are more illustrative than strictly 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 destructive batch-edit tool with no output schema, the description covers the critical operational details: partial application, per-row reporting, refusal cases, and that only text changes while scheduling stays intact.

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 parameter definitions are already documented. The description still adds useful meaning by explaining why the tool takes an array and that each edit is applied and reported on independently, plus reinforcing where stepId comes from.

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 precise verb and resource: changing the text of message steps that have not yet sent. It distinguishes this from sibling tools such as li_bulk_edit_steps, li_campaign_contacts, li_contact_dossier, li_mark_stopped, and li_mark_outcome.

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

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

It gives explicit when-to-use guidance: reach for this when corrections differ per person, and use li_bulk_edit_steps when the same sentence must change across a whole campaign. It also names alternatives for finding steps and for stopping sends.

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 (which only flag openWorldHint and readOnlyHint=false): it discloses the cost model (ONE lookup), the 30-day free cache with a `cached` flag, the response accounting fields (`creditsUsed`, `remaining`), and a real side effect — filling a blank company domain on contacts, which explains why readOnlyHint is false. This is unusually rich behavioral 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?

Purpose and output shape are front-loaded in the first sentence, and each subsequent sentence carries distinct information (routing, cost, cache, parameter advice). It is somewhat long and drifts into editorial coaching ('Never invent a development that is not in the pages'), which is useful but slightly beyond tool mechanics.

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 fully carries the burden: it names the returned field (`pages`), the cache indicator, and the credit accounting. Cost, cache, side effects, and the interpretation-vs-fetch division of labor are all covered, so 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 description coverage is 100%, so the baseline is 3, but the description adds genuine meaning: `website` beats searching and also backfills a contact's domain, and `refresh` is framed in terms of cache and cost. It stops short of explaining the sessionId/sessionLabel selection nuance, but the schema covers those.

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 ('Fetch what the web says about a company') and names the exact output shape ('raw page text (`pages`)'), plus explicitly distinguishes itself from the sibling li_enrich_profiles. An agent can identify this tool and its scope 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 explicit when-to-use ('the company's own words and recent news'), an explicit alternative for a different need ('for people use li_enrich_profiles'), and a conditional recommendation ('Pass `website` when known — fetching the real site beats searching'). Routing is fully resolved.

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

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

Adds enormous context beyond the annotations: credit cost and shared-pool semantics across accounts, 30-day shared cache and refresh override, per-URL outcome codes with the not_found/unmatched caveat, companyPage status vocabulary, and the requirement to relay `message`. With readOnlyHint=false and destructiveHint=false already set, this is far more than the annotations convey.

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

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

Front-loaded with the cost/no-browser distinction, but the body is an unusually dense wall of prose covering caching, statuses, trimming fractions, companyPage fields and batch grouping. Most sentences carry unique information, but the volume is heavy enough that scanning for a single fact is hard.

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 no-output-schema tool with 6 params and substantial complexity, the description covers returns in detail: compact-by-default shape, the never-returned raw provider record, per-URL statuses, the `companies` grouping block, and the payload-duplication note. Nothing an agent needs in order to call it and interpret results 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, but the description adds real meaning: fields trimming with concrete examples and measured size fractions, the fact trimming costs the same as the full record, empty-array identity-only behavior, and that sessionId/sessionLabel are never sent to the provider. Only refresh/estimateOnly largely restate their 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+resource ('look up who people are — name, headline, company, role, location') via a third-party provider with no browser, and explicitly contrasts the scope with li_check_targets and li_enrich_company. An agent can distinguish it from li_research_profiles and li_search_leads by the 'costs enrichment lookups / no browser time' framing.

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 context ('Use this before writing outreach, and before deciding whether to accept an inbound invitation') and routes to an alternative for a related question (li_check_targets with groupByCompany). It also prescribes estimateOnly=true first for large lists. It does not explicitly say when NOT to use it versus li_research_profiles or li_search_leads, so it stops short of 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?

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) by disclosing sticky/deterministic stratified assignment, the requirePostForArms/controlArm `forced` fallback, the copy-precedence ladder, validation performed before any write, and that nothing sends until the campaigns are launched.

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?

Long and dense, but front-loaded with the purpose and organized into labeled paragraphs (assignment, copy, first/later call) that earn their place for a tool with this much hidden behavior. Minor density cost, but little 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?

For a mutation tool with no output schema, it covers most of what an agent needs: the reply's launch.campaignIds, searchIds resolution, messageStage handling, and per-account split reporting. Remaining reply-shape details (e.g. the full dry-run preview format) are only partially 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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: stratifyBy semantics (balance within each stratum), controlArm/requirePostForArms interaction, the armCopy > row text > armSteps > defaultSteps resolution order, {first} interpolation, and experiment reuse by name+arms.

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

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

Opens with a specific verb+resource ("Run an A/B(/n) test"), then names the mechanism precisely: assigns each prospect to an arm server-side and imports them through the same multi-campaign import as li_ingest_prospects. This clearly distinguishes it from the plain import sibling.

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

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

Gives explicit sequencing (first call with `experiment`, later calls with experimentId), states dry-run is the default and confirmAssign is required to write, and routes the user to li_outreach_analytics(groupBy "arm") for results. It does not explicitly contrast when to prefer this over li_ingest_prospects, but the context is otherwise clear.

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

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

Annotations only flag readOnlyHint=false/openWorldHint=true; the description goes far beyond by disclosing the cost model (1 lookup per person, shared pool with li_enrich_profiles, free within 3 days, refresh=true at full price) and the full per-person status taxonomy with which statuses are charged. It also warns against misreading unreadable/failed as 'they do not post' and explains reactable/notReactable. No contradiction with annotations — the readOnlyHint=false is consistent with credit-charging reads.

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?

Purpose and the actionable instruction are front-loaded, and virtually every sentence carries operational weight (cost, statuses, field semantics). It is nonetheless a very dense single block that would scan better broken into cost / output / status sections.

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: it enumerates returned fields (url, text cut at 1,200 chars, postedAt, reactions/comments with null-means-unknown, reactable), the status enum, and the billing outcome. An agent has everything needed to call, interpret, and report cost 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 each parameter is already documented (refresh cost, maxPosts 1-2, sinceDays/olderPosts, estimateOnly, sessionId/sessionLabel). The description reinforces a few semantics — 'Up to 2 posts per person, newest first' and the olderPosts-charged interaction — but adds little the schema does not already say. 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 ('fetch each person's latest LinkedIn posts') plus the concrete downstream purpose (personalise the first touch, pick a post to react to). It also explicitly distinguishes itself from li_enrich_profiles (identity) and li_contact_dossier (held data), so an agent can route without opening sibling 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?

Explicit when-to-use: pick ONE post before importing, or choose the post for engage-before-invite. It names alternatives and their conditions ('for who a person IS use li_enrich_profiles', 'for what we already hold use li_contact_dossier with fields [posts]') and prescribes estimateOnly=true first for long 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 (readOnlyHint=false, destructiveHint=false, openWorldHint=true) establish the mutation/safety profile, and the description adds substantial context beyond them: what is held vs. what keeps running, that nothing is lost, that a running bulk batch stops before its next person and reports the rest as notAttempted, auto-expiry range, replacement semantics, and the auto-set 12-hour misdelivery hold. The only minor gap is no explicit auth/permission detail beyond 'OPERATOR ONLY'.

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?

Long but dense and front-loaded — the install-wide brake concept and OPERATOR ONLY warning lead, followed by effects, expiry, triggers, and the sibling pointer. Nearly every clause carries operational information, though a few parentheticals could be trimmed.

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

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

For a high-impact mutation tool with no output schema, the description covers what changes, what continues, side effects on running batches, expiry behavior, and even the sendingHeld reply flag. An agent has everything needed to call it correctly and predict the outcome.

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 interaction semantics the schema does not: that omitting both minutes and release selects read mode, that reason is required with minutes, and that release=true ends the hold immediately. This meaningfully supplements the structured fields.

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

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

States a specific verb and resource with exact scope: an install-wide brake that holds ALL sending on EVERY account, with read/release modes. It explicitly distinguishes itself from the per-account sibling by naming li_pause_account, so an agent can tell them apart 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?

Gives explicit when-to-use triggers (before a redeploy or restart, server maintenance, or when a send path looks wrong) and names the alternative (li_pause_account for per-account). It also explains how to invoke the read mode (omit both minutes and release), leaving nothing 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 cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint=false), and the description adds the access-control behavior that annotations do not: it is refused for anyone but the install operator. It also explains why the data is host-scoped, which is real behavioral 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-loads the OPERATOR ONLY constraint, which is the most important gating information. It is somewhat long for a no-parameter tool — the 'IDENTICAL symptom' narrative is a touch expansive — but each sentence still carries routing value.

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

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

For a zero-argument, read-only, no-output-schema tool, the description covers access, purpose, and the alternative, so an agent can call it correctly. It does not describe what the returned numbers look like, but the title and read-only annotation make that gap 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?

Zero parameters, so the baseline is 4. There is nothing to explain and the description correctly spends no words on 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 resource and scope: host-level CPU/memory for the machine itself rather than any account. It explicitly distinguishes itself from the account-scoped sibling li_account_activity, so an agent can tell the two apart 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?

Gives an explicit precondition (operator only), an explicit use case (deciding 'starvation vs bug' when a job fails with a timeout symptom), and names the alternative (li_account_activity) with the condition that selects it. Nothing is left to inference.

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

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

Adds substantial context beyond the annotations: it writes our database only, sends nothing, changes no contact, is scoped per team like the do-not-contact list, and is reversible via remove:true. This is consistent with readOnlyHint=false/destructiveHint=false, framing the write as safe and undoable.

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?

Dense but front-loaded — the core action and its downstream consequence come first. Multiple em-dash clauses and parentheticals make it slightly longer than necessary, but each sentence carries information that aids correct invocation.

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 reversible mutation with no output schema, the description covers the write scope, side effects (none sent, no contact change), reversibility, and the observable result (li_match_contacts returns 'ignored'). Nothing an agent needs in order 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, but the description adds real semantics: eventId marks just that event, email marks every booking by that attendee now and later, and both may be combined. The temporal/scope distinction between the two selectors goes beyond the 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+resource (mark a calendar booking as NOT from LinkedIn) and immediately names the downstream effect on li_match_contacts. It is clearly distinguishable from sibling mutation tools like li_mark_booked, li_mark_booking_cancelled and li_track_booking.

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

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

Explicit when-to-use ('a client call, a friend, anything outside outreach'), explicit when-not ('Only on the user's say-so — never mark an ambiguous or none event yourself'), and names the related tool whose output it changes.

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 openWorldHint=true, but the description goes well beyond: merge semantics (later decision wins), refusal of accepted rows without accept/campaign, unresolved-URL handling and re-keying, LinkedIn lookups being read-only with one browser session per account. Rich disclosure of side effects and edge 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 and organized logically (format, matching, merging, refusal, dry-run, idempotency). It is a dense single block, but nearly every sentence carries operative information; only the inline JSON shape is a slight reading cost.

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 steps in and describes the return shape (create/update/unchanged/refused/merges diff plus unresolved list) and the dry-run behavior. For a destructive, high-complexity migration tool, nothing an agent needs to call it 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 coverage is 100%, so baseline is 3, but the description adds meaningful semantics: it documents the ledger's JSON shape keyed by profileUrl with fields account/decision/reason/icp/campaignId/date, and clarifies that confirmImport=false returns the full diff. This is value beyond the schema's terse parameter descriptions.

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

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

States a specific verb and resource (one-time migration of a triage ledger into the memory) and distinguishes itself from siblings by naming li_mark_invitations as the behavioral reference and contrasting with li_invitation_decisions. An agent can tell what this does 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 instructs to run with confirmImport=false first and explains what that returns; also states that re-running is idempotent and describes the refusal rule. The when-to-use and the safe-operating procedure are both 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 declare a destructive, open-world write, and the description goes far beyond them: dedup on profileUrl, idempotency, permanent failure of message-stage sends when not 1st-degree, the exact semantics of launch:false staging, the ~50s browser session cost of a duplicate invite, the rolling 7-day invite allowance and its daily bands, and the do-not-contact refusal. This is exceptional disclosure for a mutation 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 core operation and its selection semantics are front-loaded, and the sectioned structure (ONE CALL MANY CAMPAIGNS, SHARED COPY, engage-before-invite) is navigable. The length is largely justified by the tool's genuine complexity, but several passages (invite-allowance tiers, engagement timing details) are more expansive than an agent needs for correct invocation.

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 13-parameter nested tool with 500-item batches, no output schema, and destructive behavior, the description covers the result contract explicitly (result.campaignName, result.campaignCreated, result.warnings, result.collisions, result.routed, result.suppressed, result.adoptedFromInviteOnly), including what each return field means. An agent has everything needed to invoke and interpret the call.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema alone does not convey: campaignName's find-or-create exact-match behavior versus campaignId's authoritative one-campaign semantics, startStage's divergent invite/message behavior, and engagePostUrl being ignored at message stage. Some prose overlaps the schema (e.g. {first} substitution, engagement caps) rather than adding new per-parameter meaning, keeping it at 4.

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

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

The opening sentence states a specific verb and resource with scope: 'Push prospects WITH their full prefilled sequence into our DB for a chosen sending account, deduped on profileUrl.' It further distinguishes itself from siblings by naming li_check_targets, li_send_connection_now, li_accept_invitations and li_launch_campaign in the context of when this tool does and does not apply.

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

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

Explicit when-to-use guidance is present throughout: message-stage requires an existing 1st-degree connection and directs the agent to accept pending invitations via li_accept_invitations first; it explicitly says NOT to call li_check_targets first; and it routes suppression management to li_suppress_profiles/li_list_suppressed. Alternatives and preconditions are named concretely.

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=false and openWorldHint=false, so safety is covered; the description reinforces with "Read-only, no browser" and adds genuinely new behavior: newest-first ordering, offset paging, and the total/truncated signals plus the changedSinceDecision "as of the last tray read" caveat.

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, front-loaded paragraph that leads with what the tool reads, then filters, then ordering/paging. No filler sentences; every clause 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?

With 10 optional parameters and no output schema, the definition covers filtering, default account scope, ordering, pagination, and the total/truncated return signals, so an agent has everything needed to call and interpret 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 baseline is 3, but the description adds real meaning: decision=wrong_lane surfaces routeTo, changedSinceDecision tracks headline/company drift since judgment, and omitting the account widens to every visible account. These go beyond the schema's per-parameter 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?

"Read the triage memory" states a specific verb and resource and immediately enumerates its scope: who was judged, what was decided, and why. It is clearly distinguishable from the write-side sibling li_import_invitation_decisions and from generic listing tools.

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

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

It gives concrete use cases (monthly rejection reporting, auditing routing via decision=wrong_lane) so an agent knows when to reach for it. It does not explicitly name an alternative tool or state when-not to use it, which holds it below 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 supply readOnly/openWorld/destructive hints, but the description discloses far more: unknown ids return found:false rather than an error, records last about an hour, eta is absent rather than guessed when the queue is unreadable, and fixed-id dedupe jobs delete themselves on completion. It also explains the firesAt/waitingBecause hold semantics and that onlyFailures catches 'completed but did nothing' sends — rich operational context no annotation carries.

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?

Purpose and the headline usage rule are front-loaded in the first two paragraphs, and the long tail is genuinely load-bearing (dedupe caveat, eta absence, found:false). It is dense and occasionally chatty ('cheaper and kinder than polling'), so it falls short of a 5, but nothing is redundant with the schema or annotations.

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 8 optional parameters and no output schema, the description carries the whole burden and does so: it names the returned fields (state, stillRunning, firesAt, waitingBecause, eta.checkAfterMs, found), explains paging via nextOffset, and covers the timeout/retry trap. An agent can act correctly without ever reading a return schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: it distinguishes the jobId (single job) path from the no-jobId (batch listing) path, explains that jobIds reports every id including missing ones, and clarifies that limit/offset paging applies only to a research jobId. Minor gaps remain (e.g. sessionId vs sessionLabel precedence), which keeps it short of a 5.

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

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

Opens with a specific verb+resource framing ('Where your queued work has got to, and what it reported doing') and immediately positions itself as the recovery path for a timed-out call or a returned job id. It is clearly separable from li_campaign_status, li_session_status, and the various check_* siblings because it is about job records, not account or campaign state.

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 ('CALL IT WITH NO jobId AFTER QUEUEING A BATCH'), an explicit when-not ('Never resend on one; ask here instead'), and routes the agent to named alternatives for cases it cannot serve (li_conversation_history to settle delivery, li_replies_to_answer / li_connections / li_withdraw_status / li_list_accounts for self-deleting jobs). Nothing is left to inference.

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

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

Goes well beyond the destructive/openWorld/idempotent annotations: no check that a connection exists so unaccepted invites fail permanently at send, worker drips invites with humanized delays, acceptance poller then auto-sends post-acceptance messages with reply checks, and bulk mode isolates failures per campaign. These are real operational consequences an agent must know before invoking.

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 and the confirm-step framing, and nearly every sentence carries non-obvious information (failure modes, preview behavior, per-campaign isolation). It is long and dense with nested parentheticals and em-dash clauses, though, which slightly hurts scanability for a 7-param tool.

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

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

With no output schema, the description still tells the agent what comes back (preview listing account/status/people/notStartedYet/would-be-refused, and messageStage.started on a connected-only launch) and how partial refusals surface. For a tool this complex, nothing material 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, and the description adds interaction semantics the schema cannot express: campaignIds/namePrefix/sessionLabel mutual roles, the expectCount anti-drift guard, and confirmLaunch as the preview-vs-launch switch. Some of this (sessionLabel/namePrefix pairing) duplicates the schema wording, so not a full 5.

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

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

Opens with a specific verb+resource ("Launch a created campaign") and immediately frames itself as the confirm step for batches ingested with launch:false, which distinguishes it from li_create_campaign, li_ingest_prospects and li_pause_campaign/resume_campaign without needing the schema. It also covers the bulk form 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?

States precisely when to use it ("THE CONFIRM STEP for a batch ingested with launch:false"), when a campaign with only connected prospects works, when to switch to campaignIds/namePrefix/sessionLabel, and that namePrefix requires expectCount matching the preview. Exclusions (what happens without confirmLaunch) 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 already cover readOnly/non-destructive/closed-world, and the description adds substantial context beyond them: 'Never exposes cookies', 'enrichment: null means the usage could not be read, never that nothing was spent', pooled-per-owner credit semantics, and the ambiguity rule that a matching label/id 'is refused, never guessed'.

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?

Purpose is front-loaded, but the body is a very long, densely parenthesized run-on block documenting dozens of return fields in em-dash clauses. Much of it is justified by the absence of an output schema, but the nesting makes it hard to scan and every clause is packed into one paragraph.

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 full burden of explaining return values, and it does so exhaustively: inviteNotes/inviteHold behavior, plan standing, enrichment pooling and window reset rules, officeHours, sendWindowMode, prospectWindow, and booking settings. Nothing an agent needs to interpret the response is missing.

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

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

The tool takes zero parameters, so the schema baseline is 4. The description still adds meaning about the sessionLabel/sessionId identifiers used by other tools (accepting label, LinkedIn name, slug or member id), which is useful context even though it isn't a parameter of this call.

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

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

The opening sentence states a specific verb and resource with scope ('List the LinkedIn sending accounts (one per saved session)'), and the closing explicitly distinguishes it from the sibling li_account_activity ('This is CONFIGURATION — for what an account is doing right now ... call li_account_activity instead'). An agent can tell exactly what this returns versus the activity tool.

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

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

It gives clear downstream context ('Use a label/id from here as sessionLabel/sessionId on the other tools to pick which account acts') and names alternatives for adjacent needs (li_account_activity for live work, li_set_booking_settings for changing booking config). It lacks an explicit 'call this when...' trigger, but the routing to alternatives is present.

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 safety (readOnly, non-destructive, closed-world), but the description adds real behavioral context: filters apply over the whole set before the page is cut, the reply carries totalMatching/truncated/nextOffset, an empty filtered page reports the unfiltered count, and the operation is 'DB-backed and instant'. This is well beyond annotation coverage.

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?

Dense but well organized into purpose, filters/paging, fields/format, and a closing performance note, with the most important routing advice ('START HERE') front-loaded. Every sentence carries information an agent needs; 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?

With no output schema, the description itself documents the return shape (campaigns rows with named columns, or csv+columns), pagination metadata, and the empty-page edge case. Combined with annotations and a fully described 10-param schema, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: filters run before pagination, nextOffset should be passed back as offset, fields always retains campaignId, and format=csv swaps the campaigns array for a csv+columns pair. Some items (case-insensitive namePrefix) merely restate the schema, keeping this just short of a 5.

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

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

Opens with a specific verb+resource ('Every campaign you can see, newest first') and enumerates the returned columns, so an agent knows exactly what this tool yields. It explicitly distinguishes itself from siblings by naming li_campaign_status and li_campaign_contacts as downstream consumers that need the campaignId this tool produces.

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 'START HERE' directive states when to use this tool relative to named alternatives, and explains that both sibling tools depend on a campaignId obtained here. It also describes the filter/pagination strategy so the agent knows how to narrow results rather than paginate blindly.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, yet the description adds substantial behavior: it queues behind browser work and can be slow, sends nothing and changes no record, notes the account's own member id, drops rows AFTER limit (so a page can hold fewer than requested), and reports lookup-failure flags rather than silently filtering. This is far beyond what annotations convey.

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

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

It is long, but well-structured with front-loaded purpose and clear FILTERS / COVERAGE sections, and the density is largely justified because there is no output schema to carry the field and count semantics. A few clauses about count flags could be tightened, but almost every sentence earns its place.

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

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

With no output schema, the description carries the full burden of explaining returns — participantName/participantProfileUrl/participantProfileId, lastActivityAt, unreadCount, lastMessageText, weOweReply, addressable, ours, and the alreadyDecidedCount/excludedInternalCount/excludedSystemCount/alreadyReviewedCount counters — plus coverage caveats (reachedEnd, truncated). Nothing an agent needs to call or 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 coverage is 100%, so the baseline is 3, but the description adds genuine semantics: the interplay of onlyNeedsReply/onlyAddressable/sinceDays/profileUrl, the fact that filtering counts happen before the decided/internal/system/reviewed drops, and that participantProfileId is the member id li_send_bulk_messages consumes. It goes beyond restating 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?

Opens with a specific verb+resource+scope: 'List one account's most recent LinkedIn message threads, read live from LinkedIn in a browser session.' It immediately differentiates from siblings by naming li_read_conversation for a full thread and li_conversation_history for stored reads, so an agent can route without opening another 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 states when to use each filter (onlyNeedsReply keeps threads where they spoke last; onlyAddressable drops blasts) and names alternatives with their triggering conditions (li_read_conversations_bulk for named people, li_mark_outcome/li_mark_reply_handled/li_snooze_reply for untracked senders). It even warns which filters do NOT answer a query.

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/openWorld=false/destructive=false, so the safety profile is covered. The description adds real behavioral context beyond them: 'DB-backed, instant, unpaged' tells the agent there is no pagination loop or eventual-consistency wait to handle, and the field list pre-empts output discovery.

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 purpose, scope, and return shape, then routing. Every clause carries information, though the long compound sentences in the second half are dense and slightly harder to scan than a bulleted alternative listing would be.

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 substitutes by enumerating return fields with meaning (campaignCount = campaigns you can see, shared = install-wide). Together with the routing table for related ICP tools, an agent has everything needed to call and use this correctly.

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

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

The tool takes zero parameters, so the baseline is 4. The description instead documents returned identifiers (id, name, description, campaignCount, shared, editable), which is the more useful semantic information for a parameterless list call.

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

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

States a specific verb+resource ('List the ICP labels') and immediately scopes it: labels attachable to campaigns, returned newest first. It explicitly distinguishes itself from li_list_strategies and li_list_campaigns, so an agent can route without opening another 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?

Goes well beyond context: it explains what an ICP *is* (a label for comparing audiences) and names the exact downstream tools/fields where the value is consumed (icpId/icpName to li_create_campaign / li_ingest_prospects, li_edit_campaign to change, li_outreach_analytics(groupBy="icp") to compare, li_create_icp to create). This is explicit when-and-how guidance with alternatives named.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds useful behavioral context beyond that: DB-backed, instant, unpaged, newest-first, and a detailed account of the returned strategy fields.

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

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

The first sentence front-loads the core action and return shape, while the second sentence cleanly states the routing guidance. Despite listing many fields, every included detail earns its place because there is no output schema.

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

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

For a zero-parameter, read-only list tool with no output schema, the description is highly complete: it explains the return fields, ordering, pagination behavior, shared/editable distinctions, and when to use it relative to sibling tools.

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

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

The tool takes zero parameters, so there are no parameter semantics to document. The empty schema and zero-parameter input are consistent with the description, which correctly implies this is an unfiltered list operation.

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 and resource: list the sequence templates (strategies). It also names distinguishing details like newest-first ordering and return fields, and explicitly routes the agent to sibling tools for campaigns and audience labels.

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

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

It explicitly says when to read it before li_create_campaign, li_ingest_prospects, and li_create_strategy, including the concrete purpose of picking a strategyId/strategyName or avoiding a name clash. It also names li_list_icps and li_list_campaigns as the alternatives for related data.

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 as a non-destructive read; the description goes far beyond that, disclosing the enforcement points (import, invite, automated messages, send tools that REFUSE listed people), the per-team vs install-wide scoping model, and the visibility rules for personal vs operator tokens. It also explains the returned fields scope, removable, and truncated.

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 purpose ('Read-only: who is on the do-not-contact list') before the dense behavioral detail. It is long and information-heavy, but each clause explains a distinct enforcement or scoping fact that aids correct interpretation.

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 fully by describing the row fields (scope, removable), the truncated flag, and the referenced result.suppressed shape. An agent has everything needed to interpret the response and understand caller-specific visibility.

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 single limit parameter is already documented with default and max. The description adds marginal meaning by tying truncation to limit, but does not go beyond what the schema states, 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 and resource immediately: 'Read-only: who is on the do-not-contact list this caller can see.' It scopes the resource ('this caller can see') and implicitly distinguishes itself from the mutating siblings li_suppress_profiles and li_unsuppress_profile by being the read side.

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?

Explains the operational role of the list (checked at import, invite, message steps; enforced by send tools) and names li_unsuppress_profile and li_ingest_prospects as related operations. It gives strong context for why/when the list matters but never states an explicit 'call this when you need to audit X' directive.

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 readOnly/openWorld=false/destructive=false, so the safety profile is covered; the description adds the operational facts the annotations cannot: the link runs in a server-side browser inside the account's own profile and proxy, the full session is auto-captured after the human logs in, a human must complete it, and the agent must never request the password. That is exactly the extra behavioral context this dimension rewards.

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 purpose in sentence one, then progressively adds rationale and constraints. It is fairly long and slightly repetitive (the cookie/password advice is restated twice), but every sentence carries real decision-relevant information, so the density justifies the length.

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 what the tool returns conceptually (a link), what happens after it is opened, who must act (a human), and what the agent must not do. With no output schema, this is complete enough for an agent to invoke and follow up correctly.

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

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

Schema description coverage is 100% and both parameters (sessionId, sessionLabel) are documented inline, so the baseline is 3. The description never mentions either parameter or explains the id-vs-label choice, so it adds no meaning 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?

Opens with a specific verb and resource ('Return the dashboard link that opens a REAL LinkedIn login for an account') and immediately qualifies it with the operating environment (server-side browser, account's own profile, its own proxy). An agent can distinguish this from sibling tools like li_session_status or li_verify_account 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 triggering conditions — account blocked, expired cookies, or first-time connection — and rules out the alternative approach ('strictly better than asking the user for cookies', with a concrete rationale about li_at/JSESSIONID). It does not name a specific sibling tool to prefer or avoid, so it stops just 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 give destructiveHint=true and idempotentHint=true, but the description goes well beyond them: same calendarEventId is a no-op, same event with a new meetingStart is a RESCHEDULE that only moves the time, and same event on a different person is refused. It also names the destructive side effects (cancelling remaining steps) that justify the destructive hint.

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 its effects, then idempotency semantics. Dense but nearly every sentence carries non-obvious information; a little tightening of the long sentences would reach the top mark.

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

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

For an 11-parameter mutation tool with no output schema, the description covers identity resolution, idempotency/reschedule behavior, and side effects. Only minor gaps remain, such as failure modes when the contact cannot be resolved.

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 meaning: calendarEventId is the idempotency key, meetingStart drives reschedule behavior, campaignId is required when a contact sits in multiple campaigns, and sessionId only applies when the person is in no campaign. These disambiguate when each optional identity field should be passed.

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 (record a booked call) and enumerates the exact state changes: booking status `booked`, outcome `meeting_booked`, remaining steps cancelled, `bookedAt` stamped. This clearly separates it from siblings like li_mark_outcome, li_mark_stopped, li_cancel_steps and li_mark_booking_cancelled.

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?

"Valid from any status — someone may book straight off a sequence link without ever replying" tells the agent the trigger condition well. It also offers routes to identify the person (profileUrl from li_match_contacts, or contactId). It does not explicitly name when to prefer a sibling (e.g. li_track_booking or li_mark_booking_cancelled), so it stops short of the top mark.

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

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

Annotations already indicate idempotency and non-destructiveness, but the description adds substantial state semantics: the booking returns to `agreed`/`interested`, next check follows cancelRecheckHours, nudge count is not reset, previously nudged contacts get `close` instead of a second nudge, and double-cancelling is a no-op. These are meaningful behavioral details beyond the structured annotations.

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

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

The description is front-loaded with the trigger, then flows through outcome, recheck timing, nudge behavior, idempotency, and the moved-event distinction. Every sentence contributes operational guidance without 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 mutation tool with no output schema, the description covers the relevant state transition, timing behavior, idempotency guarantee, nudge exception, and the nearest alternative tool. Only the optional note parameter is left to the schema, which is acceptable given 100% schema description coverage.

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 both parameters. The description still adds useful meaning for calendarEventId by tying it to the id recorded with `li_mark_booked` and clarifying the moved-event alternative, though it does not discuss the optional note parameter.

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

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

The description states a precise action: find the booking by calendarEventId and restore it to `agreed` with outcome `interested`. It also distinguishes this from `li_mark_booked` for moved events, so an agent can separate it from siblings 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?

It explicitly covers the triggering condition (calendar event gone or cancelled) and the key exclusion: a moved event is not a cancellation and should use `li_mark_booked` with the same calendarEventId and new meetingStart. This gives clear when-to-use and when-not-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?

Annotations only declare read-only/safe, but the description adds substantial context beyond them: what dueOnly DROPS and counts in excluded, what null means in theirLastAt (never 'they did not write'), what nudgesSent means, that no email is stored, and that neither the tool nor a due date sends anything. This is exactly the kind of behavioral disclosure the 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?

Substantial and information-dense, but it front-loads a long sibling-routing narrative and a full row-field catalogue before the core call signature is clear. Several clauses (booking lifecycle, storage caveats) could be trimmed or moved since they concern other tools, hurting front-loading.

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?

Rich enough to call correctly: row semantics, dueOnly behavior, storage caveats, and safety profile are all covered despite the lack of an output schema. Minor gap is that limit/sessionId/sessionLabel scoping is left 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 coverage is 100%, so the schema already documents all five parameters. The description's row-field explanation and its inline usage of outcome/dueOnly add situational clarity but no new syntax or format detail beyond 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?

States a specific verb+resource (listing people by their marked outcome) and scopes it (across every account you can see). Explicitly differentiates from the booked-call flow tracked by li_track_booking/li_booking_due, naming siblings an agent might otherwise confuse.

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?

Example invocation with dueOnly=true clarifies the primary use case, and the note that booked-call follow-up no longer runs here actively redirects the agent to li_booking_due. Doesn't spell out an exhaustive when-not list, but the routing guidance 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false), it discloses the 200/call cap, per-account keying, member-id resolution, overwrite-plus-history behavior, that re-marking preserves the old decision, that a rejection is NOT a suppression, and the dry-run row outcomes (marked/updated/unchanged/refused) with per-row independence.

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?

Dense but front-loaded — the core purpose and non-side-effect guarantee lead, with decision rules and dry-run semantics following. Some sentences are long and pack multiple clauses, but essentially no filler for a tool of this complexity.

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

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

For a complex mutation tool with no output schema, the description covers everything an agent needs: side-effect scope, decision semantics, refusal handling, history behavior, suppression caveat, and dry-run output shape. Nothing material 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 semantics: the conditional requirement of `reason` for rejected/wrong_lane, the meaning of `routeTo` as the cold-reach account, the accepted-refusal rule keyed to a decision value, and the sessionId/sessionLabel multi-account requirement. It goes beyond restating 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 (records decisions) and resource (inbound invitations on this account), and immediately scopes it as 'in OUR database only' with no LinkedIn-side action. This cleanly distinguishes it from li_accept_invitations and other invitation tools without the agent needing to open 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 routes the agent: 'accepted' is refused unless li_accept_invitations confirmed the accept, so accept via that tool instead. It also names the li_received_invitations interplay (rows leave results, counted under alreadyDecided) and defines when each decision applies.

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; the description earns that by specifying exactly what gets destroyed — scheduled steps cancelled, open sequence moved to handed_off. It goes further with non-obvious traits: a newer message REOPENS the conversation with the verdict kept, and marking does NOT reach a message already handed to the queue. This is behavioral context well beyond the annotations.

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

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

Front-loads the verdict definitions, then layers orthogonality, batching, closing semantics, and routing. Dense but each paragraph carries information; the length is justified by the eleven parameters and the destructive/reopen semantics, though it is heavier than strictly 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?

No output schema exists, yet the description fully covers what the tool does to state (closes conversation, cancels scheduled steps, hands off, reopens on new message), the queue caveat, and every sibling handoff. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds rationale beyond the schema: why profileUrls batching exists (same verdict across a queue, one call saved) and confirms outcome=null only unsets the verdict and revives nothing. Adds genuine meaning over the structured fields.

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

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

States a specific verb (record the human verdict) plus the exact resource and enumerates all five verdicts with discriminating definitions (`meeting_booked` = call on the calendar, NOT won). An agent can distinguish this from siblings like li_mark_booked or li_track_booking 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 routes to alternatives: use li_track_booking for someone who agreed to a call, li_mark_booked for a booked call, li_reset_contact to revive a sequence, li_job_result to check a queued reply first. It also states when-not (a demo request or booked call is never `won`) and how to undo (outcome=null).

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