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

Annotations already disclose the important traits: readOnlyHint=false, destructiveHint=true, idempotentHint=false, openWorldHint=true. The description adds nothing beyond that profile — no statement about whether re-adding a subscriber to an existing segment is a no-op, whether segment IDs must already exist, what happens on partial failure, or what the response contains. It neither contradicts nor enriches the annotations.

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

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

The single sentence is short and front-loaded, but it does not earn its place: it duplicates the tool name exactly, so the text could be removed with no loss of information. Brevity here reflects under-specification rather than disciplined concision.

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, nested-object, destructive write operation with no output schema, and the description supplies no operational context whatsoever. The annotations at least signal that it is a non-idempotent write, so an agent is not entirely blind, but nothing about segment prerequisites, account scoping, or result handling is covered.

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

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

Schema description coverage is 100%, so the baseline would be 3, but the description contributes zero parameter semantics. More importantly, the schema itself presents an unresolved ambiguity — a top-level 'segment_ids' array alongside 'payload.segment_ids', plus mutually exclusive 'payload' vs 'payload_file' — and the description does nothing to explain which form to use. The one sentence offered adds no value over 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?

Tautological: description restates name/title.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as remove_subscriber_from_segments or add_subscriber_to_workflow. The only signal an agent gets is the verb 'add', which is already in the name. No exclusions or conditions 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 destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds non-duplicated context: the workflow must not currently have the subscriber active and abandoned-cart workflows reject this call. That explains why the operation is non-idempotent and where it fails, which is meaningful beyond the annotations. It still says nothing about success/return behavior 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?

The content is two tight bullets with no filler, and the most consequential constraint (repeat-subscriber precondition) is listed first. The HTML markup (br, ul, li) is noisy overhead but the underlying text is lean. No wasted sentences.

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

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

For a 7-parameter, nested-body, destructive mutation, the description supplies the failure constraints that the schema and annotations cannot express, and the 100%-covered schema plus explicit annotations carry the rest. No output schema exists, but for an add-to-workflow call the return surface is trivial. Adequate; only the absence of any permission/account-scoping note keeps it from a 5.

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

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

Schema description coverage is 100%, so every parameter (id/email alternatives, account, confirm, payload, payload_file, workflow_id) is already documented in the schema. The description names no parameters and adds no semantics beyond it. Baseline 3 applies.

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

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

The tool name and title state a specific verb+resource (add a subscriber to a workflow), and the sibling set contains unambiguous counterparts (remove_subscriber_from_workflow, add_subscriber_to_segments) that make the resource separable. However, the description body itself never states the purpose and opens directly with 'Notes', so it contributes no purpose statement of its own. Clear in practice, but the description adds no sibling differentiation beyond the name.

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 two bullets give real usage conditions: the repeat-subscriber preconditions (must have completed the workflow, 'Allow repeat subscribers' must be on) and an explicit exclusion (abandoned cart workflows cannot use this endpoint). This tells the agent when the call will fail, which is above-average guidance. It stops short of naming alternatives for the excluded case, so it is not a 5.

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

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

Annotations already flag destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is partly covered. The description adds nothing about what a destructive update actually overwrites, how partial failures in a 50-item batch are handled, or whether duplicates are matched by id or email. The only added fact (the 50 cap) is already 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?

One short sentence with the key constraint front-loaded and no filler. It is efficient, though arguably too terse for a destructive 5-parameter batch tool.

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

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

For a destructive, non-idempotent batch mutation with nested objects and no output schema, the description should address partial success, matching semantics, and the confirm/payload_file interplay. None of that is present, leaving an agent under-informed about consequences of a 50-record write.

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 80%, so the schema already documents account, confirm, payload, subscribers, and payload_file. The description adds no meaning beyond the existing 50-item maximum, so the baseline 3 applies.

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

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

