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

With no annotations provided, the description carries the behavioral disclosure burden. It transparently reveals that the operation is an upsert keyed by address and that calling it twice is safe, which is meaningful behavioral context beyond a simple 'update' phrasing. It does not mention permissions or overwrite effects on existing subscribers, but the core mutation semantics are 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?

Two sentences with no filler. The action and resource are front-loaded, and the second sentence adds a valuable idempotency caveat 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 low-complexity tool with three parameters, full schema coverage, and no output schema, the description plus input schema provide enough information for an agent to invoke the tool correctly. Minor gaps such as explicit alternative routing and error/return behavior are not critical at this level of 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 input schema already documents all three parameters with descriptions (100% coverage), which sets a baseline of 3. The description adds extra meaning by identifying address as the upsert key and permalink as the broadcast stream target, clarifying how parameters relate to the operation beyond their individual schema definitions.

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 ('Add or update') on a specific resource ('one subscriber of a broadcast stream'), and the upsert-by-address note adds useful precision. It does not explicitly differentiate from sibling tools such as import_subscribers or remove_subscriber, so it falls just short of full distinction.

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 single-subscriber operations, and the idempotency note tells agents that repeated calls are safe. However, it does not explicitly state when to use this tool versus bulk import, listing, or removal tools, nor does it name alternatives.

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

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

Annotations already mark the tool as destructive, and the description adds a concrete behavioral consequence: archived streams reject new messages. This goes beyond the annotation by clarifying what archiving means operationally, though it does not mention reversibility or effects on existing messages.

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 only two sentences, both of which add necessary information: the primary action and its key consequence. There is no redundancy or filler, and 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 tool with a single required parameter and no output schema, the description provides enough context to use it correctly: what it does and what happens after archive. It does not detail return values or error cases, but those are less critical given the simplicity of the 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 description coverage is 100%—the only parameter, 'permalink', is already described as 'Stream permalink'. The description adds no additional meaning about the parameter, so the baseline of 3 is appropriate because the schema carries the full burden.

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 ('Archive') with a clear resource ('a message stream') and states the resulting behavior ('Archived streams reject new messages'). This makes the tool's purpose immediately distinguishable from sibling tools like send_to_stream or update_stream.

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 the intended effect—after archiving, new messages are rejected—so an agent knows to use this tool when it wants to stop new messages on a stream. It does not explicitly mention alternatives or when not to use it, but the context is clear enough for a single-purpose archive operation.

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?

DestructiveHint already marks this as destructive; the description adds the practical warning to inspect the message before release and clarifies the delivery consequence. This goes beyond the annotation by communicating the risk of bypassing the spam hold.

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 the core action in the first sentence and the caution in the second. Every sentence earns its place and the message 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 one-parameter tool with no output schema and clear annotations, the description is complete enough: it identifies the target action, the hold context, and the required safety step. It could mention an alternative lookup path, but that is a minor gap.

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

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

Schema coverage is 100% for the single id parameter, so the baseline is 3. The description only implicitly ties the id to a held message and does not add meaningful parameter detail beyond what the schema already documents.

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 — release a held message past the spam-filter hold and deliver it. It clearly identifies the resource and goal, though it does not explicitly contrast itself with sibling tools like retry_inbound.

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 says the message must already be held by the spam filter and instructs checking the message before releasing it. That gives clear operational context, but it does not explicitly name alternatives or when not to use the 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?

Annotations already carry destructiveHint: true, but the description adds meaningful behavioral context on top: 'Messages already queued are not recalled' clarifies the boundary of the destructive effect. This goes beyond what the structured hint conveys and warns the agent about an irreversible partial outcome.

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 filler: the action is front-loaded and the critical caveat follows immediately. 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?

For a single-parameter operation with annotations and full schema coverage, the description captures the essential behavioral caveat. It omits a note on the outcome/return value, but with no output schema present and the tool being simple, nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% and the id parameter is fully documented in the schema ('Numeric campaign id' with exclusiveMinimum). The description adds nothing about the parameter itself, so the 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 states a specific verb (Cancel), resource (campaign), and scope (scheduled or in-flight), which clearly distinguishes this tool from siblings like send_campaign_now, update_campaign, or archive_stream. An agent can identify what this tool does without opening the schema.

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

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

The phrase 'scheduled or in-flight' implies when the tool is appropriate, but the description never says when not to use it or names an alternative (e.g., update_campaign for editing, or pausing differently). Usage context 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It does this well by explaining that unset scheduled_at keeps the campaign a draft and that setting it causes the server to send when due. It does not cover side effects like whether the campaign becomes immediately visible or what auth is required, but the core safety-relevant 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?

Three tight sentences with no wasted words. The most important behavior ('WITHOUT sending it') is front-loaded, the draft/scheduled mechanism is second, and the sibling comparison is last. Every sentence earns its place.

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

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

For a 7-parameter tool with full schema coverage, the description covers selection, the draft/schedule behavior, and the sibling alternative. The only real omission is the return value, since there is no output schema; stating that the call returns a campaign ID or status would make it fully complete, but this is not critical for selecting and invoking 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?

Schema coverage is 100%, so the baseline is 3. The description adds real semantic value beyond the schema by explaining that scheduled_at is the draft/send switch: leave it unset for a draft, set it to send when due. This clarifies the most important parameter's behavior more concretely than the schema's 'RFC 3339 send time' note.

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: 'Write a campaign' and immediately clarifies the key distinction 'WITHOUT sending it.' It also contrasts with send_campaign_now, so an agent can tell this tool apart from its closest sibling without opening the schema.

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

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

