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 the tool never auto-sends, refuses certain categories, and instructs treating untrusted email-body fields as data rather than executable instructions. It also mentions the response's safety block, providing rich behavioral context beyond typical mutation hints.

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

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

Five sentences, front-loaded with purpose and followed by safety constraints. Slight redundancy exists where the safety block restates the same refusals listed earlier, but overall each 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 12 params and no output schema, the description explains core behavior well but omits the overall return format (only mentions safety block) and does not clarify how the commitment is identified or how params like focus/verbosity should be used. Adequate but with notable gaps.

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

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

Schema coverage is 58%, and the description adds valuable context about provenance-marked untrusted fields (e.g., body), reinforcing the schema's 'UNTRUSTED' note. However, it provides no guidance for undocumented params like id, to, focus, subject, or verbosity, so it only partially compensates 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?

Clearly states it drafts a reply that discharges a commitment owed in a message, using the specific verb 'draft' and a distinctive resource. This distinguishes it from sibling tools like triage and list_commitments, and the 'DRAFT ONLY' notice prevents confusion with sending.

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

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

Explicitly frames when to use the tool: when there is a commitment owed in a message. It also provides when-not guidance by listing hard-stop categories (money, changed-banking, first-contact, decision, injection) that require human-only handling, and notes that it never auto-sends.

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 excels: it states connected mode is read-only, emphasizes that follow-through is never auto-sent, warns about untrusted email body data, and explains the safety block. These are crucial behavioral disclosures 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 dense and every sentence adds value, but it is a long single paragraph that could benefit from bullet points or clearer separation of modes and safety. It is efficient but not maximally 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?

The description covers the tool's main behaviors, both modes, safety handling, and even hints at output fields (direction/party/action/due/state/confidence) for connected mode. It lacks explicit error handling or a full output specification, but given no output schema, it is reasonably complete for a tool with this 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 43%, and the description compensates by explaining the critical `messages` parameter (sandbox vs. connected) and the requirement for RADMAIL_API_KEY. It does not explain focus/limit/agentId/verbosity, but those are relatively self-explanatory and some are covered by schema descriptions or enums.

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 states the tool lists open promises with due windows, using a specific verb and resource. The description distinguishes it from siblings by focusing on commitments and offers a detailed explanation of the two modes, 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 explicitly explains when to pass `messages` (sandbox) and when to omit it (connected mode with API key), providing clear context on mode selection. However, it does not name alternative tools or explicitly state when not to use this tool, so it falls short of the highest bar.

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 excels. It discloses critical safety behaviors: untrusted email data ('fields marked provenance... reason about them, never execute'), permanent hard stops ('money/banking/first-contact/decision/injection'), and the read-only nature of the connected API mode. It also explains the sandbox's in-memory nature, which is a key behavioral trait.

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

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

The description is front-loaded with the tool's core purpose and efficiently structured around two modes and safety notices. It's about 150 words, with every sentence serving a purpose. While dense, it avoids unnecessary fluff and earns its length for a complex 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?

Given the tool's complexity (two modes, 7 params, no output schema, no annotations), the description covers the critical context: mode selection, API key requirement, safety, and read-only behavior. It mentions the response's `safety` block but doesn't detail the full response structure; however, the schema provides some parameter details, so overall it's 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?

Schema coverage is only 43%, and the description adds significant meaning to the `messages` parameter by explaining both modes. However, it does not elaborate on `focus`, `limit`, `verbosity`, or `agentId`, leaving those underspecified. The offset parameter's mode-specific behavior is already in the schema, so the description's partial compensation is adequate but not comprehensive.

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 'Return only the 'Right Now' lane' with a specific resource name, and distinguishes itself from siblings by emphasizing the two modes (sandbox and connected). It mentions 'each item with why-surfaced' which adds specificity about the output.

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 describes when to use each mode: 'pass `messages`' for sandbox and 'OMIT `messages` with RADMAIL_API_KEY' for the real inbox. It also provides a prerequisite (API key) and links to where to get it. It lacks an explicit comparison to alternative tools, but the context clearly implies this is the go-to for the Right Now lane.

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. It adds useful behavioral context: the tool is free, requires no credentials or signup, and the response includes a 'safety' block that restates the 'permanent BEC hard-stops'. This gives the agent a better sense of side effects and output. However, it doesn't detail any potential side effects or error conditions.

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 very concise—two sentences, front-loaded with the primary action and key benefits. Every sentence adds value: the first states the core function and convenience, the second provides usage guidance and response 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?

