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

Annotations already declare destructiveHint and idempotentHint=false, and the description adds real value beyond them by clarifying the side-effect boundary: subscriber status is untouched. It stops short of warning about irreversibility or behavior on a nonexistent id.

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, front-loaded with the action, zero filler. The clarifying constraint follows immediately rather than being buried.

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-param destructive delete with full annotations and no output schema, the description covers the essential gotcha. Missing only minor behaviors like error-on-missing-id vs silent no-op.

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

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

Only one required parameter with 0% schema description coverage. The description says 'by id' but adds no format detail (positive integer, exclusiveMinimum 0) beyond the brief phrase, so it minimally compensates for the undocumented schema.

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

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

States a specific verb+resource ('Delete a bounce record by id'), which clearly distinguishes it from bounces_search and bounce_get. It does not explicitly contrast with other delete tools, but the resource is unambiguous.

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

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

Explicitly names the boundary case and the alternative: deleting a bounce 'does not change the subscriber's status; use subscriber_update to re-enable a subscriber.' This routes the agent away from a common mistaken use, though it doesn't say when deletion itself is warranted.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — no note on behavior for a missing/invalid id, no auth or rate-limit context.

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

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

It is a single short fragment with no waste, but it is under-specified rather than efficient — there is essentially only one clause and no front-loaded verb to anchor it.

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 retrieval tool with no output schema and no annotations describing returns, the description should say what a bounce record contains or what happens on not-found. Neither is present, leaving the agent with little beyond the id contract.

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

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

Schema description coverage is 0% and the description only repeats 'by id' without adding format, range, or source guidance (e.g., where bounce ids come from, whether ids are campaign-scoped). It does not compensate for the undocumented parameter.

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 that it retrieves a single bounce record by id, which implicitly distinguishes it from bounces_search (plural) and bounce_delete. However, it never uses an explicit verb like 'get'/'fetch' and largely restates the tool name plus the obvious parameter.

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 indication of when to use this versus bounces_search or when a bounce id would be known. No alternatives, prerequisites, or conditions are named.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the useful 'newest first' ordering guarantee, but omits pagination behavior, result size limits, and what an empty result means.

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 compact sentences with the resource and ordering front-loaded and filters second; no filler. It is terse to the point of omitting a verb, but nothing is wasted.

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

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

With no output schema and 0% parameter description coverage, the description should do more to explain the paginated result shape and the page/per_page controls. An agent can call it, but will be guessing about pagination and total counts.

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 0%, so the description carries some burden; it does spell out the valid type values (soft, hard, complaint) and that campaign refers to campaign_id. However page and per_page are never mentioned, leaving half the parameters explained only by their schema constraints and defaults.

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 the resource (bounces) with an explicit ordering (newest first) and the two filter dimensions, which lets an agent distinguish it from bounce_get or bounce_delete. It never uses a verb like 'search' or 'list', so the intended read-and-filter behavior is inferred from the name rather than stated.

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 filter list implies this is the tool for finding bounces by type or campaign, but there is no explicit statement of when to use this versus bounce_get (single record) or other search tools, and no prerequisites or exclusions are given.

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

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

Annotations flag it as a non-readonly, non-idempotent, open-world write, and the description adds real context beyond that: creation only produces a draft and no email goes out until a separate status change. It doesn't mention required permissions or whether a campaign id is returned, but the draft/deferred-send semantics are a meaningful addition over the annotations.

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

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

Two tight sentences, front-loaded with the create-a-draft purpose followed by the sending constraint. 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 10-parameter mutation tool with 20% schema coverage and no output schema, the description is thin. It omits parameter guidance and doesn't state what comes back (e.g., a campaign id) or permission requirements, though the draft/send-deferral framing covers the most important behavioral risk.

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

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

Schema coverage is only 20% across 10 parameters, so the description must compensate, but it names no parameters at all. The nuances of body/template_id, list_ids, content_type, and send_at scheduling are left entirely to the under-documented schema.

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

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

States a specific verb and resource (create a campaign) plus the resulting state (draft), and distinguishes itself from campaign_set_status, which handles sending. An agent can tell exactly what this does versus the status-mutating sibling.

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

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

Explains the key selection condition: use this to build a draft, nothing is sent until campaign_set_status runs it. That clear routing to the send sibling is strong, though it doesn't address when to use campaign_create vs campaign_update for an existing campaign.

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 and idempotentHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the collateral damage (view and click statistics are destroyed) and the server-side rejection condition for running campaigns. It stops short of saying the deletion is irreversible or how it errors.

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

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

