MentionAgent

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

Adds real behavioral constraints not present in the schema or annotations: up to 25 keywords per call, 2–9 words each, and the 'never-searched-yet go first' ordering on the next run. 'Sends nothing' usefully reassures the agent that this write operation causes no outbound email, complementing readOnlyHint=false. It doesn't cover duplicate handling or limit-violation 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?

Four short sentences, purpose and examples front-loaded, with limits and side-effect notes trailing. Every sentence carries information an agent needs; nothing is 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?

For a two-parameter add tool with no output schema and full annotation coverage, the description supplies purpose, examples, numeric limits, ordering behavior, and the no-send guarantee. Remaining gaps (duplicate keyword behavior, append vs. replace semantics, validation error shape) are minor.

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

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

Schema coverage is 100% (both params documented), so the baseline is 3; the description goes further by characterizing what a keyword should be (a search expected to surface link prospects) and imposing 25-per-call and 2–9-word constraints the schema lacks. It adds genuine meaning beyond the schema's 'exactly as typed into Google'.

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

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

States a specific verb and resource ('Add Google searches for discovery to run') and grounds it with concrete examples ('vegan recipe blogs', 'write for us fitness'), so an agent knows exactly what is being created. The verb cleanly separates it from siblings list_keywords and remove_keywords.

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

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

Explains the purpose context well: each keyword is a search that should surface sites that could link to this one, implying this is the entry point for link-building discovery. It does not explicitly name alternatives (list_keywords/remove_keywords) or state when not to use it, so it stops short of 5.

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

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

Annotations declare readOnlyHint=false and destructiveHint=true, and the description usefully discloses the state changes behind each flag: live:true closes the thread as won, live:false drops the question, noLinkBackOwed clears the owed flag and closes as won. It doesn't clarify what 'drops the question' means concretely (deleted vs archived) or whether the action is reversible, which keeps it at a 4 rather than 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?

The primary instruction is front-loaded and there is little redundancy, but the third sentence on noLinkBackOwed is heavy with dashes and asides ('instead of live', 'a paid placement, a free mention') that slightly dilute scannability. Every sentence still carries actionable content.

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 burden and it covers outcomes (thread closed as won, question dropped) and preconditions well. Minor gaps remain: no note on error behavior if the conversationId is stale, and no explicit differentiation from mark_deal for the same won-deal state.

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 consequence-level meaning the schema lacks: live maps to closing-as-won vs dropping the question, and noLinkBackOwed is explicitly for non-swap placements (paid placement, free mention). This goes beyond the terse schema strings ('true if the link is on the page').

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

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

The description states a specific verb and resource: answering the checker's question about an unreadable page, keyed by a conversationId. It also names the exact place the ID comes from ('could not read' section of list_links), so the agent can distinguish this from the list_links read itself.

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

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

It gives clear preconditions: only answer after a person has actually looked at the page, never from a guess, and only when the person or thread says so. It also routes the noLinkBackOwed case for non-swap placements. It does not name a sibling alternative (e.g., mark_deal) for the won-deal outcome even though that sibling exists, so it stops short of full alternative routing.

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

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

Annotations already declare non-readOnly, destructive, and idempotent, so the safety profile is structured. The description adds that every value is re-checked before writing, a validation behavior not captured by annotations, though it stops short of noting it's irreversible or it returns confirmation.

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

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

Three short sentences, each carrying distinct information: what it does, how to pass input, and the re-check behavior. Front-loaded and free of 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-param mutation tied to a planner, the description covers the workflow, input contract, and validation, with annotations covering the destructive/idempotent profile and schema covering params. It would be closer to complete with a note on expected result or failure handling.

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

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

Schema coverage is 100% and both params are documented (changes must be the unmodified array from plan_campaign_change; workspaceId points to get_status). The description reinforces this ('exactly as they came') but adds no new parameter meaning beyond the schema.

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

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

States a specific verb (makes/applies changes) tied to the sibling plan_campaign_change, so the agent knows this commits a plan. It doesn't fully spell out that it mutates campaign config, but names the paired planner, which is the key disambiguation.

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

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