The description explicitly states when to use this tool: 'when a campaign should be reviewed first' and explicitly names the alternative condition: 'use send_campaign_now only when it should go out immediately.' This is direct when/when-not guidance with a named sibling.

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 behavioral burden. It discloses the critical requirement that html_wrapper must embed {{{ content }}} and that anything else is refused with ValidationError, which is valuable. However, it does not mention mutation effects, permissions, idempotency, or response behavior, leaving gaps for a create 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 sentences with no filler. The main purpose is front-loaded, and the critical validation constraint follows immediately. Every word serves a purpose.

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 create tool with no output schema and no annotations, the description covers the essential validation gotcha but omits return value expectations, error handling beyond ValidationError, and any prerequisites or side effects. The 100% schema coverage compensates for parameter details, leaving a moderate completeness level.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds genuine semantic value by specifying the enforcement of the placeholder requirement and the resulting ValidationError, which the schema does not convey. This extra clarity on html_wrapper justifies a 4.

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 verb ('Create') and resource ('template layout'), distinguishing it from sibling layout operations like update_layout, get_layout, and delete_layout. The additional detail about html_wrapper validation reinforces the tool's identity without 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?

No guidance is provided about when to use create_layout versus other layout tools or when the optional permalink/text_wrapper parameters should be set. The single validation rule is not a substitute for usage context or 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 provided, the description carries the full behavioral burden. It discloses one genuinely useful trait — the API derives permalink from name when not set — but does not cover other behaviors an agent might need, such as failure on duplicate names, idempotency, or what side effects creation has. Partial but not comprehensive 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?

Two sentences with zero filler. The purpose is front-loaded and the conditional permalink guidance earns its place by conveying the tool's key operational nuance.

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 and all three params are schema-documented at 100% coverage, but there is no output schema and the description doesn't mention what the API returns upon creation (e.g., the created stream with its permalink). Given the permalink guidance implies the identifier matters for later calls, noting the return shape would meaningfully 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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains that permalink can be known up front if set explicitly and is otherwise derived, which clarifies the relationship between name and permalink that the schema alone doesn't convey.

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?

'Create a message stream' is a specific verb+resource statement that clearly distinguishes this tool from siblings like update_stream, archive_stream, and list_streams. The scope is unambiguous and an agent can immediately tell 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 conditional guidance on when to set permalink explicitly versus letting the API derive it, which is useful within the tool. However, it never addresses when to choose create_stream over related tools like send_to_stream or archive_stream, so sibling routing is left to inference.

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

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

Annotations already flag destructiveHint=true, so the destructive nature is known. The description adds valuable behavioral context by disclosing the cascading effect on templates that referenced the layout, which is not inferable from the schema or annotations. It does not discuss reversibility or failure behavior, but the core side effect is communicated.

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 main action is front-loaded, and the important side effect is stated immediately in the second sentence.

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 delete operation, the description covers the action and the key downstream effect. There is no output schema, but a return-value explanation is less critical for a destructive tool. Minor gaps such as error behavior or nonexistent permalink handling are not addressed.

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 documents the only parameter (permalink) with the description 'Layout permalink', so schema coverage is 100%. The tool description adds no additional meaning about permalink format or constraints, landing at 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 uses a specific verb and resource ('Delete a layout') and adds a distinct consequence ('Templates that referenced it fall back to no wrapper'). This clearly differentiates deletion from sibling tools like update_layout or archive_stream.

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 explicit guidance about when to choose delete_layout over alternatives such as update_layout or create_layout. There is no when/when-not context, so an agent must infer usage solely from the tool name.

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, so the safe read-only nature is established. The description adds that it operates over stored aggregate reports and summarizes specific metrics, which is useful context, but it does not disclose output format, boundary behavior, or how the optional filters affect results.

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, compact sentence that front-loads the tool's purpose and then states the key fields in the summary. Every clause adds information and there is no filler.

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

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

For a read-only summary tool with three optional parameters and no output schema, the description gives a basic mental model: it produces a compliance summary with pass rate, top sources, and disposition totals. However, it does not describe the expected response structure, edge cases like empty results, or timezone/date-range behavior, leaving an agent to risk on assumptions.

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% description coverage for all three parameters ('to', 'from', 'domain'), so the schema carries the burden. The description does not add meaning beyond the schema; it only implies date range and domain filtering by naming the report 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 names a specific verb and resource ('DMARC compliance summary') and details the exact metrics covered (pass rate, top sending sources, disposition totals). No sibling tool is DMARC-specific, so it clearly stands out.

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

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

There is no explicit guidance on when to use this tool versus alternatives like get_stats or list_emails. The description implies a reporting use case but does not state exclusions, prerequisites, or when a different tool would be more 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?

Annotations already declare readOnlyHint and openWorldHint, and the description's 'Retrieve' is consistent with those. The description adds the return statistics list but no further behavioral detail such as not-found handling or rate limits; with annotations present 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?

A single sentence that front-loads the action and resource and then lists the returned statistics. No filler or redundant restatement of the schema.

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

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

For a one-parameter read tool, the description sufficiently covers what the tool returns by naming each statistic. There is no output schema, so the listed stats partly fill that gap; the only minor omission is explicit statement of behavior when the id does not exist.

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 fully documents the sole parameter ('Numeric campaign id', exclusiveMinimum 0), so schema coverage is 100%. The description adds no extra parameter semantics beyond implying the id selects one campaign, meeting 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 uses a specific verb ('Retrieve') and a concrete resource ('one campaign') and enumerates the statistics returned. This clearly distinguishes it from list_campaigns (plural listing) and other get_* 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 makes it clear this is the tool for fetching a single campaign along with its stats, so an agent can infer when to choose it. It does not explicitly name alternatives or exclusion conditions, but for a simple read 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 provide readOnlyHint=true, lowering the bar. The description adds useful behavioral context by stating that SMTP delivery attempts are included in the result, which is not present in the structured annotations. It does not mention not-found behavior, but this is a minor gap given the simple read 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?

