Prosyo

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

Annotations indicate it is not read-only, not destructive, and not idempotent. The description adds that approval researches people for credits, you see the message before sending, and it only runs after confirm_action. This is good extra context, though it doesn't detail rate limits or errors.

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

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

Three short sentences packed with essential information: purpose, source of ids, side effects, visibility, and ordering. No wasted words.

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

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

Given one required parameter, no output schema, and annotations covering safety, the description covers purpose, usage, and key side effects. It could be slightly more explicit about what the tool returns or whether approval is immediate versus queued.

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. It names the parameter source (run ids from list_review_queue) and implies they are required and refer to review queue items. It doesn't fully describe the array format, but gives enough semantic meaning.

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

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

The description states a specific action: preparing approval for people waiting in the review queue, and clarifies that run_ids come from list_review_queue. This distinguishes it from siblings like list_review_queue or confirm_action, though it could more explicitly frame the overall workflow.

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 ties the tool to the review queue and list_review_queue, and states that it runs only after confirm_action. This gives a clear precondition and workflow step.

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, idempotentHint=false, readOnlyHint=false, and openWorldHint=true. The description adds valuable context: this only runs after explicit chat confirmation, and the token comes from a prior tool. However, it does not warn that the action is destructive/non-idempotent or describe side effects, so it adds context but does not fully complement 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?

Three sentences, front-loaded with the core action, then the key constraint and parameter guidance. No filler; every sentence earns its place.

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

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

For a single-parameter confirmation executor, the description covers the essential gate (user confirmation) and parameter source. With annotations covering safety profile and no output schema required, it is largely complete. Minor gap: it could clarify that the action is not idempotent or that retrying may duplicate, though destructiveHint already signals risk.

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

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

Schema description coverage is 0% for the single required parameter confirmation_token, and the schema provides no description. The description compensates by stating 'Pass confirmation_token from the previous tool,' which explains the parameter's origin and meaning. This is a meaningful addition beyond the empty schema, but it is minimal; more detail on token format or expected source tool would help.

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

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

The description states a specific purpose: executing a previously-prepared action (launch, enroll, resume, inbox send, unlock, research, enrichment, or review approval) after user confirmation. It names the resource types clearly, though the very broad set of actions makes the tool feel like a catch-all rather than a single distinct capability. It is distinguishable from siblings by being the confirmation executor.

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: 'after the user explicitly confirmed in this chat' and 'Never call this unless they said yes.' It also directs the agent to pass confirmation_token from the previous tool, which is critical usage guidance. The condition for use vs. non-use is unambiguous.

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

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

Annotations only tell the agent it is a non-readonly, non-destructive mutation. The description adds real behavioral context beyond that: nothing is launched or enrolled, intent-mode audiences self-populate and 'each waits for review first,' and the draft status should be communicated to the user. Return shape is the only omitted trait.

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 essential fact (draft, no launch/enroll) and then lays out modes economically. The intent-mode sentence is long but packs distinct behavioral information that 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 mutation tool with no output schema, the description covers creation semantics, mode selection, review gating, and draft messaging. It omits what the call returns (e.g., a campaign id), which an agent would want for a follow-up launch, but otherwise nothing needed to call it correctly is missing.

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

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

Schema coverage is 63%, so several parameters (name, timezone) rely on the schema alone. The description does map mode values to their parameters (preset_id, ai_brief, intent_signals) and explains the intent mode's self-filling audience, which adds meaning beyond the enum list, but it never addresses min_fit or min_tier, so it doesn't fully compensate for the coverage gap.

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

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

States a specific verb+resource ('Create a draft campaign') and immediately delimits scope with 'Does not launch or enroll anyone,' which cleanly separates it from launch_campaign and enroll_prospects. An agent can pick this tool over its siblings without inspecting any schema.

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

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

Enumerates the four modes (blank, preset, ai, intent) and ties each to its driving parameter, plus a clear rule: 'Tell the user it is a draft until they confirm a later launch.' It doesn't explicitly name the sibling tools to use at launch time, but the when-to-use context is strong.

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

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

Annotations declare readOnlyHint=false and openWorldHint=true, so the safety profile is partly structured. The description adds meaningful context beyond that: the operation 'does not send' and 'returns text only', clarifying the side effect boundary. It does not comment on whether a persistent draft artifact is created or on permissions, so it falls short of 5.

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

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