Clearly implies use-after-plan and instructs passing the changes back exactly as returned. It lacks explicit when-not guidance (e.g., don't hand-craft changes), but the workflow relationship to plan_campaign_change is unmistakable.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered, yet the description still adds real-world consequence: real email to real people, staggered delivery over time, and no undo. These are behavioral traits the annotations do not express.

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

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

The critical warning is front-loaded in the first phrase, followed by what happens, then the required workflow, then the irreversibility clause. Four short sentences, every one load-bearing, no filler.

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

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

For a destructive action tool with no output schema, it covers the consequence, the prerequisite verification step, the cleanup action, and non-reversibility. Nothing an agent needs to decide whether and how to call it 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 both parameter descriptions already document batchId (from list_pending_drafts) and workspaceId (from get_status). The description only restates batch scope ('every draft still pending in the batch') without adding format or lookup detail 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?

The description names a specific verb and resource ('approves every draft still pending in the batch and starts delivering them'), and the leading 'SENDS REAL EMAIL' disambiguates it from read-only siblings like list_pending_drafts and skip_batch. An agent can tell exactly what this does without opening the schema.

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

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

It gives explicit ordering and preconditions: show drafts to the person with list_pending_drafts and get agreement first, discard unwanted items before calling. It names the sibling to consult and the action to take beforehand, and states the irreversible nature as a final caution.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, so the safety profile is partly covered. The description adds genuinely new context by explicitly reassuring that 'Nothing is deleted and no email is sent' and by disclosing the side effect on list_inbox results, which the annotations cannot express.

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

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

Three short sentences, front-loaded with the primary action and effect, followed by the safety reassurance and the usage trigger. Every sentence carries distinct information with no filler.

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

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

A simple two-parameter, non-destructive toggle with no output schema and full annotation coverage. The description covers action, effect on sibling output, safety, and usage timing, leaving nothing an agent needs 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%: both parameters are documented in the schema, including the archived default and the source of conversationId. The description's 'or brings it back' only loosely gestures at the boolean toggle, adding little beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('files a conversation away', 'brings it back') and names the observable effect on the sibling tool list_inbox. An agent can distinguish this from get_thread, list_inbox, or redirect_thread without opening any schema.

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

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

Gives explicit timing guidance: 'Use it once a thread is dealt with, so the inbox reflects what still needs attention.' This is clear context for when to invoke, but it never names a competing alternative (e.g. redirect_thread, discard_draft) or states when not to use it.

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

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

Adds real behavioral context beyond annotations: subdomain coverage (each covers its subdomains), the 500-per-call limit, and 'Sends nothing' confirming this doesn't trigger outreach. These are non-obvious operational facts not present in 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?

Two tight sentences, front-loaded with the purpose and scope, no waste. Every clause carries information (examples, format, subdomains, limit, no-send).

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

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

Covers purpose, format, scope semantics, limits, and side-effect absence for a 2-param mutation-free tool with no output schema. Could be slightly stronger with explicit crossover guidance to unblock/list siblings.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds value by clarifying the domains format (bare domains or URLs) and subdomain implication, but is baseline-appropriate given schema already covers params.

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 (block domains) with the exact semantic meaning stated: domains outreach must never contact. Distinguishes clearly from sibling unblock_domains and list_blocklist by contrast.

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 'what and why' (competitor, partner, client - never contact) and the input format (bare domains or URLs), but never explicitly states when to use this versus alternatives like list_blocklist or unblock_domains.

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, so the bar is lower, yet the description adds real value beyond them: irreversibility ('This cannot be undone') and blast radius ('The rest of the batch is unaffected'). No permissions or error behavior are covered.

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 filler, with the action and its irreversibility front-loaded. 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 destructive mutation with no output schema, the description covers effect, scope, and reversibility. Missing only the practical detail of where draftId comes from in workflow terms, which the schema already implies.

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

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

One parameter with 100% schema description coverage, so the schema already carries the semantics ('From list_pending_drafts'). The description adds nothing parameter-specific; 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 ('Throw away one draft') with an immediate scope/effect statement. An agent can distinguish this from edit_draft, list_pending_drafts, and skip_batch 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?

Usage is implied rather than stated: 'The rest of the batch is unaffected' hints this is the per-draft alternative to a batch-level skip, but the description never names skip_batch or states when to discard versus edit a draft. Adequate but with a clear routing gap.

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

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

Adds a lot beyond annotations: spends credits, sends nothing, async jobId return, 1-4 minute latency with the slow case identified, and that it follows workspace standing negotiation rules autonomously. These are the exact behavioral traits an agent needs and none are in the structured fields.

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

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

Front-loaded with the two most decision-relevant facts ('SPENDS CREDITS. Sends nothing.'), then rationale and mechanics. Dense and mostly efficient, though a few sentences run long.

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 async mutation tool with no output schema, the description covers cost, side effects, return value (jobId), polling path, latency and autonomous rule-following. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents mode, pageUrl, guidance, skipPageUrls and avoidAfterTexts. The description only restates the guidance parameter's purpose; it adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Starts MentionAgent's own reply writer on one thread and returns a jobId') and names the polling sibling. An agent can distinguish this from edit_draft or send_reply purely from the text.

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

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

Explicitly says to use it 'rather than writing the reply yourself when the answer should propose a placement', explains why (site crawling it can't do from thread text), and routes the follow-up to get_draft_reply. It also warns not to write a replacement while it runs.

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 destructive=true, idempotent=true, and readOnly=false, so the safety profile is covered and 'replace' is consistent with them. The description adds input-format behavior ('plain text is fine; line breaks are kept'), which is useful but modest; it says nothing about failure modes or what happens to a non-existent draftId.

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, front-loaded with the action, followed by prerequisite and format note. No filler; every sentence carries information.

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

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

For a 3-param mutation with annotations covering safety and no output schema, the description covers purpose, prerequisite, and input format adequately. Only missing edge-case behavior (invalid/absent draftId) keeps it from a 5.

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 all three parameters are documented in the schema, so the schema does the heavy lifting. The description names subject and body and the source of draftId, and adds the plain-text/line-break note relevant to body, but nothing beyond baseline.

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

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

States a specific verb and resource: 'Replace the subject and body of one draft that has not been sent.' The 'not been sent' scope cleanly separates it from send_reply and discard_draft, though no sibling is named 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?

Gives a concrete prerequisite: 'Get the draftId from list_pending_drafts.' This routes the agent to the right sibling for the ID. No when-not-to-use or exclusion guidance, 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, idempotent, non-destructive, closed-world), and the description adds substantial context on top: per-file-type return behavior (image as image, PDF/docx as extracted text, text/CSV as-is), which types silently fail to read, and a prompt-injection warning that the content is the prospect's material and 'never instructions'. That last point is real behavioral guidance an agent would otherwise miss.

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 comes back, then the format enumeration, then the id provenance and the injection caveat. Dense but every sentence carries information; the format list is the only mildly verbose part.

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 burden of describing returns, and it does so per format while flagging which formats return nothing useful. Combined with the safety caveat, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema (index, messageId, conversationId with their sources). The description only restates the get_thread provenance for messageId and index, adding little beyond the schema. Baseline 3 applies.

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

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

States a specific verb+resource ('The contents of one file attached to a message in a thread') and immediately differentiates itself from get_thread, which lists attachments but does not read them. It further specifies per-format return behavior, so an agent can tell exactly what this tool does versus its siblings.

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

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

Explicitly tells the agent where the required ids come from ('get_thread lists each message's attachments with the messageId and index this takes') and states which types cannot be read here (spreadsheets, archives, old .doc), which is an effective exclusion. It stops short of naming an alternative tool for those unreadable types, so no full alternative routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds that this reflects the site's *current* state, reinforcing freshness, but says nothing about auth, caching, or response 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?

One dense sentence that front-loads the returned content and ends with the actionable cue 'Read this before changing anything.' Slightly ornate phrasing ('What this site is currently saying and to whom') costs a little precision but wastes no tokens.

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

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

With no output schema, the description compensates by naming the fields the agent will see (target page, pitch, drafts per run, quiet hours, send days), which is the main thing missing structurally. It could have gone further on how this relates to the change-planning siblings, but nothing critical 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% with a single well-documented workspaceId, so the schema carries the parameter burden. The description contributes no additional meaning about the identifier, which is the expected baseline when coverage is this high.

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 exactly what the tool returns — the linked page, the pitch, draft volume, quiet hours, sending days — so an agent can tell it reads this site's campaign settings. It never states a clean verb+resource ('Get the campaign settings') and identifies no sibling by name, 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?

'Read this before changing anything' gives one real usage condition and implicitly routes the agent toward a read-before-write flow. It does not name the siblings that perform changes (plan_campaign_change, apply_campaign_change) or say when this is not needed, so 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 declare readOnlyHint=false / destructiveHint=true / idempotentHint=false, and the description goes well beyond them: a 25s per-call wait, a one-time handover that 'reads as expired' on re-ask, and 1–4 minute run durations. This is precisely the mutation/lifecycle context an agent needs and cannot get from the schema.

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

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

Front-loaded with the tool's identity, then each sentence carries distinct operational information (wait time, polling loop, one-time retrieval, cancellation). No filler sentences and nothing repeated from the schema verbatim.

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

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

With no output schema, the description still tells the agent what comes back ('returns it or says it is still writing and for how long') and warns about the expiry semantics. For a non-idempotent polling tool this is complete enough to call correctly without trial and error.

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

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

Schema description coverage is 100%, so both parameters are already documented in structured data and the baseline is 3. The description reinforces the meaning of cancel ('stop a run') and implies jobId comes from draft_reply, but adds no syntax or value details the schema lacks.

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

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

Opens with a specific verb+resource ('Picks up the result of draft_reply') and explicitly anchors itself to the sibling draft_reply, so an agent can separate the drafting tool from the collection tool immediately. The 25-second wait and polling behavior 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 explicit operational guidance: 'Keep calling until it returns: runs take 1 to 4 minutes,' plus the escape hatch 'Pass cancel:true to stop a run you no longer want.' This tells the agent both the loop pattern and when not to collect, which is exactly what alternatives guidance looks like.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral value by disclosing the specific diagnostic fields returned, including pause state and reason and next-run timing, which the annotations do not 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, no filler, with the payload definition front-loaded and the usage cue immediately after. Every clause contributes either returned fields or a use trigger.

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

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

There is no output schema, so the description must describe the return contents, and it does so comprehensively across sending state, pause, warmup, cap, bounce rate, and schedule. With annotations covering safety and a single well-documented parameter, 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%, and the schema description for workspaceId already explains it is the site to act on and points to get_status for listing sites. The prose adds no additional parameter meaning, so the baseline of 3 applies.

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

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

The description enumerates exactly what the tool reports for a site: sending on/off, pause reason, warmup progress, daily cap and usage, bounce rate, and next run time. That is a specific resource with concrete contents, and it is clearly a diagnostic read rather than a mutation like set_sending or resume_sending. It stops short of a crisp verb-plus-resource opening (the verb is only implied by 'Read this'), so it is strong but not maximally sharp.

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

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

It gives explicit triggering questions: 'why are so few emails going out' and 'why did it stop', which tells the agent exactly when this tool is the right call. It does not name a contrasting sibling or state when not to use it (e.g., versus get_status or set_run_settings), so it is clear context without explicit alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: it is dual-mode, returning an account-wide summary when called bare and acting as the discovery mechanism that yields workspaceIds. Pagination, volume limits and refresh cadence are not addressed.

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, no filler. The first front-loads what the agent gets; the second gives the operational instruction. Nothing is repeated and nothing could be cut without losing information.

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

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

There is no output schema, so the description must carry the return-shape burden — and it does, itemizing sites, pending drafts, threads needing reply, sent counts and remaining credits. Combined with the no-arg discovery instruction for a single optional parameter, 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% for the single optional parameter, and the schema already states 'Which site to act on. Call get_status with no arguments to list them.' The description restates the same no-argument listing behavior rather than adding syntax, default, or format detail, so the schema does the heavy lifting and 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?

The description names the resource (account) and enumerates exactly what it returns — sites, drafts awaiting approval, threads needing reply, sent emails, remaining credits — which implicitly positions it as the aggregate overview over siblings like list_pending_drafts, list_inbox, list_sent and get_sending_health. It does not explicitly say 'use this instead of those' but the content enumeration gives an agent enough to tell it apart.

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 concrete calling pattern: invoke with no arguments first to enumerate sites and obtain their workspaceId. That establishes both the discovery workflow and the precondition for the workspaceId parameter. It stops short of naming alternatives or exclusions (e.g., when to drill into get_thread or list_inbox instead), so it is clear context without full routing.

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

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

Annotations already declare readOnly/ idempotent/ non-destructive, so safety is covered; the description adds real behavioral detail beyond them: chronological ordering, the inclusion of the originating cold outreach email, and the delegation of file contents to get_attachment. It doesn't mention any limit or truncation behavior on long threads, which is the one remaining gap.

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

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

Two short sentences with no filler; the content/ordering description comes first and the usage directive second, which is the right front-loading for a retrieval tool.

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

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

With no output schema, the description carries the return-shape burden and does so well: messages, senders, timestamps, attachments, plus the thread's starting point. It omits anything about thread length limits or pagination, which keeps it from being 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 100% ('From list_inbox'), so the single parameter is already documented. The description adds no format, syntax, or sourcing information 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 resource (one thread's every message), its ordering (oldest first), and its payload (sender, timestamp, attachments). It also distinguishes itself from get_attachment by routing file reads there and from list_inbox (source of the id), so an agent can place it among 34 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 explicit when-to-use with a named sibling: 'Use this before send_reply so the reply answers what they actually asked.' It also names get_attachment as the alternative for reading files. It stops short of stating when-not to use it (e.g., for drafts or already-sent summaries), so it is strong but not exhaustive.

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 description adds substantial behavioral context beyond annotations: it sends nothing, drafts arrive in the normal pending batch, fit checks are skipped, contacts are still verified, already emailed or blocked sites are skipped, large sites require an email, and re-imports can requeue skipped sites. This is exactly the kind of operational detail an agent needs for a mutating import tool.

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

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

The description is dense but front-loaded, starting with the core action and immediately adding scope and behavior. Every sentence carries operational information, including limits and side effects, with no filler.

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

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

For a mutation tool with no output schema, the description covers the important behavior: no sends, pending-draft destination, deduplication, verification, and the 1,000-site cap. It does not describe the return value or error response, but otherwise gives an agent enough to invoke 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 url, name, note, email, and workspaceId. The description reinforces what each entry represents and mentions the note reaching the draft, but adds no new syntax or constraints for workspaceId or the site fields 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?

The description states a specific verb and resource: queue sites the person has vetted for pitching. It is clearly distinct from sibling tools like add_keywords and list_imported_sites, and the title reinforces the exact scope.

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 explains when these sites are used: next runs take them first and skip the agent's own fit check, while still verifying contacts and avoiding already-emailed or blocked sites. It gives important conditions such as re-import behavior and the Forbes-class rule, but does not explicitly name alternatives like list_imported_sites.

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), so the description's job is to add domain semantics — and it does: a blocked domain cascades to all subdomains, and already-emailed domains are omitted. What it does not describe is the shape of the returned 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 short sentences, purpose front-loaded, and each subsequent sentence earns its place by defining cascade behavior and an exclusion rule. 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 one-parameter read tool with no output schema, the description conveys what the result conceptually contains and what it deliberately omits. Only the concrete return format (list of strings vs. objects) is left unstated, which is 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?