States a specific verb pair (create or update) plus resource (subscribers) and adds the batch scope ('up to 50 subscribers in a single request'), which implicitly distinguishes it from the singular create_or_update_subscriber sibling. It never names that sibling or the related preview_subscriber_batch/submit_subscriber_batch tools, so differentiation stays inferential rather than explicit.

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 prefer this over create_or_update_subscriber for a single record, or over preview_subscriber_batch to validate before committing. No mention of preconditions, rate limits, or the confirm flag's role.

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=true, idempotentHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds nothing about the required confirmation flow, permission/account scoping, or what the destructive write affects.

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 sentence with zero padding, so there is nothing to trim, but that brevity comes from under-specification rather than disciplined editing. There is no structure or front-loaded context to evaluate.

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 create with a nested payload object, a confirm flag, and no output schema, the description omits the write semantics, confirmation requirement, and account scoping that the schema only partially conveys. The annotations cover safety but the description leaves real gaps 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 100% and the schema itself documents label, account, confirm, payload and payload_file with meaningful text. Per the rubric this establishes a baseline of 3 when the schema does the heavy lifting; the description contributes no additional parameter meaning.

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

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

Tautological: description restates name/title.

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, when not to, or which alternative to pick. An agent must infer everything from the 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 declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond that — it does not explain upsert resolution (which fields update vs create), merge vs overwrite behavior, or the meaning of the confirm flag. With annotations carrying the burden, a low 2 is fair for a description that contributes zero behavioral context.

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

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

It is short but that brevity is under-specification rather than conciseness — a single sentence that duplicates the title and earns no place. There is no front-loading of substance because there is no substance.

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 13-parameter mutation tool with nested objects, a payload-or-flags exclusivity model, no output schema, and destructive/idempotent annotations, this one-line restatement is wholly inadequate. Nothing about upsert semantics, the confirm gate, or account scoping is addressed.

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

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

Schema description coverage is 92%, so the schema already documents nearly all 13 parameters, including the payload/payload_file exclusivity rules and the double_optin constraint. Baseline 3 applies; the description adds no parameter meaning whatsoever.

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?

Tautological: description restates name/title.

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 when-to-use guidance, no prerequisites, and no named alternatives. An agent cannot tell from this text whether to call this versus batch_create_or_update_subscribers or add_subscriber_to_segments, nor when an update path vs a create path is taken.

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=true, idempotentHint=false and openWorldHint=true, so the safety profile is known. The description adds nothing beyond that — no mention of the confirm flag's gate, duplicate-name behavior, or what happens on repeated calls. No contradiction with annotations, but zero added value.

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 short sentence with no filler, but this is under-specification rather than conciseness — the brevity leaves a destructive, six-parameter tool with nested objects entirely undescribed.

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 non-idempotent, destructive create operation with six parameters, nested payload structures, and no output schema, the description provides none of the context an agent needs (payload vs payload_file exclusivity, confirm gating, account label semantics). It is wholly inadequate for the tool's complexity.

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

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

Schema description coverage is 83%, so the schema already documents color, account, confirm, payload, and payload_file. The description contributes no parameter meaning at all; baseline 3 applies because the schema carries the load, though the undocumented name field and nested payload.name remain unexplained.

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

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

Tautological: description restates name/title.

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

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

No guidance on when to use this tool versus alternatives such as add_subscriber_to_segments or list_segments, nor any prerequisites or exclusions. Usage must be entirely inferred from the 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 declare this is a non-read-only, destructive, non-idempotent, open-world mutation, so the safety bar is partially met by structured fields. However, the description adds nothing on top — no mention of the confirm flag requirement, the payload/payload_file/body-flag mutual exclusion, account scoping, or that creating a webhook is irreversible.

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?

At four words it is not bloated, but it is under-specified rather than concise — the single sentence carries no load and repeats the title. Nothing is front-loaded because nothing is stated.

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

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

For a 7-parameter destructive mutation with a nested object body, mutually exclusive input modes (payload vs. body flags vs. payload_file), a confirm safeguard, and no output schema, a title-only description is completely inadequate. An agent cannot safely invoke this tool from the definition alone.

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

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