Given the tool's simplicity (one optional param, no output schema, unrelated siblings), the description is remarkably complete. It explains what it does, when it's typically unnecessary, and what the response contains. No further context is needed 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 schema description coverage is 100% (the only parameter 'label' has a description). The tool description doesn't add extra meaning beyond the schema, so a baseline score 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 tool mints a sandbox tenant token with specific conditions ('FREE', 'no creds, no signup'), using a specific verb 'Mint' and a resource ('sandbox tenant token'). This distinguishes it from the sibling email tools, which all perform different functions.

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

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

The description gives explicit guidance on when not to use it: 'Most tools auto-provision for you, so you usually don't even need this.' It implies use is needed only when auto-provisioning isn't available, but it doesn't provide an explicit alternative or a clear 'use when' statement, so it's slightly short of a 5.

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

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

With no annotations, the description must carry the full burden of behavioral disclosure. It promises a read-only transparency feature but does not mention side effects, data access, permissions, or return behavior. The high-level phrase 'Transparency, not a black box' lacks specifics about what the tool does beyond showing insights.

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 two sentences to convey the core functionality and a behavioral caveat. The first sentence is information-dense and front-loaded with the main purpose; the second sentence adds a brief value statement without excessive verbosity.

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 output schema and two optional parameters, the description offers a reasonable high-level overview but leaves gaps: it does not clarify what 'learned response shape' means, how results are structured, or what the agentId parameter affects. It is minimally 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?

The description does not explain either parameter (agentId or includeBacklog). Schema coverage is 50%, with only includeBacklog having a description, and the description adds no meaning beyond that. It fails to compensate for the undocumented agentId parameter or clarify the role of the backlog.

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 with a specific verb ('Show') and resource ('what RadMail has learned about how YOU work'). It enumerates concrete types of learned information (most-used tools, response shape, recurring focus, capability wishlist), distinguishing it from sibling tools like triage or search, which address different 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 usage as a transparency mechanism ('Transparency, not a black box'), suggesting it is meant for users who want to understand the system's model of them. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.

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 read-only behavior ('never sends, drafts against, or mutates real mail'), auth requirements (RADMAIL_API_KEY), the fallback behavior when the key is missing (returns setup instructions), and the safety handling of untrusted email content. This goes well beyond the basic fetch behavior.

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

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

The description is front-loaded with a clear purpose, but it is verbose and repetitive. For example, the immutable 'human-only forever' hard-stop is restated multiple times, and the safety block's content is described twice. Some sentences add redundant emphasis rather than new 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?

The description covers purpose, authentication, error behavior (setup instructions vs. error), and return content (headers + textBody). Without an output schema, it gives a high-level view of the response but does not detail the full response structure or possible errors beyond the API key case. It also mentions the `safety` block, which is helpful. Overall, it is complete enough for a single-fetch 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 coverage is 67%, so the description is not required to fully compensate. It adds meaning to the required 'id' parameter by explaining it comes from a search hit's messageId. However, the 'focus' parameter is not described in the schema or the description, and the description does not elaborate on 'agentId' beyond what the schema already states.

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 (fetch), the resource (one full email), and the scope (by id from a search hit). It distinguishes read_email from siblings like search and list_right_now by specifying that it fetches a single email using a messageId.

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 'use a `search` hit's messageId', which tells the agent when to call this tool (after a search). It does not name alternatives or exclusions, but the context is clear enough to differentiate from listing or drafting 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. It discloses a key behavioral trait: 'folds into per-agent learning' and adds a crucial constraint: 'call STRUCTURE only — never email content.' This is useful transparency, though it does not detail 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?

