Cooper Email

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

The description goes well beyond the annotations by disclosing that a confirmation email is sent, that updates are gated on confirmation, and that an owner row is written. This adds meaningful behavioral detail about the write and external side effects that annotations alone do not provide.

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

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

The description is short, front-loaded, and easy to parse. The final sentence restates the confirmation email side effect slightly, but it adds the owner-row write, so the minor redundancy is acceptable.

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 action, side effects, confirmation behavior, and digest options, which is enough to call the tool correctly. It does not indicate the return shape or a default for the optional digest parameter, and duplicate/error handling is unaddressed, but these are modest 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?

With only 33% schema description coverage, the description partially compensates: it explains digest as 'immediate or daily' and ties email to a human owner. However, inbox_id is not explicitly described beyond 'this inbox', so the parameter meaning is not fully clarified.

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

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

The description states a concrete action ('Email a confirmation link and code') and explicitly names the state change ('writes an owner row') and side effect ('sends one confirmation email'). This clearly distinguishes it from sibling tools like cooper_notify_owner or cooper_list_owners.

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 use case: register a new human owner who must confirm before receiving updates. However, it does not explicitly say when to use this tool versus alternatives, nor does it name any sibling tool, so the agent must infer routing from context.

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

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

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, so the description's 'Read-only' is redundant. However, it adds valuable context beyond annotations: the 402 error behavior with upgrade_url and the 'signed-in account' scope, which informs the agent about authentication context and error handling.

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 wasted words. It front-loads the primary purpose and appends the relevant error detail. 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 parameters, no output schema, and annotations covering safety, the description provides all necessary context: what data it returns (plan, usage, inbox count, limits), that it is read-only, and the upgrade_url detail. The 'signed-in account' implies authentication. Nothing essential is missing.

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

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

