send16-mcp

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds concrete downstream effects the annotations cannot convey: contacts start being enrolled by matching triggers and emails can go out immediately. That is meaningful behavioral context beyond the structured hints, though the response/return behavior is not described.

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

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

Three short sentences, front-loaded with the action, then the effect, then the caution. Each sentence contributes distinct information and nothing is padding.

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

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

For a two-parameter mutation with no output schema, the description covers the action, its side effects, and a safety caution, which is most of what an agent needs. It does not mention behavior when the automation is already active or what the call returns, leaving minor gaps.

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

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

Schema description coverage is 100% for both parameters (automationId, apiKey override), so the schema already carries parameter meaning. The description adds nothing about parameter format or which ID to supply, making the baseline 3 correct.

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

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

States a specific verb+resource ('Activate an automation') and immediately explains the operational consequence: new events matching its triggers begin enrolling contacts. That distinguishes it clearly from pause_automation and enroll_in_automation without needing to name them.

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

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

Provides an explicit precondition ('Confirm with the user first'), which is real usage guidance for a state-changing tool. It does not, however, contrast with alternatives such as pause_automation or explain when activation is inappropriate, so it falls short of the 5 tier.

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

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

Annotations already declare readOnly=false, destructive=false, idempotent=true and openWorld=false, covering the safety profile. The description only restates the ID-based input, which is already in the schema, and says nothing about duplicate handling, whether non-existent contacts are skipped, or what the call reports back.

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 no waste. It is arguably under-specified rather than verbose, which is a completeness issue, not a conciseness one.

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 mutation tool with full annotation coverage and a fully documented schema, so the description need not carry safety or parameter detail. Still, it omits the outcome semantics (result of a batch add, handling of already-present contacts) that an agent would want before calling 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 audienceId, contactIds and apiKey are all documented in the schema; the '(by ID)' note in the description duplicates the contactIds description. Baseline 3 applies since the schema carries the parameter burden.

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

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

States a specific verb ('add') and resource ('contacts to an audience') with the identity mode clarified ('by ID'), which is clearer than the bare title. It does not, however, distinguish itself from close siblings such as remove_contact_from_audience or import_contacts.

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

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

No guidance on when to use this versus import_contacts (which also brings contacts into an audience) or remove_contact_from_audience. The agent must infer the selection criterion from the tool 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, non-destructive, non-idempotent, closed-world write. The description adds genuine value with the visibility model ('visible only to workspace members'), which is not derivable from structured fields. However, it says nothing about whether the note notifies the contact or teammates, or whether repeat calls create duplicate notes (relevant given idempotentHint=false).

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

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

Two short sentences, with the action front-loaded and the visibility constraint second. No filler, though the second sentence is a single informational clause rather than something that shapes invocation.

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 3-parameter write tool with full schema coverage and annotations covering the safety profile, the description is nearly sufficient. The main gap is side effects — notification behavior and duplicate-note risk — which an agent would want before calling a non-idempotent mutation.

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 convoId, body (with markdown support noted), and apiKey are already fully documented in the schema. The description adds no parameter-level detail beyond that, 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 (add) and resource (note on a conversation), and the qualifier 'private internal' distinguishes it from outbound messaging tools like send_reply. It does not explicitly name which sibling it contrasts with (e.g. update_convo, mark_convo_read), so it falls just short of full sibling differentiation.

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

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

The description gives no when-to-use or when-not-to-use guidance and names no alternative. An agent must infer from the name alone that this is for annotating a conversation rather than replying to or modifying it.

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

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

Annotations already declare readOnlyHint=false and non-idempotent, so the agent knows this is a mutating write. The description adds genuinely useful behavioral context beyond that: the tool returns DNS records the user must act on externally, and the verification is a separate step. It doesn't address duplicate-registration behavior or auth, but it adds real value over the annotations.

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

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

Two tight sentences, front-loaded with the purpose and then the output/workflow. No filler, every clause 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?

There is no output schema, so the description carries the burden of explaining returns and it does so concisely (DNS records to add). It also covers the required next step, making it complete for a create-domain tool.

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

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

Schema description coverage is 100%, so both parameters (apiKey, domain) are already documented in the schema, giving a baseline of 3. The description adds no syntax or format details about the domain FQDN beyond what the schema provides.

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

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

States a specific verb+resource ('Register a new sending domain') that clearly distinguishes it from siblings like list_domains and check_domain_health. An agent can tell this is a create operation for a domain without opening any schema.

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

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

Provides a clear follow-up workflow by naming check_domain_health and the condition for calling it (after adding DNS records). It doesn't state prerequisites (e.g., API key needs) or when-not-to-use, but the workflow context is explicit.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds real value by disclosing the downstream effect (future sends blocked), but says nothing about idempotent re-add behavior, whether existing contacts are affected, or error conditions. Adequate but not rich.

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

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

Two tight sentences with the action front-loaded and the consequence second. No filler, no redundancy, and the important scoping fact (blocking future sends) is not buried.

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

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

Annotations cover the mutation/safety profile and there is no output schema to explain, so the core is covered. Gaps remain: no guidance on the reason parameter or notes, and no statement about re-suppressing an already-suppressed address.

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

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

Schema description coverage is only 25% – just apiKey is documented. The description mentions only 'an email', leaving notes and the reason enum (bounce/complaint/unsubscribe/manual) completely unexplained in both schema and description, so it fails to compensate for the coverage gap.

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

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

The description states a specific verb+resource ('Add an email to the suppression list') and adds the consequence ('future sends to this address will be blocked'), making it clearly distinct from remove_suppression and list_suppressions. It does not name a sibling explicitly, which keeps it just short of a 5.

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

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

Usage is implied by the purpose: an agent can infer it is used to block an address. However, the description gives no explicit when-to-use criteria, no prerequisites (e.g., needing a verified workspace or API key), and no mention of the reason field that distinguishes bounce/complaint/unsubscribe/manual suppression.

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 a real behavioral fact beyond them: it 'triggers a fresh DNS lookup', telling the agent results reflect live state rather than cache and that the call touches external DNS. Auth, rate-limit, and latency characteristics remain unstated.

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 with the scope (which record types) front-loaded and the fresh-lookup caveat second. No filler and nothing that repeats the schema or annotations.

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

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

For a read-only, fully annotated, two-parameter check tool with no output schema, the description covers what is inspected and that results are live. It would be stronger if it sketched the return shape (per-record status) or pointed to the sibling that reports account-level deliverability.

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 2 parameters, both documented (domainId, apiKey override). The description adds no syntax, format, or sourcing detail about domainId or the API key, 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?

Specific verb (check) plus resource (DNS health of a domain) and it enumerates exactly what is verified: DKIM, SPF, DMARC, MX. An agent knows precisely what this returns, though it does not name a sibling (e.g., get_deliverability_status) to differentiate from.

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 guidance, no prerequisites, and no alternative named despite close siblings like get_deliverability_status and list_domains. The closest thing to guidance is the implied obviousness of a health check, which is not explicit routing advice.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so mutation-safety is covered. The description adds the reversibility note '(or undo it)', which reinforces the non-destructive profile, but says nothing about error behavior or what happens on a duplicate check-in. Modest added value over annotations.

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

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

Two short sentences, zero filler, with the core action front-loaded and the ID-source hint trailing as a useful pointer. Every clause earns its place.

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

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

For a simple mutation tool with full schema coverage and annotations carrying the safety profile, the description covers purpose, the undo variant, and the ID source. Only minor gaps remain (no note on duplicate/already-checked-in behavior), so it is essentially 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 all four parameters including undo, apiKey, eventId, and registrationId are already documented. The description adds only the source of registrationId, which is a marginal supplement beyond the schema — 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 and resource ('Check a registrant in at the door') and clearly distinguishes event check-in from the sibling register_for_event. The parenthetical '(or undo it)' also signals the reversible variant. It falls just short of 5 because it doesn't name a sibling explicitly to route the agent.

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

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

