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

With no annotations, the description carries the full burden, and it does disclose one meaningful side effect: tagging a booker 'stops the sequence.' It says nothing about idempotency (re-tagging an already-tagged lead), permissions, error behavior, or whether tagging creates a new tag label.

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 'Tag a lead' and reasonably short, but the closing justification ('the most avoidable bad impression in outreach') is persuasive padding that does not help an agent invoke the 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?

An output schema exists, so return values need no explanation, and the tag-value convention plus the sequence-stopping effect are covered. Still, for a 3-param, 0%-coverage, annotation-free mutation tool, key invocation details (what list_id/linkedin_url mean, idempotency of tagging) are missing.

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

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

Schema description coverage is 0% across three required params, so the description must compensate. It adds genuine meaning for `tag` (use signal type + campaign, not channel), but says nothing about what `list_id` or `linkedin_url` identify or how they interact.

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 'Tag a lead' gives a clear verb+resource, and the rest of the text specifies what kind of tag value to apply (signal type + campaign). It does not distinguish this tool from siblings that also mutate lead state, such as set_lead_state, and never clarifies whether it creates the tag or applies a pre-existing one.

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 implies when to tag ('tag anyone who books a call, so the sequence stops') and how to choose the tag value ('by signal type and campaign rather than by channel'). However, this is workflow advice rather than tool-selection guidance: no alternative tool is named and no condition for preferring add_tag over set_lead_state is given.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the safe default ('Starts paused'), that the builder enforces no rules around wait nodes or touch limits, and that daily limits default low. It omits other behavioral facts an agent would want, such as what the 'confirm' flag does or whether creation requires a verified account.

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

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

Long but well-structured with clear headers (NODES, THE STANDARD SHAPE, TWO RULES) and front-loaded purpose. Most content earns its place, though the ramp-up rationale in the final section is somewhat more verbose than needed to convey the default.

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?

An output schema exists, so return values needn't be explained. However, for a complex mutation tool with 8 params and 0% schema coverage, the description leaves several required-adjacent params (account_id, list_id, confirm, skip_leads) undocumented, making it adequate but not fully complete.

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

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

With 0% schema description coverage, the description must compensate. It richly documents the 'nodes' structure (actions, conditions, branch shape) and touches on daily limits, but leaves account_id, list_id, name, confirm, and skip_leads_in_other_campaigns entirely unaddressed. Partial compensation only.

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

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

States a specific verb+resource ('Create a campaign') and immediately adds scope that separates it from siblings: built 'from a node sequence' and 'Starts paused'. An agent can distinguish it from list_campaigns, get_campaign, set_campaign_status, and diagnose_campaign 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?

The description gives detailed guidance on HOW to build a campaign (standard shape, no-wait-after-connection_request, four-touch cap, ramp-up limits), but never states WHEN to choose this tool over alternatives or any prerequisite conditions. Usage is implied by the construction rules rather than routed explicitly.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the list is empty, but does not state auth requirements, duplicate-name behavior, side effects, or whether the list is immediately usable by import siblings.

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

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

The purpose is front-loaded in the first sentence, followed by a naming convention with concrete examples. The examples are useful, though the quoted illustrations add some length for a simple naming rule.

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

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

For a simple create tool with an output schema, the description still leaves significant gaps: no usage relative to import siblings and no semantics for the optional 'description' parameter. It adequately covers only the name parameter.

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

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

Schema description coverage is 0%, so the description must compensate. It adds naming guidance for the 'name' parameter, but completely ignores the optional 'description' parameter, leaving one of two parameters undocumented in both schema and description.

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

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

States a specific verb and resource: 'Create an empty lead list.' The word 'empty' clearly distinguishes this from import tools and from list/get siblings. An agent can identify the operation without opening other definitions.

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

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

The description gives naming advice but no guidance on when to use this tool versus import_from_search, import_from_post, or import_leads. It also lacks any when-not or prerequisite information.

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

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

With no annotations, the description carries the full disclosure burden and does well: it explains the early-termination behavior, the shape of the output (one stage, evidence, one change), and the degraded case where incomplete figures cause it to name the unassessable stage instead of guessing. It does not cover permissions, cost, or whether the diagnostic is read-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?

