Meisa

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

Annotations already establish it is a non-read-only, idempotent, non-destructive write. The description goes beyond them by disclosing the default-sender fallback and the refusal failure mode, so the agent knows activation can fail and why emails are never sent from an unset address.

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 tightly written sentences that lead with the purpose and then add precondition and failure behavior, with 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 one-parameter tool with full schema coverage and no output schema, the description covers the effect, the precondition, and the failure fallback, leaving nothing an agent needs to call it correctly.

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

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

Schema description coverage is 100% and there is a single uuid parameter fully documented in the schema; the description adds no further parameter meaning, so the baseline 3 applies.

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

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

States a specific verb (activate) plus resource (sequence) and the concrete effect — it 'starts enrolling and processing contacts' — which clearly separates it from siblings like meisa_activate_trigger or meisa_pause_sequence.

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

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

It gives a precondition ('The sequence must have at least one step'), which is useful when-to-use context, but it never routes the agent among alternatives (pause, resume, enroll_in_sequence) or states when not to activate.

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, so the safety profile is covered. The description adds real value by naming the underlying state mutation (is_active=true) and framing the call as a shortcut over update_trigger, clarifying it is a non-destructive, repeatable write. It does not mention auth or failure modes, so not 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, front-loaded with the action and its effect, with the alternative-route note second. No filler and nothing that fails to earn its place.

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

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

For a one-parameter, non-destructive, idempotent toggle with no output schema, the description supplies everything an agent needs: what it does, what state it sets, and how it relates to the sibling update tool. Nothing material is missing.

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

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

Schema coverage is 100% and the single parameter (trigger_id, UUID) is fully documented in the schema, so the description carries no additional parameter burden. Baseline 3 applies; the description adds nothing beyond what the schema already states.

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 (Activate) and resource (email trigger) plus the concrete effect (accepts send requests, sets is_active=true). It is clearly distinguishable from the sibling meisa_deactivate_trigger and from the generic meisa_update_trigger.

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 explicitly names the alternative path ('Ergonomic shortcut for toggling is_active via meisa_update_trigger'), telling the agent this is the narrow, preferred call for activation. It does not spell out exclusions (e.g., when to prefer update_trigger instead), so it stops short of a full when/when-not statement.

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 safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds context beyond that: the 409 duplicate-email conflict behavior and the routing to meisa_upsert_contact for idempotent cases. It does not, however, cover side effects like auto-creating tags or permission/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?

Three sentences, each carrying distinct load: purpose, usage constraint, error/alternative behavior, and return value. The primary purpose is front-loaded with the guidance following.

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

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

For a single-resource create tool with annotations covering the safety profile and a fully documented schema, the description supplies the two remaining unknowns an agent needs: the duplicate-email failure mode and the returned object. No output schema is needed given the return value is stated.

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

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

Schema description coverage is 100%, so every parameter (including the enum, defaults, and the auto-tag-creation note) is already documented in the schema. The description adds no parameter-level syntax or format 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 and resource ('Create a new contact in Meisa') and immediately distinguishes itself from the sibling alternatives meisa_upsert_contact and, implicitly, meisa_update_contact. An agent can identify the operation 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?

Explicit when: 'only when the user explicitly asks to add a new subscriber or contact'. Explicit failure branch and alternative: on 409 duplicate email, 'use meisa_upsert_contact instead'. Both the usage condition and the fallback tool are named, leaving nothing 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 this is a non-idempotent, non-destructive mutation. The description adds useful behavior beyond that: steps are appended by default, passing a 0-based position inserts and shifts later steps down, and one call is needed per step. It does not cover permission requirements or error conditions, so it is not fully exhaustive.

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

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

The description is front-loaded with the core action and then proceeds logically through the drip concept, the step_type-to-field mapping, the position behavior, and a final usage note. Every sentence carries information relevant to invoking the tool correctly.

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 11-parameter tool with nested objects and 100% schema coverage, the description covers the essential conditional usage and append/insert behavior. It omits some contextual details, such as whether the target sequence must be in a particular state (e.g., paused) to accept steps, which would be valuable given sibling tools for activating and pausing sequences.

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 meaningful conditional mapping: it tells the agent which field(s) to supply for each step_type (email, delay, condition, action). This consolidates the schema's per-field notes but does not add edge-case semantics (e.g., what happens if mismatched fields are passed).

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 ('Add a step to a sequence') and explains the drip-building context. However, it does not explicitly differentiate from sibling tools like meisa_update_sequence_step or meisa_reorder_sequence_steps, leaving the agent to infer that this tool is only for appending new steps.

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

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

Provides clear usage context such as 'To build a full drip, call this once per step in order' and describes the typical email -> delay flow. It stops short of stating when not to use it (e.g., for editing existing steps) or naming the relevant alternatives, so it earns a 4 rather than 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 idempotentHint=true, but the description adds the concrete consequence ('adding an email that already exists just updates its name') plus the account-level scoping that annotations cannot express. It stops short of covering error behavior (e.g. invalid email) but adds genuine 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?

Three short sentences, zero filler, with the core purpose and scope front-loaded before the idempotency detail and the sibling pointer.

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 account-level write with no output schema, the description covers purpose, scope (account-wide, not product-scoped), idempotency, and the follow-up tool. Nothing an agent needs in order to invoke it correctly is missing.

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

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

Schema description coverage is 100% with only two simple parameters, so the schema already documents both email and name. The description adds only the idempotent-update semantics for name, which is a marginal gain; 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 ('Save a test recipient') and immediately defines it in parenthetical terms ('an address you send preview/test emails to'), so an agent can distinguish it from the real-contact siblings like meisa_add_contact.

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 (preview/test emails) and routes the agent forward to meisa_send_template_to_test_recipients. It does not, however, explicitly say when to prefer this over meisa_add_contact or meisa_upsert_contact, which is the more likely confusion given the sibling list.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so safety is covered. The description adds genuine context beyond that: partial sends will halt mid-flight, the broadcast cannot be resumed, and the action is unrecoverable. That goes further than the annotation set alone.

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 and its valid states, followed by consequence and irreversibility. Every sentence carries distinct information and none repeats the title or schema.

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

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

For a one-parameter destructive mutation with no output schema, the description covers applicability, effect on in-flight sends, and irreversibility, which is what an agent needs before invoking. Only the distinction from the reversible pause/resume path is left 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?

There is a single parameter with 100% schema description coverage, so the schema already fully documents broadcast_id including its UUID format. The description contributes no additional syntax, format, or source-of-truth guidance for the identifier, matching the baseline for a fully covered 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 (Cancel) and resource (broadcast) plus the three states in which it applies (scheduled, sending, paused). It implicitly separates itself from meisa_pause_broadcast/meisa_resume_broadcast via 'cannot be resumed', but never names a 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?

Gives clear context for when the tool applies (a scheduled, sending, or paused broadcast) and adds the crucial constraint that the action is irreversible. It stops short of explicitly routing the agent away from this tool toward the reversible alternative meisa_pause_broadcast when the user only wants a temporary stop.

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 only declare the generic mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description goes well beyond that: the object is created in draft status and is inert until meisa_send_broadcast, and it explains the delivery semantics of Warm Send (engagement-ranked chunks over up to 24 hours) and the deterministic per-recipient variant assignment of the A/B test. These are non-obvious behavioral traits that materially affect how an agent invokes the tool.

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

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

Front-loaded with the core action and lifecycle, then layered with the two optional feature explanations. It is longer than most definitions but nearly every sentence earns its place; only the draft-status statement is mildly redundant (said twice in the first and fourth sentences).

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

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

For a 12-parameter, no-output-schema creation tool this is close to complete: creation state, dependencies, follow-up call, and both optional feature behaviors are covered. The one real gap is that it never says what is returned (e.g., the broadcast id needed to call meisa_send_broadcast), which matters because there is no output schema to fall back on.

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

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

Schema description coverage is 100%, so the schema already documents every parameter thoroughly, making 3 the baseline. The description restates the warm_send_enabled and subject_override_b semantics and repeats the 'subject_override_b requires subject_override' constraint already present in the schema; it adds rationale (why warm send protects reputation) but little new syntactic meaning an agent couldn't get from 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?

States a specific verb+resource ('Create a new email broadcast in Meisa') plus the lifecycle state (draft) and the one-to-many nature of the resource. It explicitly distinguishes itself from meisa_send_email and points to meisa_send_broadcast for the send step, so an agent can separate it from its siblings 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 explicit when-to-use ('a broadcast sends one email to many contacts matching an audience segment'), a naming alternative for the template dependency (meisa_list_templates), the follow-up tool (meisa_send_broadcast), and an explicit when-not ('Do NOT use for one-to-one transactional emails. Use meisa_send_email for those'). This is the full when/when-not/alternatives pattern.

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 only cover the generic write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds substantial non-obvious behavior: the caller becomes owner, a unique slug is auto-generated, the current session product is NOT switched, DNS/DKIM/SPF/DMARC authentication is needed post-creation, and a conflict error is returned on duplicate name or domain. This is well beyond what the annotations 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?