Schema description coverage is 100%, so all seven parameters (including the nested payload body, confirm, account, and payload_file) are documented in the schema itself. The description contributes zero additional meaning, so the baseline of 3 applies.

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

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

Tautological: description restates name/title.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as update_webhook for modifying an existing webhook. The agent must infer everything from the 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 declare destructiveHint=true, idempotentHint=false, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing on top of that — no statement of irreversibility, no warning about the confirm flag, no note on what happens to a missing webhook — so it contributes no behavioral value.

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 sentence with no wasted words, but the brevity comes from under-specification rather than disciplined conciseness — the entire content is a duplication of the title, so nothing in it earns its place.

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

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

For a destructive, non-idempotent mutation with no output schema, the description supplies none of the context an agent would want (reversibility, the role of the confirm flag, scoping via account). The annotations and a fully-covered schema carry most of the load, but the description itself is far from 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 100%, so id, account, and confirm are all documented in the schema itself (including the meaningful confirm='only when the user asked for exactly this action' semantics). The description adds nothing beyond the schema, which lands at the baseline of 3 for fully documented parameters.

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

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

Tautological: description restates name/title.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as update_webhook or get_webhook. The agent gets no help deciding when deletion is the right call versus modifying a webhook instead.

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 cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true), so the description's only obligation is to add context. It adds nothing — no statement of whether the returned state is cached, whether it reflects unpublished or published designs, or what happens if no design exists.

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

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

It is a single short sentence with no bloat, which is structurally fine, but the conciseness comes at the cost of zero substance — it repeats the title rather than front-loading useful 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 read tool with an optional parameter and no output schema, the description should at minimum explain what the 'design state' comprises and how it feeds campaign auto-selection. Neither is addressed, leaving the agent unable to predict the result or the trigger conditions.

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 a single parameter and 100% schema description coverage, the schema already documents the 'account' label semantics precisely (exact configured private account profile label). The description contributes no additional parameter meaning, so the baseline of 3 applies.

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

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

Tautological: description restates name/title.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. The phrase 'for auto-selecting campaigns' hints at a workflow purpose but does not tell the agent which conditions should trigger this call versus other campaign tools.

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

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

Annotations already cover read-only, idempotent, non-destructive and open-world traits. The description adds value beyond them: it is a single fixed request, it will not refresh tokens, and it rejects API keys — real behavioral constraints not present in 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 tightly packed sentences with zero filler; the core action and the credential requirement are both front-loaded.

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

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

For a simple no-argument read, the description covers invocation constraints (auth type, no fallback, no refresh) adequately. With no output schema, it says nothing about what UserInfo fields come back, which is the one remaining gap.

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

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

Schema coverage is 100% and the single optional 'account' param is fully documented in the schema. The description gestures at 'explicitly selected' account/token but adds no syntax or format detail beyond the schema, so baseline 3 is appropriate.

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

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

The description names a specific verb (GET) and resource (UserInfo) and constrains the credential type to an 'externally minted OAuth access token.' It is clear on what the tool does, but does not differentiate it from any sibling (which are Mailchimp-style subscriber/campaign tools), leaving the agent to infer placement from the name alone.

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?

'API keys refuse; no refresh, OAuth login or fallback' is an explicit when-not condition, telling the agent this only works with a pre-minted OAuth token and that there is no alternative auth path. It stops short of naming an alternative tool to use instead, but the credential precondition is stated plainly.

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 readOnly, idempotent, non-destructive and closed-world behavior, so the bar is lower. The description still adds real value beyond them by declaring that the lookup is local and requires no credentials and issues no provider request, and that the returned schema is 'reviewed' with provenance.

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 no filler, and the payload description is front-loaded. The first sentence is a dense noun phrase rather than a full clause and the second is clipped, which costs a little readability without wasting space.

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 introspection tool with no output schema and no nested objects, the description adequately sketches what comes back (method, path, query, body schema and provenance). It would be stronger if it indicated the return format or how the schema should be consumed.

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

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