Front-loaded with the core purpose in the first sentence, then two supporting sentences on behavior and edge cases. The phrasing is somewhat discursive ('that is worse than no diagnosis'), which costs a little density, but every sentence contributes 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?

An output schema exists, so return-value documentation is not required, and the description's mention of stage/evidence/change is complementary rather than redundant. It covers the key behavioral edge case (partial data) but leaves the lone parameter undocumented.

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

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

Schema coverage is 0% for the single campaign_id parameter, and the description does not compensate — it never states the id format or source. The parameter is an obvious identifier, so an agent can still invoke it, but the description 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?

States a specific verb ('Run the diagnostic chain') against a specific resource ('one campaign') and a specific return ('the failing stage'). This is clearly distinguishable from siblings like get_campaign_stats or get_campaign, which return raw data rather than a diagnosis.

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 for when to use it: it walks the chain in order and stops at the first failure 'rather than returning five stages of numbers when the first one is broken' — implicitly contrasting with the stats siblings. It also states the partial-data case, but does not name a specific alternative tool or prerequisite to prefer this over get_campaign_stats.

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

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

With no annotations, the description carries the full burden and does real work: it discloses that the limit is account-wide rather than per campaign, and quantifies the aggregation (3 campaigns x 20 = 60 attempts/day), which changes how an agent interprets the number. It does not cover auth requirements, rate limits, or failure modes, but for a read tool whose return shape is documented by an output schema, 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?

The first sentence front-loads the purpose; the second paragraph justifies the number's meaning and the third states when to call. Every sentence earns its place, though the aggregation example is slightly more elaborate 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 one-parameter read tool with an output schema covering return values, the description supplies what is missing: what the number means, how it is computed, and when it matters. An agent has everything needed to call it correctly and interpret the result.

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

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

Schema description coverage is 0%, so the description must compensate, and it only implies the parameter by saying 'one account'. The single parameter is account_id and self-evident, so the practical risk is low, but no format, source, or acquisition guidance is added.

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: the remaining daily send budget for one account, aggregated across all campaigns. This clearly separates it from siblings like get_account_health (health, not budget) and set_daily_limits (mutation of limits, not a read of remaining budget).

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 concrete triggers: call before proposing any volume, and before launching a campaign on an account that already has one running. It does not explicitly name an alternative tool or a when-not-to-use case, but the usage context is unambiguous.

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

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

No annotations exist, so the description carries the full burden; 'Check' plus the report list establishes it as a read-only inspection. It also discloses a genuinely non-obvious interpretive trait — that combined daily volume can exceed the ceiling even when each campaign looks fine — which is behavioral context an agent cannot recover from the schema or output schema. It stops short of stating auth requirements or rate limits, and there is no explicit statement that nothing is mutated.

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 in the first sentence and the three short paragraphs have no filler. The middle paragraph re-enumerates output fields despite an output schema already existing, and the closing example, while valuable, is slightly expansive for a one-parameter read 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?

An output schema is present, so return values need not be described, yet the description usefully adds interpretation of the volume ceiling. For a single-param, read-only diagnostic tool this is close to sufficient; only alternative-tool routing and any access prerequisites are missing.

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

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

Schema description coverage is 0% for the single account_id parameter. 'Check one account' signals singular scope and that the argument is an account identifier, but nothing addresses format, source, or how to obtain a valid value (e.g., via list_accounts). Minimal compensation for an undocumented 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?

Specific verb ('Check') plus resource ('one account') plus an explicit enumeration of the reported fields (connection status, session refresh, cap/restriction, active campaign count, combined daily volume). Scope is stated as single-account, but the closest sibling (diagnose_campaign) is never named; the opening phrase 'conditions that stop a campaign working' even introduces campaign terminology, so an agent must infer the account-level vs campaign-level split.

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 clause 'conditions that stop a campaign working' implies the diagnostic use case (check before or when a campaign underperforms), but there is no explicit when-to-use, when-not-to-use, or routing to get_account_budget or diagnose_campaign. Usage must be inferred.

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

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

No annotations are provided, so the description carries the burden. 'Get' implies a non-mutating read, and the description discloses what data comes back (node sequence, limits, source list, status), which is above a bare tautology. However it says nothing about permissions, whether the campaign must exist, or failure 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?