Two short sentences, zero filler, with the permanence warning and destruction scope front-loaded. Nothing repeats the title verbatim without adding information.

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

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

For a one-parameter destructive tool with full annotation coverage and no output schema, this covers the essentials: what is destroyed, what side effects occur, and what causes failure. The only missing pieces are irreversibility/auth requirements and the error behavior.

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

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

Schema coverage is 0% and the single parameter is undocumented in the schema, so the description would ideally explain that 'id' is the campaign identifier. In practice the tool name plus the parameter name make this unambiguous, so the gap is minor but not nothing.

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 ('Permanently delete') and resource ('a campaign'), and adds the scope of what is removed ('and its view and click statistics'). This distinguishes it clearly from campaign_set_status and campaign_update, which also operate on 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?

It gives one concrete usage constraint — running campaigns cannot be deleted — which is genuinely useful for avoiding a failed call. However, it never names the alternative path (e.g., stop the campaign via campaign_set_status first) or states prerequisites such as permissions or confirmation requirements.

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

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

Annotations already declare this as a read-only, idempotent, non-destructive operation, so the safety profile is covered. The description adds useful return-content context (body, lists, send statistics) but does not mention authorization needs, rate limits, or behavior when the id is not found.

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 wasted words. It states the resource, lookup key, and returned payload immediately.

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 lookup with one required id, the description is nearly complete: it explains the lookup and what the response includes. It does not cover not-found behavior, but that is a minor omission given the tool's simplicity and 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?

There is only one parameter, and the schema coverage is 0%. The description confirms that 'id' is a campaign identifier, which is marginally useful, but it does not explain the id's origin or format beyond what the field name and integer schema already imply.

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

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

The description clearly states that this retrieves a single campaign by id, and it names the returned content (body, lists, send statistics). It distinguishes itself from campaigns_search by the singular, id-based scope, though it does not explicitly name the sibling 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?

Usage is implied: use this when you have a campaign id and need the full campaign record. However, the description does not explicitly contrast this with campaigns_search or state when not to use it.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the description's real contribution is the irreversible side effect: 'running' SENDS EMAIL immediately. That is high-value context beyond the annotations. It falls short of explaining whether 'cancelled' aborts an in-flight send or whether paused can be resumed mid-send, which matters for a destructive 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?

Three short sentences, front-loaded with the action list and immediately followed by the highest-risk behavior. Minor friction: 'resume' is listed as an action but is not an enum value, forcing the agent to infer it maps to 'running'.

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, non-idempotent, open-world mutation with no output schema, the critical warning about immediate sending is present, but gaps remain around cancellation semantics, irreversibility, and how the 'id' is resolved.

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 0%, so the description must carry parameter meaning, and it only explains two of the four enum values (running, scheduled). 'paused' and 'cancelled' are left undefined, and the 'id' parameter is never described as the campaign identifier.

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

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

Names the exact lifecycle actions (start, schedule, pause, resume, cancel) applied to a campaign, which distinguishes it cleanly from campaign_update (field editing) and campaign_test_send (test delivery). An agent can identify the tool's job 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?

Gives a clear operational precondition ('Confirm the recipient lists and body before using') and explains what two of the status values do. It does not explicitly state when to choose this over campaign_update or campaign_test_send, so it stops short of full alternative routing.

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

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

Annotations already declare readOnly, idempotent, non-destructive read semantics, so the description carries little extra burden — but it adds nothing behavioral at all: no result ordering, no default result set when status is omitted, no statement about what happens with no matches.

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, leading with the core action. Listing all six enum values is slightly redundant with the schema but arguably helps the agent pick a valid status, so the verbosity is defensible.

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 search tool with zero schema description coverage and no output schema, the description leaves pagination, default page size, search matching behavior, and result ordering entirely unaddressed — an agent cannot predict what it will get back or how to page.

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

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

Schema description coverage is 0%, so the description must compensate; it only restates the status enum and mentions 'query text' loosely, leaving both pagination parameters (page, per_page) completely undocumented in either schema or description.

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 campaigns') and names the two filter axes, which cleanly separates it from campaign_get and campaign_create. It doesn't explicitly name a sibling, so it stops short of full 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?

Usage is only implied by the word 'List' plus filters; there is no statement of when to choose this over campaign_get or listmonk_dashboard_counts, and no note on defaults or preconditions.

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 non-read-only, open-world, and non-idempotent. The description adds the important behavioral fact that it sends real email to the listed addresses, which is valuable beyond the annotations, though it does not discuss repeat-send behavior or campaign-state constraints.

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, front-loaded with the core action and followed immediately by the critical real-mail side effect. No unnecessary text.

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

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