A single, front-loaded sentence states the operation, target, key, and a key result detail without any filler. 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?

For a one-parameter read-only tool with annotations, this definition is reasonably complete: it states what is retrieved and one important aspect of the return payload. Error or not-found behavior is not described, but complexity is low and no output schema is expected.

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% description coverage for the single parameter, including type, description, and minimum. The tool description adds no parameter-specific meaning, so the 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 names a specific verb ('Retrieve'), a concrete resource ('one message'), and the lookup key ('by id'). Adding 'including its SMTP delivery attempts' distinguishes this from list_emails and makes the return content clear.

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

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

The use case is implied: call this when you have a message id and need a single message with delivery attempts. However, there is no explicit mention of when not to use it or reference to sibling alternatives like list_emails or get_inbound.

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 and openWorldHint=true, covering the read-only nature and potential incomplete result sets. The description adds value by mentioning 'held' messages, which is a state that may not be obvious. However, it does not disclose error handling, response format, or any side effects, though for a read-only tool with no output schema, some of this is expected. The description does not contradict 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?

A single, efficient sentence that front-loads the verb and resource. Every word contributes to meaning, with no filler or redundant phrasing. The description is appropriately sized for a simple retrieval tool.

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

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

For a get-by-id tool with one parameter and no output schema, the description covers the basic action. However, the 'held' state is unexplained—an agent may not know what 'held' means or how it differs from a standard inbound message. There's also no context about how this tool fits into a workflow (e.g., retrieving a message before retrying or bypassing). Given the sibling tools, some additional guidance would make it more 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 of the single parameter 'id' with a clear description. The tool description only refers to 'by id' without adding extra semantics (e.g., typical usage, format nuances, or relationship to message states). Baseline of 3 is appropriate when the schema fully documents the parameter and the description doesn't go beyond it.

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 (retrieve), the resource (inbound or held message), and the method (by id). It distinguishes itself from list_inbound and other siblings by specifying a single message. The term 'held' adds specificity beyond a generic 'get 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?

No explicit guidance on when to use this tool versus alternatives. While it's implied that you use it for retrieving a single message and list_inbound for all messages, there's no mention of when not to use it, prerequisites, or how it relates to retry_inbound or bypass_inbound for held messages. The guidance is purely 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?

Annotations already indicate readOnlyHint=true (safe read) and openWorldHint=true (may return unknown fields). The description adds that wrappers are included, which is useful. However, it does not disclose behavior such as what happens if the permalink is not found (error vs null), or any pagination or response structure details. Given the annotations provide the safety profile, the description adds minimal behavioral context beyond that.

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 sentence, perfectly concise, with the core action and key identifier upfront. It includes the important detail about wrappers without any fluff. 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?

For a simple get-by-ID tool with one parameter, full schema coverage, and annotations declaring read-only and open-world behavior, the description covers the essential purpose and inclusion of wrappers. It lacks explicit mention of return value format, but no output schema is provided and the openWorldHint suggests unknown fields are possible Ruby Marshalling. Given the low complexitytools, a 3 is adequate.

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 parameter 'permalink', with a clear description 'Layout permalink'. The description's mention of 'by permalink' adds negligible meaning beyond what the schema already states, so the baseline of 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 clearly states the action (retrieve), the resource (layout), the unique identifier (permalink), and the added detail that wrappers are included. This distinguishes it from sibling tools like list_layouts, create_layout, update_layout, and delete_layout, providing a clear specific 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 this is for retrieving a single layout when the permalink is known, but it does not explicitly state when to use this instead of list_layouts or other retrieval tools. Since the tool is self-explanatory for retrieval but lacks explicit alternatives or when-not-to-use guidance, a score of 3 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?

Annotations already declare readOnlyHint=true, covering the read-only nature. The description adds the time-window filtering behavior, which is a useful nuance, but it does not disclose details like response format, pagination, or potential rate limits. Since annotations carry the safety profile, the description adds moderate value without 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?

A single, front-loaded sentence with no filler. It states the primary function first (message counters), then the optional filter. Every word earns its place, making it highly concise and easy to scan.

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

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

For a simple read-only aggregation tool with two optional parameters and no output schema, the description is adequate. It tells what is returned (counters) and how to optionally constrain by time. Minor omissions like inclusive/exclusive bounds or return field names are typical and not critical for correct invocation. The combination of schema and description is sufficient.

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

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

Schema coverage is 100% — both 'to' and 'from' have descriptions ('Window end' and 'Window start') with ISO 8601 format. The description references 'created_at time window' but does not add new semantics beyond restating the schema's intent. Baseline 3 is appropriate given the schema fully explains the 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 returns message counters (sent, pending, bounced, opens, clicks, etc.) and optionally supports time-window filtering. It identifies the specific verb ('get') and resource ('message counters'), making the purpose clear. However, it does not explicitly distinguish itself from sibling tools like list_emails or list_bounces, though its aggregated nature makes it sufficiently distinct.

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. There is no mention of 'use this for summary counts' or 'for detailed message records use list_emails'. An agent must infer usage context from the name and description alone, lacking explicit routing 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?

Annotations declare readOnlyHint=true and openWorldHint=true, so the agent already knows it is a safe read operation. The description adds value by specifying that it retrieves a 'message stream' by 'permalink', which clarifies the exact resource and lookup key. It does not contradict annotations, and the behavioral profile is largely covered by annotations plus the simple retrieval nature.

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: 'Retrieve one message stream by permalink.' It is appropriately sized, front-loaded with the action, and contains no extraneous words. Every word contributes to understanding the tool's purpose.

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 retrieval tool with one parameteraisle and no output schema. The description, combined with the annotations and full schema coverage, provides sufficient context for an agent to select and invoke the tool correctly. The only minor gap is that it does not describe what the response looks like, but the lack of an output schema and the simplicity of retrieval make this acceptable.

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

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

