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 covered elsewhere. The description adds nothing on top of that: it never mentions that the mutation requires confirm=true, that repeated calls may stack or duplicate membership, or whether the operation is additive vs replace.

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 waste, but the brevity is under-specification rather than conciseness: there is no front-loaded scoping, no required-vs-optional distinction, and no actionable directive. It is structurally clean but content-empty.

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 destructive six-parameter mutation with a nested payload object, two mutually exclusive body paths (payload vs payload_file), an account profile selector, and a confirm gate — and the description covers none of it. With no output schema and no annotation-adjacent context restated, an agent cannot call this correctly 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 the schema itself documents all six parameters, including the payload/payload_file mutual exclusion and the confirm gate. Per the baseline rule for high coverage, a 3 applies when the description does not compensate further, and here it adds no parameter 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?

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 when-to-use, when-not-to-use, or alternative routing is given, even though sibling tools such as remove_subscriber_from_segments and create_or_update_subscriber sit in the same family. The agent must infer that this is the additive counterpart to the remove tool purely from naming symmetry.

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. The description adds genuine context beyond that — the repetition prerequisite and the abandoned-cart restriction — which the agent cannot infer from the annotations. It still doesn't say what happens on rejection (error vs. silent no-op).

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 short, but it is wrapped in raw HTML (<br><b>, <ul>) with no leading purpose sentence, so the reader hits formatting markup before any substance. It is efficient in word count but poorly 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 destructive, non-idempotent mutation with 7 parameters and a nested payload object, the description covers key preconditions but omits error behavior and confirmation semantics (why confirm must be true). It is adequate but leaves real gaps for an agent invoking a write operation.

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

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

Schema description coverage is 100%, so the schema already documents id/email mutual dependency, payload, payload_file, account, and confirm. The description adds no parameter-level meaning, which is acceptable but not additive — baseline 3.

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_subscriber_to_workflow'), which an agent can distinguish from the sibling remove_subscriber_from_workflow. However, the description body itself never states what the tool does — it opens directly with 'Notes:' constraints, so the purpose rests entirely on the name/title rather than the prose.

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 concrete when-not conditions: subscribers can only be re-added after completing the workflow and only if 'Allow repeat subscribers' is enabled, and abandoned cart workflows are excluded. No alternative tool is named, but the exclusion criteria are explicit and actionable.

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's only extra content, the 50-item cap, is already restated verbatim in the schema ('Maximum 50 items'), so it adds essentially nothing beyond structured fields, and it says nothing about upsert semantics, partial failures, or the confirm/account prerequisites.

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

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

A single front-loaded sentence with no filler or redundancy; the cap is stated up front. It is efficient, though its brevity borders on under-specification rather than true conciseness for a tool of this complexity.

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 five parameters, nested objects, and no output schema, one sentence is inadequate. Missing: how create-vs-update is decided (id vs email), the role of confirm/account/payload_file mutual exclusion, partial-failure behavior, and the relationship to the preview/submit batch siblings.

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 nested subscriber item is fully documented (id/email requirement, double_optin creation-only note, custom_fields, etc.), so the schema carries the parameter burden. The description adds no parameter-level meaning beyond what is already there, which is the baseline 3.

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 pair (create/update), the resource (subscribers), and the batch scope (up to 50 in a single request), which implicitly distinguishes it from the single-item sibling create_or_update_subscriber. It stops short of naming that sibling or the preview/submit batch siblings explicitly, so differentiation relies on the agent inferring it from 'up to 50'.

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 at all: nothing says when to pick this over create_or_update_subscriber, nor how it relates to the sibling batch tools preview_subscriber_batch and submit_subscriber_batch. The agent gets no context, exclusions, or prerequisite conditions.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it does not explain that the mutation requires confirm=true, does not mention the payload vs payload_file exclusivity rule, and does not describe side effects of creating a field. With annotations present the bar is lower, but zero added context keeps this at a 2.

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 bloat, but this is under-specification rather than conciseness. The one sentence carries no useful information an agent could not get from the tool name alone.

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 mutation with five parameters including a nested payload object and mutually exclusive payload/payload_file options, the description omits everything an agent needs: the confirm requirement, the body-vs-file exclusivity rule, and the meaning of the account parameter. Annotations cover safety and the schema covers parameters, but the definition as a whole gives no operational context.

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

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