One front-loaded sentence with a clear verb and an enumerated payload; no filler. It is arguably terse given the missing usage guidance, but as written every clause earns its place.

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

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

For a one-parameter read tool with an output schema already documenting the return shape, the description covers purpose and payload adequately. It omits error/permission context, but the output schema removes the need to describe return values in detail.

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

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

The single required parameter is campaign_id with 0% schema description coverage, so the description must compensate. 'Get one campaign' implies the id selects a single campaign, but no format, source, or lookup guidance is added beyond that implication.

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 ('Get one campaign') and enumerates what it returns: node sequence, daily limits, source list and status. This clearly separates it from list_campaigns and get_campaign_stats, though it doesn't name siblings 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?

No guidance on when to use this versus get_campaign_stats, diagnose_campaign, or list_campaigns. The only implied use is fetching a single campaign by id, which is inferred rather than stated. No prerequisites or exclusions are given.

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

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

No annotations are provided, so the description carries the full burden. It usefully enumerates the metric categories and their interpretation thresholds, but says nothing about read-only safety, rate limits, or whether campaign_id must exist — 'get' is the only implicit safety signal.

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 opening line is well front-loaded and the numbered chain is scannable. But a large share of the text is prescriptive diagnostic methodology ('Report the failing stage and one change. Never more than one change a week') that belongs to the diagnostic workflow rather than to a stats getter, diluting the tool's actual behavior.

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 one obvious required parameter and an output schema that documents return values, the description needs little more to be callable. The metric list plus interpretation thresholds make it actionable, though the overlap with diagnose_campaign remains unexplained.

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?

One parameter at 0% schema description coverage, and the description never mentions campaign_id or its format/required-ness. The parameter is self-evident from its name, so this is adequate but 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?

States a specific verb+resource ('Get the figures...requests sent and accepted, messages sent, replies') and names the metrics returned, which differentiates it from siblings like get_workspace_stats. However, it never distinguishes itself from diagnose_campaign, and the closing instruction to 'Report the failing stage' blurs whether this tool reports numbers or performs diagnosis.

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 diagnostic chain implies the intended use (feed these figures into staged failure analysis) and even prescribes post-retrieval behavior. But it never explicitly says when to call this vs. diagnose_campaign, nor states prerequisites or exclusions, leaving the routing to the agent to infer.

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

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

No annotations are provided, so the description carries the burden. It does disclose what the read returns (full thread plus lead profile and campaign context), but adds nothing about access scope, thread limits, or behavior on missing/closed conversations.

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

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

Two short paragraphs, front-loaded with the core action and followed by a one-line rationale for reading the full thread. The second paragraph is motivational rather than factual, but it is brief and steers agent behavior.

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

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

With an output schema present, return-value detail is unnecessary, and the description covers purpose, scope, and workflow fit for a simple one-parameter read. The gap is the undocumented conversation_id, which is the only real omission.

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

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

Schema description coverage is 0% for the single required conversation_id parameter. The description never explains the identifier's format or where it comes from (e.g. from get_inbox or get_lead), leaving the only parameter's semantics undocumented.

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

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

States a specific verb (read) and resource (one full conversation thread) and even names the payload contents (lead profile, campaign context). It is not explicitly contrasted with siblings like get_inbox or get_lead, but the scope wording makes it distinguishable on its own.

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?

"Read the whole thread before drafting" gives clear workflow context — use this prior to composing a reply — which is real when-to-use guidance. It stops short of naming alternatives (e.g. get_inbox for the list view) or stating exclusions, so it is not 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the cross-account aggregation behavior and the empty-account_id mode, but omits the read-only safety profile, pagination/limit behavior, and how campaign_id/unread_only alter results.

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

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

The purpose is front-loaded in the first sentence, which is good. However, sentences two and three both restate the same unified-queue convenience, and the "eight client accounts" framing reads as promotional filler rather than actionable detail.

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

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

The presence of an output schema means return values need not be explained here, which the description correctly omits. Still, with no annotations and three of four parameters undocumented, the definition leaves meaningful filtering and safety context unstated.

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

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

Schema description coverage is 0% across 4 parameters, and the description compensates for only one: account_id (empty → all accounts). limit, campaign_id, and unread_only remain undocumented in both the schema and the description.

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

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