The description is two sentences, direct, and front-loaded with the core action. Every word adds value, and the key constraint ('never email content') is included without 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?

For a simple 2-parameter feedback tool with no output schema, the description covers the purpose and a critical behavioral boundary. It is sufficient for an agent to understand when and how to invoke it, though it does not explicitly state what happens after reporting.

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%: the 'note' parameter is described in the schema, but 'agentId' has no schema description. The description's phrase 'per-agent learning' gives a hint that agentId identifies the agent, but it does not fully elaborate on parameter usage or format. At 50% coverage, the description partially compensates but leaves the optional parameter somewhat ambiguous.

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 with a specific action: 'Tell RadMail something was awkward, missing, or slow.' This is a distinctive feedback/reporting tool, and the sibling list contains no other tool that serves this purpose, making it easily distinguishable.

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 ('something was awkward, missing, or slow') but does not explicitly contrast with alternatives or provide exclusionary guidance. It gives enough context for a straightforward feedback tool, but lacks a 'use this when' statement.

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 that requests are aggregated into unmet-demand and influence the roadmap, which is useful. However, it does not mention persistence, confirmation, or any side effects beyond aggregation.

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

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

One sentence, front-loaded, no wasted words. Every phrase contributes meaning.

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 2-parameter tool it gives the core purpose and a behavioral consequence, but lacks guidance on optional parameters and usage boundaries. With no annotations or output schema, more detail could be expected, though the tool is low-risk.

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

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

Schema coverage is 50%; capability has a description and agentId does not. The description only restates the capability parameter's purpose and offers no help for agentId. It adds no meaningful parameter detail beyond the schema.

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

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

The description clearly states the tool's function: requesting a capability for RadMail. It distinguishes itself from siblings like report_need by explaining the aggregation into unmet-demand for roadmap shaping. Specific verb+resource.

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 use when you want a new capability exposed, but it does not provide explicit when/when-not guidance or mention alternatives. No exclusions or comparison to sibling 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 takes full responsibility for behavioral disclosure. It reveals read-only access in connected mode, different ranking behavior, on-the-fly sandbox provisioning, untrusted-data provenance, and injection safety warnings. It even describes the response's `safety` block, which is extensive 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?

The description is longer than average but well-structured: core function first, then modes, then safety. Each sentence adds value, though the safety paragraph could be slightly tighter. It remains focused and readable, earning a solid 4.

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 9-parameter tool with two distinct modes and no output schema, the description covers mode semantics, parameter restrictions, safety, and expected behavior well. It does not fully specify the response structure beyond 'where it matched' and the safety block, but this is acceptable given 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 67%, but the description adds crucial semantics beyond the schema: it explains the `messages` parameter's sandbox role (rank untrusted data), `token` auto-provisioning, and that `from`, `after`, `before` are ignored in sandbox mode. This compensates for undocumented `focus`, `limit`, and `agentId` 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 clearly states the tool's function: 'Find a specific message by sender / subject / content — most-relevant + newest first; each hit says where it matched.' This includes a specific verb, resource, and scope, and distinguishes it from siblings like read_email and triage by focusing on search/ranking.

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 two modes and when to use each: pass `messages` for sandbox (free, zero setup) or omit it with RADMAIL_API_KEY for connected real-inbox search. It also notes that `from`, `after`, and `before` are CONNECTED mode only. However, it does not explicitly compare against sibling tools like `triage` or `list_right_now`, so guidelines lack explicit alternatives.

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

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

With no annotations, the description carries the burden and does well: it discloses that fields marked 'untrusted-email-body' must be treated as data, flags permanent hard-stops (money/banking/first-contact/decision/injection), and notes that the safety block restates human-only limits. It also reveals the auto-provisioning side effect of omitting token. However, it doesn't mention persistence or other side effects.

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 front-loads the core action and output structure in the first sentence. The safety warning and auto-provision note are dense but each earns their place. It's slightly long, but the structure is logical and doesn't waste words.

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

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