For a simple two-parameter operation with annotations already covering mutability and external effects, the description supplies the key missing context: it sends actual email and is limited to test recipients. It could say more about prerequisites such as campaign status, but is largely complete.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies that 'id' refers to a campaign and 'emails' are recipient addresses, but it does not document the positive-integer constraint on id or add much beyond the schema's email format and maxItems.

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 test copy of a campaign. The phrase 'test copy' distinguishes this from campaign_set_status and other campaign mutation 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 this is for previewing/testing a campaign before real sending, but it does not explicitly state when to use it instead of campaign_set_status, tx_send, or smtp_test.

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

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive mutation, and the description adds a materially useful behavior the annotations do not: the state gate limiting edits to draft/scheduled/paused campaigns. It stops short of saying what error surfaces or whether changing list_ids drops subscribers, but the state restriction is the key operational fact.

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

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

Three short sentences, each carrying distinct information: what it does, how partial updates behave, and the state precondition. No filler and the important constraint is not buried.

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 10-parameter mutation with no output schema and 0% schema coverage, the description covers the two biggest failure modes (partial updates, campaign state) but leaves every parameter's meaning and validation undocumented. It is adequate to attempt the call safely but not to construct fields correctly without reading the raw 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 0% across 10 parameters, so the schema names fields but explains none of them. The description only adds the partial-update rule ('only the fields you pass change') and says nothing about id, list_ids, send_at null semantics, content_type enum values, or field interactions — the compensating value is thin relative to the coverage gap.

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

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

States a specific verb and resource ('Update a campaign') with no ambiguity about what entity is affected. It does implicitly distinguish itself from campaign_set_status by describing field-level edits, but never names that sibling, so the differentiation is left to inference.

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 precondition ('only allows edits while the campaign is a draft, scheduled, or paused'), which tells the agent when the call will fail. However it never states when to use this versus campaign_set_status or campaign_delete, nor does it say what to do if the campaign is in another state.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the description's bar is lower, but it adds nothing: no mention of what happens on duplicate names, what the default type/optin actually mean, or what is returned. The only substantive sentence restates values already present in the schema.

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

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

Two short, front-loaded sentences with no filler. It is terse to the point of being telegraphic, but nothing is wasted.

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

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

For a mutation tool with a 5-parameter schema, no output schema and 0% schema coverage, the description omits most of what an agent needs: the semantics of tags and description, default values, and error behavior on duplicate list names.

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

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

Schema description coverage is 0%, so the description must compensate, yet it only mentions 'type' and 'optin' and merely echoes their enum values already visible in the schema. The required 'name', plus 'tags' and 'description', are given no meaning at all.

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

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

States a specific verb+resource ('Create a mailing list'), which cleanly separates it from list_update, list_delete and lists_list. It doesn't explicitly name those siblings, so it falls just short of a 5.

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

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

No guidance on when to use this versus list_update or lists_list, no mention of prerequisites such as authentication or uniqueness of the name. The agent must infer usage entirely 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 destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuine value beyond that by disclosing the cascade: subscriptions are removed while subscriber records survive, which an agent cannot infer from annotations or schema.

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

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

Two short sentences, zero filler, with the permanence warning and the resource front-loaded before the side-effect clause.

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

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

For a single-parameter destructive tool with rich annotations and no output schema, this covers the essentials: what is deleted and what is preserved. It does not address failure modes (e.g. an unknown id, or a list still referenced by campaigns), which would be the remaining useful detail.

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

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

Schema description coverage is 0% for the single 'id' parameter, so the description must compensate. 'by id' does establish that the id identifies the list (not a subscriber or campaign) and that lookup is by primary identifier, but it adds no constraints such as positivity or format.

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 ('Permanently delete a mailing list by id'), which separates it from list_update/list_create/list_get by verb alone. It stops short of naming a sibling or the alternative action (e.g. deactivate vs delete), so it is clear but not fully differentiated.

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 word 'Permanently' signals this is the irreversible-removal path rather than an update, so usage is implied. There is no explicit when-to-use/when-not guidance, no mention of the alternative (list_update) and no prerequisites or preconditions 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?

Annotations already establish this as a read-only, idempotent, non-destructive operation. The description adds no behavioral context beyond the id lookup, such as what happens when the id is not found or whether authentication is required.

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 short with no wasted words, but it is a sentence fragment that is under-specified rather than optimally concise.

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

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