"Read the unified inbox across every connected account" is a specific verb + resource and communicates the cross-account scope clearly. It does not name the closest sibling (get_conversation) to distinguish listing the inbox from reading a single thread, so differentiation is inferred rather than stated.

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

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

"Leave account_id empty to see everything in one queue" plus the daily-reply-pass scenario give clear context for when to reach for this tool. There is no when-not-to-use guidance and no named alternative (e.g., get_conversation), which keeps it short of a 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses returned categories and explains custom variables, but omits access requirements, error behavior, and side effects; it is a read operation, which limits risk.

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

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

Two short sentences, front-loaded with purpose and return categories. The second sentence explains custom variables without redundancy.

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

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

For a simple two-parameter read with an output schema, the description covers what the tool returns and explains custom variables. It leaves parameter semantics and operational edge cases unstated, but the output schema handles return details.

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

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

Schema description coverage is 0% and neither required parameter is described. The description does not define list_id or linkedin_url or their relationship, leaving the agent to infer meaning from parameter names alone.

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

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

The description names a specific verb and resource ('Get one lead') and enumerates the returned scope (profile fields, state, campaign membership, custom variables), which distinguishes it from multi-lead siblings like search_leads. An agent can tell it fetches a single record.

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

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

The description implies single-lead lookup but never states when to choose it over search_leads or list_lead_lists, nor any preconditions. Usage is only inferable from the phrase 'one lead'.

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

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

No annotations are provided, so the description carries the burden, and it does disclose the return shape (count plus per-state breakdown) and even how to interpret the numbers. It says nothing about permissions, error behaviour (e.g. invalid list_id), or whether counts are cached/live, and the existing output schema already covers the return fields.

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

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

Front-loaded with the core purpose in the first sentence, then two short supporting blocks. The interpretation paragraph (connection note vs list quality) is domain guidance rather than invocation help, so it earns its place less clearly, but nothing is bloated.

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?

An output schema exists, so return values need not be spelled out, and the description nonetheless enriches them. The main gap is procedural: how to obtain a valid list_id and what to do on failure, which the description omits entirely.

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?

There is one required parameter, list_id, with 0% schema description coverage, so the description is the only place it could be explained. It refers to 'one lead list' but never defines what a list_id is, its format, or that it comes from list_lead_lists, leaving the agent to infer the identifier's origin.

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 first sentence gives a specific verb and resource ('Get one lead list') and immediately scopes the return ('with its lead count and a breakdown by lead state'), which cleanly separates it from the sibling list_lead_lists. An agent can tell what it returns 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?

Usage is implied through the framing 'The state breakdown is the useful part' and the diagnostic hint about Not Accepted vs Contacted, which tells the agent this is an inspection/diagnosis tool. However, it never states when to reach for this vs list_lead_lists or search_leads, nor any prerequisites such as needing the workspace/list context first.

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

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

With no annotations provided, the description carries the full load; it does disclose the default time window and the accepted date format, which is real behavioral context. However, it says nothing about read-only safety, permissions, rate limits, or aggregation semantics (e.g., whether figures are summed or averaged across accounts), leaving meaningful gaps for a no-annotation 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 first two sentences are tight and front-loaded with the essentials (scope, then date format and default). The third sentence about reporting percentages beside absolutes is a philosophical aside about presentation rather than tool behavior, and it occupies roughly half the description without telling the agent how to call the 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?

An output schema exists, so return values need not be described, and the two parameters are covered by the date-format and default notes. What's missing is any statement of read-only nature or aggregation behavior, which matters given the absence of annotations for a stats tool spanning all accounts and campaigns.

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

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

Schema description coverage is 0% and the schema only shows date_from/date_to as nullable strings with null defaults, so the description does the compensating work: 'Dates are ISO, YYYY-MM-DD' and 'Omit both for the last 30 days' give both format and default semantics. This is a solid improvement over the bare schema, though it omits the format of any complete-date response and ordering constraints.

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 first sentence gives a specific verb ('Get figures') and an explicit scope ('across every account and campaign, for a date range'), which implicitly separates it from the single-campaign sibling get_campaign_stats. It never names a sibling outright, so the differentiation relies on the reader inferring 'all accounts/campaigns' vs. per-entity tools like get_campaign_stats or get_account_budget.

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

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