Schema description coverage is 100%, so all five parameters (label, account, confirm, payload, payload_file) are already documented in the schema. The description adds no additional parameter meaning, which lands at the baseline 3 for high schema coverage.

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

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

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. With siblings such as list_custom_fields, list_all_custom_fields, and create_segment nearby, an agent gets no signal about prerequisites, ordering, or when creating a field is the right move. No when/when-not/alternative information is present.

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 note about overwrite semantics on update, no mention that confirm=true is required for the mutation, and no disclosure of what data gets destroyed.

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 four-word sentence is technically concise but is under-specification rather than conciseness for a 13-parameter destructive mutation tool. Nothing useful is front-loaded because there is nothing there to front-load.

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 write tool with 13 parameters, nested payload objects, no output schema, and an XOR requirement on id/email, a one-line restatement of the title leaves the agent with essentially nothing beyond the structured fields. The description is completely 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 100% across all 13 parameters, so the schema carries the full parameter burden and the baseline of 3 applies. The description contributes no additional meaning about the id/email XOR, the confirm flag, or the payload vs payload_file exclusivity.

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 whatsoever on when to use this tool versus alternatives. It says nothing about when to prefer batch_create_or_update_subscribers, how it interacts with add_subscriber_to_segments, or what happens when an id/email already exists (create vs update resolution).

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, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the basic safety profile is covered. However, the description adds nothing beyond that: it never mentions the required confirm flag, that the operation mutates state irreversibly, or what it returns, leaving the behavioral burden entirely on 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 but under-specified rather than concise; it conveys none of the information an agent needs and is not front-loading anything useful.

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 six parameters, a nested payload object, no output schema, and a confirm requirement, a two-word description is completely inadequate. Nothing about the mutation lifecycle or response is conveyed.

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% (above the 80% threshold), so the schema already documents color, account, confirm, payload, and payload_file. The description adds no parameter meaning at all, 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 prerequisites, and no mention of the alternative siblings (get_segment, list_segments, list_segment_colors) that an agent must choose between. Nothing tells the agent when this is the right call.

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, openWorldHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing on top — no note that this performs an external POST to the supplied URL, that it is non-idempotent (duplicate webhooks on retry), or that the 'confirm' flag is required for the mutation to take effect.

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?

Four words with no wasted clauses, but this is under-specification rather than genuine conciseness — there is no front-loaded substance to be concise about. The brevity comes at the cost of all useful content.

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

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

For a 7-parameter mutation tool with a nested required-object payload, a confirm gate, and mutually exclusive body-passing mechanisms (payload vs. payload_file vs. body flags), plus no output schema, the description is wholly inadequate. Nothing an agent needs to invoke this correctly 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 100%, so the schema already documents all seven parameters, giving a baseline of 3. The description adds no meaning beyond the schema — it does not clarify the confirm gate, the payload vs. payload_file mutual exclusion, or the required subfields (name, post_url, events) inside the nested payload.

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 when-to-use, when-not-to-use, prerequisites, or alternative routing is given. It does not mention list_webhooks, get_webhook, update_webhook, or delete_webhook, nor any condition that would select this tool over them. Zero guidance.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is documented elsewhere. The description adds nothing beyond that — no note about irreversibility, permissions, or the confirm-flag requirement — so it fails to contribute 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 single sentence is not concise so much as absent — it is a bare restatement of the title with no front-loaded constraint or useful detail. Under-specification, not economy, is the problem.

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 mutation, the description omits everything an agent would want beyond the schema: irreversibility, the confirm requirement, and what happens on success or failure. No output schema exists to compensate, so the definition is incomplete.

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

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

Schema description coverage is 100%, so the schema already documents id, account, and the confirm flag with meaningful semantics; the baseline of 3 applies. The description supplies no additional parameter meaning at all, so it neither helps nor harms.

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 (such as the required confirm=true), and no routing away from alternatives like update_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 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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no note on pagination cost, result volume, ordering defaults, or how filtering parameters interact. With annotations carrying the whole burden, the description 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 text is short, but brevity here is under-specification rather than concision; there is no front-loaded useful information. A one-phrase restatement of the title earns no efficiency credit.

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 8-parameter, unfiltered list endpoint with no output schema, the description should at minimum explain filtering, sorting, and pagination behavior. None of that is present, leaving the agent dependent entirely on thin per-parameter schema strings.

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

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

Schema description coverage is 100%, so the baseline is 3 under the rubric. That said, several parameters (Sort, Search, OrderBy, SharedAsTemplate) are documented only as "Exact native query parameter," and the description does not compensate with syntax or accepted values for Sort/OrderBy. Baseline 3 is the correct ceiling here.

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 indication of when to use this tool versus the many other list_* siblings, no prerequisites, no scoping advice. 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, idempotentHint, destructiveHint=false and openWorldHint, covering the safety profile. The description adds nothing beyond them: the only content, '(pagination)', duplicates what the schema's page/per_page parameters already document.

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 clause with no padding and nothing to trim. But the brevity comes from under-specification rather than economy, so it earns only a middle score.

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

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

