SuperSend

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds crucial context they do not carry: this contacts real people, and it requires a sequence with an email step plus at least one assigned sender profile. It stops short of stating reversibility (deactivate_campaign) or what a failed activation returns, so not a 5.

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

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

Three tight sentences: effect first, safety workflow second, preconditions third. No filler and the most decision-relevant information is front-loaded.

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 activation tool with no output schema, the description covers effect, human-in-the-loop safeguards, and prerequisites well. It omits only post-activation behavior such as reversibility or failure modes, a minor gap.

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

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

Only one parameter and schema coverage is 100%, with the schema itself pointing to list_campaigns as the source. The description adds no format or lookup detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (activate) plus resource (campaign) and the concrete consequence: it starts emailing enrolled contacts on schedule. This distinguishes it from deactivate_campaign and complete_campaign without needing 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 an explicit gated workflow: show get_campaign_review first, use send_campaign_test, and launch only after user confirmation. It names the sibling tools to use beforehand, so the agent knows both when to call this and when not to yet.

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

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

Annotations only cover safety/idempotency flags; the description adds genuinely new behavior — the job runs in the background, returns upload_id and contact_count, and validate_emails consumes credits with a default of off. It omits what happens on duplicate or invalid rows, which is the main remaining gap for a non-idempotent bulk write.

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

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

Three dense sentences, front-loaded with the operation and its 50,000 cap; the credit cost of validate_emails and the return values are packed in without filler. Nothing reads as padding.

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

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

With no output schema, the description usefully declares the return shape (upload_id, contact_count) and the async nature, so an agent knows not to expect synchronous results. It lacks error/duplicate handling guidance and a way to poll status, which keeps it just under complete.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds a real constraint not encoded in the schema: 'Each contact needs email or linkedin_url' (item-level required is absent) and that unknown keys go in custom. That is meaningful semantics beyond the field descriptions.

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

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

States a specific verb+resource+scope: 'Queue up to 50,000 contacts for import into a campaign.' No sibling tool in the set performs contact import, and the description makes the operation and its bounds unmistakable 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 clear context for invocation: contacts belong to a campaign, each row needs email or linkedin_url, and validate_emails is an opt-in that costs credits. It does not name a 'when not to use' case or an alternative path (e.g., single-contact creation), so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnly=false, idempotent=true, destructive=false), so the bar is lower; the description still adds meaningful context by naming the two validation checks that gate success and clarifying that this does not activate. It does not say what happens if validation fails (error shape) or what the response contains, which keeps it short of a 5.

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

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

Three tight sentences with zero waste; the state change is front-loaded, validations second, and the sibling-exclusion last. 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 one-parameter mutation with no output schema, the description covers the state change, the validation gates, and the non-activation caveat. The only gap is failure/response behavior, which is 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 coverage is 100% and the single campaign_id parameter is already documented in the schema with a pointer to list_campaigns. The description adds no format, source, or constraint detail beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb and resource ('Mark a campaign setup complete') plus the resulting state change (is_draft: false), and explicitly distinguishes itself from the sibling activate_campaign. An agent can tell exactly what state transition this performs.

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 the boundary condition: 'Does not activate the campaign; use activate_campaign separately.' It also implies the precondition context (campaign has email step and sender profile) that must hold before use, giving both when-to-use and the named alternative.

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=false and destructiveHint=false, so the safety profile is covered. The description goes further by explaining the entity model and the two-step activation path, but it never mentions return values (does it hand back the new sender_profile_id?) or duplicate-name 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?

Two sentences, both earning their place: the first defines the resource and scope, the second gives the follow-up call sequence. Purpose is front-loaded and there is no filler.

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

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

For a two-parameter creation tool with no output schema, the description covers purpose, entity semantics, and the follow-up workflow. The only real gap is what the call returns and whether the new profile id is directly reusable, which the agent must infer from the mention of sender_profile_id.

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% with only two parameters, both already documented ('Profile name, e.g. "Q4 outbound"' and 'Team UUID - get from list_teams'). The description adds no format, constraint, or default information beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (create) and resource (sender profile), then defines what the resource is: 'a named group of inboxes (and optionally a LinkedIn account) that campaigns send from.' That definition makes it immediately distinguishable from siblings like update_sender or list_sender_profiles.

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

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