Schema description coverage is 100%, meaning the schema already defines 'permalink' as 'Stream permalink'. The description does not add additional detail about the permalink format or required syntax beyond what the schema provides. With full schema coverage, the baseline of 3 is appropriate; the description does not need to elaborate further.

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 'Retrieve' and the resource 'message stream by permalink'. It is specific enough to distinguish this from list_streams (which lists streams), though it does not explicitly differentiate it from get_email or other get_* siblings. The purpose is clear and not a tautology.

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 that this tool retrieves a single stream by permalink, which suggests using it when you have a permalink and need the full stream details. However, it does not explicitly state when to use this over list_streams or mention any alternatives. The guidance is implied but not 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?

With no annotations, the description carries the disclosure burden. It usefully states that blanks and duplicates are skipped and that the reported count may be lower than the input count, giving agents a clear expectation of non-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?

The description is two sentences, front-loads the main purpose, and uses a trailing caveat for the count behavior. No filler.

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

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

For a two-parameter import tool with no output schema or annotations, it covers the core action, input semantics, and response count behavior. It stops short of specifying the exact response shape or error behavior, so it is 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 the baseline is 3, but the description adds value beyond the schema by explaining that duplicate and blank addresses are silently skipped, which affects how the addresses parameter should be interpreted.

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: add many addresses to a broadcast stream at once, with the 'all as subscribed' status. This clearly separates it from single-address add_subscriber and list_subscribers.

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?

'Add many addresses ... at once' clearly signals a bulk-import use case and distinguishes it from the singular add_subscriber tool, but it does not explicitly name alternatives or provide 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?

Annotations already provide readOnlyHint=true and openWorldHint=true, but the description adds useful behavioral context: results are newest-first, they cover the server's own logged API requests rather than some external or user-facing list, and each log includes the answer returned. These traits go beyond what the annotations state, though they do not describe response format or pagination behavior in detail.

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 first sentence states the core action and ordering; the second sentence justifies when an agent would want to call it. Every word earns its place and the primary purpose 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 read-only list tool with fully documented optional parameters, the description is largely sufficient: it names the resource, ordering, and a diagnostic scenario. There is no output schema, and the description only hints that logs include 'what answer,' but it does not specify the fields returned. This is a minor gap rather than a fatal one.

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 covers 100% of the parameters with descriptions for to, from, page, method, status, and per_page, so the schema already carries the parameter documentation burden. The description adds no additional parameter-specific meaning beyond implying time and filter relationships, which keeps this at the baseline 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 names a specific verb and resource: 'List the server's own logged API requests, newest first.' This clearly distinguishes it from sibling email-list tools like list_emails and list_bounces, which list different resources. It also adds a concrete diagnostic purpose, removing ambiguity about what the tool is for.

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 a clear, concrete use case: 'Useful when a send did not arrive and the question is whether the request ever reached the API, and with what answer.' This tells an agent when to choose this tool. It does not explicitly name alternatives or say when not to use it, so it stops short of a perfect 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?

The description adds 'filtered and paginated,' which is a behavioral trait, but this is already implied by the parameter names and schema. It does not disclose non-obvious behaviors such as the default result set, whether bounces are scoped to a particular stream or user, or the shape of returned data. The annotations (readOnlyHint, openWorldHint) cover safety but not these details.

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. It conveys the verb, resource, and key behaviors efficiently. 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?

Despite having no output schema, the description does not explain what a bounce record contains or what the response format is. It also omits whether pagination has a default order or whether filters are inclusive/exclusive. For a list tool with five optional parameters, this leaves meaningful gaps for an agent to resolve 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 100%, so parameters are fully documented in the schema. The description adds a conceptual grouping ('filtered' maps to tag/query/status; 'paginated' maps to page/per_page), but does not add meaning beyond the schema's individual descriptions. This meets the baseline for high 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 states a clear verb ('List') and a specific resource ('bounced messages'), which distinguishes it from siblings like list_emails and list_inbound. It implies filtering and pagination, but does not explicitly contrast it with other list tools or state the exact scope (e.g., global vs. per-stream), so it stops short of full sibling differentiation.

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

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

No guidance is provided on when to use this tool versus list_emails, get_email, or list_inbound. The description simply states the resource and behavior, leaving the agent to infer selection from the name. There are no explicit conditions, alternatives, 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?

Annotations already mark the tool as read-only and open-world, covering the safety profile. The description adds useful behavior details like newest-first ordering and stream narrowing, but doesn't disclose pagination, limits, or return shape. 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?

The description is two short sentences with no wasted words. The action and scope are front-loaded, and the second sentence earns its place by explaining the only parameter.

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

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

For a simple read-only list tool with one optional parameter, the description covers purpose, ordering, and filtering. It doesn't explicitly state that omitting stream returns all campaigns or describe returned fields, but those are inferable and no output schema exists.

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

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

Schema coverage is 100%, and the schema already describes stream as 'Limit to one broadcast stream.' The description repeats the same concept with 'narrow,' adding no new semantic detail beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('List'), identifies the resource ('broadcast campaigns'), and states ordering ('newest first'), making the tool's purpose immediately clear. It also distinguishes itself from sibling tools such as list_streams and get_campaign.

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

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

The description explains exactly how to use the optional stream parameter: 'Pass stream to narrow to one broadcast stream.' It gives clear invocation context but doesn't explicitly mention alternatives like get_campaign for a single campaign or state when not to use this 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?

