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

The description reveals key behaviors: server-side dedup is authoritative and it returns inserted, skipped, and skippedDetails. It also explains specific skip reasons (unknown_industry, unknown_strategy). However, it does not mention side effects like one-way ratchets for doNotContact or write-once fields, which are present in the schema but not highlighted.

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 concise and well-structured, covering the core purpose, dedup behavior, return format, and common skip reasons in three sentences. It avoids unnecessary verbosity while providing essential information. The structure is clear and easy to parse.

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

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

Given the complexity of the tool with many parameters and nuanced behaviors, the description covers the high-level operation, dedup, and typical failure modes. It does not repeat all schema details, which is appropriate, but it could mention additional core behaviors like write-once fields or ratchets to be fully complete. Overall, it provides sufficient context for an agent to understand the tool's role.

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

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

The description adds context on how industry and discoveryStrategy values affect processing (skip reasons), which supplements the schema. However, the schema already provides detailed descriptions for all parameters, and the description does not significantly deepen understanding beyond that. The added value is moderate.

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

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

The description clearly states the tool's action ('Batch-register prospects') and its resource (prospects). It distinguishes from update tools by mentioning server-side dedup and provides a clear return structure. However, it could be slightly more explicit about being an 'add' vs 'update' operation, though 'register' implies creation.

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

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

The description does not explicitly state when to use this tool versus alternatives like import_prospects_from_csv or update_prospect. It implies batch use and dedup authority, but lacks direct guidance on selection criteria. Without explicit usage conditions, the agent may struggle to choose between similar batch-import 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?