Schema description coverage is 100% and the single 'operation' parameter already carries an enum and a description, so the schema does the heavy lifting. The description only reinforces that the value is a 'native tool' name, adding no format or selection guidance beyond the enum.

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 (inspect/get) and resource (the reviewed method/path/query/body schema plus provenance for a single named native operation), which is clearly distinct from the sibling tools that actually perform those operations. It stops short of explicitly contrasting itself with those siblings, but the 'one native tool' scoping makes the target 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?

Usage is only implied: 'No credentials or provider request' hints that this is a safe introspection step rather than an actual provider call, but there is no explicit 'use this before invoking X' instruction or named alternative. An agent can infer the intent, yet nothing states when this tool should be preferred.

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 baseline – no note on behavior when the id is not found, no indication of what is returned, and no mention of the account resolution semantics. It contributes zero behavioral context.

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

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

The description is a single sentence and thus technically concise, but this is under-specification rather than effective brevity. Nothing is front-loaded beyond the tool name, and the sentence earns no informational value.

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

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

For a simple read tool with a fully documented 2-parameter schema and annotations covering safety, the description still leaves key gaps: what a segment contains, how id and account interact, and what happens on a missing or unauthorized segment. No output schema exists to fill these in.

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

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

Schema description coverage is 100%: the id parameter is documented as an "Exact native path parameter" and account as an "Exact configured private account profile label." The description adds no parameter meaning at all, so the baseline 3 applies when the schema does all the work.

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?

Tautological: description restates name/title.

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 alternatives. An agent cannot tell from the description why it would call get_segment rather than list_segments or list_segment_colors, and no prerequisites (e.g. needing an existing segment id) 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 declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered without the description. The description contributes nothing beyond that — no note on whether a missing subscriber errors or returns empty, and no auth or lookup-scope 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 sentence, so it is not verbose, but that brevity comes from under-specification rather than discipline. The one sentence merely duplicates the title and earns no place beyond 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?

There is no output schema, so the description should ideally indicate what a retrieved subscriber contains or what happens when the id_or_email does not resolve. With no annotations gap to fill and no return-value guidance, the definition is too thin for a lookup tool in a crowded subscriber-tool family.

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

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

Schema description coverage is 100%, so both parameters (account and id_or_email) are already documented in the schema, including the caveat that account is a profile label and not a tenant/provider ID. The description adds no syntax, format, or disambiguation beyond the schema, so the baseline 3 applies.

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

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

Tautological: description restates name/title.

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 when-to-use guidance, no mention of prerequisites, and no reference to alternatives such as list_subscribers for bulk retrieval or create_or_update_subscriber for writes. The agent must guess the boundary between this tool and its many sibling subscriber tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing on top — no error/not-found behavior, no noting that this is a safe repeatable read, no scoping caveats.

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 sentence, so there is no waste, but it is under-specified rather than concise — it conveys only what the title already does. Front-loaded yes, but no substantive content follows.

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 full annotation coverage and a fully documented schema, the minimum is met, but there is no output schema, so the description could reasonably state what is returned or what happens when the webhook id is unknown. It leaves all of that unaddressed.

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

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

Schema description coverage is 100% and the two parameters (id, account) are fully documented in the schema, including the nuance that 'account' is a profile label rather than a tenant/provider ID. The description contributes nothing further, so the baseline 3 applies.

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

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

Tautological: description restates name/title.

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 call this versus list_webhooks (for enumeration) or the create/update/delete webhook siblings. The verb 'retrieve' weakly implies 'fetch one webhook by id', which is the only inferred usage signal.

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=false, so safety is covered. The description adds genuine context beyond that: output is limited to local profile labels/defaults/auth method and deliberately excludes keys, token paths, and provider identity, telling the agent the result is safe to surface.

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 very short (two fragments) and wastes no words, but it is telegraphic and front-loads a qualifier rather than the core action. The terseness borders on under-specification rather than disciplined conciseness.

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

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