For a simple read tool with annotations but no output schema, the description should at least clarify the return value or error behavior. It does neither, leaving gaps that matter for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It only says 'by id' without explaining the id's source, constraints, or how to obtain a valid id, leaving the single parameter largely documented by its name 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 states a specific resource and scope: retrieving a single mailing list by its id. It is clear enough to distinguish a single-list lookup from the sibling lists_list tool, though the verb is implied rather than explicitly stated.

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 guidance on when to use this tool versus lists_list or other list-related siblings. The description gives no context, prerequisites, 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds the meaningful behavioral detail that the counts span the whole instance (no filtering), but says nothing about cost, caching, or freshness of the totals.

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

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

One sentence, front-loaded with the scope ('across the instance') followed by the counted categories. No wasted words; only slight terseness prevents a 5.

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

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

With no output schema, the description compensates by naming the return contents (subscribers by status, lists, campaigns, messages). Combined with annotations covering safety and idempotency, an agent has enough to call it correctly; exact field names would be nice but are not essential.

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 takes zero parameters, so the baseline is 4. The description correctly implies no scoping/filter input is possible, consistent with the empty schema.

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

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

States a specific resource (dashboard totals) and enumerates what is counted: subscribers by status, lists, campaigns, messages. This distinguishes it from listing tools like lists_list or campaigns_search, though it doesn't explicitly say 'returns aggregate counts only, not records'.

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

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

Usage is implied by 'Totals across the instance' — an agent can infer this is the summary/statistics tool rather than a listing tool. However, no explicit when-to-use guidance or named alternatives (e.g. use lists_list for per-list details) are given.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds genuinely new context with 'ring buffer, not persisted,' warning that results are ephemeral and bounded, but it omits how many lines are returned, ordering, or truncation 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?

A single tight sentence with zero filler, and the ephemerality caveat is packed into the same clause rather than buried later.

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

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

With no output schema and no parameters, the description is the only source for return shape, yet it gives no sense of volume, ordering, or line format. For a zero-arg tool this is acceptable but leaves the agent guessing what it will actually receive.

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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-related gaps exist.

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

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

States the specific resource returned — recent Listmonk application log lines — and adds a key qualifier about the ring buffer. It does not name a sibling it differs from (e.g., listmonk_status), but the resource is distinctive enough that an agent can distinguish it from status/counts 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?

No explicit guidance on when to use this versus listmonk_status or dashboard_counts for diagnostics. The 'not persisted' note implies a debugging/troubleshooting context, but that must be inferred rather than read.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered structurally. The description adds genuinely non-obvious context: secrets in the returned settings are replaced with [redacted], which tells the agent why credentials will appear masked and prevents pointless retries or workarounds. It stops short of describing the shape of the settings object.

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, zero waste, with the resource identified first and the redaction caveat front-loaded before any call is made. Nothing could be removed without losing information.

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

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

With no parameters and no output schema, the description carries the burden of explaining the return, and it does so partially by flagging redaction. A little more on what the settings payload contains (e.g., SMTP, security, and performance sections) would make it fully complete for an agent deciding whether this call answers its question.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The two sentences do not need to spend words on arguments.

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

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

The description names the resource ('Instance settings') directly, so paired with the name 'listmonk_settings_get' an agent can tell this is a zero-arg read of configuration. It does not explicitly contrast itself with near-neighbors like listmonk_status or listmonk_dashboard_counts, but the resource word 'settings' is specific enough to separate it from status/counts/logs 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?

There is no statement of when this tool should be used versus listmonk_status, listmonk_dashboard_counts, or listmonk_logs, all of which plausibly return instance-level information. The agent must infer the choice from the resource name alone.

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 establish that this is not read-only, is open-world, and is non-idempotent. The description adds useful behavioral context by explicitly warning that it sends real mail through the instance's SMTP settings.

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

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

Two concise sentences, front-loaded with the core action and followed by the key side-effect warning. No unnecessary wording.

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

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

For a two-parameter test tool with full schema coverage and relevant annotations, the description covers purpose and side effect. It does not explain return behavior, but no output schema exists and the omission is minor.

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

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

The schema has 100% description coverage for both parameters, so the baseline is 3. The description mentions the email address and configured SMTP server but adds no syntax, indexing, or format details beyond the schema.

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

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

The description states a specific action: open an SMTP connection and send a test email to a given address. It clearly identifies the resource as the configured SMTP server, which distinguishes it from campaign-oriented test-send tools.

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

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