Gives explicit post-creation workflow steps and names the tools to use next ('put inboxes in it with update_sender (sender_profile_id), then attach it to a campaign with assign_campaign_sender_profile'). This is strong sequencing guidance, though it offers no when-not-to-use condition or prerequisite checks (e.g., whether a team must already 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?

Annotations already declare destructiveHint=true and idempotentHint=true; the description adds valuable context beyond them by clarifying the operation is a reversible pause ('Contacts keep their place in the sequence') and that a resume path exists. It does not say whether an already-paused campaign errors or no-ops despite the idempotent hint, leaving one behavioral gap.

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

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

Two short sentences, no filler, with the core action and effect front-loaded and the recovery path trailing. Every clause carries information.

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

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

For a one-parameter mutation with no output schema, the description covers the action, the side effect on contacts, and the reversal route, which is enough for correct invocation. Only the edge case of deactivating an already-paused campaign is left unaddressed.

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

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

There is a single parameter with 100% schema description coverage ('Campaign UUID - get from list_campaigns'), so the schema already carries the semantics. The description adds no parameter detail, which is the baseline 3 expectation when the schema does the heavy lifting.

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

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

Specific verb+resource ('Deactivate (pause) a campaign') with the effect stated ('stops sending'), and it explicitly distinguishes itself from the sibling activate_campaign. An agent can immediately tell this apart from complete_campaign or update_* siblings.

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

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

It gives a clear condition for use (to stop sending) and names the counterpart tool for the reverse action ('resume with activate_campaign'), which effectively routes the agent. It does not state when NOT to use it (e.g., vs complete_campaign, which is terminal), so it falls short of a full 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes well beyond by explaining that can_launch predicts whether activate_campaign will work, that non-ok checks say what to fix, that blocking ones stop the launch, and the Claude web/desktop review-card behavior. This is rich behavioral context an agent cannot get from the annotations.

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

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

The paragraph is information-dense and front-loads the review's contents before the usage ordering and UI note. Every clause carries meaning, though the run-on inventory of contents is slightly heavy and could be tightened.

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

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

With no output schema, the description carries the burden of explaining returns and does so thoroughly (can_launch, checks, blocking semantics). It also covers the draft-workflow prerequisite and platform-specific behavior, so nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the single id parameter is fully documented in the schema ('Campaign UUID - get from list_campaigns'). The description adds no additional parameter semantics, so the baseline 3 for full schema coverage is appropriate.

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

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

States a specific verb+resource ('review a campaign before it sends') and then enumerates exactly what the review covers: ordered steps, senders, waiting contacts, schedule/volume, and launch checks. This clearly distinguishes it from sibling read tools like get_campaign_stats and preview_campaign.

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

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

Explicitly says when to call it ('before activate_campaign and again after fixing anything') and gives a conditional prerequisite: 'If campaign.is_draft is true, call complete_campaign before activate_campaign.' It names the alternative tools and the ordering conditions, leaving nothing to inference.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantive behavioral rules: email totals are omitted when the campaign has no email steps, and the leading A/B variant is only reported once each variant has 50+ sends. These are non-obvious output behaviors not captured by 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?

It is a single dense but well-structured sentence with the subject ('A campaign's results') front-loaded, followed by progressively finer detail. Every clause carries information, though the length is at the upper edge of comfortable scanning.

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 carries the full burden of explaining return values, and it does so thoroughly across email, LinkedIn, lead-outcome, per-step and per-variant dimensions, including the conditional omission rules. Nothing needed to interpret the response is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains that the optional start/end dates limit opens, clicks and replies only, and gives the YYYY-MM-DD format. That scoping semantic is not derivable from the bare 'Start date' schema text.

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

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

States a specific verb (get) and resource (campaign stats) and then enumerates exactly which results are returned, down to per-step and per-variant breakdowns. It is clearly distinguishable from siblings like list_campaigns, get_campaign_review, and get_setup_status.

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

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

The phrase 'with the same numbers as the dashboard' gives situational context, and the id is traceable to list_campaigns via the schema, but the description offers no explicit when-to-use or when-not-to-use guidance versus get_campaign_review or get_setup_status. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds the useful payload context of what the tool surfaces (participants, read/archive state, labels, contact/campaign, AI category and sentiment), which goes 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?

One compact sentence that front-loads the verb and scope, then lists the payload. No filler, no repetition of the title, no wasted clauses.

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

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

For a simple one-parameter read tool with full schema coverage and rich annotations, the minimal definition is adequate. However, with no output schema, it would help to state what happens when the ID is not found and to distinguish itself from list_conversations more explicitly.

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 'id' parameter is documented as a conversation UUID, so the schema does the heavy lifting. The description adds nothing about the parameter beyond reinforcing that it is an ID lookup; baseline 3 applies.

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

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

Specific verb 'get' plus resource 'one inbox conversation by ID', and it enumerates the returned fields. It does not explicitly differentiate itself from the sibling list_conversations or update_conversation, but the singular 'by ID' framing makes the read-by-identifier scope 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 description states what the tool does but gives no when-to-use guidance and does not reference the obvious alternative list_conversations for browsing or update_conversation for mutation. The agent must infer the selection conditions from the name alone.

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, so the safety profile is covered. The description adds real behavioral value beyond that: 'Nothing is charged by this tool', pricing estimates, that SuperSend starts warmup itself, and that inboxes appear within 24-48 hours. Minor gap: no explicit statement about permissions/team scope beyond the team_id default.

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

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

Front-loaded with purpose and the key 'nothing is charged' reassurance, and nearly every sentence carries actionable detail. It is dense and parenthetical-heavy, with pricing and edge cases packed into long run-on sentences, which slightly hurts scannability.

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

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

No output schema exists, and the description covers the return value (the link plus estimated cost) as well as downstream timing and follow-up steps. For a planning/checkout tool of this complexity, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents domain, provider, team_id, and mailbox fields; the baseline is 3. The description nevertheless adds operational meaning the schema lacks — 2-3 inboxes per domain and at most 5 (azure: list no inboxes), azure = 50 inboxes for $49/month, and brand-style domain naming — which materially shapes correct invocation.

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

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

States a specific verb and resource: plan sending domains/inboxes and produce a checkout link for the user to review and pay. It explicitly frames the tool as non-charging and distinguishes itself from related siblings (connect_domain, verify_domain, get_setup_status). An agent can tell what this does and how it differs from setup/status tools without opening a schema.

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

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

Gives explicit when-to-use context and edge cases: new vs. already-owned domains, domains bought through SuperSend vs. connected elsewhere, the registrar nameserver follow-up, and the instruction to verify later with verify_domain / get_setup_status. It also prescribes domain naming and inbox-count heuristics, leaving little to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: next_steps is ordered and attributed (agent vs. user), browser links must be relayed verbatim, and the tool is meant to be re-called iteratively after each step.

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

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

Front-loaded with the primary instruction ('Start here...'), then progressively adds what is checked, the next_steps semantics, and the link/re-call rules. Dense but each sentence carries operational weight; minor density without waste.

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

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

With no output schema, the description must explain return values, and it does describe next_steps contents, ordering, ownership, and links. It does not describe the per-item 'set up vs. missing' result shape in detail, but for a read-only status tool the coverage is strong.

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 team_id parameter is fully documented in the schema, including its default and where to obtain it. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Shows what is set up and what is still missing before campaigns can send') and enumerates exactly what it inspects: billing, inboxes/warmup, sender profiles, LinkedIn accounts, campaigns. It is clearly distinct from sibling action tools like setup_outbound_campaign or list_campaigns.

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

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

Explicitly says when to use it ('Start here with a new or unfamiliar account') and prescribes the follow-up loop ('Call again after each step to see what is left'), plus how to handle returned links. It stops short of naming when-not-to-use or a sibling alternative, so it is clear context rather than full routing guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real context beyond that: the default field set, that sequence and schedule settings are omitted, and the pagination defaults (50 default, 100 max).

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

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

Dense but front-loaded: the resource and scope lead, then the return-shape caveat, then filtering and pagination. Every sentence carries information, though the packed parentheticals require a careful read.

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

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

With no output schema, the description carries the return-shape burden and does so by naming the compact field set and what is omitted. Pagination and filtering are covered; only minor detail (ordering, whether contact metrics are per-send) is absent.

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

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

Schema coverage is 100%, so the baseline is 3 and the schema already documents every parameter including the compact field list and pagination limits. The description's status parenthetical ('1 = active, 2 = inactive') refers to the returned field value rather than the string enum on the parameter, which adds slight ambiguity instead of clarifying.

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

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

States a specific verb (List) and resource (campaigns) scoped to a team, and explicitly distinguishes itself from get_campaign for the full field set. An agent can tell it apart from list_conversations and the mutation siblings without opening a schema.

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

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

Gives filtering guidance (status "active"/"inactive") and names get_campaign / the fields param as the escape hatch when the compact set is insufficient. It does not state explicit when-not-to-use conditions beyond that, but the routing to the sibling is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: preview is trimmed to 300 characters, pagination defaults to 25/max 100, and the has_more loop semantics. Return format and preview caveat are 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?

Front-loaded with what is listed, then triage context, then usage guidance and pagination. Dense and information-rich, though the enumeration of returned fields is long; nearly every clause earns its place.

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

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

With no output schema, the description carries the return-shape burden, and it does so by enumerating fields and the 300-char preview limit plus pagination contract. Filtering by folder/channel is left to the (fully documented) schema, so nothing critical is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: the concrete meaning of "inbound" as replies awaiting response, the offset = offset + limit pagination formula, and the preview trimming rule. This is more than restating fields.

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

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

States a specific verb+resource (list inbox conversations) and enumerates the returned content fields: counterpart, last activity, read/archive state, preview, labels, ai_category and sentiment. An agent can distinguish it from the single-thread sibling get_conversation without opening the schema.

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

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

Gives explicit routing guidance: use last_message_direction "inbound" to find replies awaiting a response, and notes the preview caveat that it may be our own later message, directing the agent to get_conversation_messages to read the thread. It also spells out when to re-call (while pagination.has_more) and with what offset.

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 destructiveHint=false, so the safety profile is fully covered by structured data. The description adds conceptual context (what a profile is, the warmup-tag concept) but says nothing about pagination behavior or result shape.

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, zero waste, purpose stated first followed by the entity definition and the workflow pointer. Well front-loaded.

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, but for a simple filtered list tool the description plus a fully documented schema covers what an agent needs to invoke it. The only small gap is that return shape/pagination semantics are left entirely to the schema.

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

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

Schema description coverage is 100% and all four parameters are documented there, including the 'get from list_teams' hint on team_id and defaults for limit. The description only alludes to 'profile IDs' in the workflow sentence, adding nothing beyond the schema, so the baseline 3 applies.

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

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

Specific verb+resource ('List sender profiles'), plus a clarifying gloss ('warmup tags') and a definition of what a profile contains ('groups one or more email senders'). This clearly separates it from the mutating sibling create_sender_profile.

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 the downstream workflow: 'Use before assign_campaign_sender_profile — pass profile IDs to attach senders to a campaign.' Clear context for when to call it, though it gives no exclusions or alternatives for the read case.

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 the description reinforces this with 'Nothing is created' — no contradiction. It adds genuine behavioral context beyond the annotations: the output is rendered as a card with a Create campaign button, and the agent must pause rather than proceed. It stops short of covering persistence or repeat-call behavior, but the annotated safety profile is well corroborated.

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

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

Front-loaded with the purpose and the no-side-effect guarantee, then the argument-sourcing rule, then the wait-and-confirm protocol. Dense and mostly waste-free, though the closing sentence about create.arguments is long and could be tightened.

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

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

No output schema exists, and the description compensates by describing the preview payload (emails, send days, schedule, inboxes, fixes) and the card UI. Combined with the annotated safety profile and a fully documented schema, an agent has everything needed to call this correctly and know what to do next.

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

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

Schema description coverage is 100%, so baseline is 3, but the description adds real value by mapping the parameter set onto a sibling tool ('the same team, name, emails, sender profiles and schedule you would pass to setup_outbound_campaign'), which tells the agent how to source values without re-deriving them. No per-parameter format detail is added beyond that.

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 (preview a campaign draft) and enumerates exactly what the preview shows: each email, send day, schedule, sending inboxes, and issues to fix. It is immediately distinguishable from setup_outbound_campaign, which it names as the actual creation step.

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

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

Gives explicit sequencing: call this after writing the copy with the user, with the same arguments you would pass to setup_outbound_campaign, then wait for the user to create from the card or tell you to. It also states the exclusion condition — only call setup_outbound_campaign with create.arguments if the user asks in the conversation.

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

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

With readOnlyHint=false and openWorldHint=true already declared, the description still adds substantial behavior: nothing is delivered to contacts, variables are filled from a real contact, reply steps inherit their thread's subject, and test subjects get a 'test' suffix. That is exactly the extra context annotations cannot convey.

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

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

Long but dense and front-loaded — the core action, the non-delivery guarantee, and the step/sender/variable conventions come in a deliberate order with no filler sentences. Some clauses (subject suffix) are minor detail, but none are pure padding.

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

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

No output schema exists, and the description adequately covers what happens (mail arrives in the user's inbox, subject suffixed 'test') plus the operational constraints. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: 'from one of the campaign's inboxes' clarifies the sender_id default, the {{variables}} filling explains contact_id in operational terms, and the step/step-omission convention ties to get_campaign_review.

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 precise verb+resource+scope: sends test emails of a campaign's email steps to the user's own inbox before launch. It distinguishes itself from preview_campaign and get_campaign_review (which it references for step numbering) and explicitly rules out sending to contacts.

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

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

States the when ('before launch'), the fallback behavior (omit step to send every email step), the narrow condition for using `to` ('only to send to another address the user names'), and names get_campaign_review as the source of step numbering. An agent can pick this over siblings without 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 flag destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description adds the concrete consequence: delivery is immediate by email or LinkedIn and "cannot be unsent." It also discloses that sender_id and subject fall back to the conversation's inbox/title, which is real behavioral context 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?

Three sentences, no filler, with the core action and its irreversible consequence front-loaded before the pre-call confirmation step and the default rules. Every sentence carries distinct information.

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

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

For an irreversible send tool with full schema coverage and annotations covering the safety profile, the description supplies the operational essentials (irreversibility, confirmation requirement, sender/subject defaults). Minor omissions remain, such as what a successful send returns or whether cc/bcc apply only to email, but nothing critical is missing.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema, including the defaults for sender_id and subject that the description repeats. The description adds the "Re: <conversation title>" convention but otherwise does not deepen parameter meaning, so baseline 3 applies.

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

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

States a specific verb and resource ("Send a reply in an existing inbox conversation") and constrains it to an existing conversation, which cleanly separates it from send_campaign_test and the campaign setup siblings. The delivery channels (email or LinkedIn) further pin down what the tool actually does.

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

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

Gives clear operational context: use it for an *existing* conversation, and confirm recipient and message text with the user before calling. It does not explicitly name an alternative (e.g., get_conversation or update_conversation) or state when not to use it, so it stops short of a 5.

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

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

Annotations already declare the safety profile (destructiveHint=true, idempotentHint=true, readOnlyHint=false), so the bar is lower. The parenthetical "archived conversations leave the main inbox" adds genuine semantic value beyond the annotations by explaining what archiving actually does.

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

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

Two compact sentences with the actions front-loaded and no filler. The "or ... or ..." construction with an inserted parenthetical is slightly clunky but still efficient.

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?

A three-parameter mutation with full schema coverage and safety annotations; the description covers all three operations plus usage timing, which is nearly everything an agent needs. No output schema exists, so return values need not be explained, though permission/prerequisite details are absent.

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

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

Schema description coverage is 100%, and the description largely restates the schema's own boolean semantics ("read or unread", "archive it ... or move it back", "after handling a reply"). With the schema already doing the heavy lifting, the baseline of 3 is appropriate.

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

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

States a specific verb (update) and resource (conversation) and enumerates the three state changes it can perform: read/unread, archive, and unarchive. It is distinguishable from get_conversation and send_conversation_message, though it never names a sibling to sharpen the boundary.

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 after handling a reply" gives a clear situational trigger for invoking the tool. It offers no explicit exclusions or named alternatives, so it falls short of a full when/when-not rubric.

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

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

Annotations already cover safety (destructiveHint=true, idempotentHint=true, openWorldHint=true), so the bar is lower. The description adds real behavior beyond that: it is a patch-style update ('pass only fields to change') and it resolves the forward_to/forward_rules precedence, which the annotations cannot convey.

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

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

Two sentences, front-loaded with the verb and update semantics, followed by the field list and precedence rule. Dense but every clause carries information; no redundant restatement of the title.

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

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

For an 11-parameter mutation tool with no output schema, the description covers the main ambiguities (partial update, forward precedence) and the schema covers the rest. It omits confirmation of return shape, but no output schema exists so that is acceptable.

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

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

Schema description coverage is 100%, so baseline is 3. The description goes beyond the schema by explaining the forward_rules-vs-forward_to interaction and the precedence rule ('non-empty forward_rules overrides per-rule'), which the schema descriptions do not state as a combined rule.

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 (Update) and resource (sender/inbox) with a clarifying parenthetical, so an agent can distinguish it from create_sender_profile and list_sender_profiles. It does not explicitly name a sibling alternative, but the purpose itself 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 partial-update guidance ('Pass only fields to change') and a rule for choosing between forward_to and forward_rules, which is genuine usage direction. However, there is no explicit when-to-use vs when-not or reference to an alternative tool for related operations.

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