Schema coverage is 100% and the workspaceId description already explains how to discover valid values via get_status. The description adds nothing about the parameter, so baseline 3 is correct.

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

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

Names a specific resource ('the domains the person has blocked for this site') and the scope of that resource. It is implicitly the read counterpart to block_domains/unblock_domains, but it never contrasts itself with those siblings by 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?

Usage is only implied — an agent would infer 'check this before blocking/unblocking.' The description does clarify a boundary condition (already-emailed sites are excluded), which is useful, but it gives no explicit when-to-use statement or alternative routing.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description adds value by disclosing the result state machine, including that 'skipped' carries a reason and that 'drafted' implies a draft exists elsewhere. It does not say whether results are ordered or limited, which keeps it off 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?

One sentence, front-loaded with the resource, then the detail. The status enumeration is the only elaboration and every item earns its place by describing a distinct outcome.

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 return semantics and does so by enumerating the three possible statuses and the optional skip reason. It omits ordering or pagination behavior, which is a real but minor gap for a read-only progress list.

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

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

There is a single required parameter at 100% schema coverage, and the schema even tells the caller to use get_status to discover valid values. The description adds no extra meaning about workspaceId, so the baseline 3 for fully documented schemas 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?

Names a specific resource (sites queued via import_sites) and states exactly what is reported about each: waiting, drafted, or skipped with reason. An agent can immediately distinguish it from import_sites (which enqueues) and list_pending_drafts (which shows the drafts produced).

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?