It implies the tool is for testing SMTP configuration by sending real mail, but does not explicitly say when to use it versus siblings like campaign_test_send or what conditions should exclude its 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 declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the concrete return shape {health, about, config}, which tells the agent this is a lightweight probe, though it says nothing about auth requirements or whether the probe is expensive.

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

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

Three short sentences, front-loaded with the resource and immediately followed by the usage cue and return shape. No filler; every clause carries information.

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

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

For a zero-param tool with no output schema, the description usefully enumerates the top-level return keys, which is the main thing an agent needs to interpret results. It could be slightly more complete by hinting at what 'health' contains or how failures surface, but it is adequate for a status probe.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline is satisfied. The schema is an empty object with 100% coverage, consistent with the description's implicit no-argument call.

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

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

States a specific resource (server health, version, build info) with clear scope, and is distinguishable from siblings like listmonk_settings_get or listmonk_dashboard_counts which expose config/aggregates rather than server state. An agent can tell what this returns without opening a schema.

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

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

"Start here when diagnosing anything" gives explicit entry-point guidance that places this tool first in a diagnostic sequence. It stops short of naming specific alternatives (e.g., use listmonk_logs for error detail), so the exclusion side is 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description's only added value is enumerating the fields returned per list, which helps the agent judge whether the call answers its question, but it says nothing about pagination, ordering, or result size.

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 phrase with no wasted words, and the field list is front-loaded. It is a sentence fragment rather than a complete statement, which slightly weakens its standalone readability.

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

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

With no output schema, the description does the right thing by naming the returned fields, which is the key missing piece. However, it omits whether results are paginated or how many lists come back, which matters for an unfiltered enumeration call on an open-world dataset.

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 takes zero parameters, so there is no parameter semantics to document; the baseline for a 0-param tool applies. The description correctly implies the call returns everything without filtering, which matches the empty 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 is a noun phrase ('All mailing lists with id, name, type, opt-in mode, tags, and subscriber counts') that implicitly states the resource, and the title supplies the verb. It loosely distinguishes this from the singular list_get, but never explicitly scopes itself against siblings like list_create or subscribers_search.

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 guidance on when to use this tool versus list_get or any sibling. An agent must infer from the plural name that this is the enumeration endpoint; no conditions, prerequisites, or alternatives are 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?

Annotations declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, but say nothing about merge semantics. The description adds a genuinely non-obvious trait: omission of a field means 'keep existing value' rather than 'clear it', which is critical for a PATCH-style mutation and is consistent with idempotentHint=false. It notably omits how to clear a field (e.g. empty string vs null) or what happens if `id` does not exist.

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, front-loaded with the action, and the partial-update rule placed immediately after. Zero filler.

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

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

For a 6-parameter mutation with no output schema and 0% schema coverage, the description covers only the partial-update contract. It leaves out which list fields can be changed, enum meanings, tag replacement behavior, permission requirements, and what the response contains.

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

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

Schema description coverage is 0% across 6 parameters, so the description carries the burden, yet it names no parameters. The required `id` is never mentioned, the two enums (`type`: public/private; `optin`: single/double) are unexplained, and array-replacement behavior for `tags` (replaced vs appended) is a real ambiguity left open.

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 clear verb+resource: 'Update a mailing list', which is readily distinguished from list_create, list_get, and list_delete in the sibling set. It stops short of naming which aspects of the list are updatable (name, tags, type, optin, description), leaving that to 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?

No explicit when-to-use guidance, no prerequisites (e.g. must the list exist or be owned), and no routing to alternatives such as list_create for new lists. Usage is only implied by the verb 'update'.

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

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

Annotations already declare non-read-only, non-idempotent, open-world, non-destructive, so the safety profile is covered. The description adds a real behavioral consequence beyond annotations—that list_ids actually subscribes the new subscriber and that preconfirm bypasses double opt-in—but says nothing about duplicate-email handling, validation failures, or what is returned.

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 wasted words, and the core action is front-loaded. The style is telegraphic—parameter notes read as fragments rather than structured guidance—but nothing is padded.

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

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

For a 6-parameter creation tool with no output schema, the description omits the return value (subscriber ID?), duplicate-email behavior, and the semantics of attribs/status. It covers only the two side-effect-related parameters, leaving an agent to guess at the rest.

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 0%, so the description must compensate, and it does explain the two least obvious parameters (list_ids and preconfirm) with meaning beyond the raw array/bool types. However, attribs (a free-form nested object), status (enum), and name are left entirely undocumented in both schema and description.

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 ("Create a subscriber") that is unambiguous against siblings like subscriber_update or subscriber_get. It does not explicitly name an alternative, but the create semantics are clear enough that an agent can pick it 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?