No annotations are provided, so the description carries the full burden. It explicitly states 'Read-only' (implying no side effects) and describes the output structure and the reason field. However, it does not disclose error handling, normalization behavior, or constraints like max candidates (though that is in 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?

The description is concise, using a single sentence with clear structure. It packs crucial information: read-only nature, output format, and relationship to add_prospects, with 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?

Given no output schema, the description adequately describes the return structure. It also covers the dedup logic and key behaviors. However, it does not specify error cases or rate limits, but that is mitigated by the straightforward nature of a pre-check tool and the schema's 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%, so the schema already documents both parameters. The description adds value by explaining the effect of omitting projectId (tenant-scope only, no project-link check) and mentions normalization server-side for organizationDomain, which complements the schema. This goes beyond the 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?

The description clearly states the tool's purpose: a read-only duplicate pre-check that returns decisions in input order with kind ('fresh' or 'skip'). It specifies the exact output structure and explicitly mentions the dedup subset, distinguishing it from sibling tools like add_prospects and skip_prospect.

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

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

It clearly indicates this is a pre-check tool (read-only) and references the dedup subset of add_prospects, which suggests when to use it (before adding prospects). However, it does not explicitly state when not to use it or name alternatives beyond the reference to add_prospects.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavior such as defaulting name/websiteUrl from the domain and CONFLICT handling on duplicate, which is valuable. It could also clearly state that this is a write operation, but the mutation is strongly implied by 'register' and 'CONFLICT'.

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 main purpose, and every clause adds useful behavioral or contextual detail. No wasted words.

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

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

The description covers purpose, when to use, conflict handling, and default behavior for common parameters. For a create tool with no output schema, it is largely complete, though it could mention what the create action returns on success if that matters for follow-up calls.

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 only 25% (only domain is documented in the schema), but the description clarifies the semantics of the 'name' and 'websiteUrl' parameters (default from domain) and illustrates the 'doNotContact' use case. It does not explicitly describe the doNotContact parameter, but the schema has a default.

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 uses a specific verb ('Register an organization') with a clear resource and method ('by domain alone'). The example of flagging a company and the explicit pointer to update_organization for existing domains distinguishes it from sibling tools.

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

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

It provides an explicit use case ('before any prospect exists') and explicitly says 'CONFLICT if the domain already exists (use update_organization)', which tells the agent when to choose a different tool.

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

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

With no annotations, the description discloses permanent deletion, the max batch size, and the skip behavior with a reason. It does not mention idempotency or error responses, but the key destructive and partial-failure aspects are transparent.

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 two concise sentences with no redundancy. It front-loads the action and immediately provides critical constraints and a useful preview tip, making every word purposeful.

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 delete tool with no output schema, the description covers the essential context: permanence, limit, conditional skipping, and preview. It does not explain return values, but that is not required given the tool's simplicity.

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

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

The description explicitly notes 'by id' and 'max 200', which aligns with the schema's organizationIds array and maxItems. Since schema coverage is 0%, the description partially compensates, but it adds little beyond what the parameter name and schema already imply.

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

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

The description clearly states the action (delete), the resource (organizations), and the scope (by id). It also highlights a key constraint (max 200) and a behavioral nuance (skipped if prospects exist), which distinguishes it from related tools like delete_prospects or delete_project.

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

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

The description advises to 'Preview with list_organizations,' which gives clear usage context. However, it does not explicitly mention when not to use this tool or alternative tools for deleting individual prospects, leaving some room for ambiguity.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently lists the categories of project-scoped data that will be deleted and adds a crucial warning that prospects are NOT deleted, which is a significant side-effect clarification. It doesn't mention reversibility or permissions, but for a delete operation, this coverage is above average.

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?

Despite being a single sentence, the description efficiently packs essential details: the action, the explicit list of affected data, and the exclusion of prospects. The structure front-loads the verb and resource, and the parenthetical list is scannable. No wasted words.

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

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

For a destructive tool with one parameter and no output schema, the description covers the key aspects: what gets deleted, what doesn't, and the scope of impact. It doesn't address restore capabilities or authorization, but that's acceptable. The nuance about prospects being tenant assets is valuable and covers a likely source of confusion.

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

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

The schema covers 100% of parameters with a description for projectId ('Project name or ID.'). The description adds no additional parameter-level detail beyond the schema, which is acceptable since the schema is complete. This is a baseline 3, as the description doesn't enhance parameter understanding beyond the structured data.

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

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

The description clearly states the verb 'Delete' and identifies the resource 'project' while listing the exact scope of deletion (project-prospect links, outreach logs, etc.). It distinguishes itself from sibling tools like delete_prospects and delete_organizations by explicitly scoping the deletion to project-scoped data and highlighting that prospects are tenant assets and NOT deleted, making the purpose unambiguous.

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

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

The description provides clear context on what the tool does and implies when to use it (when deleting a project without affecting tenant prospects). However, it does not explicitly name alternatives or state 'use this instead of X.' The clarification about prospects suggests a boundary but doesn't offer explicit guidance on choosing between this and other delete 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?

With no annotations provided, the description carries full burden. It discloses permanence ('permanently delete'), workspace-wide scope, skip conditions, and a side effect (reports organizations left with no prospects). This is highly transparent.

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 two sentences, front-loaded with the action and constraints, and contains no unnecessary words. Every word contributes to understanding the tool's purpose and edge cases.

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 tool with one parameter and no output schema, the description covers purpose, scope, exclusions, preview step, and side effects. It is sufficiently complete for an agent to invoke correctly.

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

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

The schema fully constrains the single parameter prospectIds (array of integers, max 200). The description adds 'by id' and 'max 200', but those duplicate schema constraints; no significant new meaning beyond the schema is provided.

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

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

The description clearly states the tool permanently deletes prospects by ID with a maximum of 200, workspace-wide. This distinguishes it from sibling delete tools like delete_project and delete_organizations, and the preview reference adds context.

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

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

It explicitly recommends previewing with list_project_prospects before deleting, which is an alternative. It also notes skipped categories (do-not-contact, outreach history, 2+ projects), helping the agent decide when the tool is appropriate, though it doesn't contrast with softer alternatives like skip_prospect.

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

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

With no annotations provided, the description carries full burden and reveals meaningful behavioral details: it only deletes pending_review rows, silently skips other statuses, returns the deleted count and skipped ids. It does not mention irreversible nature but 'delete' is explicit and the status-filtering and return-value disclosure is good.

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: first states the action and both modes, second clarifies scope/exclusion, third states return values and preview workflow. Every sentence earns its place; no redundant 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 deletion tool with no annotations or output schema, the description covers invocation mode, scope, exclusions, return value, and preview alternative. Missing minor details like whether projectId matches exact prefix or exact name, but the critical operational facts are present.

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 both ids and projectId described, so baseline credit applies. The description adds that ids/projectId are 'mutually exclusive' (also in schema descriptions) and confirms the ids represent outreach log ids, matching the schema. It doesn't need to add syntax because the schema already covers both 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?

The description uses a specific verb ('batch-delete') with a clear resource ('pending_review drafts') and explicitly distinguishes two invocation modes (by ids or by projectId). It also differentiates from sibling delete tools like delete_project and delete_prospects by scoping to drafts, and even points to list_drafts for preview.

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

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

It explicitly states when to use this tool (batch-delete pending_review drafts) and describes exclusionary behavior ('only pending_review rows are deleted; any other status silently excluded'). The note 'Preview with list_drafts' gives a clear workflow and alternative for dry-running before deletion.

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

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

With no annotations, the description carries the full burden. It discloses that it reports readiness status, defines 'incomplete' precisely with the missing fields, and states the downstream 412 consequence. This is transparent for a read-only check, though it doesn't mention side effects or permissions.

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?

Single sentence, front-loaded with the core purpose, then provides essential detail about the incomplete condition and downstream actions. No waste.

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

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

For a tool with no parameters and no output schema, the description fully explains what it returns (ready/incomplete with unset fields) and why it matters. It is complete for its simple scope.

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

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

There are zero parameters, so the baseline is 4. The description doesn't need to explain parameters, and it correctly focuses on output semantics instead.

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

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

The description clearly states the tool's purpose: 'Pre-flight compliance check for outbound.' It specifies what it reports (ready or incomplete) and the specific fields checked, distinguishing it as a pre-condition checker for outbound actions.

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

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

The description implies when to use this tool by calling it a 'pre-flight check' and noting that send_email_and_record and record_outreach_with_inquiry refuse with 412 if incomplete. This gives clear context for usage, though it doesn't name alternative check tools or explicit exclusions.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a behavioral trait: it returns the latest version, not a specific historical version. But it does not mention return format, not-found behavior, or any read-only guarantees. Since 'get' implies a fetch, this is a minimal but acceptable disclosure.

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

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

A single sentence that is front-loaded and contains no filler. Every word contributes to meaning: 'Get', 'latest version', 'project document', 'by slug'.

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

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

The tool is simple with two well-documented parameters, so the description is mostly complete. However, there is no output schema and the description does not explain the return shape or behavior for missing documents. Sibling context shows document-related tools exist, but the description doesn't clarify how this differs from get_master_document.

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 slug and projectId have useful descriptions in the schema. The tool description adds no extra parameter semantics, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Get the latest version of a project document by slug.' It clearly identifies the target resource (project document), the action (get), and the key parameter (slug). It also distinguishes from siblings like list_documents and get_master_document through 'latest version' and 'by slug.'

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 context is implied via 'by slug' and 'latest version' — the tool is for targeted retrieval of a specific document version. However, there is no explicit guidance on when to choose this over related siblings such as list_documents or get_master_document, and no alternatives are 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?

With no annotations, the description carries the full burden and discloses important behavioral nuances: mature-send windows, bounce metrics spanning all sends, reply rates excluding bounces/auto-replies, and the threaded-only lower-bound nature of per-bucket bounces. It does not mention return format, permissions, or rate limits, but the counting semantics are unusually well specified.

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 and runs on as one long sentence with multiple parenthetical asides, making it hard to scan. However, nearly every clause carries substantive information about metric definitions, so the length is not padded with 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 complex metrics tool with no output schema and no annotations, the description covers many metric fields, bucket definitions, and counting caveats, including the maturity-window distinction and null provenance bucket. It stops short of describing the exact return shape or the data-sufficiency check outcome, but overall coverage is strong relative to complexity.

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

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

The single parameter projectId is already fully documented in the schema with 100% coverage, so the description does not need to add parameter syntax. The project-scoped context is implicit in the schema and the description adds no extra parameter-specific meaning.

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

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

The description opens with 'Evaluation statistics for a project' and enumerates specific metric families (response rates, channel performance, sentiment breakdown, targeting axes), making the tool's resource and output scope clear. It is clearly distinguishable from sibling tools like get_outbound_targets or get_mailbox_health.

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

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

The description implies usage when project evaluation statistics are needed, but it never explicitly states when to choose this tool over alternatives or lists exclusions. There is no mention of prerequisites, typical scenarios, or 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It clearly indicates this is a read-only status query and enumerates the data returned, but it does not mention authentication, rate limits, or error behavior. This is adequate for a simple status tool but not rich.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and lists the exact pieces of information returned. Every word earns its place; there is no wasted 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?

This is a low-complexity tool with no parameters and no output schema. The description sufficiently explains the return values (connection status, address, revocation) and overall behavior, making it complete enough for an agent to select and 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?

The tool has zero parameters, so there is no parameter semantics to explain. Per the rubric, a baseline of 4 is appropriate when no parameters exist.

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

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

The description clearly identifies the tool as a status check for the current user's Gmail connection, specifying the scope (gmail.send), connected address, and revocation status. It is specific but does not explicitly differentiate from siblings like get_mailbox_health.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as get_mailbox_health, nor any prerequisites or exclusions. Usage context is only implied by the nature of a status check.

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

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

With no annotations, the description carries the full burden and does so richly: it states read-only behavior, newest-first ordering, per-entry composition, null semantics for pre-upgrade entries, and empty-state behavior until the tick runs. This far exceeds minimal behavioral disclosure.

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

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

The description is a single dense paragraph but front-loads the core purpose and then systematically enumerates entry fields. It is longer than minimal, but the complexity of the returned data justifies the detail; it remains organized and readable.

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

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

Given there is no output schema and the tool returns highly structured historical data, the description is remarkably complete: it covers ordering, field contents, null behavior, and empty-state semantics. No critical behavioral or return-value aspects are left obscure.

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%: projectId and days are both described in the schema. The tool description adds no parameter-level detail beyond the schema, so the baseline of 3 is appropriate.

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

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

The description opens with 'Read-only history of the project's daily lever-tick decisions, newest first,' which clearly identifies the verb (read/get), resource (lever-tick decisions), and scope (daily history per project). It differentiates from sibling tools like run_lever_tick and get_lever_state by emphasizing historical read-only access.

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

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

The description clearly establishes the tool's context: it is for inspecting past daily lever-tick decisions and explicitly notes 'Empty until the tick has run at least once,' setting expectations for when results exist. It does not explicitly name alternatives or provide when-not-to-use guidance, but the read-only history framing makes the appropriate use case clear.

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

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

With no annotations provided, the description must fully disclose behavior, and it does extensively. It explicitly states 'read-only', explains null/default states (null until first tick, {} until measured), and details how flags like needsReplenishment behave. This provides the agent with a clear understanding of side-effects and state semantics.

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 an extremely long single sentence with numerous nested parentheticals, making it difficult to parse. Although it is information-dense, it lacks structural breaks (e.g., bullet points, sentences) and buries key facts. This reduces readability and violates the principle of front-loading with concise scannable text.

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

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

Given the tool's complexity (many state fields, relationships to other operations), the description is exceptionally complete, covering all reported state elements and their meanings. It even explains how the discovery block connects to /build-list, add_prospects, and /evaluate. Since no output schema exists, the description carries the full burden of describing return content, which it does thoroughly.

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

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

The input schema has 100% parameter coverage with descriptions for both projectId and batchSize. The description does not add significant parameter-specific meaning beyond the schema; it mentions batchSize in context of batchPlan but the schema already describes it. Therefore 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?

The description opens with 'Read-only snapshot of the project's outbound optimizer', clearly identifying the tool's purpose and immediate read-only nature. It enumerates the specific state components (draw weights, channel affinity, targetingLifts, discovery block, etc.), distinguishing it from sibling tools like run_lever_tick (which executes a tick) and get_lever_decisions (which retrieves decision records).

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

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

The description clearly implies the tool is for inspecting the current state of the optimizer, contrasting indirectly with actions like running a tick or registering strategies. However, it does not explicitly state 'use this when you need to view the optimizer state' or exclude specific alternatives, so it falls short of full explicit guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It is transparent about what the tool returns (mailbox email, warmup ramp, cap, used, remaining, pause, bounce rate), the reset time (UTC midnight), the scope (email sends only), and the edge case of a no-mailbox state. It also clarifies the bounce rate is a 'threaded-only lower bound', which is a useful nuance. It doesn't explicitly state read-only, but the 'get' nature implies it, and no side effects are mentioned.

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

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

The description is a single, well-structured paragraph that front-loads the primary purpose and then enumerates the return fields. It is concise but information-dense, covering all necessary details without redundancy. Every sentence adds value, and the length is appropriate for the complexity of the tool.

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

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

Since there is no output schema, the description must explain the return values, and it does so thoroughly: mailbox email, warmup ramp or fixed cap override, today's cap/used/remaining, pause status, and 30-day bounce rate, plus the no-mailbox state. It also provides relevant context like reset timing and the separate quota distinction, making it fully self-sufficient for an agent to understand expected outputs and behavior.

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

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

The input schema fully documents the single parameter projectId with a clear description ('Project name or ID'). Since schema description coverage is 100%, the baseline is 3. The tool description does not add any additional meaning to the parameter itself, but it doesn't need to because the schema covers it; the description focuses on the return value context instead.

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

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

The description clearly states the tool retrieves mailbox health state, listing specific data points like warmup ramp, daily cap, used/remaining, bounce rate. It uses a specific verb 'get' with a well-defined resource 'mailbox health', and it implicitly distinguishes itself from sibling tools like get_gmail_status and get_lever_state by focusing on per-mailbox sending limits.

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

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

The description provides context on when to use the tool by explaining it covers the mailbox used for sending, and explicitly notes the daily cap is separate from the plan/billing outreach quota, which helps avoid confusion with other quota-related tools. However, it doesn't explicitly name alternative tools or state dedicated 'when to use' versus 'when not to use' guidance.

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

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

Given no annotations, the description carries the burden of transparency, and 'Get' clearly signals a read-only operation. It adds the qualifier 'shared,' which hints at the resource type, but does not disclose what the response contains, any required permissions, or potential error conditions—adequate for a simple getter but not detailed.

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

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

The description is a single, front-loaded sentence with no filler or redundant phrasing. Every word contributes meaning, making it exceptionally concise and easy to parse.

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 operation with no output schema or annotations, the description provides the essential 'what' and 'how.' However, it omits any indication of the returned document structure or format, leaving the agent to infer the response shape—acceptable for a simple tool but not fully complete.

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

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

The schema provides 100% coverage for the single 'slug' parameter, including an example, so the description's 'by slug' adds no new semantic information. The description reinforces the parameter's role but does not go beyond what the schema already states, earning the baseline 3.

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 uses a clear verb ('Get') and explicitly names the resource ('shared master document') and retrieval method ('by slug'), which sets it apart from the generic get_document sibling. However, it does not explicitly contrast itself with get_document or list_master_documents, so it stops short of a perfect 5.

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

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

The description implies usage: the agent should call this when a master document's slug is known. It provides no explicit when-not-to-use guidance or reference to alternatives like get_document or list_master_documents, so the context is only implied.

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

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

The description discloses internal logic such as the use of a measured targeting priority, random exploration for a share of batches, server-side filtering by enabled channels and country, and the structure of the output (reachable total, split, mode, quota). This goes well beyond any annotations (none provided).

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

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

The description is a single dense paragraph covering multiple aspects (ordering, filters, output details). It is not overly verbose but conveys a lot of information efficiently. Well-structured despite length.

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

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

Given there is no output schema, the description compensates by detailing the return format (reachable total, split, mode, quota, and prospect fields). It also explains query parameters' effects and filtering logic, making it fairly complete for a get operation.

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

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

The input schema already provides descriptions for both parameters (limit and projectId). The tool description does not add significant extra meaning to these parameters beyond what is already in the schema, though it does imply their role in the overall process. Baseline is 3 due to full schema coverage.

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

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

The description clearly states that the tool retrieves prospects due for outreach, specifying ordering, filtering, and output details. It distinguishes itself from sibling tools by detailing its unique behavior (priority-based ordering, random exploration, server-side filters).

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

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

The description explains the tool's behavior (e.g., how prospects are ordered and filtered) but does not explicitly state when to use it over alternatives or provide when-not-to-use guidance. The context is implicit, but no explicit usage comparisons are made.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly states this is a read operation returning JSON, explains that unset fields revert to column defaults, and specifies a 404 error for missing projects. This is valuable contextual information beyond the bare operation.

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 two sentences: the first states the purpose and lists return fields, the second explains default behavior and error case. There is no redundant information, and the key details are front-loaded. Every sentence contributes value.

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

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

For a simple getter with one parameter and no output schema, the description is comprehensive. It specifies the return format (JSON), lists the contained fields, explains defaulting behavior, and handles the error case. No additional information is necessary for an agent to use the tool correctly.

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

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

The schema already describes the single parameter 'projectId' as 'Project name or ID', achieving 100% schema coverage. The description does not add further parameter-specific details, but the baseline score of 3 is appropriate given the high schema coverage. The description implies the parameter identifies the project to fetch settings for.

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

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

The description clearly identifies the tool as retrieving user-editable project settings, listing specific fields and distinguishing it from the sibling update_project_settings by focusing on the read aspect. It uses a specific verb 'get' and resource 'project settings', with a clear scope of what is returned.

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

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

The context is clear: this is the read-only counterpart to update_project_settings. While it doesn't explicitly state when to use this versus alternatives, the purpose is unambiguous and the tool is a natural getter for project settings. It provides no exclusion criteria but sets expectations about defaults and error handling.

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

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

No annotations are provided, so the description must carry the burden. It clarifies the filtering behavior and lists included fields, but does not specify any additional behavioral aspects like authentication, rate limiting, or how 'recent' is determined. It's not misleading but could add more context about the returned data's scope.

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 concise, front-loads the main purpose, and includes necessary detail about exclusions and output fields without unnecessary fluff. Each sentence adds value.

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

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

Given the tool has only 2 parameters, no output schema, and no annotations, the description provides a solid overview of behavior, exclusions, and output fields. It is sufficient for a straightforward read operation, though it could mention how 'recent' is defined or any default ordering.

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

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

The schema covers 50% of parameters with projectId having a description, but limit is unexplained. The description does not elaborate on either parameter, relying on the schema. Since the description does not add meaning beyond what the schema provides, and the coverage is partial, this is a gap.

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

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

The description clearly states it retrieves recent outreach logs for a project, and explicitly distinguishes itself from list_drafts by noting that it only includes confirmed events and excludes pending_review and pre_send rows. This differentiates it from sibling tools like list_drafts.

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

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

The description provides explicit guidance on when to use this tool (for confirmed outreach events) and points to an alternative (list_drafts) for excluded statuses. This directly helps the agent decide between get_recent_outreach and list_drafts.

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

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

With no annotations, the description carries the burden. It explicitly states 'Read-only view' and explains that deferral/prospect creation happen elsewhere, which is transparent about side effects. It could mention pagination or performance, but for an aggregation summary, this is adequate.

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 two sentences long, focuses only on key details, and is front-loaded with the core action. Every word adds value—no fluff.

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?

Although there is no output schema, the description lists the return fields (primaryReasonDistribution, tactical fields, pmf field). This covers the main expected result. It does not explain edge cases like empty results, but the read-only nature and field details are sufficient for a summary 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 parameters are documented in the schema. The description does not add extra meaning beyond what schema already explains, but it does mention the output fields, which are not parameters. 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?

The description clearly states the action: 'Aggregate rejection_feedback for a project' and lists the specific output fields. This is specific and distinguishes from siblings, though no sibling does the same thing. It's a clear verb+resource+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?

The description sets context by noting it's a read-only view and clarifies that side effects occurred at record_response time, not on read. This guides usage for reading aggregated feedback. However, it doesn't explicitly mention when to prefer this over alternatives, though no similar tool exists.

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

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

No annotations are provided, so the description carries the burden of behavioral transparency. It states that the tool 'Returns' data, implying a read-only operation with no side effects. While it doesn't explicitly mention side effects or lack thereof, the nature of the operation (fetching version info) makes it safe to assume no modifications occur. This is adequate for a simple getter.

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

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

The description is a single, concise sentence that directly states the tool's output. It uses clear language ('Returns { serverVersion, minPluginVersion }') without any superfluous information. Every word serves a purpose, making it highly efficient.

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

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

Although no output schema is provided, the description explicitly lists the return fields (serverVersion and minPluginVersion), giving users a complete picture of what to expect. This is sufficient for a tool with such a simple output. No additional context is required for understanding the tool's behavior or result.

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

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

The tool has zero parameters, and the schema coverage is trivially 100% (no parameters to document). The description does not need to elaborate on parameters. Per the rubric, with high schema coverage and no parameter info, a baseline score of 3 is appropriate. The description adds no parameter-related details because none are needed.

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

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

The description clearly states the tool's purpose: it retrieves the server version and minimum plugin version for the LeadAck backend MCP server. The verb 'Returns' specifies the action, and the resource (server version) is unambiguous. It is distinct from sibling tools, none of which appear to fetch version information.

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

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

The description conveys the tool's function without explicit guidance on when to use it. Since it is a simple getter with no alternatives, the context is implied. However, it lacks explicit 'when not to use' or comparison with other tools, though the simplicity of the operation makes it clear it should be called when version information is needed.

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

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

With no annotations, the description must carry the behavioral burden. It does well by stating the tool returns specific fields and a readiness status, and by disclosing the downstream gating behavior (412 refusal). It does not explicitly state 'read-only' or 'no side effects', but 'Returns' strongly implies 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?

The description is one dense sentence that conveys the resource, the specific fields, the additional status output, and the behavioral consequence of the gate. No filler or redundant wording; it 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?

Given no parameters and no output schema, the description does a good job telling the agent what the tool returns and why it matters. It misses an explicit differentiation from the sibling get_compliance_status, but the field-level detail and gate explanation make the tool's purpose sufficiently complete.

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

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

The tool has zero parameters, so there is nothing to explain. Based on the rubric, 0 params earns a baseline of 4. The description adds no parametric semantics, but none are needed.

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 uses a specific verb ('Returns') and names the exact resource ('workspace identity/compliance fields') plus its output ('readiness status line'). It clearly distinguishes itself from generic getters by specifying the field names and the outbound gating behavior.

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

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

The description implies strong usage context: check these settings before sending outbound, as send tools refuse 412 until all three fields are set. It does not explicitly exclude or name alternatives like get_compliance_status, but it provides clear context for when the tool's output is needed.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it succeeds thoroughly. It exposes the one-way doNotContact ratchet, domain-only skip behavior, overwrite re-linking semantics, and the complete return payload including skippedDetails and errorDetails.

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 every clause carries necessary information: input format, output fields, dedup policy semantics, edge cases, and limits. There is no filler or repetition of schema trivia; it is front-loaded with the core action and resource.

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 tool with no annotations and no output schema, this description is remarkably complete. It documents return fields, error/skip details, dedup edge cases, the doNotContact ratchet, and the max row count; only the exact CSV column contract is left to the 'canonical' term, which is a reasonable shared assumption.

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 67%, and the description substantially enriches the dedupPolicy parameter by explaining exactly how 'overwrite' matches prospects and why domain-only matches are skipped. It also adds the meaning of 'canonical CSV string' and the significance of omitting projectId, going well beyond the schema's enum and minLength.

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 clause states the operation precisely: 'Import prospects from a canonical CSV string.' It clearly distinguishes this bulk-import tool from sibling tools like add_prospects or list_tenant_prospects by focusing on CSV ingestion, dedup policy, and import results.

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

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

The description gives strong situational context: it explains dedupPolicy behavior, tenant-only behavior when projectId is omitted, and the 1000-row limit. It does not explicitly name alternatives such as add_prospects for non-CSV or single-prospect scenarios, so exclusions are implied rather than stated.

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

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

With no annotations provided, the description carries full burden. It discloses key behaviors: it links existing prospects, skips do_not_contact or not-found prospects, and returns counts with per-prospect reasons in skippedDetails. This gives the agent a clear picture of side effects and expected behavior, though it omits permission requirements or potential irreversible changes.

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

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

The description is a single, information-dense sentence that front-loads the purpose and includes all essential behavior and return summary. There is no filler or redundancy; every clause adds value.

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

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

Given the tool's moderate complexity (two parameters, one an array of objects) and no output schema, the description adequately covers the main behavior, return counts, and skipping logic. It notes skippedDetails for per-prospect reasons, which is helpful. It could mention error handling for invalid projectIds or further shape the skippedDetails structure, but the description is reasonably complete for an agent to use correctly.

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

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

Schema coverage is 50%, with descriptions for projectId and matchReason in the schema itself. The description adds meaning to prospectId by stating it must reference existing prospects and that certain ones are skipped, but it does not elaborate on the priority field or the structure of the links array beyond what the schema already covers. It adds some value but does not fully compensate for the coverage gap.

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

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

The description clearly states the action: linking existing tenant prospects to a project, and explicitly distinguishes from creating new prospects or organizations. It also mentions the skipping behavior and return counts, making the purpose unambiguous and distinct from siblings like add_prospects.

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

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

The description clarifies that this tool does NOT create new prospects or organizations, which implicitly tells users to use this when they have existing prospect IDs. It also notes that do_not_contact or not-found prospects are skipped, providing context on when results may be partial. However, it does not explicitly name alternative tools or contrast with add_prospects or import_prospects_from_csv.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It covers the return shape and the semantics of sendAllowed, including that non-allowed codes 'store but are blocked at send time.' This is valuable behavioral context beyond the bare tool name.

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 with no filler. The first sentence states what the tool lists; the second explains the return object and the key behavioral distinction. Every word contributes.

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

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

For a zero-parameter, reference-style tool with no output schema, the description is complete: it names the standard, the domain, the exact return fields, and the meaning of sendAllowed. The agent has enough information to invoke and interpret this tool correctly.

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

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

The input schema has no parameters, so the baseline is 4. The description correctly avoids inventing parameter details and instead provides output semantics. Its mention of the 'country' context is useful but not a parameter definition.

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 uses a specific verb ('Lists') and a precise resource ('ISO 3166-1 alpha-2 country codes LeadAce recognizes'), with additional scope defined as 'for a prospect/organization country.' This is clearly distinct from any sibling tool in the set.

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

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

The description provides clear context for when this tool is relevant: when working with country values for prospects/organizations. It also explains the meaningful distinction between sendAllowed and blocked codes, which helps the agent decide how to use the results. No explicit alternatives or exclusions are given, but no competing sibling tool exists.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only listing but does not clarify any side effects, pagination, sorting, or permission requirements. The minimal information does not add behavioral insight beyond the action itself.

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

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

The description is a single, clear sentence that conveys the core action and output immediately. No redundant phrasing or unnecessary detail.

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

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

The tool is simple with one parameter and no output schema. The description gives the essential purpose and hints at the returned data (timestamps), but omits details like whether output includes document names, pagination limits, or how to interpret the list. Adequate for a basic list, but not fully complete without an output schema.

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

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

Schema description covers 100% of the single parameter (projectId). The description adds no extra semantic detail about the parameter beyond what the schema already provides, but it does clarify the context (documents for a project). 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?

The description clearly states the action (list all documents) and the object (documents for a project), and mentions the included data (last updated timestamps). However, it does not explicitly distinguish itself from sibling tools like list_master_documents, leaving slight ambiguity about 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?

No guidance on when to use this tool versus alternatives such as list_master_documents or get_document. No mention of prerequisites or typical use cases beyond the basic action.

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

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

No annotations are present, so the description carries the burden. It discloses output shape (total, rows, truncated bodyPreview), sorting order, and the important doNotContact behavior with blocked sending. It omits auth/permission details, but those are not critical for a simple read/list operation.

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 focused sentences: the first front-loads the purpose and ordering, the second adds return-shape detail and a behavior-critical warning. Every sentence earns its place with no repetition of schema 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 simple list tool with no annotations and no output schema, the description covers the essential behavior: scope, ordering, return elements, and a critical filtering caveat. A small gap is that pagination behavior isn't explicitly tied to limit/offset, though the schema defaults mitigate 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 description coverage is only 33% because projectId is the only parameter with a description. The description adds no detail for limit or offset, leaving their semantics entirely to schema names and defaults, so it fails to compensate for the low coverage.

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?

Clearly identifies a specific verb+resource: lists pending_review drafts for a project, newest first. It distinguishes itself from sibling tools like list_documents and discard_drafts by scoping to the draft review workflow.

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

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

Provides clear context: the tool is the drafts-listing entry point, and it explicitly instructs how to handle doNotContact rows — discard them because sending is blocked. It doesn't name alternatives or when-not-to-use scenarios, so it doesn't earn a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'List all available master documents', implying a read-only operation but never explicitly stating safety, output format, or side effects. The phrase 'all available' adds scope but not enough behavioral context.

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

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

The description is a single front-loaded sentence that immediately states the action and object, followed by a clarifying parenthesis. No wasted words or redundant 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 zero-parameter, no-output-schema list tool, the description is minimally viable. It tells what is listed and what qualifies as a master document, but it omits any mention of the return structure, potential volume, or distinction from closely related sibling tools like 'list_documents' and 'get_master_document'.

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

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

The tool has zero parameters, so the schema is trivially 100% covered. The description adds useful domain context about what counts as a master document, but since there are no parameters to describe, a baseline of 4 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?

The description states a clear verb ('List') and a specific resource ('master documents'), with a parenthetical clarifying the resource as templates, guidelines, and frameworks. It is unambiguous in what it does, but it does not explicitly differentiate from the sibling tool 'list_documents', leaving potential confusion about when to use which.

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

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

No usage guidance is provided. The description does not mention when to use this tool versus alternatives like 'list_documents' or 'get_master_document', nor does it give any contextual prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses meaningful behavior: it reports active/archived counts, then returns variants as a JSON array with specific fields and ordering by createdAt asc. It does not discuss auth or rate limits, but for a simple read-only list the disclosed behavior is clear.

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

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

The description is a single, front-loaded sentence: it states the purpose first and then gives compact output details. There is no filler or redundancy.

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

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

This is a simple one-parameter read tool with no output schema, and the description sufficiently compensates by specifying the output shape, fields, counts, and ordering. Any missing detail like empty-result behavior is minor for this tool's simplicity.

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

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

The schema already fully documents the only parameter, projectId, with the description 'Project name or ID'. The tool description adds no additional parameter semantics beyond restating project scope, 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 uses a specific verb ('List') and a clear resource ('the project's message-angle variants'), and it distinguishes itself from sibling operations like upsert_message_variant and pick_message_variant by focusing on enumeration. The scope is explicit: project-level variants.

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: this tool is for listing message-angle variants for a project. However, it does not explicitly state when to use it instead of pick_message_variant or upsert_message_variant, nor does it mention any exclusions or prerequisites beyond a projectId.

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

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

No annotations, so the description carries the burden. 'List' implies a read-only operationcars, and it discloses output characteristics (employee-size band, counts, DNC marking). However, it doesn't explicitly state side-effect-free behavior or potential performance implications, but for a simple list it's adequate.

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 concise sentence that's front-loaded with the action and resource, immediately followed by key output details. No fluff, easily scannable.

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 list tool, the description captures the essential return values. It doesn't mention pagination exactly but the schema covers defaults. It doesn't discuss edge cases like empty results or performance, but overall it's adequate for an agent to use correctly.

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

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

The description doesn't explain the query parameter q's behavior beyond schema's 'substring' hint. It adds no context for limit/offset, which are self-explanatory. Since schema coverage is only 33%, the description should compensate but doesn't. The user isn't guided on how to filter or paginate effectively.

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 the exact action ('List') and resource ('organizations'), plus what's included (employee-size band, counts, DNC marking). It clearly distinguishes from other list tools (e.g., list_projects) and conveys the scope (tenant-level).

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

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

The description implies when to use (when you need an overview of organizations with counts and DNC status) but doesn't explicitly contrast with alternatives or state exclusions. It's clear enough for an agent to pick this for listing orgs, but doesn't mention not to use it for filtered prospect searches, for example.

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

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

With no annotations, the description carries the burden. It discloses sorting order (priority ascending, newest first within rank) and full status coverage, which are key behavioral traits. It does not mention read-only or pagination details, but 'list' implies non-mutating, and adding more might bloat the description.

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 concise sentences: purpose, differentiation, and sorting. No fluff, key information 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?

Given no output schema, the description compensates by naming key output fields (status, priority, matchReason) and conveying the filtering/sorting behavior. It lacks explicit mention of pagination default or search fields, but the schema covers those. For a list tool with moderate complexity, this is complete enough.

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 67%, and the description does not add extra meaning to parameters beyond what the schema already provides. The schema descriptions for q, status, priority, and projectId are informative; limit/offset are self-explanatory from names and bounds. The description's mention of status and priority refers to output fields, not parameter usage, so it adds limited semantic value.

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

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

The description clearly states the tool lists a project's prospects with status, priority, and matchReason. It explicitly distinguishes itself from get_outbound_targets, making its purpose and scope unambiguous.

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

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

The description provides explicit guidance by contrasting with get_outbound_targets: use this tool for prospects in any status, while the sibling lists reachable rows only. This clarifies when to choose one over the other.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly implies a read-only operation but does not mention any side effects, authentication requirements, pagination, or whether the list includes all project details or just summaries. It is not misleading but lacks additional context.

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

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

The description is a single, concise sentence that states the action and scope with no superfluous words. It is front-loaded and to the point, earning a perfect score for conciseness.

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

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

For a simple listing tool with no parameters and no output schema, the description covers the basic purpose but does not specify the return format, whether archived projects are included, or any ordering/filtering. It is minimally adequate but lacks completeness given that the agent has no other clues about the output structure.

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

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

With zero parameters, the description needs to explain no parameter semantics. It does mention the implicit scope 'current user' which defines the context of the operation. Since there are no parameters, a baseline of 4 is appropriate given the description adds the only relevant semantic detail (user scope).

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 'List all projects for the current user' clearly identifies the action (list), resource (projects), and scope (current user). It is distinct from sibling tools like delete_project or setup_project, making its purpose unambiguous.

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

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

The description implies when to use it (when you need a list of projects), but it does not explicitly mention when not to use it or suggest alternatives from the sibling set. There is no guidance on how it differs from other list tools like list_documents or list_organizations, so the usage context is only implicit.

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

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

No annotations are provided, so the description carries the burden. It describes a read operation ('List persisted suggestions') and indicates it returns all suggestions by default, with an optional filter. It doesn't mention pagination, ordering, or whether deleted suggestions are included, but it is a simple read 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 a single sentence that is compact and front-loaded with the core purpose. It lists the fields and the optional filter with no wasted words.

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

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

The tool is simple: two parameters, no output schema, and no nested objects. The description covers the purpose, fields, and filter. It is complete enough for an agent to know what to expect, though it could mention if there is a limit or ordering.

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%: projectId and status are both described in the schema. The description adds that status filter is optional and lists the status values, but it doesn't add much beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool lists persisted suggestions for a project and enumerates the returned fields. It distinguishes itself from siblings like record_suggestion (which creates) and list_documents, though it doesn't explicitly name alternatives.

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

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

It indicates the optional status filter and implies it is for reading suggestions in a project context. However, it does not provide explicit when-to-use or when-not-to-use guidance versus other list tools, but the context is clear enough.

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 discloses key behavioral traits: it excludes do-not-contact prospects and warns that results are truncated beyond the limit (no pagination). Since no annotations are provided, the description carries the full burden, and it covers the most important behaviors. It does not mention potential errors or response format, but these are not critical for a list operation.

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

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

The description is a single, succinct sentence that front-loads the main purpose and immediately follows with key behavior notes. It contains no redundant or extraneous information, making it highly concise and well-structured.

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

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

The description covers the core aspects: purpose, tenant-wide scope, exclusion of do-not-contact, and truncation behavior. It does not explicitly mention the filter parameters, but those are fully defined in the schema, which the description complements. For a list function, this is sufficiently 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?

All four parameters (q, limit, industry, excludeProjectId) have descriptions in the input schema, giving 100% schema coverage. The tool description itself adds no parameter-specific information, so it meets the baseline of 3 as per the rubric for high schema coverage.

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

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

The description clearly states the tool's function: 'List existing prospects across the entire tenant, excluding do-not-contact prospects.' It specifies the verb (list), resource (prospects), scope (entire tenant), and exclusion criteria, leaving no ambiguity about the tool's primary purpose.

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

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

The description implies usage by stating the scope and exclusions, and it provides a practical note about truncation ('No pagination — results beyond limit are truncated'), which guides users on setting limits. However, it does not explicitly contrast with alternative tools, though no direct alternatives for listing prospects exist among the siblings.

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?

Since there are no annotations, the description carries the full burden and does well: it discloses the weighted draw, the bypass behavior, silent fallback on unknown/archived variant IDs, and the NOT_FOUND return. It also describes what is returned (variant id, subject pattern, body approach, label) and the subtlety that body line is absent when no body exists. This is transparent and helps the agent anticipate edge cases.

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

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

The description is a single sentence that is information-dense but not overly long. It front-loads the primary purpose and packs important nuances (return values, NOT_FOUND, body line absence) into a compact form. It could be slightly improved by adding a comma after 'project' for readability, but it is still efficient.

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

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

For a tool with 2 parameters (100% schema coverage) and no output schema, the description covers the input semantics and return value details well. It also handles an important edge case (NOT_FOUND) and explains the optional bypass parameter. The absence of an output schema is mitigated by the explicit return values. This is nearly complete for the tool's complexity.

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

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

The schema already describes both parameters well (projectId as name/ID, variantId as specific active variant with pattern and fallback). The description adds the context of the weighted draw and the bypass semantics, which enriches the meaning of variantId. Since schema coverage is 100%, the description doesn't need to re-explain parameters but adds useful behavioral nuance.

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 ('Pick') and resource ('active message-angle variant') and clearly explains the server-side weighted draw mechanism. It also explicitly notes the return values and the NOT_FOUND case, which distinguishes it from sibling tools like list_message_variants.

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

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

The description clearly implies when to use this tool (when you need to randomly select an active variant) and mentions the optional variantId to bypass the draw. It doesn't explicitly name alternatives or when not to use it, but the sibling tools (like list_message_variants) are distinct enough that the intended use is clear.

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

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

With no annotations, the description fully carries disclosure of side effects. It clearly explains that 'sent' flips prospect status to contacted, stamps next_outreach_after = sentAt + noResponseRecycleDays, and gates inclusion in get_outbound_targets; it also clarifies that 'failed' and 'pending_review' have distinct downstream consequences.

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 packed with necessary behavioral detail in a single coherent paragraph, with no filler or repetition. Every clause contributes either a status transition or an alternative-routing hint, and the final sentence intentionally steers the reader to the sibling when appropriate.

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

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

Given the lack of annotations and output schema, the description covers all critical behavioral context: side effects, downstream target queues, recycle windows, prospect state changes, and channel-specific exceptions. This is sufficient for an agent to safely and correctly invoke the 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?

At 50% schema description coverage, the description compensates meaningfully by giving value-level semantics to 'status' and to the 'channel' such that form/SNS DM paths through the alternative tool. It does not explicitly describe body, subject, or prospectId in prose, but those are simpler text/integer fields and partially self-evident.

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

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

The description opens with a clear verb and resource: 'Record an outreach log entry', then defines behavioral distinctions for each status value. It distinguishes itself from record_outreach_with_inquiry by explicitly redirecting form/SNS DM submissions, which goes beyond vague purpose.

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

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

It explicitly states when to use the alternative tool: 'For form / SNS DM submissions, prefer record_outreach_with_inquiry.' The status walkthrough also gives implementable guidance for choosing between sent, failed, and pending_review based on intended state transitions.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses the returned fields, the two possible statuses based on mode, the requirement to resolve pre_send rows via update_outreach_status, the no-follow-up nature of pending_review, and the platform-channel footer exception.

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

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

The description is a single long sentence but is front-loaded with the core purpose and every clause adds substantive detail about behavior, return values, or follow-up requirements. It is dense rather than wasteful, though it could be broken into clearer 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?

Given there is no output schema and no annotations, the description does a good job explaining return values, status semantics, follow-up obligations, and footer behavior. It is not fully complete because it omits parameter semantics for several fields and does not mention error conditions or permissions, but it covers the most critical operational context.

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

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

Schema description coverage is only 33%, so the description must compensate for undocumented parameters. It does add meaning for channel (platform gets no footer) and body (footer appended), but it does not explain subject, prospectId, or variantId beyond what the schema already provides, leaving a significant gap.

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

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

The description opens with a specific verb and resource: 'Reserve an outreach log row for a form / SNS DM / platform channel before submission.' It clearly distinguishes this tool from send_email_and_record by explicitly stating that email should use the other tool, and it also conveys the unique pre-submission reservation role.

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

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

The description gives clear usage context: use before submission for form/SNS DM/platform channels, and explicitly directs email use to send_email_and_record instead. It does not explicitly contrast with the sibling record_outreach tool, so it misses a full when-not/alternatives comparison, but the provided guidance is still strong.

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

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

With no annotations, the description carries the full responsibility and excels by disclosing forced do_not_contact triggers (bounce, opt-out reasons, cap reached), cap-related recontact window behavior, and auto-creation of prospects via `decision_maker_pointer`. All significant side effects are transparently spelled out.

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?

Every sentence packs meaningful business logic, and the description is front-loaded with the core purpose. However, it is a dense single paragraph that could benefit from bullet points or breaks to improve scannability and comprehension.

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

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

The description covers the non-obvious conditional behaviors (bounce, cap, deferral, derived prospects) integral to using the tool correctly. Given no output schema, it stops short of describing return values or error handling, which is a minor gap given the tool's complexity.

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 only 50%, so the description must compensate, and it does thoroughly. It explains the meaning of `responseType` values (e.g., bounce forces DNC), the `rejectionFeedback` nuances (e.g., wrong_timing/budget leads to deferred status), and the role of `markDoNotContact` relative to forced behavior. This adds substantial value beyond the raw 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 clearly states 'Record a response (email reply, SNS DM, etc.) to an outreach' which identifies the action and resource, and it accurately distinguishes from related tools like `record_outreach` and `record_outreach_with_inquiry`. It also outlines primary side effects ('updates prospect status and marks do-not-contact'), making the tool's purpose unmistakable.

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

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

The description provides clear context about when to use the tool and detailed conditional logic (e.g., 'rejectionFeedback with wrong_timing/budget plus a recontact window sets status=deferred'). However, it does not explicitly compare with alternatives or state when not to use it, such as for outbound outreach, which would elevate it to a 5.

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

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

With no annotations, the description carries the full burden and addresses key behaviors: upsert semantics ('refreshes an open suggestion, never resurrects a dismissed/done one') and confirmation details (id, status, whether written or untouched). It does not cover permissions or side effects, but these are not critical for this 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 two sentences, front-loaded with the primary purpose, followed by a concise explanation of key behaviors. Every clause adds necessary information—no filler or repetition.

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

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

Given the lack of output schema and annotations, the description covers the essential aspects: purpose, dedup behavior, and the nature of the confirmation response. It does not explain return structure in detail, but it indicates what the confirmation reports, which is adequate for a straightforward write operation.

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 each parameter clearly described. The description adds value by explaining that 'kind + dedupeKey' drive the upsert logic, which the schema alone does not convey. This complements the schema without redundancy.

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

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

The description clearly states the tool's purpose: 'Persist an actionable suggestion for the user' with a specific verb and resource. It also differentiates from siblings like list_suggestions (read) and record_outreach (different resource) by noting the Web UI dashboard context and the 'user-only action' reservation.

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

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

Provides a clear usage criterion: 'Reserve for actions only the user can perform.' This tells the agent when to use it, distinguishing from system‑level actions. It does not explicitly name alternative tools, but the guidance is sufficient for the intended use case.

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

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

With no annotations provided, the description carries the full transparency burden. It does disclose a meaningful behavioral trait: the daily per-tenant cap and that exceeding it returns an error. However, it does not describe what happens on successful submission, expected response shape, or side effects, leaving notable gaps.

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

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

The description is a single sentence that front-loads the purpose and adds one crucial behavioral constraint. Every word contributes value, and there is no redundancy or 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 tool with four parameters, a nested object, and no output schema, this description provides the essential purpose and cap behavior but omits what the response looks like on success or failure. The schema fills in parameter details, so the description is adequate but not complete for an agent needing to interpret results.

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

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

The input schema already provides thorough descriptions for all four parameters, including enum meaning for category, suggested keys for context, and length constraints for title/body. The tool description adds no additional parameter-level semantics beyond the cap context, 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?

The description clearly states the tool's purpose: filing a bug, feedback, or idea about LeadAce. It uses a specific verb ('File') and identifies the resource, making the primary intent unambiguous. However, it does not explicitly differentiate from the sibling 'record_suggestion' tool, which may overlap in purpose.

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

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

The description implies when to use this tool (for bug, feedback, or idea submissions about LeadAce) and adds a key usage constraint (daily cap, error over cap). It does not provide explicit when-not-to-use guidance or mention alternatives, leaving the usage context only implicit rather than fully specified.

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

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

With no annotations, the description carries full responsibility for transparency. It discloses idempotency, return values (variant weights, archived variants), and flags (needsReplenishment), but the convoluted phrasing makes these behaviors less transparent than they could be.

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

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

The description is a single, extremely long sentence with repetitive jargon and unclear clause boundaries. It is not concise and would benefit from breaking into structured points, but it does at least follow a logical order of operations and return values.

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

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

The description covers core aspects: what the tool does, idempotency, and return values. However, the dense and repetitive language obscures some details, and the lack of an output schema adds burden, making it only moderately complete.

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

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

The schema provides a description for projectId ('Project name or ID'), achieving 100% coverage. The tool description does not add further semantic detail beyond reinforcing that it operates on a project, so the baseline of 3 is maintained.

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

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

The description clearly states the tool's purpose: 'Run the project's daily outbound-optimization tick' and elaborates on the actions performed. It differentiates from siblings by focusing on the daily optimization routine, though the verbose explanation slightly obscures the core purpose.

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

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

The description mentions idempotency per UTC day, implying it should be run once daily, but does not explicitly state when to use this tool versus alternatives. No comparative guidance is provided, leaving the agent to infer appropriate 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?

No annotations are provided, so the description carries the full burden. It discloses the immutability and versioning behavior, which is critical for an agent to understand the side effects. However, it doesn't mention any permissions or error conditions, but the core behavioral trait is well 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?

The description is a single, concise sentence that front-loads the action and key behavior. Every word adds value, and it is appropriately sized for the tool's complexity.

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

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

Given the tool's moderate complexity (3 params, no output schema), the description covers the essential behavior (immutable versioning) and the schema covers parameters. It could mention what happens on success (e.g., returns version info) but that is not required since no output schema exists. The description is complete enough for an agent to use 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 all three parameters. The description adds the context that content is full markdown and slug has specific allowed values, but these are already in the schema. The description doesn't add significant extra 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?

The description clearly states the action (save a project document by slug), the resource (project document), and the key behavior (creates a new immutable version, preserving prior versions). It distinguishes from siblings like get_document and list_documents by focusing on the save operation.

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

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

The description implies when to use (when you need to save a document version) but does not explicitly state when not to use or mention alternatives. It doesn't clarify if this is for creating new documents or only updating existing ones, which could be ambiguous.

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

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

With no annotations available, the description carries the full burden of behavioral disclosure. It clearly states the side-effecting send behavior, the connected Gmail account, the lack of logging, and the returned identifier. It does not mention auth prerequisites or possible delivery failures, but the core behavioral contract is well 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?

The description is two sentences with no filler. It front-loads the action and important distinction, restates the logging trade-off, gives the return value, and points to the sibling tool for an alternative use case.

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?

This is a side-effecting email tool with no output schema, and the description covers the essential output identifiers. It is somewhat limited by the lack of parameter semantics, but for an otherwise standard 6-parameter email call, the situational context is easy for an agent to grasp.

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

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

Schema description coverage is 0%, and the description adds no parameter-level meaning. While names like to, cc, and bcc are conventional, the description does not clarify inReplyTo usage, message body formatting, or how the parameters relate to the Gmail API request.

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: 'Sends an email via the connected Gmail account', and immediately distinguishes itself from send_email_and_record with the 'without recording an outreach log' trait. It also states the return value, which further clarifies the tool's purpose.

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

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

It gives explicit alternatives and exclusions: 'For prospect outreach use send_email_and_record instead.' This tells an agent exactly when not to use the tool and names the preferred sibling, which is strong usage 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?

No annotations are provided, so the description carries the full burden. It clearly discloses side effects (email send, outreach log) and conditional behavior based on outboundMode. It also discloses the return information (sent/drafted status, From address on send). It omits potential failure modes or authorization requirements, but for a typical send+record tool, this is adequate.

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

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

The description is a single, information-dense sentence. It front-loads the primary action ('Sends... records') and then adds critical behavioral conditions (outboundMode) and return values. No filler or redundancy.

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

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

The description explains the tool's purpose, the conditional behavior (send vs draft), and the return information (status, id, From address). It doesn't detail error cases or prerequisites (like mailbox setup), but it is sufficient for common usage. It also differentiates from siblings like send_email and record_outreach by emphasizing the combined one-call action.

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

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

The schema covers only 2 of 5 parameters (projectId and variantId have descriptions). The tool description does not explicitly explain the parameters, but it implies prospectId is used to resolve the email address and subject/body are the email content. It adds some semantic context (e.g., 'address stored on the prospect') but doesn't fully compensate for the low schema coverage.

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

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

The description clearly identifies the action ('Sends a prospect email... and records the outreach log') and specifies the resource (prospect email and outreach log). It distinguishes from sibling tools like send_email and record_outreach by emphasizing the combined one-call behavior, and notes outboundMode conditional behavior.

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

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

The description indicates the tool is used to both send and record in one call, implying when to use it. It also mentions the outboundMode condition, which gives context on when it sends vs. drafts. However, it does not explicitly exclude alternatives like using send_email and record_outreach separately, or mention when to choose this over other siblings like record_outreach_with_inquiry.

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

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

No annotations exist, so the description must carry transparency. It explains the behavioral consequence (exclusion from re-discovery and outbound targeting) but does not disclose that setting the flag to false clears it, nor any auth requirements or side effects beyond the targeting effect. Partial transparency.

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

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

Two concise sentences, front-loaded with the action and then the consequence. No waste.

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

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

For a simple two-parameter tool, the description covers the main effect but does not explain what happens when doNotContact is false (though schema does), nor any error conditions or permissions. It's adequate but not rich.

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

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

Schema coverage is 50% (only doNotContact has a description). The tool description clarifies that the prospect is a 'tenant prospect', giving some meaning to prospectId, but does not elaborate further. It doesn't add details about doNotContact beyond the schema. Overall, marginal additional value.

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

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

The description clearly states the action ('Set the do_not_contact flag') and the target ('on a tenant prospect'), and explains the consequence (excluded from re-discovery and outbound targeting). This is specific and distinguishes the tool's purpose from siblings like 'skip_prospect'.

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

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

The description provides context on the effect of setting the flag (exclusion from re-discovery and targeting), implying usage when exclusion is desired, but it does not explicitly mention alternatives or when not to use it. This is an implied rather than explicit guideline.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It explains the priority scale, that the value is a per-prospect operator override independent of status, that measured targeting outranks priority after data accrues, and how to read the current value. This goes well beyond a basic 'sets priority' statement.

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 compact, front-loaded, and every sentence earns its place: first defines the operation, second provides key semantic behavior, third tells the agent how to verify the result. No filler or redundancy.

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

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

For a simple setter with three required parameters and no output schema, this description is reasonably complete. It covers the tool's effect, priority ordering nuance, and a readback path. It could still mention whether the value is permanent or reversible, but this is not a major gap given the tool kind.

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 low (33%), but the description compensates partly by defining the priority meaning ('1=highest') and clarifying that prospectId refers to one prospect within a project. The projectId parameter already has the schema description 'Project name or ID', while prospectId is left mostly to inference, so the compensation is incomplete.

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 uses a specific verb and resource: 'Set one prospect's outreach priority (1=highest) within a project.' It clearly differentiates from sibling tools like update_prospect or set_prospect_do_not_contact by focusing specifically on outreach priority.

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

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

The description implies the intended use case by naming the operation and explicitly points to read tools (list_project_prospects, get_outbound_targets) for verification. However, it does not explicitly state when to prefer this over related setter tools such as update_prospect_status or set_prospect_do_not_contact.

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

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

With no annotations provided, the description carries the full burden. It discloses that creation fails if the plan limit is reached, which is useful. However, it does not mention whether the operation is idempotent, what happens if the name already exists (though unique per tenant implies an error), or any authorization requirements, leaving gaps.

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

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

The description is a single, well-structured sentence that conveys the action, output, and error condition without redundancy. Every word adds value, making it highly concise.

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

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

Given the tool's low complexity (one required parameter, no output schema, no nested objects), the description sufficiently covers the core aspects. It provides the essential error condition and output, which is adequate for a simple creation tool, though it could mention potential errors like duplicate names.

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

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

The schema already provides 100% coverage, describing 'name' as 'Project name (unique per tenant).' The description adds no extra semantics beyond the schema, so a baseline of 3 is appropriate.

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

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

The description clearly states the action (create a new LeadAce project) and the specific resource (project). It also mentions the unique output (auto-generated project id) and a key failure condition (plan limit). This distinguishes it from siblings like delete_project and list_projects.

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 is evident this tool is for the initial creation of a project, contrasting with management tools like update_project_settings. It does not explicitly state when not to use it, but the context is clear since it's the only creation tool among its siblings.

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

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

With no annotations provided, the description carries the full disclosure burden and exceeds expectations: it details the audit row write, the exact stamping formula (next_outreach_after = sentAt + noResponseRecycleDays), the effect on get_outbound_targets queries, plus explicit non-effects (no quota consumed, not marked contacted). This is model-level transparency for a mutation tool.

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

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

Two tightly packed sentences with zero filler. Every clause earns its place: the purpose, the side effects, the system interaction, and the key exclusion. Front-loaded with the action verb and clear object, the description delivers a full behavioral contract in under 60 words.

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

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

For a moderate-complexity 5-parameter tool with no output schema, the description covers all essential facets: purpose, side effects (audit row), state mutation (next_outreach_after stamp), temporal behavior (window), non-effects (no quota/contact), and edge-case exclusion (unsupported countries). Returning the skipped prospect's updated state or error semantics would be nice-to-have context, but nothing critical is missing—especially given the strong schema coverage on the more complex parameters.

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

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

At 60% schema coverage, the schema already documents projectId, channel, and note reasonably well. The description alludes to domain concepts (noResponseRecycleDays, get_outbound_targets) that help the agent understand the tool's effect without fully mapping to individual parameters, but it doesn't add meaningfully beyond the schema—which is a fair trade given the existing annotation quality.

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 specific verb-phrase 'Record a deliberate skip' immediately followed by the resource ('a prospect on this outbound run') and a clear boundary ('no send is attempted'). It differentiates from siblings by explicitly stating 'no quota is consumed and the prospect is NOT marked contacted,' distinguishing it from record_outreach, while the one-window impact differentiates it from permanent actions like set_prospect_do_not_contact or delete_prospects.

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

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

Provides an explicit when-not-to-use exclusion: 'Not for unsupported-country prospects — get_outbound_targets already filters those server-side,' which both names a sibling and explains why skip is unnecessary in that case. It lacks an explicit 'use alternative X for case Y' statement, but the behavioral framing (drops out of get_outbound_targets for that window) clearly implies when this tool is appropriate.

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

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

With no annotations, the description carries the burden of disclosing behavior. It mentions 'partial-update' (indicating only provided fields change) and 'domain is immutable', adding transparency. It also clarifies the nature of organizationId. While it does not detail side effects like permission requirements or response format, it provides meaningful context beyond 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?

The description is a single, front-loaded sentence that efficiently communicates the action, target fields, and the critical constraint about domain immutability. Every clause earns its place with no fluff or repetition.

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

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

For a patch operation with a nested object and no output schema, the description covers the key aspects: partial update behavior, immutable fields, and ID provenance. It relies on the schema for doNotContact semantics. It does not mention error cases or authorization, but those are less critical given the concise and clear description.

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

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

The description adds value by explaining that organizationId is the primary key from specific list endpoints, not a domain, and by enumerating the updateable fields. Since schema coverage is 50% (only patch and doNotContact have descriptions), the description compensates for missing details on name, websiteUrl, and employeeBand, though it does not elaborate on their constraints 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 clearly states the tool performs a partial update on an organization, listing specific mutable fields (name, website URL, employeeBand, doNotContact) and noting that domain is immutable. This distinguishes it from sibling tools like create_organization or delete_organizations, making the purpose unambiguous.

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

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

The description implies when to use the tool (to modify an organization's mutable fields) and explicitly notes that domain cannot be changed. It also clarifies that organizationId is the PK from specific list methods, not a domain, which prevents common misuse. However, it does not explicitly contrast with other update tools or state prerequisites beyond the ID source.

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

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

No annotations are provided, so the description carries full responsibility for disclosing behavior. It does describe side effects (stamping next_outreach_after, dropping the prospect from get_outbound_targets, refunding quota, flipping status, confirming quota), but it omits key behaviors such as idempotency, error conditions, and whether changes are reversible. For a mutating tool, this is a significant gap.

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

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

The description is a single dense paragraph. It front-loads the core action and then provides necessary detail about consequences. It is not excessively long, but could be broken into bullet points for readability. Still, each sentence serves a purpose and there is no wasted text.

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

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

Given the tool's complexity (multiple side effects, state transitions), the description covers most critical points: allowed transitions, effects of each status, and the timing of next_outreach_after. It does not mention error handling or idempotency, and there is no output schema. Overall, it is sufficiently complete for an agent to use 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 all three parameters. The description adds semantic context by linking the status parameter to its consequences ('sent' flips prospect status, 'failed' refunds quota), which goes beyond the schema's basic descriptions. It doesn't add syntax details, but the schema is thorough.

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

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

The description clearly states the tool's purpose: to resolve a 'pre_send' outreach log row into one of two terminal states ('sent' or 'failed'). It names the exact source tool (record_outreach_with_inquiry) and the specific state transition, distinguishing it from sibling tools like record_outreach and update_prospect_status.

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

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

The description provides explicit usage guidance: it explains that this tool follows record_outreach_with_inquiry)Skip_prospect, and it clarifies that only the 'pre_send' → terminal transition is accepted. It also outlines the effects of each status choice, giving clear when-to-use context versus 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?

With no annotations, the description carries the full burden. It discloses key partial-update semantics ('Any omitted field keeps its current value') and null-clearing behavior, which is valuable. However, it does not mention return values, error conditions, or side effects beyond what the schema already describes.

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 main purpose, and zero unnecessary words. The description is concise and well-structured.

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

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

Given the high complexity (25 params, nested objects, no output schema, no annotations), the description is minimal. It covers core update semantics but omits return-value behavior and any high-level caution about interactions (though schema descriptions cover many). Leveraging the rich schema, it is adequate but not fully complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds a universal patch semantic (omitted equals keep, null clears) that applies to all 25 parameters, which is not repeated in each schema property. This adds value beyond the structured 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 clearly states the action ('Update') and the resource ('user-editable project settings'). It distinguishes from siblings like get_project_settings (read) and update_organization/update_tenant_settings (different scopes) by specifying project-level 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?

The scope is implied by 'project settings', but there is no explicit guidance on when to use this tool versus update_organization or update_tenant_settings. Given the sibling list includes several update tools, explicit alternative naming would improve clarity.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses partial-update semantics, uniqueness conflicts, the no-contact-channel constraint, and the side effect that changing email resets its deliverability verdict and queues a background re-check. These details go well beyond 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?

The description is compact, front-loaded with the core purpose, and every clause delivers useful information—constraints, conflict behavior, side effects, and explicit alternatives. There is no filler or wasted wording.

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

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

For a complex partial-update tool with a nested patch object, no annotations, and no output schema, the description is remarkably complete: it covers error states, uniqueness rules, side effects, null-clear behavior via the schema, and sibling-tool routing. An agent can confidently select and invoke it.

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

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

The description adds meaningful context beyond the schema, especially around conflict behavior and email reset side effects. The schema itself already documents omit/null patch semantics, so the description need not repeat every field; it compensates for the 50% schema coverage with the most critical behavioral constraints.

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

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

The description opens with a specific verb and resource: 'Partial-update a tenant prospect's fields.' It also distinguishes itself from sibling tools by naming update_prospect_status, set_prospect_priority, and set_prospect_do_not_contact for related but separate concerns.

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

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

It explicitly says when to use alternative tools: 'Per-project status via update_prospect_status, priority via set_prospect_priority, DNC via set_prospect_do_not_contact.' It also communicates invalid-patch conditions through UNPROCESSABLE and CONFLICT error semantics, helping the agent decide whether the tool is appropriate.

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

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

With no annotations, the description carries the transparency burden and it discloses a meaningful non-obvious behavior: setting status to 'new' is rejected if the prospect has already received outreach in that project. It does not cover authorization or side effects, but the rejection rule is valuable and reduces surprise for agents.

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 two sentences with no filler. The main purpose is front-loaded, and the critical behavioral caveat is added immediately after, making it efficient and easy to parse.

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 three-parameter update operation, the description gives the core purpose and a key constraint. It does not explain return behavior or parameter meanings in depth, but the tool complexity is low and the provided information covers the main workflow 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 only 33% (only projectId is documented). The description adds meaning only for the 'new' status value and does not explain the other enum values or the prospectId parameter, leaving significant semantic gaps for a low-coverage 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 uses a specific verb ('update') and clearly identifies the resource ('a prospect's status within a project'). This distinguishes it from sibling tools like update_prospect, which is broader, and update_outreach_status, which focuses on outreach rather than prospect status.

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

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

The description implies its use case by scoping status changes to a project and highlights a special condition when 'new' is rejected. However, it does not explicitly state when to use this tool instead of alternatives such as update_prospect, update_outreach_status, or set_prospect_priority, nor does it mention when it should not be used.

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

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

With no annotations, the description carries the full burden. It discloses the merge-not-replace behavior and the gating condition for outbound sends, which is essential for safe use. It also clarifies the semantics of defaultSenderCountry. However, it does not mention permission requirements or other side effects, so it's 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?

The description is concise, with three sentences that each add value: the first states the operation and merge semantics, the second warns about gating, and the third clarifies a specific parameter's meaning. No fluff or redundancy.

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

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

For a settings update tool with no required parameters and no output schema, the description covers all key aspects: what fields are affected, the merge behavior, the gating condition, and the special meaning of defaultSenderCountry. It is sufficient for correct usage.

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

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

The schema covers 75% of parameters with descriptions, but the description adds critical context by explaining the merge behavior and explicitly detailing the meaning of defaultSenderCountry, which lacks a schema description. This goes beyond the schema's pattern constraint to clarify its role.

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

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

The description clearly states the tool updates workspace identity/compliance fields, with a specific verb and resource. It also explains the merge behavior (only keys passed are written), distinguishing it from a replace operation. This sets it apart from get_tenant_settings or update_organization.

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

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

The description provides practical context by explaining that legalName, physicalAddress, and defaultSenderCountry gate outbound sends (412) until all are set. It also clarifies that defaultSenderCountry is separate from recipient targeting. This gives clear guidance on when these settings matter, though it doesn't explicitly name alternative 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?

With no annotations, the description carries the full burden and does so excellently. It discloses idempotency by slug, update behavior, archive/revive semantics, activation default, and the 400 refusal on exceeding the cap—providing thorough transparency beyond 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?

The description is a single, well-structured paragraph that front-loads the core purpose, then sequentially explains idempotency, archive behavior, and the cap constraint. Every sentence provides necessary information without redundancy.

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

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

Given the lack of annotations and output schema, the description fully explains the tool's behavior, including edge cases (revival of archived slugs) and failure conditions (400 on cap). It covers all aspects needed for correct invocation despite the absence of structured hints.

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%, giving a baseline of 3. The description adds significant extra meaning for 'slug' (stable for life, renaming orphans history) and 'approach' (2-5 lines, playbook referral), enriching the parameter understanding beyond raw 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 action: 'Register or update a discovery strategy' with a clear resource. It also distinguishes the tool by referencing how it relates to '/build-list' and 'add_prospects', making its purpose unique among 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?

The description explains when the tool is used (create/update a discovery strategy) and includes critical usage nuances (idempotency, archive behavior, revival, and the cap refusal). However, it does not explicitly name alternatives or state when not to use it, so it falls short of the 'explicit when-not/alternatives' criteria.

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

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

No annotations are provided, so the description carries the full burden. It transparently explains idempotency, the effect of archived=true, and the 400 refusal on exceeding the cap. It does not cover authentication or rate limits, but the core side effects are disclosed well.

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 two sentences, front-loaded with the core action, and every sentence adds essential behavioral information (idempotency, archival semantics, cap enforcement). No redundancy or fluff.

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

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

Given no output schema or annotations, the description covers key behavioral aspects: idempotent updates, archived state handling, and 400 on cap. It lacks explicit mention of return values or authentication/rate limits, but for an upsert tool with rich parameter descriptions, it is sufficiently complete. Minor gap: no explicit 'when to use' exclusions, but the CRUD context is clear.

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 83% (5 of 6 properties have descriptions), so the schema already documents each parameter. The description adds broader context (how archived affects rotation, why some params are null, the purpose of bodyApproach), though it doesn't detail each parameter 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 clearly states the tool's function: 'Register or update a message-angle variant' with specifics on idempotency, archived state, and cap enforcement. It distinguishes itself from sibling tools like list_message_variants and pick_message_variants by focusing on creation/update behavior.

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

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

The description provides clear context on when to use the tool (when registering or updating a variant) and explains the 400 error condition for cap violations, but does not explicitly contrast with alternatives like pick_message_variant or when not to use it. It gives enough behavioral guidance for an agent to select appropriately.

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