Three short sentences, front-loaded with the core action and then the key caveat and routing hint. 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?

No output schema exists, so the description appropriately clarifies the return ('text only'). For a one-parameter tool this is nearly complete, with the only gap being the unexplained thread_id 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% and the single parameter (thread_id) is never mentioned or explained in the description. The description gives no guidance on what thread_id should be or its format, so it adds no meaning beyond the bare schema.

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

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

States a specific verb and resource (draft an inbox reply) and immediately distinguishes itself from the sibling send_inbox_reply. An agent can tell drafting apart from sending 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 names the alternative tool and the condition that selects it: 'Use send_inbox_reply after the user wants to send it.' The when-to-use-this-vs-that is fully spelled out.

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

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

Annotations already disclose that this is a non-readonly, non-idempotent, non-destructive mutation. The description adds material context beyond that: credit consumption per person and the hard dependency on a prior confirm_action call, which an agent cannot infer from annotations alone.

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

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

Two compact sentences with no filler, and the primary action is front-loaded before the cost/prerequisite caveats. Slight awkwardness in 'Prepare enriching prospects' but nothing wasteful.

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 and a two-parameter surface, the description covers modes, cost, and the confirm_action dependency, which is most of what an agent needs. It omits what the call returns or how the prepared result is later committed, leaving the confirm_action handoff only half-explained.

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

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

Schema coverage is 0%, so the description must carry the load. It does explain the ambiguous 'mode' enum values, which is the most valuable addition, but leaves 'prospect_ids' unexplained (format, source, limits) and says nothing about whether both modes accept the same ID list.

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 ('enrich prospects') and names the two operating modes with their enum values, so the agent knows exactly what this tool produces. It is distinguishable from siblings like research_prospects and enroll_prospects, though the 'prepare' framing leaves the two-step flow slightly ambiguous without reading the confirm_action 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 the mode-selection condition implicitly (enrich_only vs personalized_line) and an ordering prerequisite ('runs only after confirm_action'), which is genuinely useful. However, it never says when to prefer this over research_prospects or enroll_prospects, nor when to pick each mode.

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

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

Annotations only say readOnlyHint=false, destructiveHint=false, idempotentHint=false; the description adds the crucial behavioral fact that nothing is enrolled until confirm_action runs, which tells the agent the call is non-committal despite the write-flavored name. It does not describe what the call returns (a preview? a token to pass to confirm_action?) or how long a prepared enrollment stays valid.

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 with the staging semantics front-loaded and the gating condition second. No filler, no restatement of the tool name.

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

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

For a no-output-schema, three-parameter staging tool, the description covers the essential flow an agent needs to avoid double-enrolling someone. Gaps remain around parameter relationships and what to do with the result, but the core contract is conveyed.

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 three parameters, so the description must carry the load. It hints that 'a list or specific people' correspond to list_id vs prospect_ids, implying they are alternatives, but it says nothing about formats, whether they are mutually exclusive, or that campaign_id is required.

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 action (preparing to add a list or specific people to a campaign) and correctly reframes the misleading 'enroll' name as a staging step. It implicitly separates itself from confirm_action, which handles the actual enrollment, though it doesn't say how it relates to sibling tools like list_lists or search_prospects that would supply the inputs.

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

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

It clearly states the two-step flow: call this to prepare, then confirm_action once the user agrees in chat. That gives an explicit when-to-use and names the follow-up tool, but it offers no exclusion guidance (e.g., whether it can be called repeatedly, or what to do if the user declines).

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, idempotentHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing about return behavior, pagination, or auth beyond what annotations and the field list imply.

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

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

A single front-loaded fragment with no filler; each listed field earns its place as a preview of the return shape. Slightly terse even for a one-param read tool, but no 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 one-parameter read-only tool with 100% schema coverage and clear annotations, this is adequate: the agent knows the id, safety profile, and rough return fields. It lacks any error/not-found or empty-state note, so it is complete enough but not rich.

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% (campaign_id documented), and the description adds no syntax, format, or sourcing guidance for the id. Baseline 3 applies when the schema carries the parameter burden.

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_campaign → 'Campaign detail') and enumerates the fields returned (status, enrolled count, sequence step types, connected seats), which distinguishes it from list_campaigns and preview_campaign. It does not explicitly name a sibling to avoid, so it falls short of 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?