There is no guidance on when to use this versus subscriber_update (e.g. upsert behavior) or subscribers_lists_change, and no prerequisites such as required permissions or what happens if the email already exists. The only usage hint is the implied side effect of list_ids.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description earns credit beyond that by disclosing the cascade: list subscriptions and campaign history are deleted too, which is the critical fact an agent needs before calling a destructive tool. It does not mention recoverability or permission requirements.

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

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

One sentence, front-loaded with the verb and the cascade scope. Every clause carries information; nothing is padding.

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

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

For a one-parameter destructive mutation with full annotation coverage and no output schema, the description is nearly sufficient: it tells the agent the operation is permanent and cascades. The remaining omissions are the identity semantics of 'id' and any precondition or response information.

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 0%, so the single 'id' parameter is undocumented in the schema itself. The description only says deletion is 'by id', adding little about what identifier is expected (subscriber id vs. email/uuid) or whether it must be a positive integer. That leaves a real gap, but the parameter is simple enough that a 3 is fair.

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 ('permanently delete') and resource ('a subscriber by id') and adds scope: the deletion takes list subscriptions and campaign history with it. An agent can distinguish this from subscriber_get/subscriber_update/subscribers_lists_change. Sibling differentiation is implied by the verb rather than stated, so it stops short of a 5.

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

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

There is no guidance on when to use this versus e.g. subscribers_lists_change (which would detach a subscriber from a list without destroying the record), nor on prerequisites such as confirmation or permissions. 'Permanently' hints at caution but does not tell the agent what to do with it.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the useful detail that list memberships are included in the response, but says nothing about not-found behavior or the shape of the payload 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?

A single compact sentence with the resource and lookup key front-loaded. Nothing is wasted, though the extreme brevity leaves gaps that a clause or two could have closed.

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 read tool with full annotation coverage and no output schema, the description is close to sufficient. It is missing the key practical details: what happens on a missing id and how this differs from the search 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?

With schema description coverage at 0%, the description is the only place 'id' gets context, and it confirms it is the subscriber id. It does not clarify format constraints (the schema uses an integer with exclusiveMinimum 0) or whether the id refers to the subscriber versus a list or user.

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

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

The description names the resource (one subscriber) and the lookup key (id), and it signals the return payload ('including their list memberships'). It implicitly distinguishes itself from subscribers_search and subscriber_create/update, though it never uses an explicit verb like 'get' or 'fetch'.

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 guidance on when to use this versus subscribers_search, which is the obvious alternative for finding subscribers. No prerequisites, no mention of behavior when the id doesn't exist, and no exclusions are 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds meaningful partial-update semantics ('without replacing their other memberships'), but stays silent on whether 'unsubscribe' triggers a global unsubscribe, what 'status' does, or failure/partial-success behavior for bulk ops.

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

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

Two tight sentences, front-loaded with the operation and scope, with the action values appended inline. The trailing enum repetition is mildly redundant but cheap and useful at a glance.

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 4-parameter mutation tool with 0% schema coverage and no output schema, the description omits the 'status' parameter entirely, says nothing about what the response reports for bulk operations, and gives no error or permission context. It is under-specified relative to the tool's complexity.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It only restates the action enum (already in the schema) and never explains the 'status' parameter or the semantics of the list_ids/subscriber_ids arrays (bulk cardinality, all-or-nothing vs per-item results), which are the core of the tool.

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 set (add/remove/unsubscribe) and resource (subscriber list membership) plus bulk scope, which is clearly distinct from subscriber_create/update/delete siblings. It does not explicitly name a sibling, but 'without replacing their other memberships' signals the differentiation from whole-record update 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?

Bulk membership mutation is implied as the use case, and the 'without replacing other memberships' clause hints at when to prefer this over a full update. However, there is no explicit when/when-not guidance versus subscriber_update, nor any note on prerequisites such as list existence or confirmation status.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so safety is covered. The description adds real context the annotations don't: the query is a raw SQL expression scoped to the subscribers table, which implies string-syntax dependence and possible failure on invalid expressions. It says nothing about pagination behavior or result limits when query is omitted.

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

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

Three short sentences, front-loaded with purpose, then the highest-value detail (query syntax) with illustrative examples. No filler; only minor cost is the two examples padding length slightly.

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

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