Usage is only implied through scope: the workspace-wide aggregation suggests when to prefer this over a per-campaign stat tool, but no explicit when-to-use or when-not-to-use statement is given. The default-window note ('Omit both for the last 30 days') is parameter behavior, not selection guidance.

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

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

With no annotations, the description carries the full burden, and it does disclose real behavior: importing is free, sending is the capped resource, and include_future_reactions leaves the import open so later engagement is pulled in automatically. It omits other behaviors an agent would want, such as duplicate handling against existing list members, permissions, and whether the import is synchronous.

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?

Opens with the purpose, then layers the differentiator, the parameter rule, and the cost model in short scannable paragraphs. The 'highest-intent cold source' framing is persuasive rather than operational, but it is brief and does support tool selection.

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?

An output schema exists, so return values need not be described, and the description plus schema together cover the core call. Gaps remain around how the import interacts with existing list contents (append vs replace) and required permissions for a 5-parameter write tool with no annotations.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate. It explains the one genuinely ambiguous parameter well (include_future_reactions keeps the import open for later engagement), but list_id, post_url, include_likers and include_commenters are never addressed.

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 (Import), a specific resource (people who engaged with a LinkedIn post) and a destination (into a list). It also draws a conceptual line against filter-based sourcing ('someone who matches a search filter has not'), which is exactly how a sibling like import_from_search is distinguished.

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

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

Gives clear when-to-use framing ('highest-intent cold source') plus a conditional rule for include_future_reactions ('Leave it on for a post that is still travelling') and a strategic rule ('import broad and filter at the send step'). It never names the alternative tool to call instead, so it stops short of explicit when-not/alternatives routing.

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

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

With no annotations, the description carries the full behavioral burden and only partially meets it: it discloses that results have "weaker intent" and require heavier post-filtering, useful context about output quality. It says nothing about permissions, rate limits, deduplication, or what happens on failure.

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

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

Two short sentences, front-loaded with the core action, with no filler. "Weaker intent than a post import" is slightly terse/jargon-y but still earns its place as comparative guidance.

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?

An output schema exists, so return values need no explanation, but the description leaves two required parameters and a result cap undocumented and omits any behavioral detail for an annotation-less importing tool that creates lead records.

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

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

Schema coverage is 0% for all three parameters, so the description must compensate but does not: list_id, search_url, and max_results (default 200) are never mentioned. The names are somewhat self-describing, but the default limit and the required identifiers are left entirely to 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 (Import) and resource (leads) plus the source (LinkedIn or Sales Navigator search URL), which separates it from the URL-less import_leads and the post-based import_from_post. It does not explicitly name or contrast with import_leads, leaving some sibling ambiguity.

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

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

"Use it when there is no relevant post" gives a clear when-to-use condition that routes the agent away from import_from_post. However, it never addresses when to prefer import_leads, and no exclusions or prerequisites are stated.

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

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

No annotations are provided, so the description carries the full burden. It does disclose meaningful behavior — that each lead requires linkedin_url and that arbitrary extra keys become custom variables usable in message prompts — which is genuinely useful. It omits permissions, duplicate handling, list append-vs-overwrite semantics, and partial-failure 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 action, then the two most important behavioral facts, then a compact concrete example. The example earns its length because the schema is opaque; nothing reads as 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?

An output schema exists, so return values need no explanation. Still, for a required-parameter mutation tool with no annotations and an undescribed list_id, an agent lacks enough to call it confidently against its import siblings.

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

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

Schema coverage is 0% and the leads array is an opaque additionalProperties:true object, so the description's explanation of the lead shape (linkedin_url mandatory, everything else becomes a custom variable) is essential and it delivers that. But list_id is never explained anywhere, and there is no guidance on multi-lead array limits or key naming rules.

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 ('Import leads') and adds the crucial qualifier 'from structured data', which hints at the distinction from import_from_post/import_from_search. However, it never explicitly contrasts itself with those siblings, so the boundary must be inferred.

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

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

The phrase 'from structured data' plus the worked example implies usage, but there is no explicit when-to-use statement and no pointer to import_from_post or import_from_search for the other ingestion paths — a real gap given three import siblings exist.

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

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