Gives concrete context ('at the door') and, importantly, tells the agent where the registrationId comes from — the sibling list_event_registrations. It doesn't spell out when check-in is inappropriate (e.g., unregistered attendees) or alternative tools, so 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 declare the write/idempotency/safety profile (readOnly=false, idempotent=false, destructive=false), so the description only needs to add context. It does: 'each matching event sends one email to the contact' conveys the runtime effect of the created resource, which is not derivable from annotations or schema. It omits auth requirements and duplicate-eventName behavior, keeping it below 5.

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

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

Two sentences, no filler, and the core purpose is front-loaded before the behavioral detail. Every sentence earns its place.

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

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

For a 7-parameter create tool with strong annotation coverage and 86% schema coverage, the description covers what the tool does and its runtime effect. It does not indicate what is returned (e.g., the created action's id) — no output schema exists to cover this — which is the main 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 description coverage is 86%, so the schema already documents nearly all parameters and the baseline is 3. The description echoes the eventName-to-templateSlug mapping but adds no meaning for delaySeconds, sendOnce, enabled, or apiKey beyond what the schema states. No compensation for the small remaining gap.

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

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

The description gives a specific verb (create) plus the resource (Action) and then defines what an Action is in domain terms — a mapping from event name to transactional template. That definition is genuinely useful because 'Action' is jargon that could otherwise be confused with create_campaign or send_email. It stops short of naming a sibling to distinguish itself from, so it lands at 4 rather than 5.

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

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

There is no guidance on when to use this versus create_campaign, create_webhook, or send_event, and no prerequisites stated (e.g., that the referenced templateSlug must already exist, or that events are fired via send_event). The trigger semantics are described, but nothing tells the agent when this tool is the right choice.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing on top: no mention that creation is non-idempotent, that repeat calls may produce duplicate audiences, or what permissions are needed. For a write tool this leaves a real gap.

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, front-loaded sentence with no padding, so it is not bloated. However, its brevity comes from under-specification rather than efficiency — the sentence adds almost no information beyond the tool 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?

A mutation tool with three parameters (33% schema coverage), no output schema, and a description that adds nothing beyond annotations is not complete enough. An agent cannot tell from this definition what it must supply, what happens on duplicate names, or what the call returns.

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

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

Schema description coverage is only 33% (only apiKey is documented inline; name and description are not). The description names no parameters at all, so it does nothing to compensate for the documentation gap — it doesn't even confirm that a name is required or what the description field is for.

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

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

"Create a new audience" does state a verb and resource, so it is not pure noise, but it is nearly a verbatim restatement of the tool title and name. It offers no differentiation from siblings such as list_audiences, delete_audience, add_contacts_to_audience, or duplicate_campaign. Minimum viable, with no distinguishing detail.

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 what alternative to pick. The agent gets no signal about prerequisites (e.g., whether an API key or workspace is required) or relationship to list_audiences / delete_audience.

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

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

Annotations declare it is a non-read-only, non-destructive, non-idempotent create; the description adds the important behavioral fact that creation is inert (draft) and sending is a separate step. It does not mention auth (the apiKey parameter) or any return value, but the draft/no-send guarantee is substantive context beyond the annotations.

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

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

A single dense sentence that front-loads the action and state, then the targeting constraint, then the workflow boundary. No filler or repetition.

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

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

For a 13-parameter create with full schema coverage and no output schema, the description covers the essential semantics: draft state, targeting exclusivity, and the send boundary. Minor gaps remain around the apiKey override and what the response returns, but nothing blocks 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 coverage is 100%, so the baseline is 3, but the description adds a real constraint not encoded in the schema: exactly ONE of audienceIds / segmentId / contactIds / tagIds / sendToAll must be supplied. That mutual-exclusivity rule is the key thing an agent could get wrong and is not derivable from the individual parameter descriptions.

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

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

States a specific verb (create), resource (email campaign), and resulting state (draft), which cleanly separates it from duplicate_campaign, update_campaign, and schedule_campaign. An agent can identify the tool's role without opening the schema.

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

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

Explains the tool's place in the workflow: create as a draft so it is 'ready to test and send,' and explicitly notes 'Nothing is sent until schedule_campaign,' routing the agent to that sibling for sending. No explicit when-not guidance, but the lifecycle boundary is clear.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, so safety and idempotency are covered structurally. The description adds a genuinely useful behavioral fact not in the annotations: 'Contacts are subscribed by default'. It does not say what happens when the email already exists, which is the main remaining unknown for a non-idempotent create.

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

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

Three tight sentences, front-loaded with the action and scope, then the sibling routing rule. The inline example is short and directly disambiguates the tool's intent rather than padding the text.

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

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

Covers purpose, scope limit, subscription default, and bulk alternative, which is most of what an agent needs for a 7-parameter create. The notable gap is return behavior (e.g. the created contact ID) since no output schema exists, and handling of duplicate emails is unstated.

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 all 7 parameters are documented in the schema (including tag case-insensitivity, audienceIds referencing list_audiences, and the apiKey override). The description only restates the audience/tag capability at a high level, adding no syntax or format detail beyond the schema, 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?

States a specific verb and resource with scope ('Add a single new contact'), and immediately narrows it against the bulk sibling by name ('use import_contacts instead'). An agent can distinguish this from import_contacts, add_contacts_to_audience, and update_contact without opening a schema.

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

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

Explicit routing guidance for the bulk case ('For more than a handful of people, use import_contacts instead') plus a concrete usage example. It does not address the existing-contact case (update_contact) or when to prefer add_contacts_to_audience over the audienceIds parameter, but the primary boundary is clearly drawn.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is covered structurally. The description adds the opt-in/preference-center context, which is useful, but says nothing about duplicate name/slug handling or failure behavior for a non-idempotent create.

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 with no filler, and the core action is front-loaded in the first sentence. Nothing is repeated and no sentence is wasted.

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

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

For a five-parameter create tool with full schema coverage and safety annotations, the description covers purpose but omits usage guidance and mutation behavior. It is minimally adequate rather than complete, and the opt-in detail does not compensate for the missing when-to-use 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 (name, slug, apiKey, isDefault, description) are already documented in the schema with formats, patterns, and defaults. The description adds no parameter-level 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?

States a specific verb and resource ('Create a new subscription topic'), which is unambiguous. It does not, however, explicitly differentiate itself from the sibling tools update_topic, delete_topic, or list_topics, so the agent must infer the distinction 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?

The description provides no when-to-use guidance, no prerequisites, and names no alternatives. The second sentence about contacts opting in via the preference center is domain flavor rather than invocation guidance, so an agent gains little about when this tool is the right choice.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavior: it will POST event JSON to the URL with an HMAC-SHA256 signature, plus the plan-entitlement requirement. It omits whether a signing secret is returned at creation or how duplicate URLs are handled.

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

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

Three short sentences, front-loaded with what the tool does, then delivery semantics, then the plan gate. No filler or redundancy; each sentence carries distinct 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 5-parameter create tool with full schema coverage and standard annotations, the description covers purpose, delivery mechanism and entitlement. The notable gap is that with no output schema, it doesn't say what is returned on success (e.g. a webhook id or signing secret), which the agent would need for follow-up calls.

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 (url, name, apiKey, events, enabled) are already documented in the schema. The description only refers obliquely to the URL and event payload and adds no field-level meaning beyond the schema; 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: 'Register an outgoing webhook endpoint.' An agent can immediately distinguish this from create_contact, create_campaign and other create_* siblings. It stops short of a 5 only because it never names a sibling (e.g. list_webhooks, regenerate_webhook_secret) to contrast against.

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 create a webhook versus using automations or other event mechanisms, and no alternatives are referenced. The one eligibility note ('outgoing webhooks are a plan feature') is a constraint rather than usage direction, and it is buried at the end.

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=true, readOnlyHint=false, and openWorldHint=false, covering the safety profile. The description adds nothing on top of that: no cascade behavior, no statement about whether the action must be inactive first, no confirmation or permission requirements, no recovery implications.

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 three-word sentence with zero waste and the essential verb front-loaded. However, this brevity stems from under-specification rather than efficient communication, so it cannot be rewarded as genuinely well-structured.

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 with annotations covering reversibility and idempotency, the description still omits important operational context: what happens to related records when an action is deleted, and whether dependent automations or campaigns are affected. It is not misleading, but it is materially 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%, with both actionId and apiKey documented in the schema itself, so the baseline of 3 applies. The description contributes no additional parameter meaning, but the schema already carries the full burden.

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

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

"Delete an Action" only restates the tool name and title; it adds no scope, target detail, or distinction beyond the verb+resource already conveyed by the identifier. It is a tautology rather than a genuine statement of purpose, though the verb+resource pairing does at least identify what entity is affected.

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 the many siblings (delete_audience, delete_campaign, delete_contact, delete_topic, delete_webhook, update_action, get_action). No prerequisites such as state requirements or ordering relative to other operations 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 destructiveHint=true and idempotentHint=true, so safety is covered. The description adds genuinely non-obvious blast-radius context: contacts are NOT deleted, only the list and its memberships are removed. That is exactly the kind of consequence detail annotations cannot express.

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

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

Two short sentences, the destructive action front-loaded and the important consequence immediately after. Nothing redundant, nothing 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 simple two-parameter delete with annotations covering the safety profile and no output schema, the description supplies the one thing an agent actually needs to reason about (contacts survive, memberships don't). Return-value detail is unnecessary here; only the lack of any usage routing 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% with only two parameters (apiKey, audienceId), both documented in the schema itself. The description adds no format, ID-source, or override detail, 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+resource ('Delete an audience') and even clarifies the domain synonym ('list'), so the agent knows exactly what object is being removed. It is clearly distinguishable from create_audience/list_audiences by the verb, though it does not name a sibling explicitly the way the highest-scoring examples do.

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

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

Usage is implied by the destructive verb rather than stated; there is no explicit when-to-use/when-not-to-use guidance and no pointer to adjacent tools like remove_contact_from_audience or delete_contact. The clarification that contacts survive is a useful boundary, but routing guidance is 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 destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the hard guardrail that sent campaigns are protected, which annotations alone would not reveal.

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

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

Two short sentences, zero waste, with the core action front-loaded and the constraint following immediately. Nothing could be removed without losing information.

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

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

For a two-parameter destructive tool with no output schema, the description plus annotations cover what an agent needs, including the draft-only guardrail. It is only marginally incomplete in not saying what the caller gets back or how the protected-campaign case is signalled.

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 both parameters (apiKey, campaignId) are documented in the schema, so the description need not repeat them. It adds no syntax or format detail, making the baseline 3 correct.

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

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

The description states a specific verb and resource ('Delete a draft campaign') and immediately scopes it, distinguishing it from update_campaign/pause_campaign by restricting the operation to drafts only. An agent can tell what this does without opening the schema.

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

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

It clearly states the applicable condition (draft) and the exclusion (sent campaigns cannot be deleted, only archived), which is exactly the routing information an agent needs. It falls just short of 5 because it does not name a sibling tool to use instead for the archive path.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so safety is partly covered, but the description adds genuinely new behavioral facts: the deletion cascades to associated events and cannot be undone. It still omits error behavior (e.g., unknown contactId) and whether the apiKey override is required for this operation.

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

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

Two terse sentences with the destructive cascade front-loaded before the irreversibility warning. Every word earns its place and nothing is buried.

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

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

For a two-parameter delete with no output schema, the description covers the essential scope and irreversibility. It would be complete with a note on behavior when the contact does not exist or on dependent records beyond events.

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 (apiKey, contactId) are already documented in the schema. The description adds no format or constraint details beyond that, making the baseline 3 appropriate.

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

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

States a specific verb (Delete) and resource (contact) plus the cascade scope (all associated events). This lets an agent distinguish it from remove_contact_from_audience or add_suppression, which are non-destructive alternatives in the sibling list.

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

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

The description gives no when-to-use or when-not-to-use guidance and never mentions alternatives such as suppression or audience removal. An agent must infer entirely from the tool name that this is the hard-delete path.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds a consequence not present in annotations: 'All subscribers will be detached' — a real side effect beyond the topic itself. It stops short of stating whether the deletion is permanent or reversible, so it does not reach a 5.

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

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

Two short sentences, the purpose first and the side effect second, with no filler. Every clause 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 mutation with no output schema, the description supplies the essential impact statement and annotations cover idempotency and destructiveness. It omits confirmation requirements and whether deletion is immediate versus scheduled, leaving a small but real 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 only two parameters, so the schema already carries the parameter documentation burden. The description does not mention topicId or the apiKey override, adding no semantic value beyond the schema — 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?

The description gives a specific verb and resource ('Delete a subscription topic'), making the operation unambiguous. It does not explicitly differentiate itself from siblings like delete_action or delete_audience, but the resource noun is distinct enough that an agent can route correctly.

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

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

There is no statement of when to use this tool versus alternatives (e.g., update_topic to modify rather than remove a topic), nor any note about prerequisites such as required permissions or the API key parameter. Usage is only implied by the name and one-line purpose.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so safety and repeatability are covered by structured data. The description adds only the qualifier 'outgoing' about the webhook type, which is marginal 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?

A single front-loaded sentence with no filler; every word earns its place for a simple delete operation.

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 destructive delete with rich annotations and full schema coverage, the description is adequate but thin: it does not say whether deletion is permanent, whether the endpoint secret is revoked, or what a successful response indicates. The annotations carry most of the weight.

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 both parameters (apiKey, webhookId) are documented in the schema itself. The description adds no syntax, format, or sourcing detail beyond that, 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?

States a specific verb (delete) and resource (outgoing webhook endpoint), so the agent knows exactly what the tool operates on. It does not differentiate itself from related siblings such as create_webhook or regenerate_webhook_secret, but those are distinguishable by name and the resource is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives or prerequisites, such as needing an existing webhook ID or when to prefer regenerate_webhook_secret instead of deleting. Usage must be inferred 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the result is ready-to-use HTML suitable for sending or campaigns, but does not disclose whether the template is persisted (or requires a follow-up save_template call), nor any latency/cost of AI generation.

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 with the generation action front-loaded and the output payoff second; no filler. It could be marginally tighter but nothing is wasted.

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

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

There is no output schema, so the description must carry the return-value burden, and it does only in one clause ('ready-to-use HTML'). For a six-parameter AI generation tool, the workflow gap (does it save? what does the HTML payload look like? does it need an API key configured?) is left open.

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 two enum-constrained parameters, so the schema already carries the parameter meaning. The description adds nothing about type/style/description limits or how brandColor and companyName influence the output, 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?

Specific verb (generate) plus resource (complete email HTML template) and the input basis (a description). It is distinguishable from save_template and list_templates, but it never distinguishes itself from the close siblings generate_email_from_url or render_email_content, which would require explicit contrast.

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-tool guidance. The agent must infer that generate_email_from_url is the URL-based counterpart and that this tool produces an unsaved artifact, neither of which the description states.

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?

Goes beyond the annotations (which only mark it as a non-idempotent write, destructive=false) by disclosing that it works on already-sent campaigns and, critically, that without retargeting the copy keeps the ORIGINAL recipients — a non-obvious behavioral trap that the schema and annotations do not reveal.

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

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

Three tight sentences, front-loaded with purpose and the re-use rationale, followed by the constraint and the recipient warning. Every sentence earns its place with no redundancy.

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

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

For an 8-param, no-output-schema tool, it covers purpose, the retargeting exclusivity rule, and the key recipient caveat. It stops short of stating what the call returns (e.g., the new draft's ID), which an agent might want given no output schema exists.

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

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

Schema coverage is 100% so parameter basics are already documented, but the description adds real meaning the schema lacks: the 'exactly ONE of audienceIds / segmentId / contactIds / tagIds / sendToAll' mutual-exclusivity rule, which would be invisible otherwise. The rename via name is only implied.

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 (duplicate) and resource (campaign) plus what gets copied (template, content, settings) and the output (a new draft). This clearly distinguishes it from create_campaign and update_campaign without opening any schema.

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

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

Gives clear context for when to use it ('the way to re-use a past campaign's design') and states the retargeting constraint explicitly. It does not name a specific alternative tool (e.g., create_campaign) for the from-scratch case, so it falls just short of full routing 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 destructive=true, idempotent=false, openWorld=true, so the safety profile is partly covered. The description still adds real value by warning that enrollment can trigger immediate emailing and that user confirmation is required, plus the active-status precondition. It stops short of describing failure modes or what happens on duplicate enrollment.

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

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

Three tight sentences, front-loaded with the action, then precondition, then alternative, then the caution. No filler; every clause carries information.

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

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

For a destructive, non-idempotent mutation with no output schema, the description covers precondition, side effect, and alternative path. It omits any indication of what a successful enrollment returns or how to verify it, which is a minor gap given no output schema exists.

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

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

Schema description coverage is 100%, so contactId (with a search_contacts pointer) and automationId are already documented. The description adds no additional parameter meaning, so the baseline 3 is appropriate.

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

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

States a specific verb (enroll) and resource (contact in automation), and immediately distinguishes itself from the event-driven path by naming send_event. An agent can tell this apart from send_event and activate_automation without opening a schema.

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

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

Gives the precondition (automation must be 'active'), names the alternative (send_event for event-driven enrollment), and adds an operational instruction (confirm with the user first). Explicit when/when-not/alternative coverage.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the safety profile is covered. The description adds meaningful context beyond that: it reveals the tool scrapes external web content and produces a draft (not a sent email), plus the exact return fields. It omits auth/rate-limit notes, though the apiKey parameter hints at these.

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 with zero filler; the core action is front-loaded and the return values follow. Every clause earns its place.

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

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

With no output schema, the description usefully enumerates the return values (subject, preview text, HTML body), which an agent would otherwise lack. It is slightly thin on how 'instructions' shapes the generation, but overall it equips the agent to call the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents url, apiKey, and instructions in detail. The description adds no additional parameter-level meaning (it never mentions instructions or the API key override), so the baseline 3 for schema-documented parameters applies.

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

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

The description states a specific two-step verb (scrape a URL, generate an email draft) and the resource (email draft), which is clearly distinct from siblings like design_email_template or render_email_content. It never explicitly names an alternative tool, so it stops short of the top score for sibling differentiation.

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

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

The parenthetical examples ('a launch blog post or product page') imply the intended use case, giving some context for when to reach for this tool. However, there is no explicit when-to-use/when-not guidance and no reference to alternative drafting or templating tools, so usage is only implied.

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, so the safety profile is covered. The description adds useful return-content context ('trigger config and template binding'), which matters since there is no output schema, but says nothing about not-found or error behavior.

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

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

A single tight sentence with the core action front-loaded and zero filler. There is room to append routing guidance without bloat, but as written it is efficiently sized.

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 get tool with rich annotations and fully described params, the essentials are present. However, with no output schema the description only gestures at the return shape and omits any distinction from get_automation, leaving a 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% (both apiKey and actionId are documented in the schema), so the description carries no parameter burden. It adds no syntax, format, or ID-source detail beyond what the schema already states, matching 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?

States a specific verb and resource ('Get a single Action') and adds what the payload contains ('trigger config and template binding'). The word 'single' implicitly separates it from the sibling list_actions, but no sibling is named explicitly, so it stops short of a 5.

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

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

No guidance on when to call this instead of list_actions, get_automation, or the create/update_action siblings. The only cue is the implicit singular-vs-plural distinction, which the agent must infer.

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, non-destructive and closed-world, so the safety profile is fully covered. The description adds value by disclosing what the response contains (trigger, steps, current status), but says nothing about error behavior for a missing/unknown ID or any rate limits.

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; the resource and scope lead and the returned fields follow. Nothing is wasted, though it is minimal rather than richly structured.

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

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

For a simple two-parameter read tool with no output schema and annotations that already cover the safety profile, the description tells the agent what it fetches and what comes back. It is adequately complete for the complexity, missing only guidance on selecting it over sibling read tools.

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 both parameters are documented there, so the schema carries the burden. The description's 'by ID' merely restates that automationId identifies the target and adds no format or constraint detail beyond the schema, making the baseline 3 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?

Specific verb (Get) plus resource (automation) plus scope (single, by ID), and it enumerates the returned fields (trigger, steps, status). The 'single' scope implicitly separates it from the sibling list_automations and get_automation_stats, though it never names them.

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

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

Usage is implied by 'single automation by ID' and the list of returned fields, which signals a detail-retrieval call. There is no explicit when-to-use, when-not-to-use, or mention of the alternatives (list_automations, get_automation_stats) that an agent would weigh this against.

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 value by disclosing the shape of the returned aggregate payload (enrollments, completed, exited, open/click rates per step), which is important since there is no output 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?

A single, front-loaded sentence with no filler; the metric list is compact and informative.

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

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

With no output schema, the description usefully enumerates the returned metrics, which is the main thing the agent needs. Minor gap: no indication of the time window or whether results are aggregated over all time.

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 (apiKey, automationId) are already documented in the schema. The description adds no extra parameter semantics beyond implying the stats are scoped to one automation.

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?

Specific verb (get) and resource (automation stats) with an explicit enumeration of the metrics returned: enrollments, completed, exited, open/click rates per step. Clear on what it does, but does not differentiate itself from neighbors like get_automation or list_automation_enrollments.

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

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

Usage is only implied by 'for an automation' – the agent can infer this is the analytics view rather than the config view, but no explicit when-to-use or when-not-to-use guidance against sibling tools such as get_automation, get_campaign_stats, or list_automation_enrollments is given.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: what specific assets are returned and the notable behavioral detail that a DESIGN.md spec is injected into AI generation prompts.

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 that packs purpose, resource, and returned contents with no filler. Every clause earns its place.

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

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

For a simple read-only tool with one optional param and no output schema, the description covers what it does and what it returns. It omits auth/scope nuance, but annotations already carry the safety profile and the schema documents the key.

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

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

There is a single optional apiKey parameter with 100% schema description coverage, so the schema already documents its purpose and env-var override behavior. The description adds nothing about parameters, so the baseline 3 is appropriate.

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

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

States a specific verb (Get) and resource (workspace's brand settings) and even enumerates the contents: colors, logo, fonts, and the DESIGN.md spec. The 'get' vs sibling 'update_brand' contrast is reasonably clear, but the description never explicitly names a sibling to distinguish itself.

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?

Pure description with no when-to-use, when-not-to-use, or alternative guidance. It never says to use update_brand to modify settings or get_workspace for other workspace-level data, leaving the agent to infer scope.

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 the safety profile is fully covered. The description adds only that the payload includes engagement/delivery rates; it omits any note on time window, refresh cadence, or behavior for campaigns with no sends.

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 front-loaded sentence naming the action and the returned metrics with no filler. It is appropriately short for a simple read tool, though the trailing metric list is somewhat enumerative rather than informative.

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

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

With no output schema, the description usefully sketches the returned metrics, and annotations cover the safety profile. It is nearly complete for a single-param stats getter, missing only time-range/scope semantics of the returned numbers.

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% for both params, so campaignId and apiKey are already documented in the schema. The description adds no format or sourcing detail beyond that, 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 (get) and resource (stats for a specific campaign) and enumerates the metrics returned (open, click, bounce, delivery). It implicitly separates itself from get_automation_stats and get_workspace_usage via the 'campaign' resource, but never explicitly names the sibling it is not.

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 call this versus list_campaigns, get_automation_stats, or get_deliverability_status, and no mention of prerequisites such as the campaign needing to exist or already have sent mail.

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 a safe, idempotent, non-destructive, non-open-world read. The description adds real value by defining the score scale and its inputs, but says nothing about freshness/staleness of the score, behavior for contacts with no engagement, or error conditions — gaps that matter for interpreting the result.

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 that front-loads the verb and resource and packs the useful score definition into the same clause. No filler, nothing to trim.

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

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

With no output schema, the description partly compensates by explaining the return range (0-100) and what drives it. It does not say whether the response is a bare number, an object with a breakdown, or includes a last-updated field, which leaves a modest gap for a read tool.

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

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

Schema coverage is 100% with only two parameters (apiKey, contactId), both documented in the schema. The description adds no format or sourcing detail for contactId, and the apiKey override is covered entirely by 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?

States a specific verb (get) and resource (contact health score), and adds the substantive detail that the score is 0-100 and derived from recent engagement (opens, clicks, replies). That distinguishes it from the many other contact-related siblings such as get_contact_timeline, though no sibling is named explicitly.

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

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

The description gives no when-to-use context, no prerequisites (e.g., contact must exist / have engagement history), and does not point to an alternative tool for related data like timeline or message events. An agent must infer applicability 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety and idempotency are covered externally. The description adds only the content of the timeline, with no notes on pagination behavior, result ordering, or volume — acceptable but not rich.

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

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

A single front-loaded sentence with no filler; the enumerated activity types are the only elaboration and each earns its place. Slightly longer than strictly necessary but well structured.

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?

No output schema, so the description carries some of the return-value burden and does list activity types, which helps. However it omits ordering, pagination semantics (cursor/limit), and whether the timeline is bounded — gaps an agent would face for a paginated aggregation call.

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% (contactId, limit, cursor, apiKey all documented), so the schema does the heavy lifting. The description adds no meaning about the required contactId or how pagination interacts with 'full timeline', leaving this at 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?

States a specific verb (Get) and resource (a contact's full activity timeline) and enumerates the event types it aggregates. This distinguishes it as a composite per-contact aggregation tool rather than the narrower siblings like get_message_events or list_automation_enrollments, though it never names those alternatives.

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

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

No indication of when to use this aggregate timeline versus the many narrower siblings (get_message_events, get_event_insights, list_automation_enrollments). The phrase 'full activity timeline' implies aggregate scope but gives no explicit when/when-not guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered structurally. The description adds useful scope context ('full thread ... incoming + outgoing'), clarifying the completeness of the returned data, but says nothing about pagination, ordering, or auth beyond 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?

A single front-loaded sentence with zero filler; the verb leads and the parenthetical clarifies thread direction efficiently.

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

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

For a simple read-only tool with full schema coverage and no output schema, the description conveys the key return characteristic (full thread, both directions). It could note ordering or pagination behavior, but nothing essential blocks 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%, so both parameters (id, apiKey) are already documented in the schema. The description adds no further meaning about parameter format or the API key override behavior, 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?

States a specific verb ('Get') and resource ('a single conversation with its full thread of posts'), making clear this fetches one conversation plus its posts. It implicitly contrasts with list_convos by specifying 'single', though it never names the sibling explicitly.

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 list_convos or add_convo_note. The agent must infer that this is for retrieving one known conversation by ID.

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 safety is covered structurally. The description adds the plan-gating requirement (Deliverability Hub feature), which is exactly the kind of entitlement/auth context the rubric credits beyond annotations. It does not describe freshness of the data or failure behavior when the plan is absent.

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

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

One sentence plus a short parenthetical, with the resource and returned fields front-loaded and zero filler. Nothing could be cut without losing information.

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

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

With no output schema, the description carries the burden of conveying return content, and it does so by naming the three summary dimensions. That is sufficient for a read-only status tool, though it omits scope details such as time window for the bounce/complaint data.

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

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

There is a single optional apiKey parameter at 100% schema description coverage, so the schema fully documents its meaning and env-var override behavior. The description adds nothing parameter-related, which is acceptable given the baseline for a one-param, fully documented schema.

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

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

States a specific verb (Get) and resource (workspace's deliverability summary) and enumerates the three content areas returned: sending reputation, domain authentication, and bounce/complaint health. This distinguishes it from the narrower sibling check_domain_health, but the description never names that sibling explicitly, so differentiation is inferential rather than stated.

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

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

The parenthetical '(Deliverability Hub plan feature.)' signals an entitlement prerequisite, which is real usage guidance. However, there is no statement of when to reach for this versus check_domain_health or pre_send_review, and no exclusions or trigger 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, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds real value by disclosing that the returned content differs fundamentally by mode (per-event breakdown vs cross-event streaks/retention/growth), which the annotations cannot convey.

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

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

Two sentences, front-loaded with the common single-event case before the fallback aggregate mode. The field lists are dense but each item maps to a distinct insight, so little is wasted.

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

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

With no output schema, the description must describe the return content, and it does so thoroughly for both modes. It omits any note on response shape/pagination, but for a read-only insights call that gap is minor.

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

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

Schema description coverage is 100% – both apiKey and eventId are documented in the schema, including the 'leave out for all events' behavior. The description restates the eventId semantics without adding syntax or format detail, 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?

States a specific resource (event attendance insights) and enumerates exactly what it computes: counts, no-show rate, geography, first-timers vs returning, orgs, registrations over time. This clearly separates it from list_event_registrations (raw rows) and list_events in the sibling set.

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

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

Explicitly defines the two operating modes: single-event when eventId is given, and cross-event aggregate insights when omitted. That is clear usage context, though it never names the sibling tools (e.g. list_event_registrations) an agent might otherwise reach 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the response includes a full event timeline, which is useful return-shape context, but says nothing about auth requirements beyond the API key already documented 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?

A single front-loaded sentence that names the resource and the payload, with the event stages sketched inline. Nothing is wasted.

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

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

For a simple read with full annotation coverage and no output schema, the definition is mostly sufficient, but the unresolved overlap with get_message_events means an agent cannot confidently choose between them from the descriptions 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% and both parameters (id, apiKey) are documented in the schema itself. The description adds no meaning about the id format or the env-var override behavior, 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 (fetch) and resource (a single message) plus the returned content (full event timeline). However, the sibling get_message_events appears to cover overlapping timeline territory, and the description does not clarify how these two differ, leaving an ambiguity an agent must resolve on its own.

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 instead of list_messages or get_message_events. The scope ('single message') is implied by the name only; there are no exclusions or alternative-routing statements.

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, non-destructive and closed-world, so the safety profile is fully covered structurally. The description adds a scope disclosure about what is intentionally omitted (body, recipient details), but says nothing about ordering, pagination, or how many events are returned.

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

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

A single sentence with zero filler, front-loading the resource and immediately qualifying the scope with the exclusion clause. Every clause earns its place.

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

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

For a simple read-only lookup with full schema coverage, complete annotations, and no output schema, the description is sufficient: an agent knows what it gets (event timeline) and what it will not get. Minor gap is the absence of any return-shape or ordering hint.

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 schema already documents 'id' as the Message ID and 'apiKey' as the key override. The description adds no format, prefix, or lookup guidance beyond that, 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?

States a specific verb and resource (get the delivery event timeline for a message) and scopes it by exclusion ('no body or recipient details'), which implicitly separates it from the sibling get_message. It stops short of naming get_message explicitly, so sibling differentiation is inferable rather than stated.

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

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

Usage is implied by the scoping phrase: reach for this when you only need the event timeline, not the full message. However, no alternative tool is named and no explicit when-not condition is given (e.g. 'if you also need the body, use get_message').

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 a closed-world scope, so safety and idempotency are covered structurally. The description's only added behavioral detail is that the response carries the template's EmailContent JSON, which is useful given there is no output schema, but it says nothing about error behavior for unknown IDs.

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 naming the verb, the resource, the lookup key and the payload of interest, with no filler.

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

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

For a simple two-parameter read with no output schema, the description covers the identity of the resource and what the response contains (EmailContent JSON). Only the failure mode for a missing ID is unaddressed, a minor gap.

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

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

Schema description coverage is 100%, with templateId documented as 'Template ID (slug)' and apiKey's override behavior spelled out, so the schema carries the semantics. The description's 'by ID' merely echoes the schema rather than adding format or lookup guidance, making the baseline 3 correct.

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 ('Get') and resource ('a single starter template by ID') and implies the single-vs-list distinction against list_templates via 'single' and 'by ID'. It does not explicitly name any sibling, so it stops short of the top score.

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

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

Usage is only implied: 'by ID' suggests it is the follow-up to a list or search call, but the description never says when to choose this over list_templates or render_email_content, nor does it state any prerequisite such as knowing the template ID in advance.

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 the safety profile is fully covered. The description adds only the API-key-binding context and says nothing about return shape, error behavior for an invalid key, or defaults.

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

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

A single tight sentence with the scoping detail front-loaded and no filler; every clause 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 zero-required-parameter read tool with no output schema and full annotation coverage, the essentials are present. It would be stronger if it hinted at the returned workspace fields or the failure mode when the API key is absent or invalid.

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

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

There is one parameter with 100% schema description coverage, so the schema already explains the apiKey override of SEND16_API_KEY. The description adds no parameter-level meaning beyond that, which is the expected baseline when the schema does 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?

Specific verb (get) plus resource (workspace), and the parenthetical narrows scope to the workspace bound to the API key, which implicitly separates it from list_workspaces. It stops short of naming the sibling explicitly, so it is clear but not maximally differentiating.

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

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

The phrase 'the one the API key belongs to' implies when this applies (you want the caller's own workspace rather than an enumeration), but there is no explicit when-to-use, no exclusion, and no named alternative such as list_workspaces or whoami.

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 (read-only, idempotent, non-destructive, closed-world). The description adds useful scope ('current month's') and the metrics returned, but does not mention auth requirements, rate limits, or response shape, so it is only moderately additive.

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 that states exactly what the tool returns with no filler. Every word earns its place for such a simple read operation.

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

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

Given the low complexity, rich annotations, and no output schema, the description supplies the essential return content and time scope needed to select the tool. It stops short of describing response structure or edge cases, but is adequate for this simple stats endpoint.

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 the single apiKey parameter fully documented in the schema. The description adds no parameter-level meaning beyond the schema, 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?

States a specific verb ('Get') and resource ('workspace usage') and names the three returned metrics (send count, contact count, plan limits). It does not explicitly differentiate itself from nearby siblings like get_workspace or whoami, so it falls short of a 5 despite being clear.

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

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

The description implies usage for checking quota and plan limits, but gives no explicit when-to-use guidance or alternatives such as get_workspace. It is minimum viable implied context rather than actionable routing advice.

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 give the safety profile (destructiveHint=true, idempotentHint=false), and the description adds non-obvious behavior: updateExisting delivers upsert semantics that make re-runs safe, tags are created if missing, and a consent gate is enforced. Note the mild tension with idempotentHint=false — the re-run safety is conditional on setting updateExisting=true, which the description could have stated more sharply, but it is not a contradiction of the default behavior.

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

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

Three dense sentences, front-loaded with the core action and required column, then usage context, then the consent gate. No filler and every sentence carries distinct 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 6-param mutation tool with no output schema, the description covers the action, the input format, the upsert option, and the consent precondition well. It does not indicate what the call returns (e.g., counts of imported/skipped/failed rows), which would be the remaining gap given no output schema exists.

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

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

Schema coverage is 100% and each parameter already carries a rich description, so the baseline is 3. The description adds only marginal framing on top of that ('upsert semantics (safe to re-run)' for updateExisting, the opt-in rationale for consentConfirmed), which reinforces rather than extends 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?

Specific verb + resource + input format: 'Bulk import contacts from CSV data (min column: email)'. It further scopes itself as 'the tool for cross-app flows', which separates it from single-record siblings like create_contact and audience-scoped add_contacts_to_audience.

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

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

Gives concrete usage context (pulling people from Gmail, a CRM, or a spreadsheet into a Send16 audience) and a hard precondition (consentConfirmed must be true, confirm opt-in first). It doesn't explicitly say when to prefer create_contact or add_contacts_to_audience instead, so it stops short of full when/when-not routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description contributes domain semantics about what an Action is, which is genuinely beyond the structured fields, but it says nothing about return shape, volume, or pagination behavior.

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

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

Two compact sentences with no filler, and the operational statement is front-loaded before the domain definition. It could be marginally tighter given how little it does beyond define the resource.

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

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

For a read-only list tool with a single fully-documented optional parameter and no output schema, the annotations plus this definition largely suffice. The description supplies the domain meaning an agent needs to not confuse Actions with Automations, though it stops short of describing the returned collection.

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 single parameter (apiKey) is fully documented at 100% schema coverage, so the schema carries the meaning and the baseline of 3 applies. The description adds no additional parameter context such as overriding behavior or scope, which is acceptable here since nothing is left unexplained.

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

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

The description names the resource ('Actions') and adds a clear conceptual definition — 'event_name → template pairings, lighter than full automations' — which meaningfully distinguishes it from the adjacent automation resource. However, the verb portion is a near-tautology of the name/title ('List Actions'), and it never explicitly states that it returns all actions, nor does it differentiate from get_action/list_automations by 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?

There is no when-to-use guidance, no prerequisite, and no named alternative — it only implies a conceptual contrast with automations. An agent is left to infer when to call list_actions versus get_action or list_automations, and there is no mention of filtering or pagination 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=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered without the description. The description adds domain context (audiences are static and manually managed) but says nothing about pagination, result ordering, or volume, which matters 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?

Two short sentences, zero filler, with the resource and its scope front-loaded. Every clause earns its place by disambiguating terminology.

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 annotation coverage, full schema coverage and no output schema, the definition is essentially sufficient. It only lacks any note on return shape or pagination, a minor gap given no output schema exists.

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

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

There is a single optional parameter (apiKey) already fully documented in the schema at 100% coverage. The description adds no parameter meaning, so the baseline of 3 for schema-covered parameters 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 and resource ("List audiences") and clarifies the terminology with "(lists)", which is genuinely useful given the product's mixed vocabulary. It does not name a sibling, but the read-only list intent is unambiguous against create_audience/delete_audience.

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

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

There is no explicit when-to-use statement, but "static, manually-managed group of contacts" implicitly routes the agent away from list_segments, which is the main alternative for grouping contacts. No exclusions or 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, and destructiveHint=false, so the safety profile is covered. The description adds that results span both active and historical records, which is useful context, but says nothing about pagination behavior or result volume.

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. It is efficient, though its brevity comes at the cost of detail rather than being tightly optimized.

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 five parameters, no output schema, and pagination controls, the description should say something about what an enrollment record contains or how paging works. It leaves the return shape and pagination entirely to inference.

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

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

Schema description coverage is 80%, so the schema already documents page, pageSize, apiKey, and automationId. The phrase 'active and historical' loosely maps to the state enum but does not explain the state values or filtering semantics beyond what the schema shows.

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

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

States a specific verb (list) and resource (enrollments) scoped to an automation, and clarifies coverage as 'active and historical'. It does not name a sibling to distinguish from, but the purpose is unmistakable.

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: the agent infers this is the read path for enrollment data versus enroll_in_automation or get_automation_stats. No explicit when-to-use, when-not, or alternative is given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description's added value is limited to noting that draft/active/paused statuses and trigger types are included in the result, which is modest context but not the pagination, filtering, or ordering behavior an agent might want.

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; the resource is stated first and the returned information second. It is efficient, though a brief scoping clause would have cost nothing extra.

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 no output schema, the description does glance at what the result contains (statuses, trigger types), which is the right compensation for the missing output schema. Only the absence of any filtering/pagination or alternative-tool guidance keeps it short of 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% — the sole apiKey parameter is fully documented in the schema as an override for the SEND16_API_KEY env var. The description adds nothing about parameters, which is acceptable at this coverage level (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?

States a specific verb and resource (list automations) and adds the fields surfaced (status, trigger types), so the agent knows what comes back. It does not, however, distinguish itself from nearby siblings such as get_automation or list_automation_enrollments, which an agent must infer.

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

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

The description gives no when-to-use guidance and names no alternatives. With get_automation (single automation) and list_automation_enrollments (enrollments) in the sibling set, the boundary between these tools is left entirely to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile needs no restating. The only behavior the description adds is result ordering ('newest first'); the case-insensitive name/subject matching merely restates the `search` schema description, and pagination behavior is left unaddressed.

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 core action and ordering lead the sentence with zero preamble, and the second sentence is task-focused. It is slightly padded with parenthetical example phrases, but nothing is redundant.

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 5-param, zero-required, read-only listing tool with no output schema, the agent gets action, ordering, and search strategy; pagination (page/pageSize defaults and the 100 cap) is left entirely to the schema. Adequate, with a small gap around result-set size expectations.

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

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

Schema coverage is 100%, so 3 is the baseline. The description goes further by explaining how to actually choose a `search` value ('try distinctive words from their description and broaden if no hits'), which is operational meaning the schema's one-line 'case-insensitive substring match' does not convey.

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

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

Starts with a specific verb+resource ('List email campaigns') and adds ordering scope ('newest first'), which unambiguously places it apart from create_campaign, update_campaign, and delete_campaign. It never explicitly names a sibling it competes with (e.g. get_campaign_stats or list_automations), so it stops short of the top band.

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

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

Gives concrete routing guidance for the free-text path: use `search` when the user describes a campaign vaguely, with example phrasings and a fallback ('broaden if no hits'). It does not cover tool-level alternatives (stats vs listing vs search_contacts) or when not to use this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only that pagination is supported, without noting default/max page sizes, result caps, ordering, or rate limits. Adequate but thin given the low bar set by 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 front-loaded sentences with zero filler: the core action comes first, followed by the filter scope and pagination note. Nothing is wasted.

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

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

For a simple read-only list tool with full schema coverage and annotations carrying the safety profile, the description is serviceable. It omits return-shape hints (there is no output schema) such as whether results are paginated envelopes or bare arrays, which would help an agent interpret the response.

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 (page, pageSize, tagId, subscribed, apiKey) are already documented in the schema; baseline 3 applies. The description's mention of subscription-status and tag filtering mirrors schema content without adding format or syntax detail.

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

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

States a specific verb and resource ('List all contacts') plus the filter dimensions and pagination support, so the operation is unambiguous. However, it does not differentiate from the sibling search_contacts, leaving the agent to infer the boundary between listing and searching.

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

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

The phrase 'optional filtering by subscription status and tag' implies when the filters are worth using, but there is no explicit when-to-use/when-not guidance and no mention of search_contacts as the alternative for keyword or complex queries. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only product framing about a 'unified inbox' and nothing behavioral such as pagination or result limits, despite the 'limit' parameter existing. Value beyond annotations is minimal.

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

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

Three sentences, of which the first merely restates the title and the third is marketing copy about the product ('unified inbox combines transactional reply threading...'). Only the second sentence carries real information, so there is meaningful waste despite the compact length.

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

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

With no output schema, the description does not describe the return shape, and it omits pagination/cursor behavior even though a 'limit' parameter and 200 maximum imply paging. Safety and parameters are adequately covered by annotations and schema, but return/usage behavior is left implicit for a listing tool.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, establishing a baseline of 3. The description's filter list maps to state, mailboxId, label, and search, but it also cites a 'screener status' filter that does not exist as a schema parameter, which introduces mild confusion rather than added precision.

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

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

States a clear verb+resource ('List inbox conversations') and enumerates the filterable dimensions, so an agent can tell it's the list endpoint. However, it does not explicitly distinguish itself from siblings like get_convo, list_inbox_counts, or list_messages, leaving the agent to infer which of several conversation-related read tools to pick.

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

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

The filter enumeration implies when the tool is useful (broad filtered conversation listing), but there is no explicit when-to-use guidance, no mention of alternatives (get_convo for one, list_inbox_counts for aggregates), and no stated prerequisites. Usage is implied rather than directed.

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 that results include verification status and DNS records, which is useful return context, but says nothing about pagination, workspace scoping behavior, or auth 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?

A single front-loaded sentence with no filler. It could be slightly more efficient by not restating the workspace context, but every element earns its place.

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

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

For a no-parameter list tool with no output schema, the description usefully previews what comes back (verification status and DNS records). It is largely complete, with only minor gaps around result volume and ordering.

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

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

Only one parameter exists and schema description coverage is 100% (apiKey fully documented as overriding the env var), so the schema does the heavy lifting. The description adds no parameter-level detail, which is acceptable at this coverage level but earns no bonus.

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

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

States a specific verb ('List') and resource ('sending domains') and adds scope detail (verification status and DNS records). It clearly differs from write siblings like add_domain and from diagnostic tools like check_domain_health, though it does not explicitly name those alternatives.

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

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

The description gives no when-to-use guidance or alternatives. It doesn't tell the agent whether to reach for this versus check_domain_health for per-domain diagnostics, or add_domain when a domain is missing. Usage is only implied by the resource 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 usefully enumerates the returned fields, but says nothing about pagination, result limits, sorting, or the apiKey auth override, which are the remaining behavioral unknowns.

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; the returned-field list is dense but informative. Nothing is wasted, though it is essentially one clause rather than a structured breakdown of filters vs. returns.

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

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

With no output schema, the description compensates by naming the returned fields (status, company, city, check-in time), which is the main gap an agent would otherwise have to guess. What remains missing is pagination/limit behavior, which is a minor omission for a simple read tool.

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

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

Schema coverage is 75% and the schema already documents q, apiKey and eventId, so the baseline is 3. The description repeats the status enum values but adds no filtering syntax or semantics beyond what the enum already conveys, and does not touch the q or apiKey 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?

States a specific verb and resource ('List the people registered for an event') and enumerates the returned fields, so an agent can immediately tell it apart from list_events or register_for_event. It stops short of explicitly naming siblings or contrasting scopes, so it isn't a full 5.

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

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

There is no when-to-use guidance, no statement of prerequisites (e.g. event must exist, see list_events), and no mention of alternatives such as get_event_insights or check_in_attendee. The purpose is inferable but the routing decision is left entirely to the agent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds useful extra context by disclosing the returned metrics and registration-page field, but says nothing about pagination, result limits, or whether registration pages include unpublished events.

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 dense sentence that front-loads the verb and resource before the payload detail. Every clause earns its place and there is no filler or redundancy.

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

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

Because there is no output schema, the description must carry return-value context, and it does name the key metrics and the registration page. It still omits pagination, ordering, and result-size behavior, which an agent would likely need when deciding how to consume the list.

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 'scope' enum (upcoming/past/all, default all) and 'apiKey' override are fully documented in the schema. The description adds nothing about parameters, so the baseline 3 applies — the schema carries the full burden 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?

States a specific verb (List) and resource (the workspace's events), and clarifies the domain with concrete examples (meetups, workshops, conferences). It also previews the payload (registered/attended/no-show counts, public registration page), which helps distinguish it from siblings like list_event_registrations or get_event_insights, though it never names those alternatives explicitly.

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 when to prefer this over list_event_registrations or get_event_insights. The phrase 'the workspace's events' implies scope but the description never tells the agent the tool is unfiltered by default or how the 'scope' parameter affects results.

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 the safety profile is covered. The description adds that results are grouped per category/label and enumerates the categories, which is genuine context, but it says nothing about refresh behavior, caching, or scope (workspace-wide vs filtered).

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 front-loaded sentence, no wasted words. The category list is slightly verbose but useful for interpreting the output.

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

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

With no output schema, the description usefully enumerates the categories returned so an agent can anticipate the response shape, and annotations cover the safety profile. It is adequate, though it omits whether counts are workspace-scoped or time-bounded.

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

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

There is a single optional apiKey parameter and schema coverage is 100%, so the description need not explain parameters. It adds no parameter meaning, which is the expected baseline 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?

States a specific verb (get) and resource (unread/total counts per category and label), plus the surface it feeds (inbox sidebar). It is clearly distinguishable from siblings like list_messages or get_deliverability_status, though it does not explicitly name an alternative it is not.

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

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

The description says what is returned but gives no when-to-use guidance, no prerequisites, and no comparison against adjacent tools such as list_messages or get_workspace_usage.

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=false, so the safety profile is fully covered by structured data. The description adds the useful behavioral fact that the log is unified across transactional and campaign sources, but it says nothing about pagination behavior, result ordering, or how the limit/offset caps apply. Reasonable value-add on top of annotations, no contradiction.

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

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

Two sentences, zero filler, with the resource and its scope front-loaded before the filter list. Every clause earns its place and nothing is repeated from the schema.

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

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

For a zero-required-parameter read-only list tool with a fully documented schema and no output schema, the description covers what the tool is and what can be filtered. The only gap is the absence of pagination guidance (default page size of 50, caps at 100), which the schema does carry but which an agent might benefit from seeing up front.

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 9 parameters, including enum values for source and status and the ISO-8601 format for date bounds, so the schema does the heavy lifting. The description only groups the filterable fields at a high level (recipient, sender, status, date range, source) and adds no syntax or semantics beyond the schema. Baseline 3 applies.

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

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

The description states a specific verb and resource ("List messages from the unified send log") and adds the scope that matters: it merges transactional and campaign sources. That scope helps separate it from list_campaigns and get_message, though it does not name a sibling explicitly. Minor tension with the title's "sent messages," since the status enum includes queued/failed/bounced.

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

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

Usage is implied by the enumeration of filter dimensions (recipient, sender, status, date range, source), which tells the agent when this tool is applicable in a general sense. However, it names no alternative (e.g., get_message for a single record) and states no when-not condition. Adequate but leaves routing to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds genuinely useful context beyond that: members are computed from a filter expression at send time, implying segment membership is not materialized. It says nothing about pagination, ordering, or return shape, so it only exceeds the annotation baseline modestly.

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

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

Two short sentences, zero filler, front-loaded with what the tool does and followed by the one piece of non-obvious context. Every sentence earns its place.

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

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

For a zero-required-parameter read tool with full schema coverage this is close to adequate, but with no output schema the description could reasonably mention what a listed segment looks like or whether results are paginated. The dynamic-computation note is the main gap covered; return expectations are not.

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 single parameter (apiKey) has 100% schema description coverage, including the env-var override note, so the schema carries the burden. The description adds no parameter meaning, which is the baseline 3 when schema coverage is complete.

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

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

States a specific verb (List) and resource (dynamic segments) and clarifies what a segment is: a filter expression evaluated at send time. It distinguishes segments as dynamic/computed, which separates it somewhat from static list tools, but it never explicitly contrasts with siblings like list_audiences or preview_segment.

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 guidance, no prerequisites, and no mention of the closely related preview_segment tool. Usage is only implied by the verb 'List'; an agent gets no help deciding between this and preview_segment or list_audiences.

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=false, so the safety profile is fully covered. The description adds the useful fact that four suppression categories exist, but says nothing about pagination behavior or result shape for a listing endpoint with limit/offset.

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

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

A single tight sentence with the purpose front-loaded and zero filler. Nothing is wasted.

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

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

For a read-only list tool with limit/offset parameters and no output schema, the description omits pagination semantics and return format. Annotations cover safety, but the operational gaps around paging leave an agent under-equipped.

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

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

Schema coverage is only 25% (just apiKey is documented). The parenthetical category list effectively maps to the reason enum, adding some value, but limit and offset are entirely unexplained in both schema and description for a paginated list tool.

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

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

States a specific verb (List) and resource (suppressed email addresses), and clarifies what a suppression is by naming the four categories. It distinguishes itself from add_suppression and remove_suppression by the listing verb, though it never names those siblings explicitly.

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 guidance, prerequisites, or alternatives are given. The description only restates the operation; an agent must infer that this is the read counterpart to add_suppression/remove_suppression 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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the useful scope fact that these templates are global/unfiltered, but says nothing about pagination, result volume, or auth beyond the apiKey parameter.

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

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

One sentence with zero filler, and the distinguishing scope qualifier is placed at the end where it reads naturally. Appropriately sized for a trivial list operation, though it is so terse that it borders on under-specification.

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, annotation-rich read-only list tool with no required parameters, the description covers what an agent needs to select it. The only minor gap is that no output schema exists and the description says nothing about return shape or pagination, though this is inferable for a catalog listing.

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?

Single parameter (apiKey) with 100% schema description coverage, so the schema already documents it and the description adds nothing parameter-specific. Baseline 3 is appropriate when the schema does the heavy lifting and the description does not compensate with extra 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?

States a specific verb ('List') and resource ('starter-gallery email templates') with explicit scope ('available to every workspace'). This scope wording implicitly separates it from list_workspace_templates, but no sibling is named outright, so it falls just short of a 5.

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

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

Usage is only implied: the phrase 'available to every workspace' tells the agent this is the unfiltered global catalog, but the description never states when to prefer it over list_workspace_templates or get_template, nor any prerequisites. No explicit when/when-not guidance 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 readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds domain context about what topics are, but no additional operational behavior such as pagination, rate limits, or return shape.

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

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

Two sentences, front-loaded with the action and then a concise definition. No filler or redundancy.

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

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

For a simple read-only list tool with full annotation coverage and no output schema, the description provides adequate domain context. It could optionally note the return fields or pagination, but the omission is minor.

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

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

The single apiKey parameter has 100% schema description coverage, so the description correctly does not need to document it. Baseline is 3 when the schema does the heavy lifting.

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

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

States a specific verb and resource ('List subscription topics') and immediately defines what a topic is with examples, which distinguishes it from sibling list_* tools that cover other resources.

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?

Offers implicit usage context (topics gate campaigns and automations) but never says when to call this tool, when not to, or which sibling to use instead (e.g., list_audiences vs list_topics).

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context that outgoing webhooks are a plan feature, signaling a potential access constraint. It does not describe return format or pagination, but with annotations covering safety the added value is moderate.

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

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

Two concise sentences that are front-loaded with purpose. Every sentence earns its place by defining the resource and noting a key plan constraint.

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 parameter schema and thorough annotations, the description is nearly complete. It could optionally mention return structure or any default filtering, but such details are not essential here.

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% for the single optional apiKey parameter, so the schema already provides full meaning. The description adds no additional parameter details, which is acceptable at 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?

States a specific verb 'List' and resource 'outgoing webhooks', and clarifies what outgoing webhooks are. This distinguishes it from create_webhook, delete_webhook, and regenerate_webhook_secret without opening any schema.

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

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

No guidance on when to use this tool versus alternatives such as create_webhook or regenerate_webhook_secret. The note that outgoing webhooks are a plan feature is availability context, not usage guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing the visibility filter (only workspaces where the user is owner or member), which an agent cannot get from the schema or annotations. Pagination behavior and return shape remain unspecified.

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, tightly written sentence with the scope constraint front-loaded after the action. Every clause carries information; nothing is padded or repetitive.

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, non-destructive list tool with full annotation coverage and no output schema, the description plus structured fields give an agent everything needed to invoke it correctly. The only minor gap is that the shape of returned workspace objects is not characterized.

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

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

Only one optional parameter (apiKey) and schema description coverage is 100%, so the schema fully documents it. The description adds nothing about the apiKey override, which is acceptable given the schema already explains 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?

Specific verb+resource ('List workspaces') with an added scope qualifier ('the authenticated user has access to (owner or member)'), which makes the result set concrete. It doesn't explicitly distinguish itself from get_workspace / get_workspace_usage, but the list-vs-single distinction is inferable from the verb.

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: an agent will infer this is the enumeration entry point, and the access-scope note hints at what it returns. There is no explicit guidance on when to prefer this over get_workspace or get_workspace_usage, and no prerequisites 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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds genuine context beyond the annotations by scoping results to the user's own workspace and linking them to save_template. However, it says nothing about ordering, pagination, or result shape, so it adds only moderate value over the structured fields.

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

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

Two short sentences, zero filler, with the scoping definition front-loaded and the disambiguation trailing. Every clause earns its place.

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

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

For a no-argument, read-only list tool with annotations covering safety and no output schema, the description supplies the essential context: what is listed and where it lives relative to the sibling gallery. Minor gaps around ordering/result shape remain but are not required 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?

There is a single apiKey parameter with 100% schema description coverage, so the schema already documents it fully. The description adds no parameter-level detail, which matches the expected baseline of 3 when schema coverage is high.

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

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

States a specific verb (list) and a precisely scoped resource (templates saved in the user's own workspace), and explicitly contrasts it with the sibling list_templates. An agent can select between the two without opening either schema.

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