Purpose and required inputs are front-loaded, and nearly every sentence carries operational information (ownership, slug, session behavior, DNS prerequisite, error case, return payload). It is long, and the two consecutive 'Returns...' sentences could be merged, but there is little genuine 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?

Even with no output schema, the description states the return payload (id, name, slug, domain, from_email, next steps) and the error case, and it covers the post-create DNS/provider workflow the agent must communicate. For a multi-parameter mutation tool this is unusually 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 the schema already documents all 8 parameters including defaults for from_email and primary_color. The description only restates the two required inputs (name, sending domain) and the example domain; it does not add syntax or format meaning beyond the schema. Baseline 3 applies 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?

Opens with a specific verb+resource ('Create a brand-new Meisa product') and immediately defines what a product is (app or brand with its own sending domain, contacts, sequences, templates, broadcasts). It distinguishes itself from working inside an existing product and from meisa_switch_product, so an agent can place it among the many sibling create_* tools 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 when-to-use: 'when the user wants to add another product or brand to their Meisa account, rather than working inside an existing one.' It also names the required follow-up (call meisa_switch_product afterwards to make it active) and the exception (unless it is the user's first product), which is exactly the routing guidance an agent needs.

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 safety profile (non-readOnly, non-destructive, non-idempotent). The description adds value beyond them by disclosing the provider_id precondition and that the created object (with sender id and defaults) is returned. It omits duplicate-handling and the fact that non-idempotency means repeated calls create multiple senders, which would be useful.

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 compact sentences: purpose first, usage/prerequisite next, return value last. Every sentence carries distinct information with no padding.

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

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

With no output schema, the description appropriately summarizes the return (created sender with sender id and defaults). Combined with 100% schema coverage and annotations, only minor behavioral details (duplicate/idempotency handling, default behavior of is_default) are missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes slightly beyond the schema by clarifying that 'provider_id' must belong to the same product as the sender and by grouping the From/reply-to fields into a coherent setup action.

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

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

States a specific verb+resource ('Create a sender identity') and the business purpose ('so email campaigns can send from a specific from email'). No sibling tool creates senders, so an agent can distinguish this from list_senders and the broadcast/sequence tools without opening the schema.

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

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

Gives clear context ('set up From name, from email, and reply-to for branding or operational routing') plus a hard prerequisite ('Requires an existing provider_id for the same product as the sender'). It does not name exclusions or when-not-to-use cases, but the trigger condition 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 establish non-read-only, non-destructive, non-idempotent behavior. The description adds lifecycle context the annotations cannot convey: the sequence is created in draft status and stays inert until activation, and it returns an auto-generated slug. It stops short of warning about duplicate creation on retry, which the idempotentHint=false would make valuable.

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

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

Four short sentences, front-loaded with the action and status, then the concept, then the workflow, then the return value. Nothing is redundant with the title and every sentence 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?

With no output schema, the description does note the return value (the created sequence with its slug) and the draft lifecycle, and the workflow pointers cover the multi-tool procedure. It omits any failure modes or validation constraints, a minor gap for a five-parameter create 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 name, sender_id, description, entry_trigger and email_category are all documented in the schema itself, including enum semantics. The description adds no parameter-level detail beyond the concept of enrollment, 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 ('Create a new email automation sequence') and defines what a sequence is ('multi-step drip campaign that contacts are enrolled in over time'), which disambiguates it from step-level and activation siblings. An agent can distinguish this container-creation tool from meisa_add_sequence_step and meisa_activate_sequence 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?

Explicitly lays out the workflow order — create the container, add drip steps with meisa_add_sequence_step, then activate with meisa_activate_sequence — which is exactly the sequencing guidance an agent needs. It does not, however, address when to choose a sequence over the sibling trigger-creation path, nor state any exclusions.

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

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

Annotations already declare the write/non-destructive/non-idempotent profile, so the safety burden is largely carried. The description adds that the result is reusable in broadcasts/sequences and that it returns the created template, but omits auth/permission needs, uniqueness constraints on name, or rate limits. 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?

Four short sentences, front-loaded with the core purpose and followed by usage context, requirements, and return value. Slightly repetitive of schema-required fields but no significant 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?

Given 100% schema coverage, no output schema, and clear annotations, the description covers purpose, when-to-use, required inputs, and return value. The absence of a stated output shape is mitigated by 'Returns the created template', leaving little an agent must infer.

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 schema fully documents all 7 parameters including the nested spintax_variables object and enum category. The description's 'Requires a name, subject line, and HTML body' merely restates the required fields and adds no syntax or format detail 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+resource ('Create a new email template in Meisa') and clarifies it produces a reusable template usable in broadcasts or sequences. It distinguishes the resource from siblings like meisa_create_broadcast or meisa_create_sequence, but 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?

'Use this when the user wants to save new email content as a reusable template' gives a clear triggering context. No exclusions or named alternatives (e.g., vs. meisa_update_template or meisa_create_broadcast) are provided, so it stops short of a full when/when-not statement.

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 safety profile (readOnly=false, destructive=false, idempotent=false); the description adds useful workflow context that annotations cannot: the trigger_key must be unique, the template must pre-exist, and external products later call meisa_send_email with the key. It stays consistent with the non-idempotent hint (duplicate key would fail) rather than contradicting it.

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

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

Four sentences, zero waste, and front-loaded: purpose first, then when to use, then the downstream send flow, then prerequisites. Every sentence carries information an agent needs.

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 16-parameter creation tool with no output schema, the description covers the identity, required inputs, and post-creation flow. It omits mention of behaviorally significant options (conditions, delay, override_unsubscribe, skip_duplicate_check), though the schema documents those fully, so the gap is modest.

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 16 parameters are already documented, including the important conditions/delay/override_unsubscribe semantics. The description only restates the three required fields and the uniqueness of trigger_key, adding little beyond the schema; 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 and resource ('Create a new email trigger') plus the core mapping it establishes (trigger_key -> existing template). This cleanly separates it from meisa_update_trigger, meisa_activate_trigger, and meisa_delete_trigger 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?

Gives clear when-to-use context ('wire up a transactional email like a verification code, password reset, welcome email, or refund confirmation') and names meisa_list_templates as the prerequisite lookup tool. It does not state any when-not condition or contrast triggers against sequences/broadcasts, which is the only gap.

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 idempotentHint=true and destructiveHint=false, and the description is consistent with both. It adds genuine behavioral context beyond the annotations: the exact persisted state (is_active=false) and the observable consequence that inbound /email/trigger/ calls with this trigger_key return 404 while inactive.

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 effect, followed by the operational consequence. Every clause carries information; 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 single-parameter toggle with no output schema, the description covers the action, the resulting state, the runtime side effect (404), and the alternative tool. Nothing an agent needs to call it correctly is missing.

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

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

Only one parameter, documented at 100% schema coverage with type, format (uuid) and a description. The prose adds no syntax or format detail beyond the schema, so the baseline 3 for full coverage 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 (Deactivate) and resource (email trigger), plus the concrete state change (is_active=false). It is clearly distinguishable from the sibling meisa_activate_trigger and from meisa_delete_trigger, which permanently removes rather than toggles.

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 names the alternative path explicitly ('Ergonomic shortcut for toggling is_active via meisa_update_trigger'), giving the agent a clear reason to prefer this tool for that specific operation. It stops short of stating when-not to use it (e.g., bulk updates or combined field edits).

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

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

Annotations already flag destructiveHint=true and idempotentHint=true, so the bar is lower. The description adds valuable context beyond annotations: the irreversibility statement reinforces destruction, and the 'currently sending' constraint is a behavioral rule not captured in 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?

Three short sentences, front-loaded with the core action, then the constraint, then the irreversibility warning. No wasted words and the most important information comes first.

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 single-parameter tool with full schema coverage and no output schema, the description covers the action, a key precondition, an alternative tool path, and irreversibility. An agent has everything needed to call it correctly or route elsewhere.

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

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

Schema coverage is 100% and the single parameter is fully documented as a UUID, so the description correctly does not repeat it. Baseline 3 is appropriate since no additional parameter meaning is provided beyond the schema.

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

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

States a specific verb (delete) and resource (broadcast), and qualifies it with 'Permanently' to distinguish from soft-delete siblings like meisa_delete_sequence. Clear which sibling verb is being applied.

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 ('currently sending cannot be deleted') and names the alternative action ('cancel it first with meisa_cancel_broadcast'). This is clear routing guidance, though it doesn't cover every alternative such as pause vs cancel.

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 the safety profile is known. The description goes beyond that by disclosing the specific failure mode (409 on active or paused enrollments), the remediation (pause and drain first), exactly what is destroyed (steps and draft state), and irreversibility.

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

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

Four short sentences, front-loaded with the action and followed by usage, the blocking condition, and side effects. 'Permanently' and 'This action is irreversible' are mildly redundant, which keeps this just short of a 5.

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

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

For a one-parameter destructive tool with no output schema, the description covers action, usage trigger, blocking precondition, remediation, and blast radius. Nothing an agent needs to invoke this correctly is missing.

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

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

There is a single parameter and schema description coverage is 100%, so the schema already documents sequence_id as a UUID. The description echoes the UUID requirement but adds no format, sourcing, or lookup guidance beyond the schema. 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 and resource ('Permanently delete an automation sequence') and identifies the resource by UUID. The clause about steps being removed distinguishes it from the sibling meisa_delete_sequence_step, which deletes a single step rather than the whole sequence.

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 an explicit when: 'when the user wants to clean up unused or empty sequences.' It also gives the when-not and the alternative path: deletion fails with 409 when enrollments exist, and the agent is told to pause the sequence and drain enrollments first. That is a full routing instruction.

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 readOnlyHint=false, so the safety bar is lower. The description nonetheless adds a real side effect the annotations do not convey: remaining steps are re-packed to stay contiguous, and the updated step list is returned. That is meaningfully useful context for a destructive mutation.

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: action, side effect, return value. Front-loaded with the verb and resource, and every sentence adds information 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?

No output schema exists, so the description correctly discloses the return value (the updated step list) and the re-packing behavior. For a two-param destructive tool this covers what an agent needs; only auth/permission expectations are unaddressed.

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

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

Schema description coverage is 100%, with both parameters carrying UUID format and provenance hints (step_id references meisa_get_sequence), so the schema does the heavy lifting. The description adds no parameter-level detail beyond what is already structured, which is the baseline 3.

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

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

Specific verb (Remove) plus precise scope (a step from a sequence), which cleanly separates it from meisa_delete_sequence (whole sequence) and meisa_delete_template_block. It does not explicitly name a sibling, 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?

Usage is implied by the purpose: remove a step. There is no explicit when-to-use, no reference to alternatives such as reorder_sequence_steps or update_sequence_step, and no prerequisites stated. Adequate but thin.

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 well beyond the annotations (destructiveHint, idempotentHint) by disclosing the 409 refusal path when triggers or sequence steps still reference the template, that the response lists the blocking triggers, and that the action is irreversible. This is exactly the kind of behavioral context an agent needs before invoking an irreversible mutation.

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 core action, then usage context, then the failure behavior. No filler and nothing 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 single-param destructive tool with no output schema, the description covers the operation, the intended trigger condition, the failure mode, and the recovery path, leaving nothing an agent needs to call it correctly unaddressed.

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

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

Schema description coverage is 100% and the single template_id (uuid) param is fully documented in the schema. The description's 'by UUID' adds no syntax or format detail 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+resource ('Permanently delete an email template') with the identifier type (UUID), clearly distinguishing it from siblings like meisa_delete_template_block, meisa_delete_trigger, and meisa_delete_sequence.

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 an explicit when-to-use condition ('when the user wants to clean up unused or obsolete templates') and names alternatives (meisa_update_trigger, meisa_delete_trigger) for the blocking case. It stops short of stating when NOT to use it, e.g. versus deleting a single template block, so no explicit exclusion 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 declare destructiveHint=true and idempotentHint=false, covering the safety profile. The description adds valuable behavioral context beyond annotations: it explains the side effect (remaining blocks re-serialized, plain-text body regenerated) and the freshness constraint (ids are position-based, re-read after mutations). This is helpful operational detail, though it doesn't mention permissions 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?

Three sentences, front-loaded with the action, then the parameter source, then the side effect and id stability 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 a destructive mutation with no output schema, the description covers the action, parameter sourcing, and critical side effects. It omits error cases (e.g., invalid block_id) and permission requirements, but is largely complete for correct invocation.

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

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

Schema coverage is 100%, so the schema already documents template_id (UUID) and block_id (e.g., blk-0). The description adds meaning by specifying the source of block_id ('from meisa_get_template_blocks call') and clarifying that ids are position-based and stable, which helps the agent understand the identifier's semantics.

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

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

States a specific verb (Remove) and resource (a single block from a template), and distinguishes itself from siblings like meisa_delete_template (whole template) and meisa_update_template_block. An agent can tell this apart from other deletion tools without opening schemas.

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

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

Provides clear guidance on the prerequisite: 'Pass the block_id from meisa_get_template_blocks call.' This tells the agent the workflow dependency. However, it doesn't explicitly state when to use this vs. meisa_update_template_block or what happens if the block is already deleted.

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 value beyond that by clarifying the blast radius (only the saved test-recipient list) and that no message is sent, which is the key side-effect question for this tool. It does not address behavior on a missing/invalid id, so it stops short of 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?

One sentence, front-loaded with the action, with a parenthetical for the id source and a trailing scope clause. Every clause earns its place; 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 single-parameter delete with full annotation coverage and no output schema, the description covers what an agent needs: the key, its source, and the limited scope. Only the error path (unknown id) is unstated, 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% and the single parameter already documents the UUID format and its source tool. The description repeats the id-source hint but adds no new semantics such as error handling or acceptable id forms, 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 (Remove) and resource (saved test recipient) plus the lookup key (by id), and names the sibling tool that supplies the id. An agent can distinguish this from meisa_delete_trigger, meisa_delete_template, and meisa_remove-style siblings immediately.

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?

Tells the agent where to obtain the required id (meisa_list_test_recipients) and scopes the effect ('Only affects your saved test-recipient list; sends nothing'), which implicitly rules out the send-style siblings. No explicit when-not guidance, but the routing context 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 destructiveHint=true and idempotentHint=true, and the description reinforces irreversibility. It adds real value beyond annotations by disclosing the concrete consequence: inbound calls to /email/trigger/ with the deleted trigger_key begin returning 404 immediately. It stops short of stating auth/permission requirements.

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

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

Front-loads the action, then the usage condition, then the downstream risk. Three tight sentences. 'This action is irreversible' overlaps with destructiveHint but serves as a closing emphasis, so minor redundancy only.

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

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

For a single-param destructive tool with rich annotations and no output schema, the description covers action, trigger condition, precondition and failure mode. Complete enough to invoke safely; only explicit alternative-tool routing is absent.

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

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

Schema coverage is 100% and the single trigger_id parameter is fully documented as a UUID in the schema. The description only restates that identification is by UUID, adding no format or constraint detail the schema lacks, 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 ('permanently delete') plus resource ('email trigger') and identifier type ('by UUID'). 'Permanently' cleanly separates it from the sibling meisa_deactivate_trigger, so an agent can route 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.

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

Gives a clear usage condition ('when the user wants to retire a transactional email mapping') and a precondition (confirm the upstream caller has migrated). It does not explicitly name deactivate_trigger as the reversible alternative, which leaves one inference to the agent.

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

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

Annotations declare a non-destructive, non-idempotent write, and the description adds genuinely new behavioral context beyond that: which properties are carried over (template, sender, subject overrides, audience segment, warm-send settings) and that the result is a draft, not a sent broadcast. It omits permission requirements and what the response contains, but the added state/side-effect detail is substantive.

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 are front-loaded with the action and use the remaining space for the naming convention, carried-over fields, and resulting state. No sentence is redundant and nothing is padded.

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

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

For a single-parameter duplication tool this covers action, effect, and resulting state well. The one gap is that no output schema exists and the description never says what is returned (e.g., the new broadcast's ID), which an agent needs to chain into edit/send operations.

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%, so the UUID semantics are already fully documented by the schema; the description adds no syntax, constraints, or format detail about it. The carry-over sentence describes the tool's effect rather than the parameter, so baseline 3 applies.

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

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

The first sentence states a precise verb+resource ('Create a draft copy of an existing broadcast') and is inherently distinguishable from the sibling meisa_create_broadcast, which makes new content rather than copying an existing one. It even specifies the resulting name convention ('<name> (Copy)') and the fields carried over, giving the agent an unambiguous picture of the action.

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

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

'Useful for reusing a proven campaign' gives clear when-to-use context for a duplication tool. It stops short of being explicit about alternatives (e.g., meisa_create_broadcast for net-new campaigns) or exclusions, so it is strong context without 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 readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds real behavioral value beyond that: it discloses two preconditions and, importantly, that re-enrollment errors if the contact is already enrolled (active or paused), which explains the non-idempotent behavior. Return format is not described, but no output schema exists.

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

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

Four short sentences, all load-bearing: core action first, then preconditions, then usage guidance, then error behavior. No redundancy or filler.

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

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

For a 2-parameter tool with full schema coverage and annotations, the description covers action, preconditions, and the key failure mode. It lacks a pointer to the meisa_list_sequences sibling for finding a slug (though the schema mentions it), which leaves one small 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%, so both parameters (email, sequence_slug) are already documented with format and lookup hints. The description restates the identification scheme (email for contact, slug for sequence) but adds no syntax or constraint detail 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 (enroll) and resource (contact in a Meisa automation sequence), and the title reinforces it. An agent can distinguish it from the inverse sibling meisa_unenroll_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?

Explicitly gives a usage trigger ('when the user wants to start a contact through a drip campaign or automation') and states prerequisites (contact must be 'active', sequence must be 'active'). It does not name the alternative meisa_unenroll_contact or other sequence-start tools explicitly, so it stops 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description still adds meaningful behavioral context beyond that: the count is performed 'without creating a broadcast,' which confirms no persistent artifact is produced. It does not describe response shape or any rate/volume limits, 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?

Three short sentences with the core purpose front-loaded and every clause carrying information. Slight redundancy: the omit-or-pass-{} default for segment_query is already stated verbatim in the schema description, so one sentence partially duplicates structured data.

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 signals the return value ('Count how many contacts match'), and the nested-object parameter is explained via cross-reference. For a one-parameter, read-only tool this is close to sufficient; only the exact return shape (bare integer vs. object) is left implicit.

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

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

Schema coverage is 100% and the single nested parameter carries its own example, so the baseline is 3. The description adds value by cross-referencing 'the same segment_query shape used by meisa_create_broadcast' and restating the omit-or-{} default behavior, giving the agent an additional mental model for authoring the nested object.

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 ('Count how many contacts match a segment query') and immediately separates itself from the write path with 'without creating a broadcast.' An agent can distinguish it from meisa_create_broadcast and meisa_search_contacts 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?

'Use this to size an audience before building a campaign' gives clear context for when to reach for it, and the reference to the segment_query shape used by meisa_create_broadcast routes the agent to the related tool. It stops short of an explicit when-not statement (e.g., 'do not use this to actually send'), which would make it 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only that the response includes statistics and scheduling information, which is output content rather than behavioral traits; no auth, rate-limit, or freshness context is offered.

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

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

Three tight sentences with no waste; the core action is front-loaded and the return-field list is informative rather than padded. It is appropriately sized for a one-parameter retrieval tool.

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

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

With no output schema, the description carries the burden of describing return values and does name the key metrics and scheduling info, which is good. The gap is sibling disambiguation from meisa_get_broadcast_analytics, which is never addressed despite heavy overlap in the described 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?

Schema coverage is 100% and the single parameter is fully documented with a UUID format hint. The description's 'by UUID' simply restates the schema, so the baseline 3 applies when the schema does all the work.

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

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

The description states a specific verb and resource ('Retrieve the full details and delivery statistics of a single Meisa broadcast by UUID') and the word 'single' signals it is not a list operation. However, it does not differentiate from the very close sibling meisa_get_broadcast_analytics, which the described stats fields (open/click/bounce rate) would equally suggest.

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?

'Use this when the user asks about results or stats for a specific campaign' gives an implied usage context. But it provides no when-not and, critically, does not tell the agent when to choose this over meisa_get_broadcast_analytics or meisa_list_broadcasts, leaving the highest-risk routing decision 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 this a read-only, idempotent, non-destructive operation, so safety is covered. The description adds useful scope ('most recent sent broadcasts' as opposed to drafts or scheduled) and the returned metric set, but says nothing about ordering, pagination, or behavior when fewer broadcasts exist than requested.

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

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

Three tight sentences with zero filler: purpose first, then the payload contents, then the usage triggers. Every sentence earns its place and the most decision-relevant information is front-loaded.

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

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

With only one optional integer parameter, no nested objects, and no output schema, the description does enough by enumerating the returned metrics in place of an output schema. It omits ordering/pagination details, which is a minor gap for a tool this simple.

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

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

Schema description coverage is 100%, and the single last_n parameter is fully documented in the schema with default and max. The description's phrase 'most recent sent broadcasts' reinforces the recency semantics but adds no syntax or bounds beyond what the schema already states, 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?

The definition gives a specific verb and resource (return performance metrics for the most recent sent broadcasts) and names the exact metrics returned (open rate, click rate, send counts). It clearly distinguishes itself from the plain broadcast getters at the metric level, though it never names a sibling 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?

It gives three concrete triggers ('asks how their emails are performing', 'asks for email stats', 'wants to review recent campaign results'), which map directly to plausible user intents. There are no exclusions or alternative tools named, so an agent must infer the boundary against meisa_get_broadcast or meisa_get_contact_analytics.

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 covered. The description adds useful behavioral content: exactly what the response contains (engagement metrics, tags, custom fields, email preferences) and that it is a single-contact read returning the complete object.

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

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

Three tightly scoped sentences with the core action front-loaded and no filler. The closing 'Returns the complete contact object' is mildly redundant with the first sentence's field list, a minor redundancy rather than bloat.

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 return-value burden and does so at a high level by enumerating the field groups. It does not cover error behavior for an unknown UUID, which is a small gap for a lookup tool, but nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100% and the single parameter already specifies UUID format, so the description's mention of 'by their UUID' adds no syntax beyond the schema. Baseline 3 applies 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?

States a specific verb (Retrieve) and resource (full profile of a single Meisa contact) plus the lookup key (UUID) and the field groups returned. It is clearly distinguishable from sibling list/search tools by the singular, ID-keyed scope.

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

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

Explicitly says to use it after obtaining an ID via meisa_search_contacts or meisa_list_contacts, naming the two alternative entry points. It stops short of stating when not to use it (e.g. bulk retrieval via meisa_list_contacts), but the routing context 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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real value by disclosing the shape of the result (total plus status breakdown), but says nothing about scope (workspace/product filtering), auth, or caching/freshness.

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. What it returns comes first, the usage trigger second, so the most decision-relevant information is front-loaded.

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

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

With no input parameters and no output schema, the description carries the return-value burden and does so by enumerating total contacts and the four status buckets. Nothing further is needed to call it correctly.

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

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

Zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The description correctly does not invent parameter details.

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?

Specifies a clear verb and resource ('Return aggregate contact health statistics') plus the exact breakdown returned (active, unsubscribed, bounced, complained). The word 'aggregate' implicitly separates it from meisa_list_contacts and meisa_get_contact, but 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?

Gives concrete trigger conditions: 'when the user asks about their list health, list size, or subscriber counts.' That is clear when-to-use guidance, though it names no alternative (e.g. vs. list_contacts for individual records) or when-not condition.

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 safe read profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuine value by disclosing the composition of the response (step definitions, entry trigger, enrollment statistics, completion rate), which matters because no output schema exists.

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

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

Two tight sentences: purpose first, then usage. Zero filler, and the return contents are front-loaded before the routing hint.

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

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

For a single-parameter read tool whose annotations carry the safety profile, this covers what an agent needs: the identifier, what comes back, and when to call it. Nothing material is missing despite the absence of an output schema.

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

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

Single parameter with 100% schema description coverage, so the schema already documents the UUID format. The description repeats the identifier type ('by UUID') but adds no syntax or behavior beyond it, 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 (Retrieve) and resource (a single Meisa automation sequence) scoped by UUID, and enumerates the returned payload (steps, entry trigger, enrollment stats, completion rate). The 'single' scope plus the resource noun cleanly distinguishes it from list_sequences and from the other get_* siblings.

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

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

Explicitly states when to use it: user asks for details about a specific sequence or wants to review its steps. No alternatives or exclusions are named (e.g., when to prefer list_sequences vs this), so it stops short of a full when/when-not mapping.

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 value beyond that by disclosing what the call returns (HTML body and plain-text version), which matters since there is no output schema. It omits error/not-found behavior, but that is a minor gap for a read tool.

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

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

Two sentences, zero filler, and the action plus return contents are front-loaded before the usage sentence. 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-by-id tool with rich annotations and full schema coverage, the description covers purpose, usage, and the main return contents, which is sufficient without an output schema. It stops short of enumerating the remaining template fields or failure modes, so it is complete but not exhaustive.

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

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

With a single parameter at 100% schema description coverage, the schema already documents template_id and its UUID format. The description's 'by UUID' restates the schema rather than adding syntax, lookup, or validation 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 (Retrieve) plus resource (Meisa email template), scope (single, by UUID), and contents returned (HTML body, plain-text version). It implicitly separates itself from meisa_list_templates via 'single', but never names a sibling such as meisa_get_template_blocks or meisa_list_templates, so differentiation is left to inference.

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

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

The sentence 'Use this when the user wants to review or inspect an existing template's content' gives a usage scenario, but it is largely restated from the tool name and adds no routing value: it does not say when to prefer meisa_get_template_blocks, meisa_list_templates, or meisa_update_template. Implied usage rather than explicit when/when-not.

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, but the description goes well beyond them: it explains that block ids are position-based (blk-0, blk-1, ...), that ids stay stable only while order is unchanged, and that positions shift after insert/delete/move. This id-lifecycle detail is exactly the behavioral context an agent needs and 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?

Front-loaded with the core action and return, then the when-to-use, then the id-stability caveat. Every sentence carries new information (block types, alternative, id semantics, re-read rule) with no repetition or filler.

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

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

With no output schema, the description compensates by enumerating the returned block types and describing the id format and how it behaves across reads/mutations. For a single-param read tool, nothing an agent needs to call and consume it correctly is missing.

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

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

Only one parameter (template_id) and schema description coverage is 100%, so the schema already fully documents it as the UUID of the template. The description adds no syntax or format 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 (parse) and resource (a template's HTML → block model) and the exact return (ordered list of blocks), enumerating all 15 block types. An agent can distinguish this from siblings like meisa_get_template and meisa_update_template_block 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?

Explicitly says when to use it ('to inspect a template's structure before editing a single block') and names the alternative it replaces ('instead of rewriting the whole HTML'). It further prescribes re-reading after insert/delete/move, giving a concrete workflow condition.

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 cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false), and the description adds real behavior beyond them: settings are merged over type defaults, out-of-range indexes are clamped/appended, and a bare insert yields a sensible default block. It stops short of failure modes or validation 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 sentences, front-loaded with the action and position, then optional-field behavior, then the prerequisite tool. Slight redundancy between 'Provide the block type and the 0-based at_index' and the schema, but nothing is wasted.

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

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

For a non-idempotent mutation with no output schema and nested settings, the description supplies the merge semantics, index clamping, default behavior, and a prerequisite read tool, which is enough to call it correctly. It does not describe what is returned after insertion.

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 baseline is 3, but the description still adds meaning: the 0-based indexing convention with 0=top, append-on-overflow behavior, and the merge-over-defaults semantics of settings that the schema's terse 'merged over the block type's defaults' only gestures at.

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 precise verb+resource (insert a new block into a template) plus the positional scope, which is enough to separate it from meisa_update_template_block and meisa_move_template_block without opening any schema. The word 'new' makes the create-vs-edit distinction explicit.

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

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

Gives a concrete prerequisite workflow: 'Use meisa_get_template_blocks first to decide the index.' It never names the competing alternative (updating an existing block) or states exclusions, so it is strong context rather than 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, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds value beyond that by disclosing what a result contains (name, status, send stats, scheduled time), which annotations cannot convey. It stops short of noting pagination limits or auth requirements, so it is not fully 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?

Three tight sentences with the purpose stated first, then the return payload, then the routing rule to the sibling. No sentence is redundant 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?

There is no output schema, so the description appropriately carries the return-value burden by naming the summary fields. Combined with the fully-covered input schema, an agent has everything needed to select and call this read-only, zero-required-parameter list 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% and all three parameters (limit, offset, status) are documented in the schema itself, including ranges, defaults, and the enum. The description adds no parameter-level detail beyond the implicit notion of past/upcoming campaigns, 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?

Starts with a specific verb+resource ('List email broadcasts') and clarifies scope with the parenthetical '(one-time or recurring campaigns)'. It also distinguishes itself from the single-broadcast sibling by naming meisa_get_broadcast, so an agent can route correctly 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.

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

Gives an explicit trigger ('Use this when the user asks to see their past or upcoming email campaigns') and an explicit alternative with its condition ('For full delivery statistics on one broadcast, use meisa_get_broadcast'). Both when-to-use and when-to-prefer-a-sibling 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 cover read-only, idempotent and non-destructive behavior, but the description adds genuinely non-obvious context: unsubscribed/bounced/complained contacts are hidden unless include_suppressed is true or a status is given, and results are summaries only (no email body). No auth or rate-limit notes, but the suppression rule is exactly the kind of behavior an agent would otherwise guess wrong.

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?

Front-loads the core action and scope, then layers filtering, suppression behavior, return format, and sibling routing. Every sentence carries distinct information and none is redundant with 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?

With no output schema, the description steps in to explain the return shape ('summary for each contact, no email body content'), and all six parameters are covered. An agent has enough to call this correctly without further 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 100%, so all six parameters (tag, limit, offset, search, status, include_suppressed) are already documented in the schema. The description references filtering by status/tag and pagination but adds no syntax or format detail beyond what the schema provides, 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 (list) and resource (contacts) with scope (connected Meisa product, reverse-chronological order). Explicitly distinguishes itself from the sibling meisa_get_contact by routing single-contact lookups elsewhere, so an agent can tell the two apart 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.

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

Gives concrete trigger phrases ('see their subscriber list, browse contacts, or check how many contacts they have') and names one alternative (meisa_get_contact). However, it omits meisa_search_contacts, which is a very close sibling, leaving that routing decision 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 the safe read profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description doesn't need to restate safety. It still adds value beyond annotations by disclosing that the result marks the active product and includes names and IDs. It stops short of detailing pagination or ordering, which keeps it from a 5.

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

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

Three short sentences: what it lists, when to use it, and what comes back. The purpose is front-loaded and every sentence carries distinct information 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?

With no output schema, the description takes on return-value disclosure and does so at a useful level (names, IDs, active product indicator). It omits ordering/pagination details, but for a zero-parameter read-only list tool this is close to complete.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing parameter-related for the description to clarify, and it correctly avoids inventing filter semantics.

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

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

The description names a specific verb and resource (list Meisa products) plus an extra behavior (indicate the currently active product), which distinguishes it from list siblings like meisa_list_templates or meisa_list_senders. An agent can identify the tool 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 gives explicit trigger conditions ('user asks which product they are connected to', 'wants to see their products') and names a concrete downstream alternative ('before calling meisa_switch_product'), which is exactly the when-to-use routing an agent needs.

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

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

Annotations already establish the safe-read profile (readOnly, idempotent, non-destructive), so the description only needs to add operational context. It does: the default scoping to the active product is a non-obvious behavior an agent must know, and it reiterates the product_id/all_products mutual exclusion. It does not describe pagination or return shape, keeping it from a 5.

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

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

Three sentences, front-loaded with the core purpose before the scoping mechanics and use cases. Every sentence contributes, though the closing use-case list is slightly expansive for a simple list tool.

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

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

No output schema exists, so the description must at least characterize the result, which it does ('sender identities'), and annotations cover the safety profile. It omits return shape and pagination behavior, the only meaningful gap for a paginated list 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 all four parameters are already documented in the schema. The description restates the product_id/all_products semantics but adds no new format, constraint, or default detail beyond what the schema provides. Baseline 3 is appropriate when the schema carries the load.

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 sender identities') with clear scope ('available in the connected Meisa account'). An agent can immediately distinguish this read tool from write siblings like meisa_create_sender 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?

Clearly explains when to use each scoping mode ('Use product_id to target one product directly, or all_products=true to fetch senders across every product') and names concrete use cases ('audit, setup validation, or finding the right sender_id before creating campaigns and triggers'). It lacks explicit when-not guidance or a named alternative sibling, so it stops short of 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 readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds useful context beyond annotations by listing exactly what each returned sequence contains, though it says nothing about pagination behavior or result totals.

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

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

Three tight sentences, front-loaded with the resource and scope, then return fields, then usage and the sibling route. No filler sentences and nothing 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?

With no output schema, the description usefully compensates by enumerating the returned fields, and pagination is fully covered by the schema. The only shortfall is that the enrollment use case is hinted at without naming the tool that performs it.

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

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

Schema description coverage is 100%, with limit, offset, search and status all documented in the schema itself, so the baseline is 3. The description adds no syntax or format detail beyond what the schema provides (e.g., it never mentions the status filter values or substring matching).

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 automation sequences (drip campaigns)') and enumerates the returned fields (name, slug, status, entry trigger, step count, enrollment stats, completion rate). It explicitly distinguishes itself from the sibling meisa_get_sequence, which returns steps.

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

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

Gives a clear when-to-use condition ('user asks to see their automations or wants to enroll a contact') and names one alternative, meisa_get_sequence, for step details. However, it mentions enrolling a contact without pointing to the actual action tool (meisa_enroll_in_sequence), leaving that routing implicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds product scoping (tags from the connected product) and discloses that contact counts are returned, which is meaningful return-shape context given 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?

Two sentences, no redundancy. The factual scope leads and the usage recommendation follows, so an agent gets the essential information first.

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 characterizes the return (tags plus per-tag contact counts) and covers pagination indirectly through schema. It stops short of noting result ordering or total-count behavior, a minor gap for a list 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%, and both pagination parameters are fully documented in the schema, so the description is not required to explain them. It adds no additional parameter semantics (e.g. ordering of results), which is the expected 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 precise verb+resource: listing all contact tags in the connected Meisa product, and adds the notable detail that each entry includes a count of tagged contacts. It is unambiguous against siblings such as meisa_list_contacts or meisa_search_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?

Explicitly says when to use it: 'before filtering contacts or adding tags to a contact', which frames it as a discovery/prerequisite step. It does not name a when-not case or a competing alternative, so it falls short of 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 readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuine value by disclosing the return shape ('summaries only') and warning that full content requires a separate call — context not available in 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?

Three tightly written sentences: purpose, definition, and the ID-lookup use case plus the return-shape caveat. Nothing is redundant and the critical routing information is front-loaded.

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

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

With no output schema, the description compensates by stating that only summaries are returned and naming the follow-up tool for full content. Pagination params are covered by the schema. Complete enough for confident 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 limit, offset, search, and category are fully documented in the schema itself. The description adds no syntax or semantics 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 and resource ('List email templates') and defines what a template is (reusable subject + HTML body). It distinguishes itself from the closest sibling by pointing to meisa_get_template for full content, so an agent can tell the two apart without opening schemas.

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 an explicit use case: 'find a template ID before creating a broadcast or sequence.' It also routes to the alternative (meisa_get_template) when full HTML is needed. No when-not-to-use statements, but the context 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuine behavioral fact beyond that: these recipients are account-level and shared across all products regardless of the active one, which matters 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?

Three tight sentences, front-loaded with the definition of the resource before the scoping constraint and the use case. No filler or restatement of the name.

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

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

With no output schema, the description compensates by stating what the items are (email addresses), and the account-level scope note prevents a false assumption about per-product filtering. It does not mention ordering, count, or what an empty result means, which is a minor gap for a list 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?

The tool takes no parameters (empty schema, additionalProperties false), so there is nothing for the description to disambiguate. Baseline for a zero-parameter tool; no misuse risk from arguments.

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

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

States a specific verb (List) and resource (saved test recipients), then disambiguates the resource from the similarly named contacts list by defining it as 'the email addresses you send preview/test emails TO'. Unambiguously separable from siblings like meisa_list_contacts, meisa_list_senders and meisa_list_templates.

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 when-to-use guidance: 'find an address before sending a test, or to review who test emails go to.' That covers the primary intent, though it does not name the sibling actions that consume this list (e.g. meisa_send_template_to_test_recipients) or note that add/delete_test_recipient exist as alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds non-obvious domain behavior – that triggers bridge a trigger_key to a template and expose expected variables – which an agent could not infer from the annotations. It stops short of describing return format or pagination.

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

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

Three tight sentences with zero waste. The core purpose is front-loaded, followed by a concise domain gloss and the actionable routing instruction.

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 hints at return content ('available trigger_key values and understand what variables each trigger expects'), and pagination is covered by the schema. Combined with the read-only annotations, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, with both limit and offset fully documented in the schema including defaults and maxima. The description adds nothing about these parameters, so the baseline 3 is appropriate when the schema does all the work.

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

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

States a specific verb and resource ('List all configured email triggers') scoped to the connected Meisa product, and defines what a trigger is ('maps a trigger_key to an email template'). This distinguishes it clearly from siblings like meisa_create_trigger, meisa_update_trigger, and meisa_test_trigger.

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

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

Explicitly names when to use it: 'Use this before calling meisa_send_email to discover the available trigger_key values.' It routes the agent to the specific downstream tool and states the condition that motivates the call, leaving nothing 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 the mutation with destructiveHint=false and idempotentHint=true. The description adds value beyond them by confirming 'Content is unchanged; only the order changes' and disclosing the clamping behavior for out-of-range indices, which an agent needs to predict results. It omits what happens on an invalid/stale block_id, which is the main remaining 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?

Four short sentences, front-loaded with the action and position semantics, then the prerequisite. Every sentence adds usable information 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 three-parameter, no-output-schema reorder tool with full annotation coverage, the description supplies the essential context: identity of the moved item, indexing convention, clamping, and the freshness requirement. Only error/stale-id behavior is left unspecified, a minor omission.

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

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

Schema description coverage is 100%, so block_id and to_index formats are already documented in the schema. The description essentially restates that block_id comes from meisa_get_template_blocks and that to_index is 0-based, adding provenance but no syntax or semantics beyond the structured fields. Baseline 3 applies when the schema carries this load.

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 ('Reorder') and resource ('a template ... moving one block') with the exact mechanism and indexing convention. An agent can separate this from meisa_update_template_block (edit content) and meisa_reorder_sequence_steps (sequence steps, not template blocks) 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 a concrete prerequisite workflow: fetch block_id from a fresh meisa_get_template_blocks call and 'Re-read blocks right before calling this,' which names the sibling to use and warns against stale ids. It does not explicitly state when to prefer this over meisa_update_template_block, so it stops short of a full routing rule.

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 it is a non-read-only, non-destructive, non-idempotent mutation, and the description adds real context: the observable effect ('Delivery stops until you resume it') and the state gate ('only sending broadcasts'). It does not say what happens on a repeat call or on a non-sending broadcast, which matters 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?

Three short sentences, front-loaded with the action and with no filler. 'Currently sending' and 'only sending broadcasts can be paused' partially restate the same precondition, a small redundancy that keeps it just short of ideal.

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

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

For a single-parameter state-mutation tool with no output schema and full annotation coverage, the description supplies the precondition, the delivery effect, and the recovery path. The main omission is failure behavior (repeat pause, wrong-state broadcast) on a tool flagged non-idempotent.

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 with 100% schema description coverage, so the schema already documents broadcast_id as the UUID of the sending broadcast. The description's state constraint slightly narrows which UUID is valid but adds no syntax or format detail 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 ('Pause') and resource ('broadcast') with scope ('that is currently sending'). It also names the inverse sibling meisa_resume_broadcast, letting an agent distinguish pause from resume, cancel, or delete without opening schemas.

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 an explicit precondition ('Only sending broadcasts can be paused') which implicitly excludes draft/scheduled/cancelled ones, and points to the resume tool for the reverse action. It stops short of contrasting with siblings like cancel_broadcast, which is a plausible alternative when an agent wants to stop delivery permanently.

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

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

Annotations already declare non-read-only, idempotent, non-destructive behavior. The description adds genuinely new context: already-enrolled contacts remain enrolled but stop advancing until reactivation, and only active sequences qualify. It omits what happens to in-flight sends or the response shape, but the state semantics disclosed are valuable.

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, zero filler, and the core action is front-loaded ahead of the caveats. Every sentence earns its place by adding either scope or a precondition.

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

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

For a one-parameter mutation with no output schema, the description covers action, side effects on enrolled contacts, and the validity precondition. Missing only edge-case behavior (e.g., what happens to pending sends) and any mention of reactivation via the sibling 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?

There is a single parameter (sequence_id) with 100% schema description coverage, so the schema already carries the meaning. The description adds nothing about the parameter, 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?

States a specific verb ('Pause') and resource ('an active sequence') plus the operational effect ('stops processing enrollments'). An agent can distinguish it from meisa_activate_sequence, meisa_pause_broadcast, and meisa_update_sequence 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 a clear precondition: 'Only active sequences can be paused,' which tells the agent when the call is valid. It does not explicitly name the counterpart tool (meisa_activate_sequence) or state what to do when the sequence is not active, so it stops 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 declare a non-read-only, idempotent, non-destructive mutation. The description adds the key behavioral constraint beyond the annotations: step_ids must contain exactly the current steps, no missing or extra ids — revealing this is a whole-collection replace rather than an incremental 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?

Three short sentences, front-loaded with the action, followed by the constraint and the prerequisite. No filler.

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

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

For a two-parameter, no-output-schema tool this covers the essential call contract and the exact-match constraint. It could note what happens if the id set mismatches (error) but otherwise nothing an agent needs is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by stressing that the list must match the current step set exactly and ordering semantics ('desired order'). It does not clarify error behavior when the set mismatches.

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 ('Reorder all of a sequence's steps') and clarifies the one-call, whole-sequence scope. This distinguishes it cleanly from meisa_add_sequence_step, meisa_update_sequence_step, and meisa_delete_sequence_step.

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 tells the agent how to obtain prerequisites ('Get the current step ids from meisa_get_sequence first') and states the completeness requirement for the input. It stops short of naming a when-not-to-use case, but the context 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 destructiveHint=true, idempotentHint=false, and openWorldHint=true, establishing a safe baseline. The description adds valuable context: it creates and queues a new resend, returns the new broadcast id, and has status/prerequisite constraints. However, it doesn't detail what happens to the original broadcast or potential duplicate-sending risks.

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

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

The description is three compact sentences, front-loading the core action and conditions. Every sentence adds value without 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?

Given the tool's complexity (2 parameters, no output schema, annotations provided), the description is complete. It covers purpose, prerequisites, optional parameter guidance, and return value, enabling 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 the schema fully documents both parameters. The description adds practical advice ('a new subject line often lifts opens') but no new syntax or semantic details beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Create and queue a resend of a SENT broadcast to the contacts who received it but did not open it.' This precisely distinguishes it from siblings like meisa_duplicate_broadcast (which copies) and meisa_send_broadcast (which sends originally), leaving no ambiguity.

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

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

The description provides clear prerequisites: 'Only works on broadcasts in sent status that have at least one non-opener.' It implies when to use (to re-engage non-openers) but does not name alternatives (e.g., creating a new broadcast vs. resending).

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

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

Annotations already flag destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is partly covered. The description adds genuinely useful context beyond the annotations: only contacts who have not received the email are sent to, so resuming never double-sends, and the paused-state requirement. This is valuable behavioral disclosure not present in 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?

Three short sentences, all front-loaded with the core action first, followed by the no-double-send guarantee and the state precondition. 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 a single-parameter action tool, the description covers action, eligibility, and the key side-effect guarantee, while annotations carry the safety profile and there is no output schema to explain. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100% with a single clearly documented broadcast_id parameter (UUID of the paused broadcast). The description adds no parameter syntax or format detail beyond the schema, so baseline 3 is appropriate.

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

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

Specific verb+resource ('Resume a paused broadcast') that cleanly distinguishes it from siblings like meisa_pause_broadcast and meisa_cancel_broadcast. It also states the eligibility precondition, so an agent knows exactly what state the resource must be in.

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 states the when-to-use condition ('Only paused broadcasts can be resumed'), which rules out resuming draft/sent broadcasts. It doesn't name alternative tools (e.g. resend_broadcast_to_non_openers) for adjacent cases, so it stops 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 declare a non-read-only, idempotent, non-destructive write, and the description reinforces this by disclosing the state transition to 'scheduled' and the draft-only precondition, which is genuinely useful context beyond the annotations. It does not cover authorization needs, rate limits, or what happens on rejection of a non-draft id, 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?

Four short sentences, front-loaded with the action and resulting status, then constraints, then the precondition. No filler or repetition beyond minor overlap with the schema examples.

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 covers the action, the state change, parameter requirements, and eligibility. It omits error behavior for non-draft or past-dated input, which would round it out but is not essential to invoke 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 all three parameters including the ISO 8601 example and IANA timezone. The description largely restates the same constraints (future ISO 8601 datetime, timezone for display) without adding new syntax or format detail, 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 ('Schedule a DRAFT broadcast'), plus the resulting state ('Sets the broadcast to scheduled status'). It clearly distinguishes itself from siblings like send_broadcast or cancel_broadcast by scoping to drafts.

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

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

Gives a clear precondition ('Only draft broadcasts can be scheduled') and a constraint on the parameter ('scheduled_at must be an ISO 8601 datetime in the future'). It does not explicitly name an alternative tool (e.g., use send_broadcast to send immediately), so it stops short of 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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavioral facts: a 50-match cap and the absence of pagination. It stops short of describing match semantics (exact vs. partial/fuzzy) or result ordering, which would matter for search 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 tight sentences: capability, when to use, and the pagination limitation plus escape hatch. Front-loaded with the operation and free of 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 one-parameter read-only search with an annotated safety profile, this is nearly complete — the match cap and pagination stance are disclosed even without an output schema. The only real omission is whether matching is exact or partial and how results are ordered.

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

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

Schema coverage is 100% and the single parameter `q` is fully documented in the schema, so the baseline is 3. The description's 'by email, name, or external ID' restates the schema's match targets without adding syntax, exactness, or formatting guidance.

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

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

States a specific verb (search) + resource (contacts) + matching fields (email, name, external ID), and explicitly sets itself apart from meisa_list_contacts. An agent can distinguish it from the list sibling 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.

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

Gives explicit when-to-use triggers ('user mentions a specific person by name or email', 'do I have a contact for X?') and names the alternative for the opposite case ('for browsing large lists use meisa_list_contacts'). Nothing is left to inference.

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

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

Annotations already flag destructive/openWorld/non-idempotent, but the description adds the consequences an agent actually needs: real emails to all matching contacts, irreversible, immediate return with status 'sending', and the warm_send pacing behavior that changes delivery timing up to 24 hours. This is behavior beyond the annotation flags.

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?

Five short sentences, each load-bearing: purpose, irreversibility warning, consent gate, precondition, pacing nuance, and return/monitor behavior. The critical warning is front-loaded right after the purpose.

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

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

No output schema exists, but the description compensates by stating the immediate return value ('sending') and pointing to meisa_get_broadcast for progress. Combined with the precondition and consent gate, an agent has everything needed to call this correctly and safely.

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

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

Schema coverage is 100% for the single broadcast_id parameter, so the baseline is 3. The description adds a real constraint on the parameter's valid value (it must reference a broadcast in 'draft' status) and a sibling tool to inspect it, which is meaning the schema does not carry.

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 ('Queue a draft Meisa broadcast') plus the scope 'for immediate delivery,' which separates it from meisa_schedule_broadcast and meisa_test_send_broadcast without needing to open their schemas.

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 an explicit precondition ('broadcast must be in draft status'), an explicit consent gate ('only call this after the user has explicitly confirmed'), and names meisa_get_broadcast as the way to verify state. When-to-use and how-to-verify are both covered.

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

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

Annotations already declare this is a non-readonly, non-idempotent, open-world mutation, so the safety profile is covered. The description adds real value beyond that: it warns the email is sent for real and immediately, and that the trigger must pre-exist. It doesn't mention permissions, rate limits, or delivery/return behavior, which keeps it short of 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?

Every sentence earns its place: purpose, use cases, prerequisite, immediate-send warning, and the do-not-use exclusion. It is front-loaded with the core action and carries no redundant restatement of the schema.

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

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

For a tool with no output schema and a nested recipient object, the description covers the operational essentials (single recipient, immediate real send, trigger prerequisite, bulk exclusion). It stops short of describing the response or error cases, a minor gap given the richness already present.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema doesn't: it explains that trigger_key must already be configured and points to meisa_list_triggers, reinforcing the schema's own hint. The recipient/variables mechanics remain schema-documented.

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 ('Send a triggered (transactional) email to a single email address') and immediately scopes it via a pre-configured trigger. It distinguishes itself from the sibling meisa_send_broadcast by naming it explicitly, so an agent can route correctly 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 explicit when-to-use examples (verification code, password reset, notification), a prerequisite path (trigger_key must exist; use meisa_list_triggers), and an explicit exclusion naming the alternative (bulk → meisa_send_broadcast). Nothing is left to inference.

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

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

Annotations only give the generic safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the description's disclosure that this is 'not recorded as a real send and never goes to your contacts', plus the dependency on the active product's configured sender, is genuinely additive. It stops short of stating rate limits or how skipped addresses are reported 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?

Purpose is front-loaded in the first clause, and each subsequent sentence carries a distinct prerequisite (recipient list behavior, sender configuration, preview-only semantics). No filler or restatement of 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?

For a two-parameter tool with no output schema and adequate annotations, the description covers the send target, the recipient eligibility constraint, the sender dependency, and the non-persistent side-effect profile. An agent has everything needed to call it correctly or route elsewhere.

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 and the schema already explains `emails` and `template_id`. The description still adds workflow meaning the schema lacks: addresses must be pre-registered via meisa_add_test_recipient, and the from-address derives from product configuration rather than a parameter.

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

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

States a specific verb+resource ('Render a template and send it as a [TEST] email') and immediately scopes it to test recipients, which cleanly separates it from meisa_send_email and meisa_test_send_broadcast. The bracketed [TEST] marker and 'preview only' clause make the operation type 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?

Gives explicit operating conditions: omit `emails` to hit all saved test recipients, pass a list to target specific ones, each address must already be saved (use meisa_add_test_recipient first), and the active product must have a default sender configured. It also implies the when-not case by stating this is a preview and not a real send.

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 disclose the mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds real value by explaining the session-scoped effect: subsequent tool calls operate on the new product. It does not mention auth/permission requirements or error behavior, so not a 5.

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

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

Three short sentences, front-loaded with purpose, then usage trigger, then downstream consequence. Zero wasted words.

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

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

For a single-param, low-complexity tool with 100% schema coverage, no output schema, and annotations covering safety, the description is complete: it explains purpose, invocation condition, prerequisite, and session-wide effect.

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

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

Schema description coverage is 100% and the schema already states the parameter is the product ID to switch to and to get it from meisa_list_products; the description merely restates this. Baseline 3 applies since the schema carries the parameter semantics.

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

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

States a specific verb+resource ('Switch the active Meisa product for this session') and clearly distinguishes itself from siblings like meisa_create_product and meisa_list_products, which are separate resources/operations.

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 an explicit trigger condition ('when the user asks to work with a different product or says switch to my X product') and names the prerequisite alternative step (call meisa_list_products first to get the product_id). Nothing is left to inference.

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

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

Goes well beyond the annotations: it discloses the outward side effect (an email is actually sent), the scoping guarantee that audience/status/stats are untouched (elaborating destructiveHint=false), the '[TEST]' subject transform, the contact-existence requirement, and the not_found_emails return field despite no output schema. This is rich disclosure for a write-with-side-effects tool.

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

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

Four tight sentences, front-loaded with purpose, then scope guarantees, then recipient constraints, then the usage cue. No filler; every clause (subject prefix, stats immunity, not_found_emails) carries actionable 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 2-param tool with no output schema and no annotations covering behavioral scope, the description covers purpose, side effects, non-destructiveness, recipient preconditions, and the return signal. Nothing an agent needs to call it correctly appears to be missing.

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

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

Schema coverage is 100%, so both parameters are already documented (baseline 3). The description adds real meaning beyond the schema by explaining the consequence for the `emails` parameter when an address is not a contact ('returned in not_found_emails'), which the schema does not state.

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 precise verb+resource+scope: sends a *test copy* of a *broadcast* to *specific email addresses*, and the '[TEST]' subject prefix confirms the intent. The closing line ('preview a real send before launching') implicitly distinguishes it from meisa_send_broadcast, so an agent can tell it apart from the real-send sibling.

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

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

Explicit when-to-use is given: 'Use this to preview a real send before launching.' However, it names no alternative tool by name and states no when-not condition (e.g., using it beyond previewing), so routing guidance is clear but not exhaustive.

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 largely covered. The description adds real value by explaining it is a dry-run that evaluates hypothetical attributes and returns a pass/fail, and reassures that nothing is created or sent. It stops short of describing error behavior or what happens with an invalid trigger_id, keeping it out of 5 territory.

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, front-loaded with the dry-run/no-email constraint so the key safety point lands first. Slightly repetitive, since 'WITHOUT sending any email' is restated as 'Does not create or send anything', which trims the score below 5.

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

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

There is no output schema, and the description compensates by stating what is returned ('whether the conditions would pass given the contact attributes'). Combined with annotations that carry the safety profile and a fully documented schema, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so all five parameters (trigger_id, tags, source, status, custom_fields) are already documented in the schema. The description gestures at 'contact attributes you provide' but adds no syntax, format, or defaulting detail beyond that. Baseline 3 is appropriate when 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?

Specific verb+resource ('Dry-run a trigger's send conditions') with an explicit scope statement ('for a hypothetical contact WITHOUT sending any email'). It clearly distinguishes itself from send-oriented siblings like meisa_test_send_broadcast and meisa_send_email by emphasizing no mail is actually sent. An agent can identify this as a safe simulation tool without opening the schema.

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

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

The phrase 'verify targeting before relying on the trigger' gives a clear context for when to reach for it. However, it never names an alternative sibling (e.g. meisa_test_send_broadcast, meisa_activate_trigger) or states when NOT to use this. Clear usage context, but no explicit routing or exclusions.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false. The description adds meaningful non-annotation context: both active and paused enrollments are exited, the contact stops receiving steps, the reason is optional metadata, and a non-enrolled contact produces an error.

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

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

Four tight sentences, front-loaded with the action and scope, then the identifying parameters, the effect, and the error condition. 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?

No output schema exists, and the description covers the notable return behavior (error when not enrolled) plus the state transitions affected. It stops just short of describing any success payload, but for a three-parameter mutation this is close to 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 the schema already documents email, sequence_slug and reason. The description largely restates the schema (slug from meisa_list_sequences, optional reason) without adding format/syntax detail, so the baseline of 3 is appropriate.

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

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

Specific verb (remove/unenroll) plus resource (contact from a sequence) with explicit scope: 'exiting their active or paused enrollment'. This clearly distinguishes it from the sibling meisa_enroll_in_sequence and the various pause/resume sequence tools.

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

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

Explains the identifying keys (email + sequence slug) and the precondition that the contact must currently be enrolled, and states the effect ('stops receiving further steps'). It does not explicitly name pause_sequence or delete_sequence as alternatives, so the boundary with sibling tools 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?

Goes beyond the annotations (which only cover readOnly/idempotent/destructive) by disclosing PATCH-style partial-update semantics and the 409 failure mode on locked broadcasts. These are important operational traits an agent cannot infer from the structured fields alone.

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-loading the DRAFT constraint so the most important precondition is read first. Every clause earns its place 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 mutation tool with no output schema, the description covers the key behavioral facts (draft-only, lock behavior, 409) that the 100%-covered schema and annotations do not. It omits return-value/confirmation details, but no output schema exists to require them.

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

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

Schema description coverage is 100%, so every parameter is already documented (including the detailed enum guidance and empty-string-clears semantics). The description only recaps a subset of the editable fields, adding no syntax or format detail beyond the schema; 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 (Edit) and resource (broadcast's fields) constrained to DRAFT broadcasts, and distinguishes itself from the many other update_* siblings by naming its scope. An agent can tell this apart from create_broadcast, schedule_broadcast, or update_sequence immediately.

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 gives the when ('fix the name, subject override, audience segment, template, or sender before sending') and the when-not (scheduled/sending/sent broadcasts are locked and return 409). It does not name the alternative tool for editing a non-draft, but the prerequisite condition is fully spelled out.

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

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

Annotations already declare the safety profile (idempotent, non-destructive, not read-only). The description earns credit for going beyond them with partial-update semantics and the merge-not-replace behavior for custom fields, which prevents accidental data loss assumptions. It does not cover auth/permission requirements or conflict handling, keeping it short of 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?

Front-loads the operation, then the partial-update rule, then usage guidance and the prerequisite. Every sentence is functional, though the merge detail is stated both here and in the schema, a small 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-parameter mutation with a nested object, full schema coverage, and no output schema, the description supplies the key behavioral facts an agent needs (partial update, merge, UUID prerequisite). The main remaining gap is not distinguishing itself from meisa_upsert_contact.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the custom_fields merge behavior, but that same fact is already stated in the schema's custom_fields description, so it adds little beyond the structured data.

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 (update) and resource (existing contact), and adds semantic detail: only provided fields are changed, omitted fields untouched, custom fields merged. This clearly separates it from a generic write. However, it does not name its closest sibling meisa_upsert_contact, so the agent must infer the update-vs-upsert boundary 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?

Gives explicit when-to-use context ('when the user wants to change a contact's name, status, tags, or custom attributes') and names the prerequisite alternative meisa_search_contacts for obtaining the UUID. It stops short of stating when NOT to use it (e.g., creating a new contact or upserting), which is the natural counterpart sibling.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds genuinely beyond that: PATCH-style semantics (only passed fields change) and settings merge behavior (tweak one key without resending the whole object). It omits permissions/auth and return behavior, so not a full 5.

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

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

Three sentences, zero waste, front-loaded with the core action and scope before the PATCH/merge nuance and the sibling routing. 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 partial-update tool with full schema coverage, no output schema, and annotations covering safety, the description covers the important behavioral nuances (partial update, merge, status routing). It does not describe the returned payload, 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 coverage is 100%, so the baseline is 3. The description goes further by explaining that the update is PATCH-style (only passed fields change) and that settings are merged rather than replaced, which adds meaning beyond the schema's 'Settings to merge in' wording and clarifies the semantics of a nested object parameter.

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

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

States a specific verb (Update) and resource (a sequence's name, description, or settings), and explicitly carves out status changes to the activate/pause siblings. An agent can distinguish this from meisa_update_sequence_step, meisa_update_trigger, and the status-management tools 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 explicit routing: for status changes use meisa_activate_sequence or meisa_pause_sequence, noting they enforce state rules. This tells the agent both when to use this tool and which alternatives cover the adjacent case.

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