A search tool with five parameters, no schema descriptions and no output schema needs more from the description than it gives. Four parameters governing pagination and filtering are undocumented anywhere, leaving the agent to guess at per_page caps and list_id semantics.

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

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

Schema description coverage is 0%, so the description carries the full burden and it only documents one of five parameters. The query explanation with two concrete examples is excellent, but page, per_page, list_id and subscription_status are left entirely unexplained.

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

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

States a specific verb (search) and resource (subscribers), and the query examples make the search domain unmistakable. It doesn't name distinctions from siblings like subscriber_get or subscribers_lists_change, but the plural/search framing is clear enough for an agent.

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?

'Omit query to list all' gives one conditional path, which is genuinely useful. There is no guidance on when to use this versus subscriber_get (single lookup) or how it relates to subscribers_lists_change, nor any exclusions or prerequisites.

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

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, openWorld=true, so the safety profile is carried. The description adds real value beyond them: it discloses partial-update semantics and, critically, that passing list_ids performs a wholesale replacement of memberships — a destructive-in-effect behavior not signaled by destructiveHint=false. It stops short of noting that preconfirm or status changes may trigger external side effects.

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

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

Three short sentences, no filler, with the partial-update rule front-loaded before the list_ids caveat. Tight and each sentence carries information, though the opening "Update a subscriber" restates the title.

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 mutation with zero schema descriptions and no output schema, the description should say more about the remaining fields. It covers the two highest-risk behaviors well, but preconfirm (likely controls confirmation email sending — an externally visible side effect), attribs merge semantics, and valid status transitions are left entirely to inference.

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

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

Schema description coverage is 0% across 7 parameters, so the schema alone conveys only types and the required `id`. The description compensates for the single most dangerous parameter (list_ids = replace) but says nothing about status enum transitions, the nested attribs merge behavior, or what preconfirm actually controls. Partial compensation, not full.

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 ("Update a subscriber") and carves out the list-membership case by naming the sibling subscribers_lists_change. That differentiation is partial — it only distinguishes this tool from one of the three sibling subscribers_* tools — but an agent can still identify 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?

Explicitly says "Only the fields you pass change", which tells the agent this is a partial/PATCH-style update rather than a full replace. It also gives a concrete routing rule: use subscribers_lists_change when you want to add/remove without replacing. No when-not guidance for other siblings (e.g. vs subscriber_create), but the core selection logic is covered.

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

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

Annotations already declare this is a non-readonly, non-idempotent, non-destructive write to an open world, so the safety profile is covered structurally. The description adds the important behavioral constraint that campaign bodies must contain the Go template include directive. It says nothing about duplicate-name behavior, validation failures, or what gets created/returned.

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

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

Three short sentences, front-loaded with the verb and immediately followed by the two constraints an agent would otherwise get wrong. No filler, though the body requirement could be phrased slightly more tightly.

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 4-parameter mutation tool with no output schema, the description covers the two highest-risk inputs (type and body) but is silent on subject semantics and failure modes such as duplicate names. No output schema exists, so return values need not be explained, but the remaining parameter gaps keep this at minimum-viable.

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 0% across four parameters, so the description carries real weight here. It explains the meaning of both enum values and a hard body content constraint, but leaves 'name' and especially 'subject' (which has a default) entirely undocumented in both schema and prose.

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 ('Create a template'), which is unambiguous against siblings like template_update, template_get, and campaign_create. It does not explicitly contrast itself with template_update, but the create verb plus the schema makes the distinction 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 description clarifies how to choose between the two type values and adds a hard requirement for the body on campaign templates, which is genuine usage guidance. It gives no guidance on when to use this versus template_update, or what to do if a template with the same name exists.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety bar is lower, but the description still adds real value by disclosing the two server-side refusal conditions that will cause the call to fail. It does not say whether the failure surfaces as an error or a silent no-op, which keeps it off a 5.

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

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

Two short sentences with the destructive scope front-loaded and the failure condition second. Every clause carries distinct information and nothing repeats the schema or annotations.

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

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

For a single-parameter destructive tool with no output schema and solid annotation coverage, the description covers purpose, permanence, and the main failure modes. The one real gap is provenance and semantics of the `id` argument, which an agent must guess.

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 0%: the single `id` property carries no description, type-only documentation, and an exclusiveMinimum constraint. The description never mentions the parameter, so it adds no meaning — it does not say this is the template ID, nor that an ID can be obtained from templates_list or template_get.

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

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