Annotations already mark it readOnly and openWorld, so the safety profile is covered. The description adds the ordering guarantee ('newest first') and summarizes the filterable dimensions, but it does not disclose return shape, pagination defaults, or how filters combine. Given the annotations, 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 short sentences, with the action and ordering front-loaded and the filter list in the second sentence. 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 read-only, filterable list endpoint, the description plus fully described schema covers what an agent needs: resource, ordering, available filters, and pagination parameters. No output schema exists, but the absence of a return-shape statement is not critical for a list tool with these annotations.

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

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

All 7 parameters are documented in the schema (100% coverage), so the baseline is 3. The description merely recaps the filter categories already present in the schema without adding semantics such as format, defaults, or interaction between filters.

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 the specific verb 'List' and the resource 'messages of the CamelMailer server', then adds ordering ('newest first'). This makes it clearly a read-only listing tool and distinguishes it from single-item getters like get_email and from list_streams/list_campaigns by 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?

It states the primary use case (listing messages) and enumerates the available filter dimensions, giving an agent clear context for when to call it. It does not, however, name any alternative tools or exclusion conditions, so it stops short of explicit 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?

Annotations already declare readOnlyHint=true, so the description doesn't need to establish safety. It adds useful behavioral details such as 'newest first' and the held-message nuance, but does not describe pagination behavior or result shape. This is comparable to a baseline where annotations cover the core behavioral profile.

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 with no filler. The core purpose and ordering are front-loaded, and the scope expansion about held messages is placed second without wasting 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 read-only list tool with five fully documented optional parameters and no output schema, the description provides enough context: what is listed, ordering, and which message categories are included. It does not describe the output envelope, but that is a minor gap for a simple list operation 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 description coverage is 100%, so all five parameters are already documented. The description adds no additional parameter-level meaning, which matches the baseline of 3 for fully covered schemas.

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 action and resource: 'List inbound and held messages, newest first.' It clearly defines the scope, including the non-obvious inclusion of outbound mail held by the spam filter, which distinguishes it from sibling tools like get_inbound or list_emails.

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 on what the tool covers: inbound-route mail and spam-filter-held outbound mail. It does not explicitly name alternatives or state when not to use it, but the coverage description is enough to guide selection.

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 openWorldHint, so the safety and mutability profile is covered. The description adds useful domain context—layouts wrap templates and centralize header/footer/styling—but does not describe behavioral details like response shape or ordering. There is no contradiction with the annotations.

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

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

The description is two short sentences with no filler. The core operation is front-loaded, and the second sentence adds meaningful domain context without unnecessary 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?

For a zero-argument, read-only listing tool, the description is sufficient: it states what is returned and explains what a layout is. The absence of an output schema is acceptable given the simplicity of the operation and the presence of a get_layout sibling for detailed access.

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 are no parameter semantics to document. The baseline of 4 for zero-parameter tools is appropriate, and the description does not misleadingly imply any 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 names the operation ('List') and resource ('template layouts of the server') precisely, making it clear this returns the set of layouts rather than one layout. It does not explicitly contrast with get_layout or list_templates, so it falls just short of fully distinguishing itself from 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 implies its use case: retrieving all template layouts. However, it gives no explicit guidance about when to choose this over get_layout, create_layout, or list_templates, and it mentions no exclusions or conditions.

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, so the read-only nature is covered. The description adds useful context about the two stream categories and their relationship to campaigns and subscribers, helping the agent interpret results without contradicting any annotation.

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 fluff. The action is front-loaded in the first sentence, and the second sentence adds domain context that 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 no-parameter list operation with readOnly and openWorld annotations, the description is sufficient to invoke the tool. It explains what a stream is and names the categories, and no output schema is required.

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

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

The tool has zero parameters and schema description coverage is 100%, so there is no missing parameter information. The description adds no param-specific details because none are needed; baseline 4 for zero-parameter tools is appropriate.

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

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

States a specific verb ('List') and resource ('message streams of the server') with a clear scope. Distinguishes stream types (transactional vs broadcast) and relates broadcast streams to campaigns/subscribers, differentiating from sibling tools like get_stream or list_campaigns.

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

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

The description establishes the general use case (enumerate all streams) and provides meaningful domain context about which streams carry campaigns and subscribers. However, it never explicitly contrasts with alternatives such as get_stream for a single stream or create_stream for creating, so when-not guidance is left to inference.

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

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

Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: the list includes both subscribed and unsubscribed addresses, and it defines the broadcast audience. This goes beyond the safety hint without contradicting it.

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

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

Two concise sentences deliver the core purpose and the important audience implication without any wasted words. The main action 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 single-parameter read-only tool, the description provides enough information to select and call it correctly. It could mention the returned data shape, but the lack of an output schema is not a serious gap given the straightforward 'list' purpose.

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 100% parameter description coverage, with 'permalink' documented as 'Broadcast stream permalink.' The tool description does not need to add parameter details, 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?

States a specific verb and resource: 'List a broadcast stream's subscribers.' The phrase 'subscribed and unsubscribed alike' clarifies the exact scope and distinguishes this tool from subscriber-management siblings like add_subscriber and remove_subscriber.

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 usage context by explaining that non-subscribed addresses will be refused for broadcast sends, so this list represents the actual audience. It does not name explicit alternative tools or when-not-to-use conditions, but the intended use case is evident.

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 and openWorldHint=true, so the safety profile is known. The description adds useful behavioral context beyond that: the data source scope ('recent messages'), the order ('most used first'), and the relationship to list_emails filtering. This meaningfully enriches the definition.

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

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