Usage is implied by the singular resource name – fetch detail for one campaign by id. There is no explicit when-to-use vs list_campaigns or preview_campaign, and no prerequisites stated, so it's minimum-viable guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered by structured data. The description's added value is that it lists the returned fields, which matters because no output schema exists, but it says nothing about account scoping, freshness, or failure modes.

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

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

A single tight sentence with no padding, and the most decision-relevant item (plan name/status) is front-loaded. It is a fragment without a verb, which costs it the top mark but not much else.

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 tool with no output schema, the description carries the burden of describing the return payload and does so reasonably well by listing the six returned values. Missing only account scoping and any hint about when the data is refreshed.

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 per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly avoids inventing 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?

The description enumerates the data the tool surfaces (plan name, trial/paid status, seat counts, campaign limit, credit balance), so an agent can infer it reads account entitlement info. However, it never states an action verb or explicitly frames this as a retrieval of the current account's plan, leaving the purpose implied rather than declared.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no differentiation from overlapping siblings such as get_overview. The agent must guess that this is the tool for plan/billing/seat 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?

The annotations already establish that this is a read-only, idempotent, non-destructive, non-open-world operation. The description adds useful context by listing the categories of returned data, but it does not discuss permissions, rate limits, or other behavioral traits beyond what the annotations cover.

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

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

The description is a single, front-loaded sentence that efficiently lists the resource contents with no filler. Every phrase 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 input parameters, rich annotations, and no output schema, the description sufficiently explains what data is returned. It could be slightly more complete by mentioning the response structure or how the data should be used, but it covers the essential scope.

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?

This tool takes no parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it correctly focuses on the returned resource content instead.

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

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

The description clearly identifies the resource—the workspace's ideal customer rules and delivery settings—and enumerates its components (roles, industries, company size, locations, exclusions, High-intent and automatic delivery settings). It lacks an explicit verb like 'get' or 'list', but the resource is specific enough for an agent to understand what the tool retrieves.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when-not-to-use cases, or any related sibling tools, leaving usage entirely to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds useful value by enumerating returned content (signals with source and date, fit reasons, research status, personalised lines), but it says nothing about whether some leads are locked or require an unlock step, despite the sibling unlock_intent_leads implying that constraint.

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

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

A single front-loaded sentence with no padding, and the key scoping word 'One' appears immediately. It is a fragment rather than a full sentence, which slightly weakens readability but not efficiency.

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 and low parameter coverage, the description carries the full burden, and it does list the main returned fields, which is helpful. It omits return format specifics, error behavior for an invalid or locked lead_id, and any relationship to unlock_intent_leads.

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

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

Schema description coverage is 0%, so the description must carry the burden for lead_id, and it does not mention the parameter at all. Given there is exactly one required, self-evidently named identifier, the practical risk is low, but no added semantics (format, source of the ID, unlock state) are provided.

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 phrase 'One Intent person or company' states a specific resource and singular scope, which distinguishes it from the sibling list_intent_leads. However, it never names the verb or explicitly contrasts itself with sibling tools like get_intent_results or list_intent_leads, leaving differentiation to the agent's inference.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no pointer to alternatives such as list_intent_leads for enumeration. The agent must infer usage purely from the name and the word 'One'.

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, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description contributes the useful fact that results span the funnel (signals through customers) plus credits per reply, but says nothing about how the time window affects the result or whether data is a snapshot vs live.

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 compact sentence with no filler, and the most important framing ('what Intent found and produced') is front-loaded. The metric list is long and slightly run-on, but each item is informative rather than 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?

With no output schema, the description does the useful work of enumerating the returned metrics, which is a real contribution. However it omits any usage context, the time-window semantics, and differentiation from the closely related intent/overview siblings, leaving gaps for a reporting tool in a crowded namespace.

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 'days' is fully documented in the schema as '7 to 365, default 30'. The description never references the time window at all, so it adds no semantics beyond the schema; baseline 3 applies for a well-documented single 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 is a noun-phrase inventory of returned metrics rather than a verb+resource statement, so the agent must infer that this is a reporting/aggregate-results tool. It never distinguishes itself from the sibling get_intent_summary or get_overview, which likely return overlapping aggregate data. The enumeration hints at purpose but does not state 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?

There is no when-to-use guidance, no mention of when this is preferable to get_intent_summary or get_overview, and no stated preconditions. The agent gets no signal about which of the several 'intent' reporting siblings to select.

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, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description's contribution is the enumeration of what the summary contains, which is useful but not behavior beyond the schema/annotation layer — no freshness, scoping, or empty-state behavior is disclosed.

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

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