By tying itself to 'the sites queued with import_sites' and pointing at list_pending_drafts for drafts, it makes the natural call sequence (import → poll progress → inspect drafts) clear. It stops short of an explicit 'use this when / do not use this when' statement, so it is a strong 4 rather than 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds that results are newest-first and include a short extract of the last message, which is useful behavioral context beyond the annotations. It doesn't mention pagination behavior explicitly, but the schema covers it.

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

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

Two sentences, front-loaded with the key behavior (replied threads, newest first, extract) and a clear filter guide, ending with the alternative. Zero 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?

Complete for a read-only filtered list tool whose annotations cover the safety profile. It gives the agent enough to call correctly, though it could mention offset/limit paging semantics, but the schema covers that.

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

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

Schema coverage is 100%, so the schema documents all parameters. The description still adds semantic meaning to the filter values (e.g., 'needs_reply' = they spoke last and nobody has answered, 'hot' = interested, 'paid' = they quoted a price), which enriches the enum beyond the schema's terse 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 resource and scope: threads where somebody replied, newest first, with an extract of the last message. Clearly distinguishes itself from sibling list tools like list_pending_drafts and get_thread.

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

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

Names the sibling alternative get_thread explicitly for full conversations, and defines each filter value semantically ('needs_reply' = they spoke last and nobody answered, 'hot' = interested, etc.), giving the agent clear conditions for when and how to use it.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds domain semantics beyond that: what 'active' versus 'retired' actually means for the underlying search runs, which is genuine context the annotations don't carry. It does not mention pagination/limit 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?

Three short sentences, front-loaded with the resource concept and ending with the actionable 'contains' tip. The opening sentence is slightly awkward and indirect, but nothing is padded.

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

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

For a read-only list tool with no output schema and a fully documented 5-parameter schema, the description supplies the domain framing (what keywords are, what the statuses mean) plus the cross-tool workflow. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: it explains the real-world significance of the status values (active vs. retired) and gives a concrete reason to use 'contains'. The limit/offset/workspaceId parameters are left entirely to the schema.

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

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