One compact sentence conveys source, ordering, and purpose without any filler or redundancy. Every phrase earns its place, and the most identifying 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 zero-parameter, read-only list tool, the description is nearly complete. It explains what is returned conceptually and how the result relates to list_emails. It does not detail the exact return shape or per-tag fields, but the absence of parameters and output schema makes that a minor gap.

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

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

The tool has zero parameters, so the schema carries no parameter burden and the baseline is 4. The description adds domain context about what the tags represent, but there are no parameters to document.

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 identifies a specific resource (tags), scopes it to the server's recent messages, and gives the ordering (most used first). It also ties the resource to its intended consumer (the tag filter of list_emails), making its purpose unambiguous and distinguishable 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?

The description clearly conveys when to use the tool: when you need the vocabulary of valid tags accepted by list_emails' tag filter. It does not explicitly state exclusions or compare against alternatives, but the consumer reference is strong enough context for correct use.

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 and openWorldHint, so safety and world-scope are covered. The description adds the scope 'all stored... of the CamelMailer server,' which is useful, but it does not disclose output format, ordering, or pagination behavior. It does not contradict the annotations.

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

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

The description is one short, front-loaded sentence with no filler. Every word earns its place and the key action and resource are immediately clear.

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 list operation with read-only and open-world annotations, the description is largely complete. The only minor gap is the lack of detail about the return value shape, but this is not critical for correct invocation of a parameterless listing 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 tool has zero parameters, and the input schema is essentially empty. The baseline for zero-parameter tools is 4, and the description does not need to add parameter-level details. It correctly describes the operation without inventing parameter semantics.

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 verb and resource: 'List all stored message templates of the CamelMailer server.' It is unambiguous and distinguishes templates from sibling resources like layouts or emails, although it does not explicitly name an alternative tool.

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 usage is implied rather than explicitly stated: an agent would use this tool when it needs to enumerate available message templates. There are no explicit when-to-use/when-not-to-use instructions or references to alternatives, but the purpose is simple enough that the context is fairly obvious.

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?

Even with destructiveHint and openWorldHint annotations already set, the description adds valuable behavioral detail: it writes a stream-scoped suppression, flips subscription status, and is idempotent so replays are safe. This goes beyond the annotation flags and does not contradict 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?

Two tight sentences front-load the primary action, immediately state side effects, and add the idempotency caveat. No filler or repetition of schema 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?

For a two-parameter mutation with full schema coverage and relevant annotations, the description covers purpose, effects, and replay safety. No output schema exists, but the description does not need to explain return values for this simple 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%, giving baseline 3, but the description adds relational meaning by tying 'address' to the complaint target and 'permalink' to stream scope ('writes a stream-scoped suppression'). This is more than the schema's one-line parameter descriptions 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 opens with a specific verb and resource ('Record a spam complaint against an address') and details the exact effects: a stream-scoped suppression plus an unsubscribed flip. This clearly differentiates it from sibling tools like list_bounces or remove_subscriber.

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 actionable context: it is for spam complaints and is safe for feedback-loop replays because it is idempotent. It does not explicitly contrast with alternatives such as remove_subscriber, so it misses the top score for explicit when-not/alternatives.

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

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

Annotations already declare destructiveHint=true, so destructive behavior is covered. The description adds value by specifying 'entirely' and contrasting with the status-based unsubscription, clarifying the irreversible nature of removal. It does not contradict annotations and provides context beyond the structured data.

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 action and then provide the alternative. Every word earns its place; 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 simple mutation tool with two fully described parameters and destructiveHint annotation, the description sufficiently covers the decision-making context. It explains the core behavior and the alternative path, and no output schema exists to explain. The only minor gap is lack of explicit statement about permanent deletion, but destructiveHint and 'entirely' imply it adequately.

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

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

Schema description coverage is 100%, with both parameters (address and permalink) already documented with clear descriptions. The description adds no additional parameter information, so it meets the baseline but does not exceed it.

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: 'Remove a subscriber from a broadcast stream entirely.' It names the specific resource (broadcast stream) and the entity (subscriber), and contrasts with the sibling add_subscriber by noting the alternative for unsubscribing. This unambiguously distinguishes the tool from its siblings.

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

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

The second sentence explicitly provides when-not-to-use guidance: 'To stop mailing someone while keeping the record, set their status to unsubscribed with add_subscriber instead.' It names the alternative tool and the condition that selects it, leaving no ambiguity about when to choose removal versus unsubscription.

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, so the no-side-effect behavior is partially covered. The description adds valuable specifics: it returns rendered subject, html_body, and text_body, and reinforces the non-sending guarantee. This goes beyond what the annotations alone provide and helps the agent understand observable results.

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 conveys the action, target, output fields, and side-effect guarantee with no filler. The key distinction from sending tools is placed at the end for emphasis but remains immediately clear.

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 preview tool with only two parameters, full schema coverage, and readOnly annotations, the description covers inputs, outputs, and non-side effects completely. No critical information is missing, and the lack of an output schema is compensated by explicitly naming the rendered fields.

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

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

Schema description coverage is 100%, with both template and template_model already described in the input schema. The description's phrase 'variable model' loosely maps to template_model but adds no new semantic detail beyond the schema. This meets the baseline for schema-covered parameters but does not elevate it.

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 ('Preview') and resource ('stored template rendered against a variable model'), and clearly lists the return values: rendered subject, html_body, and text_body. It explicitly differentiates itself from sending tools with the phrase 'without sending anything,' making its purpose distinct from siblings like send_email and send_email_with_template.

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 this tool is for testing/previewing templates before sending, and the 'without sending anything' clause rules out the sending alternatives. It does not explicitly name sibling tools or provide a when-not-to-use list, but the context is unambiguous enough for an agent to select it 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 signal destructiveHint and openWorldHint, so the description does not need to repeat those. The description adds the core redelivery behavior, but it does not disclose side effects, idempotency, or whether routing is re-evaluated beyond the implied 'back on the delivery queue.'

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, front-loaded sentence with no filler or redundant restatement of the tool name. The example use case is compact and adds meaningful context without bloating the description.

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 operation with annotations and full schema coverage, the description is largely complete. It could explicitly mention obtaining the id from list_inbound/get_inbound, but the low complexity and clear schema make this a minor gap rather than a critical omission.

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

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