A single front-loaded sentence that opens with the resource label and then lists the metrics in a compact comma series. It is dense but every clause maps to a distinct returned field, 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?

With no parameters and no output schema, the description carries the burden of telling the agent what comes back, and it does so by enumerating the metric groups. The only real gap is usage context — when to reach for this summary versus the sibling intent 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 is nothing to disambiguate; the baseline for a no-param tool applies. The description does not need to explain arguments, and it wastes no words on non-existent inputs.

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 concrete resource (Intent overview) and enumerates the exact metrics returned — tracking status, included people used/left, today's deliveries, High-intent/Warm counts, and review queue size. It is clear what the tool produces, though it never differentiates itself from siblings like get_overview or get_intent_results.

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

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

There is no when-to-use guidance and no mention of alternatives, despite several overlapping siblings (get_overview, get_intent_results, list_intent_leads). The agent must infer from the name alone when this dashboard summary is preferable to the more detailed intent tools.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the bar is lower. The description adds value by enumerating exactly which metrics the snapshot returns and scoping them to 'this Prosyo workspace', which is meaningful behavioral content 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?

A single front-loaded sentence listing the payload contents with no filler or redundant restatement of the name.

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

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

With no output schema, the description is the only source for what comes back, and it lists the key fields (campaigns, replies, inbox, credits, health). It is sufficient for an agent to decide to call it, though it doesn't describe field formats or freshness of the snapshot.

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, which is the baseline-4 case. The description correctly implies a parameterless, workspace-scoped call with nothing to configure.

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 (a dashboard snapshot) and enumerates the contents: running campaigns, replies, unread inbox, credits, and account health. This clearly distinguishes it from siblings like get_campaign, list_campaigns, or list_inbox, which return individual entities rather than an aggregate.

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

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

The word 'snapshot' and 'Dashboard' imply the use case (quick orientation / aggregate status check), but the description never states when to prefer this over get_entitlements, list_inbox, or list_campaigns, nor any exclusions. Usage is implied rather than explicit.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value by disclosing that only the LATEST research is returned and by enumerating the returned artefacts (facts with sources, icebreaker, connection note, LinkedIn message, email subject/body) in the absence of an output schema.

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

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

A single sentence with no padding; the most important element (what is returned) is front-loaded. It is slightly weakened by being a fragment without a verb, but nothing 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?