For a zero-parameter, read-only listing tool with no output schema and strong annotations, the description covers the essential safety and scope facts. However, it never plainly states what the tool does or what the returned list contains beyond field-level exclusions, leaving the purpose inferable only from the title.

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 for the description to carry. Baseline of 4 applies; nothing is missing on this dimension.

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 never states a verb or resource — it only describes the scope of what is returned ("Local profile labels/default/auth method only"). The title supplies the actual purpose, so the agent can infer this lists local accounts, but the description itself is vague about the action.

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 when-to-use guidance and no named alternative among the numerous list_* siblings (list_customers, list_partners, list_domains, etc.). The agent must infer that this tool is for enumerating locally configured account profiles rather than any remote data.

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 fully covered by structured data. The description adds nothing on top of that — no pagination behavior, no return shape, no mention of what "all" spans.

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 single sentence is compact and front-loaded with no wasted words, but its brevity stems from under-specification rather than disciplined concision. It reads as a restated title rather than an earning sentence.

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

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

For a simple read tool with no output schema the bar is low, but the description still omits the one thing an agent needs: how this differs from the near-identical sibling list_custom_fields and whether the account parameter scopes the result. Nothing is provided beyond the name.

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

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

Schema description coverage is 100% and the single 'account' parameter is clearly documented in the schema as a private account profile label. The description adds no parameter meaning, so the baseline 3 applies.

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

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

Tautological: description restates name/title.

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 list_custom_fields, create_custom_field, or any other sibling. No context, no exclusions, no prerequisites 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=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing on top of that: no pagination behavior, no note that results may be filtered by account, no indication of what happens with an empty result set.

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 four-word sentence with no wasted words, but it is under-specified rather than concise: there is no front-loaded scope, no filtering summary, and nothing to orient the agent before it reads the schema.

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

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

With 8 optional parameters, an enum status filter, a paginated result shape and no output schema, the description leaves the agent to infer everything about filtering and result handling. Annotations cover the safety profile, but the description is far too thin for a list tool with this much surface area.

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

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

Schema description coverage is 100%, so the schema itself documents page/per_page defaults and the Status enum. Per the baseline rule for high coverage, 3 is the ceiling here since the description contributes zero parameter meaning of its own (e.g. it never clarifies the 'account' profile label or the opaque Sort/OrderBy/Search native query parameters).

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

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

Tautological: description restates name/title.

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 when-to-use guidance, no mention of alternatives, and no exclusions. An agent cannot tell from the description whether this is the right tool versus any other listing endpoint, nor what the eight query parameters are for.

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 the parenthetical '(pagination)', which the schema already conveys via page/per_page parameters.

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 sentence with no padding, so it is structurally clean. However, that sentence merely duplicates the title and does no work of its own, so brevity here reflects under-specification rather than efficiency.

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 paginated list tool with no output schema, the description should at least characterize what a custom field is or what the response contains. With zero content beyond the title, an agent gets no completeness value from the description, though annotations and the full schema partly compensate.

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

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

Schema description coverage is 100%: page, per_page, and account are each documented in the schema, including defaults and the max-100 cap. The description contributes no additional meaning, so the baseline of 3 applies.

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

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

Tautological: description restates name/title.

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 alternatives. The presence of a near-identical sibling, 'list_all_custom_fields', makes this omission actively confusing rather than merely absent.

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 fully covered structurally. The description adds nothing beyond that — no note on whether the account parameter is required for multi-account setups or what the listing contains.

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 short, front-loaded sentence with zero filler or repetition. It is efficiently sized, though its brevity reflects under-specification rather than disciplined concision.

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 trivial read-only list operation with no output schema and full schema coverage, the minimum is arguably met by the name plus annotations. However, the description contributes nothing about what a 'segment color' is or how the optional account scoping affects results.

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

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

Schema description coverage is 100% and the single optional 'account' parameter is well documented in the schema itself (exact private account profile label, not a tenant/provider ID). The description adds no parameter meaning, so the baseline 3 applies.

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

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