With no annotations, the description carries the disclosure burden, and it does well: it names the returned fields and the important behavioral fact that the daily budget is per account rather than per workspace. It does not state that the call is read-only and side-effect free, nor mention permissions or rate limits, leaving a modest 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 core purpose and the call-first directive, and each sentence carries weight. The enumerated return-field list is partially redundant given an output schema exists, which is a small inefficiency but not bloat.

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 listing tool with an output schema, nothing an agent needs is missing: it knows when to call it, why (account_id prerequisite), and what it yields. Return-format detail is legitimately out of scope since the output schema covers it.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate in the schema. It does usefully explain that the account_id produced here feeds every other tool, which adds conceptual value beyond the empty schema.

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

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

States a specific verb and resource plus scope ('LinkedIn accounts connected to this Prosp workspace'), and enumerates the returned fields. It is clearly distinguishable from siblings like get_account_budget or get_account_health, which operate on a single already-known 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?

Explicitly tells the agent to 'Call this before anything else in a session' and gives the reason: every other tool needs an account_id. It even surfaces the per-account budget model, which shapes downstream planning. This is exactly the routing guidance 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?

With no annotations, the description carries the full behavioral burden. It implies a read-only listing and explains the aggregate-volume rationale, but says nothing about pagination, result size, auth/permissions, or whether filtering is exact-match. The behavioral disclosure is partial rather than rich.

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

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

The purpose is front-loaded in the first sentence, with the rationale following. The 'headroom' sentences are slightly elaborate but earn their place by motivating the call; there is no filler or repetition.

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

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

An output schema exists, so return-value explanation is rightly omitted, and the description covers purpose, filtering, and a usage heuristic. However, with no annotations and zero schema descriptions, an agent still lacks pagination behavior and the valid status vocabulary needed to invoke it confidently.

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

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

Schema coverage is 0% and there are two parameters, so the description must compensate. It does map both parameters conceptually ('filtered by account or status') and marks them optional, but gives no accepted status values, no ID format, and no indication that both filters can combine.

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 specific verb (List) and resource (campaigns) plus the filter dimensions (account, status), so an agent knows exactly what the tool returns. It stops short of naming how it differs from siblings like get_campaign or list_accounts, but the singular/plural distinction is inferable.

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 context ('Run this before creating anything') tied to a concrete decision (how much headroom a new campaign has), which routes the agent well relative to create_campaign. It does not name when-not to use it or point to an alternative for single-campaign lookups.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses sort order ('newest first') and the returned fields (id, name, lead count, source type, creation date), which is real added context. However, it says nothing about pagination behavior despite a limit parameter with a default of 25, nor about permissions or truncation.

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

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

Two short sentences, zero filler, and the scope/sort constraint is front-loaded before the return-field summary. 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?

An output schema exists, so enumerating return fields is technically redundant, and the description omits the one thing the schema cannot convey: how the limit parameter governs pagination. For a simple read-only list tool the description is nearly sufficient, but the parameter gap keeps it from being complete.

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

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

The single 'limit' parameter has 0% schema description coverage, so the schema only supplies a name and default of 25. The description never mentions limit, pagination, maximum page size, or how to retrieve subsequent pages, leaving the one parameter effectively undocumented.

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

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

States a clear verb+resource ('List the lead lists') and adds scope ('in this workspace') plus an ordering guarantee ('newest first'). It does not explicitly contrast with the sibling get_lead_list (singular), but the plural 'lists' vs. singular naming makes the distinction inferable.

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

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

Provides no when-to-use guidance, no prerequisites, and no pointer to alternatives such as get_lead_list for a single list or search_leads for filtered results. The agent must infer that this is the unfiltered enumeration tool.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the key non-obvious behavior: the conversation is marked read and no reply is sent, which matters given the send_reply sibling. It says nothing about idempotency, required permissions, or whether other conversation state changes.

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

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

Two short sentences, front-loaded with the action and its key constraint, then the rationale. No wasted words and the intent is clear on first read.

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

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

An output schema exists, so return values need no explanation, and the tool's scope is a single-parameter state change. The description covers purpose and usage well; only permission requirements and idempotency are unaddressed, which are minor for this small a mutation.

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

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