The description explains that these are the Google searches used to discover sites for a campaign, and it distinguishes the two states (active = still searching, retired = removed/fully searched). Combined with the name list_keywords, an agent knows what it returns, though the description never states the verb directly and relies on the name. It does reference the sibling remove_keywords, giving some differentiation.

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

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

It gives an explicit workflow cue: use 'contains' to find exact text before calling remove_keywords, which routes the agent correctly to a downstream tool. It does not say when not to use this tool or mention other alternatives, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds rich domain semantics: it explains what 'owing our link back' signifies (checker believes the deal was a swap) and defines the four result categories. This is genuine behavioral context beyond the structured fields.

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

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

Front-loads the enumeration of result categories, then adds two clarifying sentences resolving jargon and pointing to answer_link. Dense but every sentence earns its place; only the run-on first sentence slightly burdens readability.

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 listing tool with no output schema and a single schema-documented parameter, the description thoroughly conveys what is returned and how to act on it. Pagination, ordering, and volume are not addressed, but nothing critical to correct invocation is missing.

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

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

Only one parameter (workspaceId) with 100% schema description coverage, including a pointer to get_status for listing sites. The description adds no additional parameter meaning, so the baseline 3 applies since the schema fully carries the load.

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

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

States a specific verb and resource (every placement/link the nightly checker has seen) and enumerates the exact categories returned: live links with follow status, unreadable pages, lost links, and won deals lacking links. This level of detail lets an agent distinguish it from siblings like list_keywords or list_blocklist without opening a schema.

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

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

Explicitly routes a subset of results to an alternative: 'Answer the pages it could not read with answer_link.' Clearly signals when this tool must be paired with answer_link, though it stops short of stating when this tool should not be used instead of other link-related 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 (readOnly, idempotent, non-destructive, non-openWorld), so the lower bar applies. The description still adds useful context the annotations don't carry: the drafts are unsent ('Nothing here has been sent') and the response includes full message text, which signals payload weight.

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

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

Two tightly written sentences, front-loaded with the scope and content, followed by the routing guidance. Every clause earns its place with no filler.

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

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

For a read-only list tool with annotations covering safety and a single fully-documented parameter, the description supplies the remaining needed context: what is listed, that it is unsent, and that full text is returned. No output schema is needed given the description explains the content.

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 (workspaceId) and schema description coverage is 100%, so the schema already documents the parameter and its get_status hint. The description adds no syntax or meaning beyond what the schema provides, making the baseline 3 correct.

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

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

States a specific verb and resource ('every outreach email drafted and waiting for a decision') and clarifies the scope with 'with the full text of each one. Nothing here has been sent.' This clearly separates it from siblings like list_sent and get_draft_reply without the agent opening a schema.

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

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

Explicitly names three siblings and the action conditions that route to them: edit_draft to change, discard_draft to drop, approve_batch to send. This is direct when-to-use-this-vs-alternatives guidance rather than implied usage.

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 as a read-only, idempotent, non-destructive operation, so the safety burden is lifted. The description adds real behavioral context beyond them: result ordering (newest first) and the returned fields (who and when), which help the agent interpret output without 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?

Three short sentences, zero filler. The core behavior and ordering lead, the use cases follow, and the sibling redirect closes — a well front-loaded structure.

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 read-only list tool with full schema coverage and no output schema, the description supplies scope, ordering, and returned fields, which is nearly everything needed. Pagination mechanics are left entirely to the schema's limit/offset fields, 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?

Schema description coverage is 100%, so limit, offset, and workspaceId are already documented in the schema, including the pointer to get_status for discovering site IDs. The description adds only the 'one site' scoping, which is already implied by workspaceId, so the baseline of 3 applies.

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

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

The description states a specific resource and scope: sent emails for one site, ordered newest first, with recipient and timestamp. It also explicitly distinguishes itself from the sibling that handles the opposite direction of the same correspondence flow (list_inbox).

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 names concrete use cases ('what did we send', verifying a specific site was contacted) and routes the alternative case — replies received — to list_inbox by name. Both when-to-use and when-to-use-something-else are covered.

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

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

Annotations already declare destructiveHint, idempotentHint, and non-readOnly, but the description adds genuinely non-structured context: no email is sent, the thread stops reading as pending, and the action is reversible via done:false. It does not cover failure modes (e.g., marking an already-closed deal) or 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?

Three dense sentences with no filler, and the core effect (records placement as done) is front-loaded. The mid-sentence clause about telling the other party via send_reply is slightly convoluted but still carries necessary 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 2-parameter mutation tool with no output schema, the description covers the side effects, the notification gap, and reversibility. Remaining gaps (error behavior when already closed, any auth constraints) are minor given the annotation coverage.

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

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

Schema description coverage is 100% and both parameters are already documented, including the done true/false semantics. The description only restates the reopen behavior for done:false, adding no syntax, defaults, or constraints beyond the schema; the baseline of 3 applies.

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

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

The description states a concrete verb+effect: it records that a placement is done (link live or deal agreed) and closes the agreed placement on the thread. It distinguishes itself from send_reply by explicitly saying it sends no email, so an agent can tell the two apart without opening the schema.

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

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

It gives a clear usage condition (the link is live or the deal is agreed) and an explicit routing rule: use send_reply first because this tool does not notify the other party. It also documents done:false for reopening. It stops short of contrasting with the similarly-scoped sibling archive_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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description reinforces this with 'Writes nothing' and, more valuably, discloses the two-step preview-then-apply workflow that annotations cannot express. It does not mention behavior on ambiguous or rejected changes, so it stops 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 short sentences, front-loaded with what the tool does and immediately followed by the workflow instruction. Every clause carries information; nothing is padding.

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

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