Tautological: description restates name/title.

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 when-to-use guidance, no mention of the related list_segments/get_segment tools, and no statement about when an account argument is needed versus omitted. The agent is left to infer everything from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered without the description. The description adds nothing beyond that — no pagination behavior, no result-set size, no sorting, no account-scoping semantics, all of which would be valuable for a list endpoint.

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 short, but this is under-specification rather than conciseness — the single sentence duplicates the title and earns no additional place. There is no front-loaded scope or constraint because there is no substantive content at all.

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?

Missing.

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

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

Schema description coverage is 100%, with page, per_page, and account each documented directly in the schema, including defaults and the max of 100. The description adds no parameter meaning on top of that, so the baseline 3 for high-coverage schemas applies.

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

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

Tautological: description restates name/title.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as get_segment for fetching a single segment or list_segment_colors. The agent must infer that this is the bulk-listing counterpart of get_segment entirely on its own.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered without the description. The description adds nothing beyond that — no pagination behavior, no note on whether filtered lists are returned, no account-scoping semantics.

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

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

It is a single short sentence with no padding, which is structurally clean. But the sentence merely echoes the title and therefore does not earn its place as a distinct piece of content — brevity here reflects under-specification, not disciplined concision.

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 five-parameter, filterable list tool with no output schema needs the description to convey filtering and pagination behavior, and it conveys none of it. Saying "all subscribers" is actively incomplete given that status and segment_id exist to narrow the result set.

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

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

Schema description coverage is 100%, so the five parameters (page, per_page, status with a full enum, account, segment_id) are already fully documented in the schema and the baseline is 3. The description contributes no additional parameter meaning, so it does not exceed the baseline.

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

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

Tautological: description restates name/title.

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 when-to-use or when-not-to-use guidance and no named alternative. An agent cannot tell from this text when to call list_subscribers versus get_subscriber or list_segments. The phrase "all subscribers" even obscures that status/segment filtering 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered elsewhere. The description contributes nothing on top of them — no mention of pagination behavior, result ordering, or account scoping introduced by 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?

One short sentence with zero padding, so nothing is wasted. However, it is too thin to be front-loaded with anything useful — brevity here reflects under-specification rather than disciplined concision.

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

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

For an open-world list tool with no output schema, the description should at least gesture at return shape or pagination expectations given the page/per_page params. Annotations cover safety, but the agent still lacks any signal about what enumeration yields or how it pairs with get_webhook.

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

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

Schema description coverage is 100%, so page, per_page and account are each documented in the schema with defaults and bounds; baseline 3 applies. The description adds no parameter meaning beyond that (for example, why account is a profile label rather than a tenant ID).

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?

Tautological: description restates name/title.

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 when-to-use guidance whatsoever: nothing says when to prefer this over get_webhook, or that it is the collection-level read after create_webhook/update_webhook. The agent must infer usage entirely from the 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 disclose readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: no ordering, no scope (workspace/account context), no pagination behavior notes. With annotations carrying the burden, the description still contributes essentially zero additional context.

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

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

The single sentence is short but earns nothing — it conveys no information beyond the tool name. This is under-specification, not effective conciseness, mirroring the LOW calibration case where a bare restatement scores 2 on this dimension.

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, parameterless-required read-only list tool, the complete schema and the safety annotations mean an agent could still call it correctly. However, the description supplies no guidance on sibling selection or result scope, leaving a real but modest gap.

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

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

Schema description coverage is 100%, with page, perPage, account, and statuses all documented inline (including defaults, the 100-item cap, and the 'not a tenant or provider account ID' clarification). Per the rubric, full schema coverage sets a baseline of 3; the description adds no parameter meaning beyond it.

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

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

Tautological: description restates name/title.

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 when-to-use guidance, no mention of the sibling list_* tools, and no exclusions or prerequisites. The agent must infer everything from the name alone.

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