Schema description coverage is 0%, so the description would need to compensate, but it never mentions the single conversation_id parameter. The parameter name is largely self-explanatory and typed as string, so the practical gap is small, but the description 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?

States a specific verb+resource ('Mark a conversation as read') and immediately adds the disambiguating constraint 'without replying', which cleanly separates it from the send_reply sibling. An agent can route to it without opening the schema.

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

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

Gives concrete usage context ('auto-replies and anything already handled elsewhere') and the goal it serves (keeping the unread queue a real to-do list). It implies the alternative by negation ('without replying') but never names send_reply explicitly as the contrasting tool.

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

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

No annotations are present, so the description carries the full behavioral burden. It contributes domain knowledge (the complete set of valid state values, which is not in the schema), but omits whether this is a bounded read, how many results come back by default, and whether state and tag are combined with AND or OR — meaningful gaps for a search tool with zero 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?

Front-loaded with the core operation and the state enumeration, and the two example scenarios are short. The 'fastest way to find everyone worth a human reply today' phrasing leans promotional, but it earns its place as usage guidance.

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?

An output schema exists, so return values need not be described. However, for a read-only search with four undocumented parameters, the definition leaves the filter-combination semantics and limit behavior unexplained, leaving the agent to guess about result volume and narrowing logic.

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

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

Schema description coverage is 0%, so the description must compensate. It does document the state parameter's value domain and confirms tag filtering, but says nothing about list_id (required), limit (default 50, pagination behavior), or how state and tag interact. Partial compensation at best.

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 (search) and the two filter axes (state or tag) applied to leads in a list, and enumerates all valid state values, which is exactly what an agent needs to pick this over get_lead or list_lead_lists. It never explicitly says the results are leads or scopes the list_id resource, so it falls short of a perfect 5.

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

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

Gives two concrete when-to-use scenarios: state="replied" to surface people worth a human reply, and not_accepted after 14 days to gauge connection-note performance. That is real contextual routing, but it never names an alternative tool (e.g., get_lead for a single record) or states when NOT to use this search.

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

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

With no annotations, the description carries the full behavioral burden and does disclose meaningful traits: the confirm gate, a hard prohibition on replying to NOT_INTERESTED, and an escalation path for low-confidence classifications. It stops short of technical traits such as authentication requirements, irreversibility of a sent reply, or any rate limits, which is the main remaining gap.

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

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

Front-loads the action and the confirm prerequisite before the taxonomy, and the classification block is formatted for scanning. It is markedly longer than a 3-param tool strictly needs, and some process policy (the full category list) sits at the edge of what belongs in a tool description, but no sentence is pure 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?

An output schema exists, so return values need not be explained, and the description covers the decision surface an agent needs: classification, escalation threshold, and the confirm gate. What is missing is operational context around permissions and state effects on the conversation.

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

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

Schema coverage is 0%, so the description must compensate and only partially does. 'Requires confirm=true' directly documents that parameter, and the register/length/one-question rules indirectly constrain what belongs in `message`, but `conversation_id` receives no explanation of format or provenance.

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 (send a reply) and names the scope constraint (in an existing conversation). The agent can distinguish it from siblings like get_conversation, get_inbox, and mark_read 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?

Provides explicit when-to-use and when-not-to-use rules: 'Never send to NOT_INTERESTED' and 'Below 8 confidence, escalate to a human rather than guessing.' It also names the confirm=true prerequisite, so both the routing decision and the gating condition are stated rather than inferred.

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

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

With no annotations, the description carries the full burden and does disclose real behavioral traits: starting is an outward-facing, real-people action gated by confirm=true, while pausing is reversible/safe. It stops short of covering archival permanence, permissions, or rate limits.

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 capability, then the enum values, then the safety distinction. Four short lines, no filler; the safety sentence directly justifies its 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?

An output schema exists so return values need not be described, and the mutation's safety profile is partially covered. The main residual gap is whether archiving is irreversible and what happens to a running campaign's in-flight work.

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

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

Schema coverage is 0%, so the description must compensate, and it does for the two non-obvious parameters: it enumerates valid status values (active, paused, archived) and explains what confirm controls and when it is required. campaign_id is left unexplained but is self-evident.

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 set (start, pause, archive) on a specific resource (campaign), which cleanly separates it from siblings like create_campaign, list_campaigns and get_campaign_stats.

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 operational guidance: pausing is safe, starting requires confirm=true because it reaches real people. It does not name alternative tools, but the when-to-use distinction between the three statuses is 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?