The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline for 0 params is 4, and the description adds no parameter info because none exists, which 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 (read) and the resource (the signed-in account's Cooper plan, monthly send usage, inbox count, and limits). It is specific and distinguishes itself from siblings by being the only billing-status read tool; no other sibling covers this domain.

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 for checking the current account's billing status and notes that a 402 from send or inbox create includes upgrade_url, which hints at when this tool is relevant (e.g., when handling such errors). It does not explicitly name alternatives or exclusions, but the context is clear given the tool's unique purpose among 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?

Annotations already declare readOnlyHint=false and idempotentHint=false, so the write nature is known. The description adds that it 'writes a new public address,' which gives a bit more specificity about the side effect. However, it does not explain what happens to existing inboxes, whether the address is derived from the username parameter, or any limits or 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?

Two short sentences with no filler. The action is front-loaded, and the second sentence adds a meaningful clarifying detail about the side effect. Every word 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?

Although the tool is simple and annotations cover safety traits, the description lacks usage guidance and parameter semantics. With no output schema, the agent also cannot know what response to expect. For a create operation, this leaves notable gaps that are not compensated by annotations or schema descriptions.

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 0% description coverage, so the description carries the full burden for parameter meaning. It does not explicitly explain 'username' or 'display_name.' The phrase 'new public address' weakly implies username is the address, but display_name is completely unexplained, leaving the agent to guess.

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

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

The description states a specific verb and resource: 'Create another inbox on the signed-in Cooper Email account.' It also adds the key effect, 'writes a new public address,' which distinguishes it clearly from sibling tools like cooper_list_inboxes or cooper_send_message. No confusion about what this tool does.

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

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

The description gives no guidance on when to use this tool or when to prefer an alternative. It does not mention that this is for creating additional inboxes as opposed to listing them, nor does it reference any sibling tools. Usage context must be entirely inferred from the verb 'create.'

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's 'Read-only' is redundant. However, it adds the detail that the response includes extracted_text and attachment metadata, which gives some expectation of the output. No contradictions with annotations.

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

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

The description is a single, clear sentence with no filler. It front-loads the action and includes the key output details.

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, but the description omits any explanation of the parameters or when to use it. There is no output schema, so the description's mention of extracted_text and attachment metadata helps, but it's not enough to fully guide an agent on how to 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?

The schema has zero description coverage for the two required parameters (inbox_id and message_id), and the description does not explain their meaning or format. The description adds no value in helping the agent understand what values to provide.

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 (fetch), the resource (one stored Cooper message), and specifies the included fields (extracted_text and attachment metadata). It distinguishes from list_messages by emphasizing 'one' and 'stored', 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 no guidance on when to use this tool versus siblings like cooper_list_messages or cooper_search. It doesn't mention that this tool requires specific IDs or that it's for retrieving a single message by ID. Without this, an agent might not know when to select it.

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

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

Annotations already provide readOnly/idempotent/destructive hints. The description adds a long-poll timeout behavior, default status, and a security warning that task text is untrusted, all beyond the schema and annotations. No contradiction.

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 purpose and keeps behavioral notes in short separate sentences. 'Read-only' is redundant with annotations, and the provenance clause is slightly dense, but overall it is tight and 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 an optional-parameter read-only list tool it is mostly self-sufficient: it explains provenance, default status, polling, and trust. It under-documents limit and inbox_id and, with no output schema, does not describe the return shape, so there are still usable but non-trivial 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?

Only 'wait' is documented in the schema (25% coverage), and the description merely restates that wait is a long-poll with max 25. It adds the pending default for status, but limit and inbox_id receive no semantic help, leaving a substantial gap.

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

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

States a specific verb ('List') and resource ('actionable tasks') with precise provenance conditions (verified owner/allowlisted sender, DMARC/DKIM alignment). This distinguishes it from message-centric siblings like cooper_get_message and cooper_list_messages.

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

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

Gives clear operational context: default status pending, long-poll behavior, and read-only nature, so an agent understands typical calling conditions. It does not explicitly name alternatives or say when not to use it, but the task-vs-message split is implied by sibling names.

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

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

The description states 'This writes mail,' which aligns with readOnlyHint=false and adds explicit write behavior. It also discloses that it does not wait for MX, providing a behavioral detail beyond annotations. The test-focused nature is disclosed. No contradiction with annotations; idempotentHint=true is consistent with a store 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 concise sentences that front-load the primary purpose and key behavioral traits. No unnecessary words 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 tool has 7 parameters (2 required) with no schema descriptions and no output schema, the description is far from complete. It lacks any guidance on how to fill the parameters, what attachments entail, or what the return value is. The description covers only the high-level purpose and a few behavioral traits, leaving agents to guess parameter semantics.

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

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

Schema description coverage is 0%, so the description must explain parameters, but it mentions none. It does not clarify what inbox_id, from, subject, text, html, client_id, or attachments mean, nor their requirements or formats. The description adds zero parameter 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's purpose: 'Store a test inbound message in the inbox without waiting for MX.' This is a specific verb+resource (store message) and distinguishes it from outbound sending tools like cooper_send_message. It also clarifies it's for tests by contrasting with production inbound via Cloudflare Email Routing.

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

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

The description implies when to use it: for test inbound messages, without waiting for MX. It contrasts with production inbound, giving context on the testing scenario. However, it does not explicitly name alternative tools like cooper_send_message or state when not to use it, but the test vs production distinction provides clear 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds value by specifying the account scope and enumerating the returned fields (id, username, email, display name, created time), which is useful behavioral context beyond the annotations.

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

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

Two short sentences with no filler or redundancy. The core action is front-loaded, and the read-only nature and return fields are stated efficiently.

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 parameterless list operation with safety annotations provided, this description is complete. It tells the agent what the tool returns and which account context it operates on, so no necessary information is missing.

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

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

The tool has zero parameters, so there is nothing to document. The baseline for zero-parameter tools is 4, and the description correctly makes no parameter claims.

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

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

The description names a specific verb and resource: listing inboxes on the signed-in Cooper Email account. It clearly differentiates from sibling tools like cooper_list_messages and cooper_list_owners by identifying the exact resource type and account 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 gives clear context: it lists inboxes for the current signed-in account, which implies when this tool is appropriate. It does not explicitly name alternatives or exclusions, but for a simple zero-parameter list tool, the context is sufficient.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not restate safety. It adds valuable behavioral detail by specifying the response fields (ids, addresses, subjects, previews, times) and explicitly excluding full bodies, plus the default-inbox behavior. This goes beyond what the annotations convey.

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

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

Three sentences, each earning its place: the first gives the core action and ordering, the second defines the return scope and exclusion, and the third covers the optional parameter and the sibling alternative. No redundancy beyond the harmless 'Read-only' reinforcement.

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 makes key context explicit: default inbox behavior, return field set, and lack of full bodies. Since there is no output schema, this is important. Slight gap: the meaning of 'limit' and pagination are not addressed, but for a list operation with only two simple parameters, the description is mostly 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 documents inbox_id well, and the description reinforces it ('defaults to the newest inbox'). However, the 'limit' parameter has no description in the schema and receives no explanation in the description. With schema description coverage at only 50%, the description partially compensates but leaves limit semantics unclear.

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 ('List'), a resource ('messages in a Cooper inbox'), and an ordering guarantee ('newest first'). It also distinguishes itself from cooper_get_message by clarifying it returns only previews, not full bodies. An agent can clearly understand what this tool does and how it differs from the closest sibling.

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

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

The description clearly indicates this is for listing messages and explicitly points to cooper_get_message for reading a single message, giving useful routing guidance. It does not, however, mention any exclusions such as when to use cooper_search or other sibling tools, so it falls slightly short of fully explicit when/when-not guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds genuinely useful behavioral context: it 'does not return confirmation secrets' and explicitly includes pending, verified, and unsubscribed owners. This goes beyond the structured annotations without contradicting them.

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

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

The description is two lean sentences with the action and scope front-loaded. Every clause adds useful information; even the redundant 'Read-only' is short and reinforces the safe, non-destructive nature.

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 single-parameter list operation, the description covers the status categories returned and a key exclusion (confirmation secrets). It omits response structure and how to source inbox_id, but given the annotations and simplicity, these are minor gaps.

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

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

The only parameter, inbox_id, has 0% schema description coverage. The description merely implies the target via 'on a Cooper inbox' but does not explain what inbox_id is, where to obtain it, or what format it should take. It fails to compensate for the schema gap.

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

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

The description states a specific verb ('List'), resource ('owner addresses on a Cooper inbox'), and scope ('pending, verified, and unsubscribed'). It distinguishes this from siblings like cooper_list_inboxes and cooper_notify_owner by the resource and outcome.

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: call this to inspect owner addresses and their statuses on an inbox. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as cooper_add_owner or cooper_notify_owner, leaving the selection largely to inference.

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

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

The description adds substantial behavioral context beyond the annotations: notifications go to every verified owner, task_id groups updates into one email thread, daily-digest owners are queued until flush, and the body is a status note rather than a prompt. These are important side effects not captured by readOnlyHint/idempotentHint/destructiveHint.

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 and front-loaded, with the core action in the first sentence. Each subsequent sentence—thread grouping, digest queueing, and body nature—earns its place by conveying behavior an agent needs before invoking.

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 notification tool with no output schema, the description covers the essential behavior: recipients, update kinds, thread grouping, digest delays, and body semantics. It does not describe optional parameter usage or any return/error behavior, but the required-call semantics are 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 description coverage is only 25%, so the description must compensate. It adds meaning for the required parameters: kind enumerates the update types, text is a 'status note, not a prompt,' and inbox_id maps to 'every verified owner.' It also clarifies task_id threading, though optional parameters like links, title, and client_id remain unexplained.

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: 'Send a progress, done, needs_input, or error update to every verified owner of the inbox.' This clearly identifies the resource (inbox owners), the verb (send/notify), and the update kinds. It also distinguishes itself from message-sending siblings by noting the body is 'a status note, not a prompt.'

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—when sending progress/done/needs_input/error updates to inbox owners—and adds a useful exclusion: 'not a prompt.' However, it never explicitly names alternatives like cooper_send_message or states when those should be used instead, so the guidance is implied rather than explicit.

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

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

The description explicitly states this writes a new account inbox, matching readOnlyHint=false and idempotentHint=false. It adds valuable security behavior: the plaintext key is returned once and should not be echoed after the first show. This goes beyond the annotations, though it could also mention duplicate-handling or failure behavior.

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

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

Two sentences, no filler, and the critical caveat about not echoing the key is included without bloating the description. The core purpose is front-loaded and every sentence earns its place.

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

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

For a two-parameter creation tool with no output schema, the description is largely complete: it covers the side effect, the returned value, and the security warning. The main gap is the unresolved relationship with cooper_create_inbox, which could leave an agent unsure which creation tool to invoke.

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 explains both parameters. The description adds minimal semantic value beyond reinforcing that the username becomes the email local part and that an API key is produced, which is the baseline expectation for a fully-described 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 (create), the resource (Cooper Email inbox), and the secondary output (API key). It is easy to understand what the tool does. However, it does not distinguish itself from the near-identical sibling cooper_create_inbox, so it falls short of a 5.

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

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

The description implies this is for creating a new account inbox and returning an API key, but it gives no explicit guidance on when to choose this tool over cooper_create_inbox or other sibling tools. No exclusions, prerequisites, or alternative routing are provided.

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

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

Annotations already indicate this is a mutating, non-idempotent, open-world operation. The description adds that Cooper POSTs on mail received or sent, which is useful behavioral context, but it does not disclose effects like overwriting existing webhooks, authentication needs, or response format. It adds modest value beyond annotations.

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

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

Two sentences, front-loaded with the primary action and scope. No filler or redundancy; every word earns its place.

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

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

With no output schema and sparse annotations, the description must carry more weight. It omits critical details about the events parameter, possible validation rules, and whether repeated calls replace or duplicate webhooks. An agent cannot fully understand how to invoke it correctly without extra inference.

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

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

Schema description coverage is 0%, so the description must explain parameters. It mentions 'HTTPS URL' for the url parameter, but does not explain the events parameter at all, nor its enum values. The description fails to clarify that events can be filtered to specific message/task events, leaving agents to guess.

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 registers an HTTPS URL for webhook delivery on mail events, with a specific verb ('Register') and resource ('webhook'). It is distinct from sibling tools like send_message or list_inboxes, and the purpose is unambiguous.

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

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

The description implies usage for setting up webhook notifications but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The sibling set is diverse, but no routing guidance is given.

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

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

Beyond the annotations, the description explicitly states that this tool "writes a message and delivers it," clarifying that it has real side effects and sends an actual email. It also discloses the optional status mutation, which is not fully implied by readOnlyHint=false.

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 primary action is front-loaded and the side-effect warning is concise. Every clause contributes to selection or invocation understanding.

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 purpose, the side effects, and the optional status behavior. It does not state return values or explicitly warn about non-idempotency, but the annotations and simple parameter set make the tool adequately callable.

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 33%, but the description adds meaning for status by specifying that it can be set to in_progress or done, and for text by framing it as the content of the reply. It does not explicitly explain the text parameter format or that task_id comes from cooper_get_tasks, though the schema covers the latter.

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: "Send an in-thread email back to the human who created the task." It also mentions the optional status update, making the tool's combined behavior clear. This differentiates it from generic siblings like cooper_send_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 implies when to use it: when replying in-thread to the task creator. However, it does not explicitly contrast it with alternatives such as cooper_send_message or cooper_notify_owner, so an agent must infer the selection boundary.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description's 'Read-only' is redundant with those. However, it adds useful behavioral context beyond the schema by specifying exactly what the search returns: matching message summaries and extracted_text, which is valuable since no output schema exists.

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

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

Three short, purposeful sentences: action/scoping, safety trait, and return value. No filler or redundant elaboration. The most important information is front-loaded.

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

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

For a simple two-parameter search tool with safety carried by annotations, the description gives enough return-shape information ('message summaries and extracted_text') to inform usage. It doesn't mention pagination, defaults, or query syntax beyond the schema, but those are minor given the tool's low 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 'q' as an AND-across-tokens search query, but 'limit' has no schema description. The tool description adds no additional parameter meaning, so the 50% schema coverage gap for 'limit' is not compensated. The meaning of 'limit' is fairly self-evident, keeping this at a mid-level score.

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 a specific action ('Search stored Cooper mail for this account') and the result format ('message summaries and extracted_text'). It does not explicitly differentiate from similar sibling tools like cooper_list_messages or cooper_get_message, but 'search' plus 'matching' makes the resource and operation clear.

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

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

No guidance is given on when to use this tool versus siblings such as cooper_list_messages or cooper_get_message. The phrase 'for this account' provides some scope, but there are no exclusions, alternatives, or use-case conditions to help the agent choose correctly.

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

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

Annotations already provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds valuable context: it reveals the write action ('writes a stored message and delivers it on the public Internet') and explains idempotency ('client_id makes retries safe'). This goes beyond the annotations by clarifying the external side effect and how to handle retries. No contradiction with annotations.

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

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

Three sentences with zero fluff. The primary action is front-loaded, the side effect is stated next, and the parameter guidance is compact. Every sentence earns its place.

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

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

For a 7-parameter tool with no output schema, the description covers the core behavior, side effects, and key parameter semantics. It omits explicit return-value information, but that is not critical for a send operation. The description is sufficient for an agent to know how to call it correctly, though it could benefit from stating what the function returns (e.g., a message ID).

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

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

Schema description coverage is 0%, so the description must compensate. It explains that 'text' and/or 'html' can be passed, attachments are optional, and 'client_id' ensures idempotency. It does not explicitly explain 'to', 'subject', or 'inbox_id', but these are intuitive from the context ('addresses in to' and 'from the Cooper inbox'). It covers the non-obvious parameters meaningfully.

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 ('Send an email from the Cooper inbox to the addresses in to') with a clear verb and resource. It also mentions content types and attachments, making it distinct from sibling tools like cooper_inject_inbound (which simulates inbound mail) and cooper_reply_task (which replies to tasks).

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 states what the tool does but does not explicitly contrast with alternatives or provide when-not-to-use guidance. For example, it does not mention that cooper_inject_inbound is for simulating inbound email, nor does it advise against using this tool for internal delivery. Usage context is implied but not explicitly framed against 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?

Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds the server-side key requirement and the return type ('Returns url'), which is useful, but it doesn't disclose side effects like creating a Stripe session or failure behavior. Given the annotations carry the safety profile, this is adequate 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?

Two sentences with zero fluff. The core action and key prerequisite are front-loaded. Every word 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?

For a simple tool with no output schema, it tells the agent what it returns (url) and the required environment variable. It doesn't mention error scenarios or what happens if the key is missing, but for this level of complexity it is sufficiently complete for an agent to call it correctly.

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

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

Schema description coverage is 100%, so all three parameters are documented in the schema. The description only re-states the enum values (Starter/Pro) and adds no additional meaning for email or client_id. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description states a specific verb ('Create'), a concrete resource ('Stripe Checkout URL'), and the plan scope ('Starter or Pro'). It is immediately clear what this tool does and how it differs from billing-status or messaging tools in the sibling set. No ambiguity.

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

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

It gives a clear usage context ('so you can hand the human a pay link') and a prerequisite ('Requires STRIPE_SECRET_KEY'). It doesn't explicitly mention when not to use it or name alternatives, but the context implies it's for upgrade payments. This is better than no guidance.

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