States a specific verb+resource ("delete a template") with an explicit permanence qualifier that separates it from reversible operations. It does not explicitly name a sibling such as template_update, but the resource scope plus the template_* naming makes it distinguishable 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 second sentence gives a clear negative condition — the call fails for the default template or one referenced by a campaign — which is genuine when-not guidance rather than a restatement of purpose. It stops short of naming an alternative (e.g. use template_update or campaign_update first to clear the reference), so the agent must infer the remediation path.

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

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety behavior is covered. The description adds useful context that the returned template includes its HTML body. It does not describe what happens if the id is missing or invalid, or the full return shape.

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

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

The description is a single compact sentence with no filler. It front-loads the resource and scope, though it could be slightly more explicit about the retrieval action. Nothing extraneous is included.

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 tool with annotations covering safety and no output schema, the description supplies the key missing return context: the HTML body is included. Additional details such as error behavior for invalid ids would improve it, but the essential information is present.

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

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

Schema description coverage is 0%, so the description must compensate. It only says 'by id' and does not explain the identifier's expected format, valid range, or whether it is a template ID vs another resource ID. With a single required integer parameter, the schema supplies the basic type but the description adds little semantic depth.

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 resource and scope: a single template retrieved by id, including its HTML body. It implicitly contrasts with templates_list and template_update/delete. It stops short of using an explicit verb like 'retrieve' or 'fetch', but the intent is unambiguous.

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

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

The description implies when to use this tool: when you need one template rather than a list. It does not explicitly state when not to use it or name alternatives such as templates_list. The usage context is inferable but not spelled out.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds some useful behavioral context by naming the fields returned, but it does not mention pagination, ordering, or whether the full set is always returned.

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 wasted words. It immediately states the scope and the returned fields.

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

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

With no input parameters and no output schema, the description compensates by listing the key fields returned. It is nearly complete for a simple list-all endpoint, though it could clarify whether results are paginated or sorted.

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 takes zero parameters, so the baseline is 4. The description appropriately does not invent parameter details and instead focuses on the returned template fields.

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 resource as 'All campaign and transactional templates' and names the returned fields (id, name, type, default flag). It implies a list-all operation and distinguishes itself from template_get by covering every template rather than a single one, though it never uses an explicit verb like 'List'.

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 word 'All' hints that this is an unfiltered list, but there is no explicit guidance on when to use this tool versus template_get or other template siblings. No alternatives or exclusions are mentioned.

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 disclose readOnly=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds meaningful patch semantics that unspecified fields remain unchanged, but omits auth requirements, not-found behavior, and side effects.

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

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

Two short sentences, front-loaded with the action and immediately followed by the key partial-update rule. No unnecessary text.

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

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

For a mutation tool with no output schema and 0% parameter description coverage, the definition is too terse. It leaves an agent without field-level semantics, required-id context, or validation/error expectations.

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

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

Schema description coverage is 0% across four parameters, so the description must compensate. It only vaguely implies that non-id fields are optional; it does not explain that id is required or clarify the meaning of body, name, and subject.

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 ('Update a template'), clearly distinguishing it from template_create, template_delete, template_get, and templates_list by verb. It does not state scope or which fields are updatable, but the core purpose is unambiguous.

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

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

The phrase 'Only the fields you pass change' implies partial-update usage and gives useful guidance on how to call it. However, it does not say when to use this instead of template_create, nor does it mention prerequisites or exclusions.

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

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

The annotations already disclose readOnly=false, openWorld=true, and idempotent=false. The description adds a valuable warning that this 'Sends real mail', but it does not mention duplicate-send risk, rate limits, permissions, or irrevocability beyond what the annotations already imply.

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

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

Three short sentences, front-loaded with purpose and ending with the most important operational warning. There is no padding.

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

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

This is a six-parameter, open-world mutation tool with no output schema and no parameter descriptions. The description omits required-field semantics, override behavior for subject/from_email/content_type, and concrete side-effect detail, leaving the agent under-informed.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It only explains that 'data' fills template placeholders and does not clarify template_id, subscriber_email, subject, from_email, content_type options, or expected nested data shape.

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 ('Send') and resource ('one transactional email'), and clarifies it uses a 'tx' template aimed at a subscriber email. That distinguishes it reasonably well from campaign_test_send and campaign-oriented siblings, though it does not 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?

It implies this is for real transactional sends rather than tests ('Sends real mail'), which is useful context. However, it does not explicitly say when to use this versus campaign_test_send or other send-related siblings, nor does it state prerequisites or exclusions.

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