There is no output schema, and the description compensates by stating the return is 'exactly what would change', which tells the agent the response is a diff-style preview. The only gap is error or ambiguity handling for unparseable change descriptions, which is minor for a read-only planning tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes further by supplying four concrete examples of the natural-language 'change' input ('only send on weekdays', 'cut it to 10 a day', etc.), which teaches the agent the expected input register in a way the schema string alone does not.

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 (describe/plan), the resource (a campaign change), and the scope (preview only, writes nothing). It explicitly contrasts with the sibling apply_campaign_change, so an agent can route between the two without opening either schema.

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

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

Gives an explicit when-to-use workflow: call this first, show the result to the person, then call apply_campaign_change with the same changes to make it real. The alternative and the condition that selects it are both named, leaving nothing to inference.

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

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

Goes well beyond the annotations: "Sends nothing", opens a new thread, closes the original, and enumerates refusal cases (loop, repeat, opted-out, bounced, chain deeper than three). This confirms and elaborates the destructiveHint=true / non-idempotent profile rather than contradicting it.

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

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

Front-loads the counterintuitive fact ("Sends nothing") before the mechanics, and each sentence carries distinct information. Slightly dense and could be split, but 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 non-idempotent mutating tool with full schema coverage and no output schema, the description covers side effects, refusal conditions, and the reply-routing caveat. What happens on a refused redirect (error surface) is the only notable omission.

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

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

Schema coverage is 100% with self-documenting field descriptions (name, email, conversationId with provenance from list_inbox/get_thread). The description refers to "that address" and the referral context but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

Specific verb (redirect/hand off) plus resource (thread), with a concrete mechanism: opens a NEW thread to the named address, carries the referral, closes the original as redirected. An agent can distinguish this from send_reply and archive_thread purely from the description.

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 triggering condition explicitly ("somebody replies 'I am not the right person, talk to X'") and pre-empts the obvious confusion by noting send_reply still answers the original referrer. When-to-use and the relevant alternative are both named.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds non-obvious behavior: removed keywords are retained as history so they are not regenerated, the pool will not fall below the minimum a run needs, and there is a 25-per-call cap. These are substantive operational facts beyond the structured hints.

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?

Five short sentences, no filler; the primary action and the routing alternative are front-loaded before the secondary facts about history retention, pool floor, and batch size. 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 a 2-parameter mutation tool with no output schema, the description covers alternatives, batch limits, and retention behavior. It is slightly thin on edge cases (unknown keyword text, partial failure reporting), but annotations already carry the destructive/idempotent profile.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds one genuine constraint not present in the schema — 'Up to 25 per call' on the keywords array — while the 'exact text from list_keywords' guidance only restates the schema wording.

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?

Starts with a concrete verb+resource (stop discovery running these searches) and immediately distinguishes itself from sibling tools by naming plan_campaign_change for the broader 'no directories' case. An agent can tell this apart from add_keywords/list_keywords without opening a schema.

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

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

Explicitly routes the agent: use this for exact keyword text (as list_keywords shows it), use plan_campaign_change to stop an entire kind of site. Both the alternative and the condition that selects it are stated, so nothing is left to inference.

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

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

Annotations already declare it non-read-only, idempotent and non-destructive, so the bar is lower. The description still adds real behavioral context: volume remains reduced while the rate is high, and a single further bounce re-pauses the site - consequences an agent cannot infer from annotations or schema. It omits return/confirmation behavior, hence 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?

Four short sentences, zero waste, with the identifying condition and the sibling disambiguation front-loaded. The trailing reminder to explain the pause to the user is actionable rather than filler.

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

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

For a simple one-parameter, single-purpose mutation with no output schema, the description covers purpose, precondition, alternative, side effects and a follow-up obligation. Only a note on what a successful call yields is absent, which is minor.

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

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

Only one parameter, and schema description coverage is 100% - the schema itself explains workspaceId and how to enumerate sites via get_status. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb+resource and the exact precondition ('a site that paused ITSELF over its bounce or complaint rate'), which is far more precise than the name alone. It explicitly contrasts itself with the sibling set_sending, so an agent can route between them without opening schemas.

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

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

Explicitly says when to use it (automatic pause confirmed via get_sending_health) and when not to (this is not the on/off switch; set_sending is), naming the alternative. It also imposes a workflow prerequisite: tell the person the reason for the pause before calling.

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, openWorldHint=true and idempotentHint=false, so the safety profile is partly covered. The description adds real value by stressing that it sends real, external, irreversible mail and that recipient/subject are locked to the thread and cannot be redirected here.

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

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

Four sentences, all front-loaded with the irreversible-send warning first, then scope, then constraint, then workflow. Every sentence carries a distinct, necessary instruction with no filler.

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

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

For a two-parameter, no-output-schema mutation tool this is nearly complete: it covers effect, scope restriction, prerequisite read, and confirmation step. It could add what happens on success/failure, but annotations plus schema cover the rest adequately.

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

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

Schema coverage is 100%, so baseline is 3. The description goes beyond it by explaining why only conversationId and body exist: the recipient and subject are derived from the thread and 'cannot be set here', which prevents an agent from searching for address/subject parameters.

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

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

States a specific verb + resource ('SENDS REAL EMAIL. Replies to one conversation') with immediate scope and side-effect framing. It is clearly distinguishable from the draft_reply sibling, which would be the non-sending alternative.

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 prerequisites ('Read the thread with get_thread first') and a confirmation workflow ('show the person what you are about to send before sending it'). It does not explicitly name draft_reply as the non-sending alternative, but the workflow guidance is concrete and actionable.

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 flag this as destructive, and the description usefully narrows that meaning: 'Sends nothing' tells the agent the destructive hint refers to settings mutation, not outbound sending. It also discloses a behavioral rule absent from annotations — offer terms containing a dash or a disallowed word 'are refused' — which the agent needs to anticipate a failed call. It stops short of stating permission/auth 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?