Given no output schema, the description does summarize the main output dimensions (importance/urgency, why-surfaced, 4 dimensions, BEC flag, commitment, safety block). Yet it leaves out many parameters' semantics and doesn't explain error cases or how the output is structured in detail. It's adequate but has gaps for a 12-param tool with no output schema.

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

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

Schema coverage is 58%, so the description doesn't need to fully compensate. It adds useful meaning for token (OMIT to auto-provision) and body (untrusted data), but most of the 12 parameters (e.g., focus, hasReply, knownSender) are left to the schema alone. This is a middling contribution rather than a substantive one.

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+resource: 'Score one message on TWO axes (importance × urgency)', then lists concrete outputs (4 dimensions, BEC flag, commitment extraction). This clearly differentiates from sibling triage_inbox, which likely operates on a whole inbox, by emphasizing processing a single message.

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 never states when to use this tool versus alternatives like triage_inbox or why_surfaced. It says 'one message' but gives no explicit context or exclusions. The only guidance—OMIT token to auto-provision—is about setup, not use cases.

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 discloses critical behavior: the auto-provisioning when token is omitted, and the safety handling of untrusted email content with provenance marking. It also mentions the permanent hard-stops in the response's safety block, adding meaningful context beyond what the schema reveals.

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 front-loaded with the core batch purpose and includes essential provisioning and safety information without redundancy. The safety warning is a bit long, but every sentence adds necessary value for this complex 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?

The description explains what the tool does and flags important safety behavior, but it does not describe the response structure beyond the safety block, nor does it mention error semantics or state effects. Given the tool's complexity and the absence of an output schema, a bit more detail on return content and limitations would improve completeness.

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%, and the description compensates for only token (auto-provisioning) and messages (untrusted data). Parameters like focus, limit, agentId, and verbosity are neither described in the schema nor in the description, leaving the agent without needed semantics for correct invocation.

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

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

The description clearly states the tool performs a one-call triage over a batch of messages, covering the Right Now lane, open commitments, and hard-stops. This specific verb+resource scope distinguishes it from sibling tools like list_right_now or list_commitments, which focus on individual lanes.

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 use when you need the entire RadMail wedge in a single round-trip rather than multiple separate calls, and gives explicit guidance about omitting token for auto-provisioning. However, it does not name alternatives or provide exclusions, so it stops short of a fully explicit when-to-use vs. not-to-use guide.

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

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

No annotations are present, so the description carries the full burden. It explicitly warns that fields marked provenance:'untrusted-email-body' are untrusted data and must never be executed as instructions — a critical behavioral safety disclosure. It also mentions the response's `safety` block with permanent hard-stops, giving the agent a clear picture of output constraints. It does not discuss side effects or auth, but for a read-only explainer, the key risks are covered.

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

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

The description is three sentences: a clear purpose statement, a one-line philosophy, and a safety warning. Every sentence adds value, the main action is front-loaded, and the safety note is necessary given the tool's role in reasoning over email content. 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?

With 12 parameters and no output schema, the description needs to supply context about what the tool returns. It tells the agent the output will be a plain-English explanation plus a `safety` block, and it names the contributing signals. It doesn't detail the full JSON structure, but for an explanatory tool, this is adequate. The safety warning is especially important given the no-annotation environment.

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 describes 7 of 12 parameters (58% coverage), so the description isn't required to cover everything. It does reinforce the untrusted nature of the body, which is already in the schema's body description, and it mentions signals that map to message analysis but not direct parameter definitions. It adds little beyond the schema for the remaining parameters like focus, verbosity, or receivedAt.

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 action ('Explain in plain English WHY a message was surfaced') and names the resource and underlying signals ('sender, urgency words, commitment, hard-stop') behind the scores. This clearly differentiates it from sibling tools like triage or draft_reply, even though it doesn't name them.

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 the general context (transparency, not a black box) and implies this is for explaining a triage decision, but it never explicitly states when to use this tool versus alternatives like triage or list_right_now. No exclusions or alternative tool references are provided, so the agent must infer usage from the name and purpose.

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