Schema coverage is 100% and the single id parameter is already described as a numeric message id. The description adds no additional meaning beyond the schema, so it meets the baseline without needing to compensate.

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 ('Put an inbound message back on the delivery queue') and the resource (inbound message), making the tool's purpose immediately understandable. It is distinguishable from related siblings like list_inbound, get_inbound, and bypass_inbound by the redelivery framing.

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 'for instance after fixing the route it should have matched' provides a concrete scenario, giving some usage context. However, it does not explicitly contrast retry_inbound with alternatives like bypass_inbound or state when retry is not 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?

Beyond the destructiveHint annotation, the description adds meaningful behavior: the send starts immediately and 'cannot be undone for messages already queued'. This clarifies the irreversibility and timing consequences in a way the annotation alone does not.

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 and front-loaded, with the core action in the first sentence. There is minor redundancy between 'SENDS... NOW' and 'The send starts immediately', but the text is otherwise efficient and free of 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 one-parameter destructive tool with no output schema, the description covers the key operational facts: immediate send, schedule override, and irreversibility. It does not explain error behavior or what happens if the campaign is invalid, but those are not essential given the tool's simplicity.

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

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

Schema description coverage is 100%, and the sole required parameter 'id' is documented as a 'Numeric campaign id'. The description adds no extra parameter-level meaning, but the schema already carries the burden adequately, so baseline 3 applies.

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

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

The description clearly states the action and object: 'SENDS AN EXISTING CAMPAIGN NOW', with additional detail about overriding the existing schedule. However, it does not differentiate this tool from the sibling send_campaign_now, which appears to describe essentially the same operation, so it misses the 5-level sibling distinction.

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

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

The phrase 'whatever its schedule said' implies this tool is for sending immediately regardless of scheduled time, but the description provides no explicit when-to-use or when-not-to-use guidance and does not mention alternatives such as send_campaign_now. Context is implied rather than stated.

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

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

The description discloses that there is no draft to review, no schedule, and that the send starts before the function returns. These are behavioral traits beyond what the annotations provide. The annotations already declare destructiveHint=true, so the description's emphasis on immediate sending complements rather than contradicts the annotation. It could add more about irreversibility or recipient count, but it already covers the key behavioral risk.

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 waste. The critical behavioral warning is front-loaded, the alternative is named, and the condition for choosing this tool is stated. 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 destructive, immediate-send tool with no output schema, the description covers the essential context: what happens, when it happens, and which sibling to use instead. It doesn't mention that the send is irreversible or that it sends to all subscribers, but the destructiveHint annotation and the phrase 'every subscriber of the stream' already cover those. The description is complete enough 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 the schema already documents all six parameters. The description adds context about the 'permalink' being a broadcast stream and 'name' being a display name, but it doesn't add meaning beyond what the schema provides. Baseline 3 is appropriate because 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 ('CREATES A CAMPAIGN AND SENDS IT IMMEDIATELY') and a specific resource ('every subscriber of the stream'), and it explicitly distinguishes itself from the sibling tool create_campaign_draft. This makes the tool's purpose unmistakable and differentiates it from the many campaign-related 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 explicitly says when to use this tool ('unless the mail really should go out now') and names the alternative ('Use create_campaign_draft'). This is exactly the kind of when/when-not guidance an agent needs to select between send_campaign_now and create_campaign_draft.

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 signal openWorldHint and destructiveHint, but the description adds meaningful behavior beyond them: it queues messages, processes one per recipient, and returns ids. This gives the agent a clearer picture of side effects and what to expect after invocation.

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 convey the core purpose, input expectations, and outcome. There is no filler, and the key behavior 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?

With the schema covering all parameters and annotations providing the high-level behavioral hints, the description supplies the essential missing context: transactional nature, queueing behavior, and per-recipient result ids. It does not detail response structure or idempotency behavior, but the description is adequate for selecting and invoking 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?

Schema description coverage is 100%, so the baseline is 3. The description adds value by specifying that html_body and/or text_body can be provided and that the tool queues one message per recipient, which clarifies the semantics of the to array and body parameters 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 states a specific verb and resource: send a transactional email through CamelMailer. It also clarifies the delivery model by saying one message is queued per recipient and their ids are returned. It doesn't explicitly contrast with send_email_with_template, but 'transactional' and direct html_body/text_body hint at the distinction.

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 transactional emails with direct bodies, as opposed to template-based sending. However, it does not explicitly name alternatives or state when not to use it, leaving some inference to the agent.

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 explains non-obvious behavior: template rendering against template_model and the rule that directly set fields like subject override rendered values. These details go beyond the annotations and make the tool's runtime behavior clearer, which is especially useful given destructiveHint and openWorldHint.

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 core action is stated first, followed by a meaningful behavioral note about field overrides, 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?

Given 11 parameters packed into a 100%-covered schema and no output schema, the description covers the essential high-level semantics: what the tool does, how template rendering works, and how parameter precedence behaves. It does not fully compensate for missing usage guidance around sibling tools, but it is complete enough 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 coverage is 100%, so the baseline is 3. The description adds value by explaining how parameters interact: template_model supplies placeholder variables)Skip, and direct fields override rendered results. This clarifies the relationship between template_model, subject, and other overridable fields beyond their individual schema descriptions.

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

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