Purpose and the 'Sends nothing' caveat are front-loaded and the field-by-field parentheticals are scannable despite being packed into one dense block. Every clause earns its place, though the paragraph could be broken into a list for faster reference.

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

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

For a 7-parameter, no-output-schema mutation tool the description covers partial updates, field constraints, validation failures, and the fact that nothing is sent. What is left implicit is whether changes take effect immediately and whether any fields are mutually required.

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?

Although schema coverage is 100%, the description adds semantics the schema lacks: the 400-character cap on offerTerms, the 200-character cap on pricingDetails, the requirement that the offer be 'stated word for word', the meaning of each enum value ('exchange' = feature them too, 'mention' = brand mention only), and that pricing is 'the only figure the emails may quote'. This meaningfully raises the bar above the schema's terse glosses.

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

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

States a specific verb and resource ('Change how first emails are framed') and enumerates the exact fields under its control: offer terms, first-touch placement, outreach goal, style, pricing, sender name. It is clearly distinguishable from sibling settings tools like set_run_settings, set_profile, set_sending and set_warmup.

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?

'Pass only the fields to change' explicitly documents partial-update usage, telling the agent it need not supply all six fields. It gives no explicit when-not or named alternative, but for an idempotent settings mutator the contextual guidance is clear and actionable.

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 cover the safety profile (idempotentHint=true, destructiveHint=true), yet the description adds real context: the page is fetched once and an erroring page is refused, and 'Sends nothing' clarifies this is a silent config change rather than an outreach send. It also identifies the destructive action ('pass [] to clear them').

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 dense but front-loaded with the core action and every sentence contributes distinct information (page formats, fetch/refuse behavior, phrase limits, no-send behavior). Slightly packed, but no wasted sentences.

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

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

With no output schema, the description still covers the parameter semantics, validation behavior, and the no-send outcome, which is sufficient for a 3-parameter config tool. Minor gaps remain around how the resulting state is confirmed.

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 constraints the schema lacks: page accepts a path or same-site URL with empty string meaning homepage, phrases are capped at 3 phrases of 3 words, and the omit-vs-[] distinction for keeping or clearing. This meaningfully exceeds the schema text.

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

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

The description names a specific action and resource: choosing the page that outreach links to plus its anchor phrases. It clearly distinguishes itself from siblings like list_links and add_keywords by describing the configuration it sets, and an agent can tell what it does without opening the schema.

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

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

Usage is implied by the semantics (omit phrases to keep, [] to clear, empty string returns to homepage), but there is no explicit statement of when to prefer this tool over siblings such as set_profile or list_links, and no prerequisites or exclusions are given.

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

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

Goes well beyond the annotations: it discloses that competitors and audiences REPLACE the whole list (the specific destructive behavior behind destructiveHint=true), caps the lists (20 items of 120 chars), clarifies scope ('applies to drafts written from now on'), and negates side effects ('Sends nothing'). This is exactly the behavioral context annotations cannot convey.

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

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

Front-loads the purpose before the constraints, and each sentence carries distinct information (replace semantics, prerequisite, limits, scope). It is dense and packed, but no sentence is wasted.

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

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

For a mutation tool with no output schema, the description covers what changes, how lists are replaced, the prerequisite read, size limits, scope of effect, and the explicit absence of sending. Nothing an agent needs to call 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 baseline is 3, but the description adds constraints the schema lacks: list-size limits (20 competitors/audiences, 120 chars) and a plain-language definition of the differentiator. It does not, however, add per-parameter syntax or format detail beyond the schema.

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

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

States a specific verb ('Change') and resource ('the profile every outreach email is written from') and enumerates exactly which fields are editable (niche, competitors, differentiator, audiences). An agent can tell this is a profile-configuration tool distinct from settings-oriented siblings like set_email_settings or set_run_settings.

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 prerequisite workflow ('read get_campaign first and pass the full list with your edits'), a boundary ('The website itself cannot be changed here'), and the effect timing ('Applies to drafts written from now on'). It also states the input contract ('Pass only the fields to change'), 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?

Beyond the annotations (destructiveHint=true, idempotentHint=true, non-read-only), the description discloses genuinely non-obvious behavior: an ineligible site 'keeps the request and switches on when it becomes eligible,' autoSend means batches go out 'SENT WITHOUT REVIEW,' DR bounds change draft volume, and a siteTopic filter skips whole sites even when one article matches. That is exactly the consequences layer the annotations cannot express.

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

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

Purpose is front-loaded and the field explanations are dense but each earns its place, with the highest-risk field (autoSend) flagged explicitly. The frequency enum recitation is redundant with the schema, and the field order mixes schedule, automation, eligibility, and targeting without grouping.

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

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

For an 8-parameter mutation tool with no output schema, the description covers every parameter's effect, warns on the one destructive setting, explains the deferred-application case, and instructs partial updates. The only unanswered question — how soon a frequency change affects already-scheduled runs — is minor.

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

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

Schema coverage is already 100%, so the baseline is 3; the description earns a step above by adding consequence-level meaning — smaller sites accept more often so a high minDr means fewer drafts, -1/0 clear the setting, and a concrete siteTopic example. It loses a little value by restating the frequency enum and the 0-23 hour range that the schema already carries.

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

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

The opening sentence gives a clear verb+resource: change the run schedule and automation settings for a site, and the body enumerates exactly which knobs (frequency, preferredHour, autoFollowup, autoSend, minDr/maxDr, siteTopic). It stops short of positioning itself against the nearby siblings (set_warmup, set_profile, set_sending, trigger_run) — the only sibling named, get_campaign, is cited for a suggestion, not for routing.

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 strong per-field operational guidance: 'confirm with the person before turning it on' for autoSend, 'Turning it off is always allowed,' and 'Pass only the fields to change.' What's missing is tool-level routing — it never states when to prefer this tool over set_warmup or trigger_run, so the agent must infer the boundary from the sibling 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 declare destructiveHint=true and idempotentHint=true, and the description meaningfully narrows the blast radius: no new drafts or cold emails, but replies and in-flight batches are untouched. That is valuable scope context beyond the annotations, though reversibility/re-enable behavior is not restated.

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 tight, front-loaded sentence pair: the core action first, then the clarifying scope limits. Every clause carries information; nothing is 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?