With no output schema, the description does the right thing by enumerating return contents, and the annotations cover safety. It stops short of clarifying the key ambiguity for this tool family: whether calling it returns cached research or triggers a new research run, which matters given the research_prospects sibling.

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 prospect_id, so the description must compensate. 'A prospect's...' implicitly establishes that prospect_id selects which prospect, but gives no format, source, or example of the identifier, leaving the schema and description jointly thin.

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 the resource ('a prospect's latest research and personalised lines') and enumerates its contents, so an agent can infer this is a read of stored research. However, it is a noun fragment with no verb, and it gives no differentiation from the sibling research_prospects, which likely triggers generation rather than retrieval. Purpose is identifiable but not sharply 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as research_prospects or search_prospects. The agent must infer that this is the read path and research_prospects the write path entirely from the tool names.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful scope hint that only 'recent messages' are returned rather than the full history, but says nothing about how many messages or pagination 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?

It is a single short fragment with no waste, but it is so terse that it reads as under-specification rather than disciplined conciseness. Nothing is front-loaded beyond a noun phrase.

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 tool with no output schema, the description does not say what a thread contains, how many messages 'recent' means, or where thread_id comes from. The annotations cover safety, but the agent still lacks enough to invoke this reliably.

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 thread_id parameter has 0% schema description coverage and the description never mentions it or explains how to obtain it (presumably from list_inbox). With one undocumented required parameter, the description fails to compensate for the schema gap.

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

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

The phrase 'One inbox conversation with recent messages' identifies the resource (a single conversation) and hints at the truncated payload, but there is no verb and no differentiation from the sibling list_inbox. An agent can infer it retrieves one thread, but the description borders on restating the tool name.

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

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

There is no when-to-use guidance at all, and no mention of list_inbox as the alternative for browsing multiple threads. The agent must infer that this is the single-item counterpart to the list tool.

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

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

Annotations declare non-destructive, non-open-world, non-idempotent, but they do not convey that this step has no sending side effect. The description supplies exactly that key trait — nothing is sent until confirm_action — which is meaningful behavioral context beyond the structured fields. It omits auth requirements and response shape, but the confirmation gate is the important disclosure.

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 followed by the critical sequencing constraint. Every clause earns its place.

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

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

For a single-parameter tool with no output schema and useful annotations, the description covers the essential two-step flow and the no-send guarantee. It leaves the campaign_id's expected form/lifecycle and any failure modes unaddressed, which is a minor gap rather than a blocking one.

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, campaign_id, with 0% schema description coverage, so the description carries the burden and says nothing about it. The implicit constraint that it must reference a draft campaign is inferable but not stated, so the description adds little meaning over the bare schema.

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

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

States a specific action (prepare a draft campaign for launch) on a specific resource, and implicitly distinguishes itself from confirm_action, which it names as the completing step. The verb 'prepare' is slightly soft, but the lifecycle stage is unambiguous.

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

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

Gives clear context: call this while the campaign is a draft, and sending only happens after confirm_action once the user agrees in chat. It routes the agent to the sibling that completes the flow, though it never states an explicit exclusion (e.g. do not use on already-sent campaigns).

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered externally. The description adds only the workspace-scoping boundary; it says nothing about ordering, pagination, or how many campaigns are returned. With annotations doing the heavy lifting, a 3 is appropriate.

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 purpose and no filler. The enumeration of status values is mildly redundant with the schema enum, which keeps it from being perfect, but nothing 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?

There is no output schema, so the description could reasonably say what a returned campaign looks like, whether results are paginated, or how they are ordered. For a simple zero-required-parameter list tool whose annotations cover safety, this is adequate but leaves notable gaps.

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

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

Schema description coverage is 50%: 'search' is documented in the schema ('Match campaign name') while 'status' is not. The description compensates by enumerating the status values, but those values are already present in the schema enum, so it adds little real meaning and says nothing about how search matching works (prefix vs substring).

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 campaigns') and a scope ('in this workspace'), so an agent can distinguish it from get_campaign (single item) and from the other list_* siblings by resource noun. It reads clearly but does not explicitly contrast itself with the closest alternatives.

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

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

Usage is only implied: an agent can infer you call this to browse campaigns, and the status filter hints at narrowing a result set. There is no explicit when-to-use vs get_campaign, no statement of prerequisites, and no guidance on when this is preferable to other list tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds that results span LinkedIn and email and are 'recent', but never defines the recency window, ordering, or result 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?

Two short sentences with the resource stated first and the optional refinements second; nothing is wasted, though the phrasing is terse to the point of underspecification.

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

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

For a 3-parameter read-only list tool with no output schema, an agent still lacks the meaning of 'recent', the ordering of results, and what the non-obvious filter enum values do. Adequate as a minimum but with clear gaps.

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

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

Schema coverage is 0%, so the description carries the burden and it only partially compensates: 'search' loosely maps to query, 'unread filter' to filter, and the channel list to channel. The enum values 'positive' and 'meeting' for filter are left completely unexplained, and no parameter formats are given.

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 gives a clear resource ('LinkedIn and email conversations') with an implied list verb and names the two channels covered. It doesn't differentiate itself from siblings like get_thread, which also deal with inbox conversations, but the resource is specific enough for selection.

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?

'Optional search and unread filter' hints at what can be narrowed but never states when to call this instead of get_thread or search_prospects, nor any prerequisite such as connection/auth state. No when-not guidance at all.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context about gating: 'Locked people show only their signals until unlocked.' This is useful and not in annotations, but it doesn't explain pagination, rate limits, or output format. A 3 is appropriate.

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 concise sentences that front-load the core purpose and ordering, then add the gating behavior. No wasted words.

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

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

For a read-only list tool with no output schema, the description covers the return concept and gating, but omits pagination behavior, default sorting beyond 'strongest first', and how filters interact. With 7 parameters and partial schema coverage, more context could be provided. Adequate but with gaps.

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

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

Schema description coverage is 43%, so half the parameters lack documentation. The description doesn't clarify parameters like 'page', 'query', or 'source', so it fails to compensate for the coverage gap. However, some parameters (tier, min_fit, new_today) have schema descriptions. Baseline 3 given mixed coverage and no additional parameter detail in 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?

States a specific resource ('People (or companies) showing buying signals') and notes ordering ('strongest first'). It's clear what the tool returns. However, it doesn't differentiate from siblings like get_intent_lead or get_intent_results, so it falls short of a 5.

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

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

No explicit when-to-use guidance. The description doesn't mention alternatives like get_intent_lead (single lead) or search_prospects, nor does it say when not to use this tool. 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description's only added behavioral value is that results include people counts, which is useful but thin.

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 very short and front-loaded, with no wasted words. But it is a sentence fragment rather than a complete statement, so brevity comes at the cost of clarity rather than being disciplined conciseness.

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-parameter, read-only list tool with no output schema, the description is roughly adequate. It still omits what fields each list entry contains beyond counts and any ordering or pagination behavior, leaving minor gaps.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. No parameter details are needed or missing.

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?

Names the resource (prospect lists) and a return attribute (people counts), so the agent can tell it apart from list_campaigns/list_inbox. However, it is a noun-phrase fragment with no verb, so the action (list/retrieve) is only implied 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?

There is no statement of when to call this versus the many other list_* siblings, nor any prerequisite or context. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, covering the safety profile. The description adds value by detailing returned data (signals watched, Review first or Autopilot, matches, people added, credits used), but it does not describe format, pagination, or other behavioral traits beyond what annotations 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?

The description is a single sentence but is structured as a fragment without a leading action verb. It front-loads the resource names but then lists many return fields in a run-on manner, which slightly hinders quick comprehension.

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 return values and does list several data points. However, it omits critical context such as whether the result is a list, pagination behavior, or the overall shape of the response, leaving gaps for an agent to call the tool 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?

The tool has zero parameters, so the baseline score of 4 applies. The description does not need to compensate for parameter semantics, and the schema is fully empty with no parameter documentation required.

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 the resources (playbooks and Intent-led campaign audiences) but lacks a clear action verb such as 'list' or 'retrieve'. It does not explicitly distinguish this tool from siblings like list_campaigns or list_intent_leads, leaving the agent to infer the core purpose from the name alone.

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

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

There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description simply enumerates return content without indicating the appropriate context for invocation.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds meaningful content context (two distinct states a person can be in) but says nothing about ordering, pagination, or queue size for a list endpoint.

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 compact sentence with no filler, front-loading the resource identity before the qualifying states. Nothing redundant.

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

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

For a no-param, read-only list tool with no output schema, the description could still sketch what each queue entry returns or how the two states are distinguished. It covers the concept adequately but leaves the shape of the result unspecified.

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 is no parameter semantics to explain and the schema is trivially complete. Baseline 4 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?

The description names a specific resource (a review queue of matched people) and defines its contents precisely: matched prospects awaiting approval or with a ready researched message. That scope distinguishes it from act-on-it siblings like approve_review, though the listing verb itself is only implied by the name.

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 describes what the queue holds but never states when to call this tool versus alternatives such as list_inbox or list_intent_leads, nor that approve_review is the natural follow-up. Usage is only loosely inferable from the word 'waiting for approval'.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral value by saying the pause is immediate and stops queueing new sends (implying in-flight sends may still go out), but it omits reversibility and permission requirements.

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

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

One front-loaded sentence with the action verb first and the consequence second; no filler, no restatement of the title, nothing that could be cut.

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

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

For a single-parameter mutation tool with full annotation coverage and no output schema, the description supplies the essential purpose and effect. What is missing (in-flight send behavior, reversibility, the campaign_id requirement) is minor but non-zero.

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 single required parameter campaign_id is never mentioned in the description. The name is fairly self-descriptive, but with zero schema documentation the description does nothing to compensate for the 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 ('Pause a running campaign') and adds the operational effect ('stops queueing new sends'). It is clearly distinguishable from siblings like resume_campaign or get_campaign by the verb alone, though it never names an alternative 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?

The clause 'so it stops queueing new sends' implies the situation in which to call it, but there is no explicit when/when-not guidance and no routing to the obvious counterpart (resume_campaign) or any prerequisite. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that a real prospect is merged, meaning the preview reflects actual prospect data rather than a template, and that nothing is sent pre-launch. It does not clarify whether the merge has any persisted side effect, which is the one point where 'merge' phrasing could mislead.

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 sentence with no filler, front-loaded on the action and ending on the payoff. Nothing is padded and nothing needs trimming.

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

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

For a two-parameter tool with no output schema, the description does minimally convey what the agent gets back (readable messages). It stops short of describing the shape of the preview (per-prospect message list, sequence steps) or the fallback behavior for the optional prospect, leaving a modest gap given the absence of an output schema.

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

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

Schema coverage is 50%: prospect_id carries its own fallback description ('otherwise uses an enrolled or recent prospect'), while campaign_id is undocumented everywhere. The description contributes no parameter-level information, so it neither compensates for the gap nor adds 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 concrete action (merge a real prospect into the campaign sequence) plus the user-facing outcome (read the messages before launch), which lets an agent separate it from launch_campaign or get_campaign. The verb 'merge' is domain jargon and slightly ambiguous about what is actually produced, but the intent is clear.

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 'before launch' implies the usage context (pre-send review of a campaign), so an agent can infer when it applies. However, no alternative tool is named and there is no explicit statement of when not to use it (e.g., versus get_campaign or approve_review).

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

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

Annotations only declare the safety profile (non-read-only, non-idempotent, non-destructive, closed-world); the description goes beyond them with the credit-per-person billing model, the free-reuse caching behavior, and the confirm_action gating requirement. These are exactly the operational traits an agent needs before spending credits.

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

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

Three tight sentences: what it produces, what it costs, when it may run. Every clause carries information and the most important gating constraint is not buried.

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 and one input, the description covers the deliverables, the cost model, and the prerequisite well. It leaves minor gaps around what happens on partial failure or whether previously generated research is overwritten.

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 single required parameter prospect_ids is never mentioned in the description. 'Per person' hints that cost scales with the number of prospects, but nothing explains the ID format, whether IDs come from search_prospects, or the batch behavior.

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

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

States a specific verb (prepare research) plus the exact artifacts produced: sourced facts, icebreaker, connection note, LinkedIn message and email. This clearly separates it from retrieval siblings like get_prospect_research and enrichment siblings like enrich_prospects.

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 hard prerequisite ('Runs only after confirm_action') and cost context ('Costs credits per person; fresh research is reused free'), which tells the agent when it is safe and cheap to call. It does not explicitly contrast with get_prospect_research or enrich_prospects, so an alternative-selection sentence is missing.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the safety profile is known, and the description adds genuinely non-obvious behavior: the mutation is deferred until confirm_action, and nothing restarts on its own. This two-phase semantics is exactly the kind of context annotations cannot convey. It does not describe failure modes or idempotency implications, keeping it below 5.

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

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

Two sentences, zero filler, and the most important constraint (sending does not restart until confirm_action) is stated immediately after the purpose. Nothing is repeated from 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?

For a single-parameter mutation tool with no output schema, the description covers the critical workflow nuance an agent needs to avoid prematurely triggering a send. It omits error/precondition handling (e.g., what happens if the campaign is not paused) and the source of campaign_id, so it is strong 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?

Schema description coverage is 0%, so the description carries the burden for campaign_id, but it says nothing about the parameter — not its format, nor where to obtain it (e.g., list_campaigns). The name is largely self-explanatory, which keeps this at a minimum-viable 3 rather than lower.

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

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

The description states a specific action (prepare resuming) on a specific resource (a paused campaign), so an agent can distinguish it from pause_campaign, launch_campaign, and preview_campaign. It stops short of naming those siblings explicitly, which would have pushed it to a 5.

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

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

It gives a clear usage condition: this is a preparatory step, and the actual send only restarts after confirm_action and after the user agrees in chat. It does not state the inverse case (what to do if the campaign is not paused) or name the alternative tools, but the workflow context 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?

Annotations already declare this is a non-read-only, non-destructive, idempotent, closed-world write. The description adds genuinely non-structured facts: the operation is free, locked people are silently skipped, and personalised lines are carried along with the saved leads. It does not explain what happens on a name collision with an existing list.

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

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

Three tight sentences with the action and both targeting options front-loaded. 'Their personalised lines go with them' is slightly conversational but conveys a real side effect, 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 3-param write tool with no output schema and 0% schema coverage, the description covers the core behaviors an agent needs (unlocked-only, free, carries personalised lines, two list-targeting modes). Missing only edge-case behavior such as duplicate/idempotent handling and name-conflict resolution.

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

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

Schema description coverage is 0%, so the description carries the burden and does explain the two list parameters (list_id = existing list, list_name = new list). lead_ids is left to the schema, and required/optional status is not stated, but the meaning of the ambiguous params is supplied.

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: saves unlocked Intent people to a prospect list, with the two targeting modes (existing list_id vs new list_name) named inline. It is distinguishable from write-adjacent siblings like unlock_intent_leads or list_intent_leads, though it never names an alternative tool directly.

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 (only unlocked people are saved; locked ones are skipped) and implicitly routes the caller between supplying list_id for an existing list or list_name for a new one. No explicit when-not-to-use or named alternative is offered, which keeps it short of a 5.

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

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

Annotations already disclose readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so 'search' adds nothing new on safety. The description does not mention pagination, result caps, whether an empty query returns everything, or what happens when stage/list_id conflict with query, so the behavioral picture stays thin.

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

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

A single front-loaded sentence with no filler and the scope qualifier placed early. It is well-structured but arguably under-sized for a tool with three undocumented filters.

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 0% schema coverage, no output schema, and three filters, the description needed to define stage and list_id and describe result behavior. It covers only the query field, leaving the agent unable to confidently use two of three parameters.

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 three parameters exist. The description partially explains query (name, company, email) but says nothing about stage or list_id, so two of three filters remain semantically opaque; it does not compensate for the coverage gap.

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

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

States a specific verb (search) and resource (people/prospects) plus the workspace scope and the searchable fields (name, company, email). No sibling is a competing "search" tool, so the differentiation is implied rather than stated, which keeps it out of 5 territory.

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

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

No when-to-use, when-not-to-use, or alternative routing is given. The agent gets no hint about when to prefer this over research_prospects, enrich_prospects, or get_prospect_research, all of which operate on the same prospect population.

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

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

Annotations only declare the generic profile (not read-only, not destructive, not idempotent, not open-world). The description adds genuinely non-obvious behavior: the message is staged and not actually sent until confirm_action runs after the user agrees in chat. That two-phase commit detail is exactly the kind of context annotations cannot convey. It stops short of describing the response payload or error cases.

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

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

Two short sentences, no filler, and the most decision-relevant fact (deferred send via confirm_action) is placed up front after the action statement.

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

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

For a two-parameter mutation tool with no output schema, the description covers the critical behavior an agent must know: nothing is sent until confirmation. Remaining gaps (what the tool returns, whether it overwrites an existing draft) are minor given the tool's simplicity.

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

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

Schema description coverage is 50%: body is documented ('Exact reply text to send') while thread_id has no description in the schema or in the description text. The phrase 'reply from Inbox' weakly implies thread_id identifies an inbox conversation, but no format or source guidance is given, so the description does not compensate for the coverage gap.

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

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

States a specific verb (prepare sending) and resource (LinkedIn or email reply from Inbox), and clarifies the operation is a staging step rather than a send. It does not, however, distinguish itself from the sibling draft_reply, which an agent could easily confuse with this 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?

The description implies the usage context by tying the tool to a follow-up confirm_action call after user agreement, which is useful sequencing guidance. It never states when to prefer this over draft_reply, nor any preconditions such as needing an existing thread.

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=false, destructiveHint=false, idempotentHint=false), so the bar is lower. The description still adds substantive behavior beyond them: a billing/cost model ('plan's included people first, then credits per person') and an explicit two-phase gate ('nothing is unlocked until confirm_action'). It notably does not restate idempotency, which the annotation already 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?

Three short sentences that are front-loaded with the core action and use the rest for cost model and the confirm gate. Each sentence carries information and none is filler, though the phrasing 'Prepare unlocking locked Intent people' is slightly clunky.

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 and a single-param mutation surface, the description conveys the essential operating model: it is a staging step, it costs credits, and it requires chat-side user agreement plus confirm_action. The remaining gap is that it does not tell the agent where to obtain lead_ids.

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 a single required parameter (lead_ids) with 0% schema description coverage, so the description carries the full burden of explaining it. It says nothing about the format, source, or constraints of the IDs (array of strings, max length, etc.), leaving the only input 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+resource: prepare the unlocking of locked Intent people. It also distinguishes itself from the actual commit step by naming confirm_action, so an agent can tell it apart from the unlock-enacting call. The only weakness is that 'Prepare unlocking' is slightly indirect about what it returns.

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

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

It gives a clear routing condition to confirm_action ('after the user agrees in chat'), which is genuinely useful. However, it never says where lead_ids come from (e.g., list_intent_leads / get_intent_lead) or when to prefer this over sibling tools like save_intent_leads_to_list, leaving prerequisites implied.

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