With no annotations, the description carries the full burden, and it does disclose a genuinely important trait: limits are per-campaign but consume a shared per-account ceiling, so raising one affects others. It omits permissions required, whether changes are reversible, and what a null limit value does (clear vs. no-op), leaving meaningful behavioral gaps.

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

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

Two short sentences, front-loaded with the action and immediately followed by the prerequisite and the side-effect warning. 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?

An output schema exists so return values need not be described, and the shared-ceiling caveat is valuable. But with zero annotation coverage and zero parameter documentation, the description leaves the agent under-informed about an operation whose null-valued parameters are ambiguous.

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

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

Schema description coverage is 0% and the description never explains campaign_id, daily_message_limit, or daily_connection_limit. The nullable-with-null-default parameters in particular need semantics that neither the schema nor the description supply.

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 campaign's daily limits), which is unambiguous against siblings like set_campaign_status or get_account_budget. It does not, however, distinguish itself from other mutation tools beyond the named prerequisite.

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 tells the agent to check get_account_budget first, naming the sibling and the ordering constraint. There is no when-not guidance or mention of what happens on failure, so it falls short of a 5.

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

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

With no annotations, the description carries the full behavioral burden and only partially meets it. It discloses important semantics for the blacklist state (a boundary, not a pause, persisting across campaigns), but says nothing about whether the operation is reversible, what permissions are needed, what side effects occur on the lead or its campaigns, or how conflicting with an existing state is handled.

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 in one short sentence, then adds a focused usage note with no filler. The blacklist sentence is slightly rhetorical ('a boundary, not a pause') but it earns its place by conveying a durable semantic distinction.

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

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

For a 3-required-parameter mutation tool with no annotations and 0% schema description coverage, the definition is under-specified. The output schema relieves it of explaining return values, but the missing parameter documentation, state-value semantics, and mutation behavior leave an agent without enough context to call it safely.

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

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

Schema description coverage is 0%, so the description must compensate, and it does so only for the blacklist value of one parameter. list_id and linkedin_url are entirely unexplained, and two of the three enum values (not_contacted, duplicate) are not described in either place.

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 one lead's state') and scopes it to a single lead, which is clear enough to distinguish from batch/import siblings. However, 'state' is left undefined in the prose and its meaning only emerges from the schema enum, so it is not a fully self-contained purpose.

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

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

The description gives explicit when-to-use guidance for one enum value ('Use blacklist for anyone who asked not to be contacted'), which is genuinely useful. But it is silent on when to use the tool at all versus alternatives, and gives no guidance for the not_contacted or duplicate states, leaving usage only partially 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?

With no annotations, the description carries the full burden and it does disclose a meaningful behavioral trait: the tool depends on upstream tagging and returns nothing when that tagging is missing, which the agent should interpret as a data-quality finding rather than a bug. It does not state read-only vs mutation or any permission requirements, so a small gap remains.

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

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

The purpose is front-loaded in the first sentence, followed by a short rationale and a caveat. Each sentence carries weight, though the editorial aside about it being 'the single most useful line' is slightly padded.

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

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

The output schema covers the return format, so no explanation of results is needed, and the description handles purpose, precondition, and empty-result interpretation. However, it is silent on the date-range parameters that scope the analysis, leaving the agent without guidance on how to constrain the query.

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

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

Schema description coverage is 0%, and the description never mentions the two parameters (date_from, date_to) at all — no format, no expected range, no default behavior. The agent must infer from the schema alone that these are date bounds, which is a clear compensation gap.

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

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

States a specific verb and resource: reports which signal type and campaign produced booked meetings. An agent can tell this apart from stats-oriented siblings like get_campaign_stats or get_workspace_stats by the attribution framing. It stops short of explicitly naming a sibling it supersedes or complements.

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 use context (the monthly report line) and an explicit precondition: it only works if leads were tagged with signal type at import. It also pre-empts a likely confusion by stating that an empty result is itself the finding. No explicit alternative tool is named, but the when-to-use guidance is concrete.

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