For a two-param toggle with no output schema, the description plus annotations cover action, scope, and side-effect boundaries well. Missing only the sibling-routing detail (set_sending vs resume_sending) that would make it 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 coverage is 100% and both parameters are documented in-schema (enabled semantics, workspaceId discovery via get_status). The description adds only the implicit 'one site' scope, so baseline 3 is appropriate.

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

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

States specific verbs (stops/restarts) and the resource (new outreach for one site), covering both directions of the boolean. It is clear, but it does not address the sibling resume_sending, which appears to overlap, so an agent cannot fully tell them apart from the description 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?

Gives clear context for what turning it off means and what it explicitly does not affect (replies in flight, batches already being delivered). That is strong boundary-setting, but there is no explicit when-to-use-this-vs-resume_sending 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 declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, so safety is partly covered. The description still adds real value beyond them: pausing is scoped to all inboxes the site sends from, it does not halt outreach, and there is a deliverability cost to long pauses. It does not clarify reversibility timing or whether pausing affects in-flight warmup mail, so it's strong but not exhaustive.

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

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

Three sentences, no padding, and the core action plus scope lead. The sibling disambiguation and the consequence warning each carry distinct information, so 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 two-parameter, no-output-schema mutation tool with annotations already covering the safety profile, the description supplies everything else an agent needs: scope of effect, the sibling boundary, the side effect on outreach, and the risk of misuse.

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 schema already documents both parameters, including the boolean polarity ('true to resume warmup, false to pause it'). The description adds no parameter-level detail 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 pair (pauses/resumes) and resource (inbox warmup) with scope nailed down: 'on every inbox this site sends from'. It explicitly names the sibling it is not (set_sending) and explains the functional difference, so the agent can distinguish it without opening any schema.

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

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

Gives explicit routing guidance against the closest alternative: 'Separate from set_sending: warmup mail is exchanged with a warmup network, not sent to prospects.' It also states a when-not-to-casually-use condition ('a long pause on a young inbox can cost deliverability'), which is actionable context most definitions omit.

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=false, so the safety profile is established. The description adds real value beyond that: irreversibility ('Cannot be undone') and a side effect not visible in annotations (draft credits refunded for paying accounts). It does not cover permissions or rate limits, so it stops 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?

Five short sentences, each earning its place: action, side effect, alternative, parameter sourcing, irreversibility. The destructive consequence and scope are 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 destructive, two-parameter tool with no output schema, the description covers scope, alternative, parameter source, irreversibility, and a financial side effect. Only auth/prerequisite context is absent, which is a minor gap given the annotations.

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

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

Schema description coverage is 100%, and the description's sourcing note for batchId largely restates the schema's own 'From list_pending_drafts' text. Baseline 3 is appropriate since the schema carries parameter documentation.

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 (discard) with a precise scope (every draft still pending in the batch) and explicitly names the sibling discard_draft as the narrower alternative. An agent can distinguish it from approve_batch and discard_draft without opening any schema.

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

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

Explicitly says when to use it versus the alternative ('Use discard_draft to drop just some') and where the batchId comes from ('list_pending_drafts'), so selection and sourcing are both covered.

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

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

Goes well beyond annotations: discloses credit cost ('SPENDS CREDITS'), scope of side effects ('drafts emails... It sends nothing'), asynchronous behavior ('takes several minutes; this returns as soon as it starts'), and a hard refusal precondition. This is exactly the context annotations can't express.

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

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

Five short sentences, each carrying a distinct fact (purpose, cost, side-effect boundary, latency/return semantics, refusal condition), with the purpose front-loaded. Zero 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, but the description compensates by explaining that the call returns immediately and that get_status surfaces the drafts later. Credit cost, refusal condition, and non-sending scope are all covered — nothing an agent needs to invoke this safely is missing.

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

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

Only one parameter, and schema coverage is 100% — the schema already documents workspaceId and even points to get_status for enumeration. The description adds no syntax or format detail 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+resource ('starts a discovery and drafting run for one site') and immediately distinguishes it from the scheduled variant ('instead of waiting for the next scheduled one'). An agent can tell this apart from siblings like get_status or approve_batch without opening a schema.

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

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

Gives an explicit when ('instead of waiting for the next scheduled one') and an explicit when-not with the remedy ('Refused while a batch is already waiting for approval, so deal with those first'). It also routes to get_status for observing results, covering both trigger and follow-up.

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, idempotentHint and readOnlyHint=false, so safety is covered. The description adds genuinely non-obvious behavior beyond that: an already-emailed domain remains uncontactable and only its subdomains are unblocked, plus a 100-per-call batch limit. It does not state error behavior for non-blocklisted domains.

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, the core action front-loaded, and each clause carries distinct information (source of text, side-effect caveat, batch limit). 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 simple two-parameter mutation with no output schema and annotations covering the safety profile, the description supplies the caveat, the input format requirement and the batch cap. Only failure/partial-application behavior is left unstated.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds constraints the schema does not: domains must be passed as the exact text list_blocklist returns, and at most 100 may be submitted per call. That meaningfully constrains the domains array beyond its schema entry.

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 (remove) plus resource (domains from the blocklist), and it is immediately distinguishable from the sibling block_domains. An agent knows exactly what this does without opening a schema.

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

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

It routes the agent to list_blocklist as the source of the exact domain text and explains the relevant conditional case (an already-emailed domain stays uncontactable). There is no explicit when-not-to-use statement, but the operational context is clear.

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