The description clearly states a specific action: render a stored CamelMailer template against template_model and send it. It also adds distinctive details (Mustache-style variables and override behavior) that help differentiate from sibling tools like send_email and render_template, though it doesn't explicitly name those 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?

Usage context is implied: use this tool when you want to render a stored template and send the resulting email. However, it doesn't explicitly say when to choose this over send_email (for direct content) or render_template (for rendering only), nor does it mention any exclusions or prerequisites beyond what the schema provides.

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 mark this as openWorldHint and destructiveHint, and the description adds meaningful behavioral context: it sends immediately, reaches every subscriber, enforces a per-request cap of 1000, and reports excess recipients as skipped. 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 only two sentences, front-loads the core action, and every clause earns its place: the immediate broadcast behavior, the input alternatives, the cap, and the campaign routing guidance. 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?

For a 7-parameter destructive tool with no output schema, this description covers the key operational facts: immediacy, recipient scope, input modes, the cap, and the fallback for larger audiences. It does not spell out every edge case, but the schema covers parameter syntax and the annotations cover the safety profile.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantic value by framing the valid combinations (subject/body versus template) and by flagging the 1000-recipient cap that affects how the request should be constructed. It does not need to re-describe each parameter since the schema already does.

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 ('sends mail immediately') and resource ('every subscriber of a broadcast stream'), which clearly distinguishes this from single-recipient siblings like send_email/send_email_with_template and from scheduled campaigns. It also clarifies the immediate-send nature of the 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 gives explicit instructions on acceptable input modes ('either a subject with a body, or a template permalink') and explicitly routes larger audiences to a campaign instead. It does not explicitly name sibling alternatives, but the campaign reference and per-request cap give usable selection 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 behavioral burden. It transparently describes the schedule-state transitions: scheduling, unscheduling, and leaving the schedule untouched, plus the cannot-edit-sending restriction. It does not cover partial-update semantics or conflict behavior if both scheduled_at and clear_schedule are supplied, which keeps it from a 5.

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

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

Three short sentences with no filler. The first states purpose, the second explains the scheduling mechanism, and the third gives the critical constraint—each sentence earns its place and the 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 mutation tool with no annotations and no output schema, the description covers the most important state behavior and constraints. The main gap is that it does not explicitly state whether unspecified fields are left unchanged or whether the two schedule-related parameters are mutually exclusive, but the rich per-parameter schema reduces the impact.

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 every parameter; the baseline is 3. The description adds genuine semantic value by explaining how scheduled_at and clear_schedule interact ('Touching neither leaves the schedule standing'), which is not inferable from the schema alone.

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 precise verb-resource statement: 'Edit a draft or scheduled campaign,' and further qualifies the operation by mentioning scheduling state. This distinguishes update_campaign from adjacent tools such as create_campaign_draft, send_campaign_now, and cancel_campaign. There is no tautology or 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 clearly states the intended use case (draft or scheduled campaigns) and gives an explicit exclusion: 'A campaign that is already sending cannot be edited.' Scheduling-specific guidance (set scheduled_at vs clear_schedule) also tells the agent how to achieve the desired state. It does not name sibling tools as alternatives, so it stops just short of full routing.

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

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

With no annotations, the description carries the burden. It does disclose that only the given fields change, which is a key behavioral trait (partial update). However, it does not mention return behavior, error handling, or any side effects. The description adds some value but is far from comprehensive 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 short sentences with zero filler. The purpose is front-loaded, and the behavioral note follows. This is an appropriately concise description.

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

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

For a mutation tool with no annotations and no output schema, the description is incomplete. It does not state what the tool returns, whether it requires the layout to exist, or any error conditions. The partial-update note is helpful, but the agent lacks critical information to invoke and interpret the result 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 each parameter is already documented. The description adds no additional meaning beyond the schema; 'Only the given fields change' reiterates that omitted fields are untouched, which is somewhat implicit from the schema. Baseline is 3 because 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 clearly states 'Update a layout' – a specific verb and resource. It distinguishes from siblings like create_layout, delete_layout, and get_layout by the update intent. The phrase 'Only the given fields change' adds clarity that this is a partial update, differentiating it from a full replacement. This is a strong statement of 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?

No explicit guidance on when to use this tool versus alternatives. It doesn't mention that it requires an existing layout permalink (implied by schema) or that create_layout is for new layouts. The agent must infer usage from the tool name and sibling list. No prerequisites, exclusions, or alternative routing is 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?

With no annotations provided, the description carries the behavioral disclosure burden. 'Only the given fields change' is a useful and explicit partial-update guarantee: unspecified fields keep their value. However, it does not disclose permissions, side effects, irreversibility, or what response to expect from this mutating 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 extremely concise and front-loaded: the verb, resource, and the only meaningful behavioral constraint are stated in two short sentences. There is no filler or redundancy, and the schema carries the remaining parameter 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 4-parameter update tool with a fully documented schema, the core partial-update semantics are present. However, there is no output schema and no description of the return value or error behavior, and the relationship to archive_stream is left unresolved, so an agent has some gaps when invoking 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?

Schema description coverage is 100%, so the individual parameter meanings are already fully documented. The description adds one valuable cross-parameter semantic—omitted optional fields are left unchanged—but does not need to explain each parameter further.

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 ('Update') and the resource ('a message stream'), and adds the key partial-update semantic that only provided fields change. This is enough to distinguish it from create/get/archive siblings at a basic level, though it does not explicitly name the dedicated archive_stream alternative.

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

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

No guidance is given for when to use this tool versus siblings such as archive_stream, which overlaps on the archived field. The description implies general stream updating but does not state exclusions, prerequisites, or routing conditions, so the agent must infer usage.

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