For a simple read-only list tool with full schema coverage and annotations, a short description could suffice, but this one leaves the key question unanswered: how it differs from 'list_all_custom_fields'. No output schema exists, so return shape is also unexplained.

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 all fully documented including defaults and bounds, so the baseline is 3. The description's pagination note adds no syntax, format or account-label nuance 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?

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 when-to-use, when-not-to-use, or alternative is mentioned. This is especially costly here because 'list_all_custom_fields' sits directly alongside it, and nothing tells the agent which of the two to pick.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds no behavioral context at all — nothing about pagination behavior, result ordering, or whether the account filter scopes results — so it contributes zero beyond the annotations.

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

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

It is a single short sentence with no filler, but that sentence merely duplicates the title and therefore does not earn its place. Brevity here reflects under-specification rather than efficient communication.

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 could usefully describe the returned segment shape or ordering, and it does not. For a paginated list tool with an account-scoping filter, the definition leaves the agent without any context about what a segment is or how results are organized.

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 all documented in the schema itself, including defaults and the maximum of 100. The description adds no additional parameter meaning, so the baseline of 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 when-to-use guidance, no mention of alternatives such as get_segment for a single segment or list_segment_colors, and no stated prerequisites. The agent must infer usage entirely from the tool name and sibling list.

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 mention of pagination behavior, default page size, result ordering, or account scoping, all of which are relevant for a listing call.

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 clause with zero waste, which is good structurally. But it is under-specified rather than genuinely concise — the brevity comes from omitting information rather than from tight writing.

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

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

For a no-required-param list tool with a fully documented schema and a complete annotation set, the description is minimally viable. It does not need to explain return values (no output schema exists, but list semantics are conventional), yet it omits any note on filtering combinations or pagination that would help an agent call it correctly.

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

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

Schema description coverage is 100%, with all five parameters (page, per_page, status, account, segment_id) fully documented including enum semantics. The description contributes no additional parameter meaning, so the baseline of 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?

No guidance on when to use this tool versus alternatives such as get_subscriber (single) or the segment/workflow listers. The agent must infer usage from the name alone; nothing is said about preconditions, pagination strategy, or when filtering by segment_id/status 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, covering the safety profile. The description adds nothing beyond that—no return format, pagination behavior, or scoping details—so it earns no credit for behavioral disclosure.

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

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

The description is a single short sentence with no padding, so it is concise. But it is a tautological restatement of the name and title, meaning the brevity comes from 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 zero-parameter-required list tool with full schema coverage and rich annotations, the description is technically sufficient to invoke the tool. It nonetheless omits any note on pagination or the account filter's role, leaving gaps an agent would have to resolve from the schema 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%, with page, per_page, and account fully documented in the schema, so the baseline is 3. The description provides no additional parameter meaning, leaving it at the baseline.

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

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

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 such as get_webhook or list_all_custom_fields, and no mention of pagination context or prerequisites. 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no pagination behavior, no note on default status coverage, no indication that results are scoped to an account. For a read tool the bar is lower, but zero added context warrants a low score.

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 that brevity is under-specification rather than conciseness — there is no front-loaded scope or useful detail to trim. Nothing in the sentence earns its place beyond echoing the name.

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 full schema coverage and complete annotations the description has little left to carry, but for a list tool it still omits any hint about filtering, pagination, or result scoping that would orient an agent. The definition is minimally callable but incomplete in guidance.

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, perPage, account, and statuses are each documented in the schema (defaults, the 100-item cap, and the account-label semantics). The description contributes no additional parameter meaning, which meets the baseline of 3 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 when-to-use guidance, no mention of prerequisites, and no reference to alternatives or the related workflow tools (add_subscriber_to_workflow, remove_subscriber_from_workflow). 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real context on top: it is purely local, performs SHA-256, and explicitly touches no provider, no key, no identity check. It stops short of explaining what the digest is used for or what the preview returns.

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 that lead with the action and follow with the boundary list. Dense jargon ('selected profile label and reviewed schema') costs a little readability, 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 read-only preview tool with full schema coverage this is adequate, but it omits the one thing the agent most needs: that this is the pre-flight for submit_subscriber_batch and what to do with the SHA-256 result. With no output schema, the return value's role goes unexplained.

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 are already documented, including the ordering, the 'exact native arguments' note, and the 1-20 maxItems clarification. The description restates 'exact ordered... work' and 'selected profile label' without adding syntax or new constraint detail, so baseline 3 applies.

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

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

Names a specific verb and resource: 'Local validation and SHA-256 of exact ordered subscriber/segment/workflow/custom-field work'. An agent can tell this is a dry-run validation pass, not an executor. It does not, however, name the sibling submit_subscriber_batch it obviously pairs with, so sibling differentiation is only implied by the schema's tool enum.

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 guidance and no routing to the alternative. The negative clauses ('No provider reads, key load...') imply a safe pre-flight step, but the agent is never told this precedes submit_subscriber_batch or that the same tasks should be submitted on success.

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