MailKite

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

The description adds useful behavioral detail beyond annotations: contacts already on the list are ignored, and the return value is the count of newly added contacts. It also discloses the auth requirement. No contradiction with annotations.

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

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

Two concise sentences that front-load the action, return behavior, and auth requirement. No filler or redundant repetition of schema fields.

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

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

For a two-parameter mutation with annotations and no output schema, the description covers the core essentials: return value, duplicate handling, and auth. The main gap is explicit parameter-to-field mapping, but the tool name and ID pattern make this mostly inferable.

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

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

Schema coverage is only 50% with minimal property descriptions ('Path parameter id' and an untyped string array). The description partially compensates by mentioning 'ctr_' contact IDs, but it does not explicitly map 'id' to the list ID or explain the format/limitations of contactIds.

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?

Description uses a specific verb ('Add'), names the resource ('contacts') and target ('a list'), and clarifies contacts are identified by IDs with a 'ctr_' prefix. This clearly distinguishes the operation from sibling list/remove 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?

The description provides context by noting the management session token requirement and implies the use case of adding contacts to a list. However, it does not explicitly discuss when not to use this tool or mention alternative siblings for removing/listing contacts.

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 indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds that the suppression is permanent ('never sends to it again'), that reason defaults to manual, and that a management session token is required. These are useful behavioral details beyond the annotations, though it doesn't discuss reversibility or duplicate handling, which are partly covered by the idempotentHint.

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

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

A single, well-structured sentence that front-loads the primary action and includes the critical auth requirement. No filler or redundancy; every clause contributes.

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

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

For a simple mutation with three parameters and no output schema, the description covers the purpose, the permanent effect, the default behavior, and the auth need. Nothing essential is missing for an agent to invoke 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 parameters (email, reason, note) already have clear descriptions and examples. The description adds little beyond the schema—only the default reason and the token requirement, which is not a parameter. It meets the baseline but does not elevate.

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

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

The description clearly states the verb 'Suppress' and the resource 'an address', with the effect 'this account never sends to it again'. It distinguishes from siblings like list_suppressions and remove_suppression by the action and outcome.

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

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

The description implies when to use this tool (to add a suppression) but does not explicitly mention alternatives or when not to use it. The sibling tools for listing and removing suppressions make the context clear, but the guidance is implicit rather than 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?

Beyond the annotations, it adds that the tool requires an API key (mk_live_…) and clarifies an important non-effect: it does not match or override routes. It does not describe the reply shape or potential side effects of sending a message to an agent, but the annotations already signal non-read-only and non-destructive 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?

The description is compact and front-loaded: it states the main purpose, then covers default/target/model selection, then the routing exclusion, then authentication. Every sentence earns its place and no filler is present.

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?

The essential behavior, auth requirement, parameter-target interaction, and boundary relative to routing are covered. Since there is no output schema, a brief description of the reply shape or error handling would make it complete, but the description still provides enough for an agent to use 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?

The input schema already thoroughly describes all seven parameters, so the description mostly restates the targeting and model-override semantics rather than adding new meaning. It does not deepen the semantics of from, html, text, subject, address, or routeId beyond what is already in the schema.

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

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

The description opens with an unambiguous verb and resource: 'Send a message to one of your inbox agents and get its reply.' It also explicitly distinguishes the tool from inbound routing, saying it does not match or override routes, which differentiates it from siblings like mailkite_route and mailkite_create_route.

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 clear usage conditions: uses the default agent, or targets a specific agent via routeId or address, and optionally overrides the model. It also states a when-not boundary by clarifying it is separate from inbound routing, but it does not explicitly name a sibling alternative for regular outbound sending when the user does not want an agent.

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

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

Annotations already communicate destructiveHint, idempotentHint, and non-read-only behavior, so the description gets credit for adding the API key requirement and clarifying the scoped, per-run action. However, it does not describe side effects such as whether cancellation is reversible or what happens to related records.

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

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

Three short sentences, each earning its place: the main action and context, the alternative, and the auth requirement. Key information is front-loaded before branching to the alternative.

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 action with strong annotations, the description covers the core usage scenario, the alternative tool, and credential requirement. It is slightly incomplete in that it does not mention the expected result or effect, but this is minor for such a simple call.

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

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

The schema only says 'Path parameter id', but the description clarifies that the id is the enrollment id specifically targeting one run. This adds meaningful semantics over the bare schema for a single-parameter tool.

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

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

Description states a specific verb ('Cancel'), a precise resource ('one specific run by its enrollment id'), and explicitly frames it as the per-row enrollments-table action. It also distinguishes itself from the sequence-level stopSequence alternative, making the purpose unambiguous.

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

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

Explicitly tells the agent when to use this tool: for a single run from the enrollments table. It also names the alternative path for when the run is unknown ('use stopSequence') and contrasts the two conditions clearly.

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

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

The annotation already tells the agent readOnlyHint=true, but the description adds meaningful behavioral context: 'Read-only — no charge' and 'Requires a management session token'. These are material details beyond the structured annotations. It does not disclose the exact return format, but the read‑only nature is well covered.

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

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

Three short sentences, each earning their place: the core purpose is front-loaded, followed by the no-charge caveat and the auth requirement. No fluff or irrelevant detail.

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 could clarify what the response will contain beyond 'availability and price', such as whether the price is present only when available or the format of the status. It also doesn't explain error cases or behavior for domains already registered. Still, for a one-parameter, read-only check, the essential trigger is clear enough.

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

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

The schema description for the single parameter is minimal ('Query parameter `domain`.'), but schema coverage is 100%. The tool description adds no further meaning for the domain parameter — no format, examples, or guidance on accepted values — so the description does not improve on the schema.

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

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

The description clearly states the verb 'check' and the resource 'domain availability', and adds the outcome 'at what price'. However, it does not explicitly differentiate from the sibling mailkite_check_subdomain; a reader must infer that 'domain' is not 'subdomain'.

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 only guidance offered is 'Requires a management session token', which is a prerequisite rather than a usage scenario. It does not say when to use this tool (e.g., before registering a domain) or when to avoid it and prefer an alternative.

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?

Beyond the readOnlyHint annotation, the description adds 'cheap' (cost/performance), 'requires a management session token' (authentication requirement), and that the 'reason' field is safe to show verbatim (output safety). These are valuable behavioral disclosures that the annotations do not cover.

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

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

Two concise sentences that front-load the core purpose, then add usage and behavioral context. No wasted words; every sentence adds value.

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

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

For a simple read-only check with one parameter, the description covers purpose, when to invoke, authentication requirement, and output behavior. Nothing essential is missing for an agent 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 a description 'Query parameter `name`.' which is tautological. The tool description does not clarify that 'name' refers to a subdomain label, though it is implied by the tool name and purpose. The schema does the heavy lifting minimally, and the description adds no extra semantic value, 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 description clearly states the action ('check whether a free subdomain label can be claimed') with a specific resource (subdomain label) and distinguishes it from related tools like claim_subdomain or suggest_subdomain. It is unambiguous and uses a specific verb.

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

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

Provides explicit guidance to call it 'as the user types' and notes that the 'reason' field is safe to display verbatim. It does not explicitly name alternatives or conditions for not using it, but the context implies it is a pre-check before claiming. This is clear but could be strengthened by naming the sibling tool for claiming.

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

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

The annotations already cover readOnly (false), idempotent (false), and destructive (false). The description adds meaningful behavioral context beyond the annotations: the resulting subdomain comes back already verified with an empty `dns` array, so the agent knows no DNS publishing is needed. It also notes the pool changes over time, which impacts repeated claims. A minor gap is not mentioning what happens on duplicate/conflicting label, but the provided detail goes beyond the structural hints.

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

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

The description is a tight three-sentence block: it states the purpose, the behavioral guarantee (already verified), the use-case tradeoff vs createDomain, and the auth requirement. Every sentence adds distinct value and none are filler. It is front-loaded with the most decisive fact ('Claim a free MailKite subdomain') and then scaffolds the necessary decisions around the call.

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, but the description provides a clear expectation of the result: a subdomain that is already verified with an empty dns array. It also covers prerequisites (management session token, the base from suggestSubdomain), and distinguishes the use case from a custom-domain route. It doesn't spell out the exact response shape (e.g., whether it returns the full hostname) but for a single-parameter claim endpoint it is complete enough for an agent 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 a thorough `subdomain` description, but the tool description enriches the meaning: it explains that the base is dynamic and should be fetched from `suggestSubdomain`, and that the label forms a full host on a MailKite-managed zone. This goes beyond the schema's character-format details and tells the agent how to obtain the required base, which is valuable context.

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 opens with a specific verb and resource ('Claim a free MailKite subdomain') and precisely defines the object as a `<label>.<base>` host on a zone MailKite runs. It also distinguishes itself from the sibling `createDomain` by noting the difference between a managed subdomain and a bring-your-own-domain path, so an agent can immediately tell this apart from other domain tools.

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

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

It tells the agent when to use this tool ('when you want onboarding to work without asking anyone to touch DNS') and explicitly says the alternative is `createDomain` for a custom domain. It also points to `suggestSubdomain` for the current `base` and states the requirement for a management session token, leaving no ambiguity about prerequisites or alternatives.

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

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

The annotations only record non-readOnly, non-idempotent, and non-destructive hints, so the description carries the behavioral burden. It explicitly discloses that the password is returned exactly once and never again, plus the authentication prerequisite. This is materially important for how an agent should handle 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?

The description is three short sentences with the action front-loaded, followed by the crucial secret-disclosure warning and the auth requirement. 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?

All parameters are fully described by the schema, and the description covers the non-obvious output caveat: the secret will not be returned again. It does not spell out the exact return envelope or explicitly route to rotate/list/delete siblings, but those are minor for a straightforward creation tool.

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

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

Schema description coverage is 100%, so the parameter objects already fully define label, domain, address, domainId, and protocols. The description only echoes 'domain and address pattern' and adds little beyond the schema, which is the baseline case.

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 identifies the verb ('Create'), the resource ('app password'), and the scope ('for one domain and address pattern'). Its use case, handing it to a mail client or agent, also distinguishes it from the sibling lifecycle tools (list, rotate, delete, update).

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

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

It clearly communicates when this tool is relevant: when a password must be generated for a client or agent, and it flags the management session token requirement. It does not explicitly name alternatives for lost secrets or rotation, so it is not maximally explicit, but the intended 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?

The description claims the tool creates a broadcast draft, which is a write operation. Annotations have readOnlyHint=false, so there is no contradiction. However, the description does not disclose any behavioral traits beyond the action itself, such as whether it validates content, what happens on failure, or side effects. With readOnlyHint=false and no further context, the description adds little to the annotation. However, the bar is lower because readOnlyHint is already false, but the description should still add context; it mentions the return value and the requirement for a token, which is some value. So score 3 would be appropriate, but I need to justify: it does mention 'returns the broadcast with its id' and 'requires a management session token', which are behavioral details beyond the annotation. So score 3.

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 3 sentences, concise and structured logically: purpose, key parameter guidance, return and next step, and auth requirement. It is front-loaded with the main action. No fluff. Score 4 because it could be slightly more compact, but it's efficient.

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 10 parameters, no output schema, and no annotation beyond readOnly, the description is relatively complete: it covers required field, audience format, return value, and auth. However, it does not explain the meaning of other parameters (e.g., replyTo, footerAddress, templateId) or any validation rules. It also doesn't mention the 'filter' audience type that appears in the schema enum. This is a significant gap for a complex tool, so score 3.

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

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

Schema coverage is 0%, so the description must compensate. It clarifies that 'from' is required, and explains the 'audience' parameter with specific formats (type: 'all' or type: 'list' with id). It also mentions 'name', 'subject', 'html', etc. implicitly by listing parameters, but does not explain each. It partially compensates by giving examples for audience, but not for other parameters like templateId or footerAddress. This is a moderate compensation, so score 3.

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

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

The description clearly states that the tool creates a broadcast draft and returns its id. It distinguishes itself from siblings like mailkite_send_broadcast (which sends) and mailkite_update_broadcast (which modifies). However, it does not explicitly contrast with those siblings, but the action is clear.

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

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

It indicates when to use it (to create a draft) and that sending is a separate step (sendBroadcast). It also gives a prerequisite: requires a management session token. It does not explicitly state when not to use it or mention alternatives, but the step-by-step guidance is helpful.

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 supply readOnlyHint=false, idempotentHint=false, and destructiveHint=false, which tell the agent little. The description adds meaningful behavior: the return includes DNS records, provider behavior depends on plan, and a management session token is required. It would be even better if it explained idempotency/duplicate handling, but the description is fairly informative beyond the annotations.

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

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

The description is three sentences and front-loads the primary action and return value. The second sentence packs a lot of plan/parameter information into one sentence, which is somewhat dense but not bloated. Every sentence earns its place, though the mention of email_provider_id creates confusion.

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 low-complexity tool with one parameter and no output schema, the description covers about returns, auth, and plan behavior. However, the missing/extraneous parameter mismatch (email_provider_id in description but not schema) is a serious gap that prevents correct invocation, and it never explains how the parameter should be formatted or what additional setup (DNS verification, existence pitfalls) follows creation.

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

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

Schema coverage is 0%: the only parameter, `domain`, is not described at all. Worse, the description references `email_provider_id` and tells callers they 'may pass' it, but the input schema does not include that parameter, so an agent following the description would send an invalid request. This is misleading and harms correct invocation.

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 uses a clear action verb with a resource — "Add a domain" — and adds that the tool returns domain plus DNS records, which distinguishes it from many sibling tools. However, it does not explicitly differentiate from mailkite_register_domain or verify-related siblings, so it is just short of a 5.

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

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

The description gives useful contextual guidance: it says the tool requires a management session token, and explains how provider selection works on paid vs. free plans with a pointer to listEmailProviders. There is no explicit "when to use this vs register_domain or verify_domain", so the agent is left to infer the boundary between these siblings.

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?

Beyond the annotations, it discloses the return shape ('list with its id (lst_…)') and the auth requirement ('management session token'). It does not discuss duplicates, limits, or errors, but for a simple create operation the added context is meaningful.

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, with no filler. Each clause adds useful information: action, return value, next step, and auth requirement.

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 creation tool with no output schema, this is complete: the return value is specified, the auth requirement is stated, and the natural follow-up action is mentioned. An agent can invoke this tool correctly with minimal guessing.

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

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

There is only one required parameter, name, and its meaning is reasonably inferable from the property name and 'contact list.' However, the description never explicitly explains the name parameter or any constraints, and the schema has 0% description coverage, so this is a minor gap.

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

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

The description clearly states the specific verb ('Create'), the resource ('a contact list'), and the expected return (the list with its id). It also distinguishes itself from the closely related add-contacts operation by explicitly referencing addListContacts.

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

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

The description gives useful procedural context: create the list first, then add contacts via addListContacts. It also notes the auth prerequisite. It does not explicitly state exclusions versus other list-manipulation siblings, but the workflow 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?

The annotations carry essentially no signal (all three hints are false), so the description carries the full burden — and it pays: it discloses five-minute expiry, single-use burn-on-first-use, scope inheritance from the calling credential, and the API-key requirement (mk_live_…). These are exactly the behavioral facts an agent needs and none are visible in the annotations or schema.

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

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

Five sentences, each earning its place: core purpose, browser use case, expiry/burn/scope behavior, the stream-boundary clarification, and authentication requirement. Information is front-loaded with the primary verb and resource in the first sentence, with zero filler or repetition.

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

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

For a 0-parameter tool with no output schema, the description covers purpose, context, behavior, lifecycle, and auth. The sole gap is that the return value (the token string) is only implied by 'this is what a page passes as ?token=' rather than stated explicitly; there is no output schema to compensate.

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

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

The tool takes 0 parameters, so the schema description coverage is trivially complete and there is nothing for the description to annotate. With 0 params, the baseline is 4, and the description provides the relevant operational semantics (token lifetime, scope, auth) anyway.

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 gives a specific verb ('Mint') and a specific resource ('short-lived, single-use token for one Realtime API connection'). This clearly distinguishes the tool from all siblings, which handle webhooks, routes, templates, domains, sequences, and other mail/domain concerns. Even without the title, the purpose is unambiguous.

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

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

The description explains a concrete when-to-use: browsers where EventSource cannot set headers, where the token is passed as `?token=` instead of an API key in a URL. It also delineates the boundary of what the tool does not do ('the stream itself is GET /v1/realtime… contracted in sdks/spec/realtime.json rather than here'). It lacks an explicit mention of alternative tokens like scoped keys or app passwords, 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 indicate this is a non-read-only, non-idempotent operation, and the description adds a useful behavioral/operational detail: a management session token is required. This is beyond what the annotations provide and helps the agent avoid invoking the tool with the wrong authentication context.

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

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

The description is two short sentences with no filler. The core operation is front-loaded, and the auth requirement is stated immediately after. It earns its place even if the parenthetical oversimplifies the optionality of some fields.

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

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

The schema carries most of the parameter semantics, and the description supplies the key auth prerequisite. However, there is no output schema and no mention of what the tool returns or what side effects occur beyond creating a route, and it offers no guidance on how this relates to route siblings. For a six-parameter creation tool with conditional agent fields, this is adequate but not 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%, with detailed per-parameter descriptions including enums, defaults, and conditional requirements. The description's parenthetical '(match, action, destination)' is a helpful shorthand but adds no semantic meaning beyond what the input schema already provides, so the baseline score 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?

The description names a specific verb and resource ('Create a route') and enumerates the core components (match, action, destination). It is clear about what the tool does, though it does not explicitly distinguish itself from sibling tools like mailkite_list_routes, mailkite_delete_route, or mailkite_deliver_to_route.

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 states an operational prerequisite — a management session token — which helps the agent know when the call is authorized. It does not explain when to prefer this tool over route-related siblings, nor does it mention preconditions such as a verified domain or configured webhook destination, so usage is mostly implied by the verb 'create'.

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

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

Annotations already mark this as non-read-only, non-idempotent, and non-destructive. The description adds valuable context beyond those annotations: it requires a management session token and explains the security property that the site never holds the master key. It does not detail response behavior, but the essential create-operation traits are covered.

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 with no filler. The core purpose is front-loaded, followed by a practical use case and an important auth prerequisite. 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 two-parameter creation tool with rich schema descriptions, the description covers the purpose, scope, typical deployment, and authentication requirement. The lack of an output schema means the return value is not explicitly described, but this is not critical for invoking 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%, and the parameter descriptions are already specific, including examples and the requirement that the domain belong to the calling account. The description reinforces the domain-scoping concept but does not add significant parameter-level meaning beyond the schema.

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

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

The description clearly identifies the operation as creating a key limited to one domain, using a specific verb and resource. It also differentiates from account-level credentials by noting the site never holds the master key, making the tool's specific role obvious among many siblings.

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

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

The description gives a concrete use case (per-site installs like a WordPress plugin) and a prerequisite (management session token). It does not explicitly contrast this tool with alternatives such as app passwords or account-wide API keys, so it stops short of a full when-to-use/when-not-to-use 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?

The annotations only provide generic false hints, so the description carries the main behavioral load. It explicitly discloses the draft-by-default behavior, the up-front validation of the entire definition, the need for a mk_live_ API key, and the fact that a sequence enrolls nobody until active. This is meaningful and consistent with the annotations; there is no contradiction.

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

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

The description is front-loaded with the core purpose and then gives short, useful behavioral details about draft status, validation, and API key requirement. The metaphor of a sequence as a function is compact and adds semantic value without bloating the text.

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

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

This is a complex 8-parameter creation tool with no output schema, so the description plus schema still provides enough context to invoke it correctly. The coverage of input semantics, trigger behavior, and default status is strong; task only open concept is the exact output shape, which the description does not describe, but it remains enough 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?

The input schema already documents all 8 parameters, so the baseline is 3. The description adds genuine extra semantics on top by explaining input as re shared function signature that every trigger must satisfy, and by clarifying what a missing/empty triggers set means. This goes beyond the kind of line-level field descriptions already present in the schema.

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

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

The opening sentence says "Create a sequence" and immediately names the resource's core parts: a declared input shape, the steps a contact walks over time, and triggers. This makes both the verb and the resource unambiguous, and it is easy to tell this tool from list_sequence/get_sequence/update_sequence/delete_sequence peers.

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

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

The description gives useful operational context: a sequence starts as a draft unless status active, and a sequence with no triggers can still be used through a send or explicit enroll. However, it does not explicitly say when to choose this tool over alternatives like update_sequence, start_sequence, or stop_sequence, so the tool-selection guidance is implicit rather than direct.

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?

With no meaningful annotations beyond readOnlyHint=false, the description carries the burden of behavioral disclosure. It usefully discloses the management session token requirement and the two mutation modes, but it does not mention side effects, ownership semantics of cloned templates, or what the call returns. That is adequate but not fully transparent.

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 core action, then mode alternatives, then the auth requirement. Every sentence 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 7-parameter tool with zero required parameters and complete schema documentation, the description covers the critical decision (baseId vs fields) and the auth precondition. It does not describe return values, but that is a minor gap given 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?

Schema description coverage is 100%, so the baseline is 3. The description lists the relevant fields by mode but adds no semantics beyond the schema, such as validation rules, format expectations, or relationships between parameters.

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

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

The description names the specific operation—creating a template—and clearly distinguishes the two intended paths: cloning via baseId or supplying content fields directly. This makes it easy for an agent to tell it apart from sibling list/get template 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?

The description gives clear situational guidance: use baseId to clone a base template, or provide name/subject/html/text/theme directly. It also notes the management session token requirement. It stops short of explicitly naming alternatives such as mailkite_list_base_templates or stating when not to use this tool, but the mode-based guidance is strong.

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

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

The annotations only state readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: attaching never bumps the sequence version and never touches contacts already in flight, and it requires an API key. It does not describe response/error behavior, but it meaningfully supplements the sparse annotations.

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

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

The action is front-loaded and the sentences are mostly purposeful. The 'fact about the outside world' metaphor is slightly decorative but helps justify why version bumps are irrelevant. There is no redundant restatement of the tool name 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?

The tool has four parameters, including a rule-based filter, and no output schema. The description covers the core purpose and prerequisite but does not explain `filter`, `enabled`, or the expected response shape. It is adequate for a basic call but leaves gaps an agent would need to resolve.

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

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

Schema coverage is only 50%, so the description needed to compensate for undocumented parameters. It explains `event` and indirectly `id`, but `filter` is entirely unexplained and `enabled` is only noted in the schema. For a tool with a rule reference, this leaves a significant semantic gap.

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

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

The description opens with a specific verb and resource: 'Attach a trigger', and clarifies the exact behavior: 'when this event arrives, enroll the contact it is about.' It also distinguishes triggers from sequences, helping an agent tell this apart from sibling sequence and trigger tools.

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

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

It gives a concrete prerequisite: the sequence needs a `from` address before event-triggered enrollment, because there is no message to inherit a sender. It does not explicitly name alternatives or exclusion conditions, but the conceptual contrast with sequences and the prerequisite provide clear context for when to use it.

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

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

The annotations already state destructiveHint=true and readOnlyHint=false, which signal mutation. The description adds critical behavioral details: it explicitly says the effect is immediate ('Takes effect immediately') and describes the consequence ('any IMAP session or API call using it stops authenticating'). It also discloses the authentication requirement ('Requires a management session token'). This goes beyond the annotations and helps the agent anticipate side effects.

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

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

The description is three short sentences, each with a distinct purpose: the action, the immediacy and impact, and the prerequisite. It is front-loaded with the verb and resource, and every sentence adds value without redundancy. This is an model of conciseness.

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

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

Given the simple tool (one parameter, no output schema, no nested objects), the description is complete enough: it states the action, the effect, and the required token. It could mention what the response is (e.g., success/failure), but that is typically expected for a delete operation, and the user asked for broad context. The annotation `idempotentHint=true` also implies repeated calls are safe, which the description does not need to repeat.

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

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

The schema describes the only parameter `id` with coverage 100%, but the schema's description is minimal ('Path parameter `id`.'). The tool description does not add any detail about what `id` refers to (e.g., the app password ID). However, because the schema fully documents the parameter's existence and the tool purpose is clear, the description does not need to compensate heavily. 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 clearly states the action ('Revoke an app password') and the resource ('app password'), which is precise and immediately differentiates it from siblings like `mailkite_update_app_password` (which modifies, not revokes) and `mailkite_rotate_app_password` (which replaces). The verb 'Revoke' is specific and unambiguous.

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

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

The description implies when to use it (when you need to invalidate an app password) but does not explicitly state when NOT to use it or mention alternatives like rotation. However, the sibling list includes `mailkite_rotate_app_password`, which is the obvious alternative for when you need to replace rather than just revoke. The requirement for a management session token is mentioned, which is a clear gate for use.

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

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

With annotations already declaring readOnlyHint=false, idempotentHint=true, and destructiveHint=true, the description's burden is reduced. It adds two useful behavioral details beyond the annotations: the auth requirement (management session token) and the 'draft' restriction, implying only drafts are deletable. No contradiction with the annotations.

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

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

A single, direct sentence with no filler. The core action is front-loaded, and the auth prerequisite is appended without bloating the description. Every word 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 one-parameter delete operation with rich annotations covering safety semantics, the description adequately covers what the tool does and a key prerequisite. Omissions like return behavior or edge cases (e.g., deleting a sent broadcast) are minor given the simple shape, but there is still slight room for more explicit guidance.

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

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

Schema description coverage is 100% because 'id' has a description, but that description ('Path parameter `id`.') is tautological and uninformative. The tool description hints that 'id' refers to a broadcast draft, which adds some context, but it never explicitly maps the parameter to the resource. This aligns with the baseline 3 for high schema coverage.

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

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

The description opens with a specific verb and resource: 'Delete a broadcast draft.' The qualifier 'draft' narrows the scope, and the resource is distinct from the many other delete tools in the sibling list (delete_sequence, delete_domain, etc.). An agent can tell exactly what this tool operates on without 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 implies the tool should be used when a broadcast draft needs to be deleted and even states a prerequisite ('Requires a management session token'). However, it offers no explicit when/not-to-use guidance, no exclusions, and does not differentiate itself from sibling deletion tools beyond the resource name in the tool name.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true, and the description adds the auth requirement ('Requires a management session token'), which is valuable context. It does not contradict annotations and provides a meaningful behavioral detail beyond what the annotations state. However, it does not describe side effects like cascading removal of associated resources, but that is not strictly necessary given the destructive hint.

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 two short sentences with zero wasted words. It front-loads the primary action ('Remove a domain') and immediately follows with the key prerequisite. It is concise and well-structured for quick parsing by an agent.

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 delete operation with a single required parameter and no output schema, the description provides sufficient context: what the tool does and a key requirement. The destructive nature is covered by annotations, and the id parameter is sufficiently clarified. It could mention the permanence of the action, but the destructiveHint annotation already conveys that, so the description is complete enough for this tool's complexity.

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

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

The schema has one parameter 'id' with description 'Path parameter id.' The tool description adds the context that the id refers to the domain to be removed, which is a slight enhancement. Since schema coverage is 100% and the description adds only marginal meaning (domain id), a baseline score 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?

The description states a clear verb ('Remove') and resource ('domain'), making the tool's purpose obvious. It does not explicitly differentiate from other delete tools in the sibling list, but the resource type (domain) is distinct enough that an agent would not confuse it with deleting webhooks or sequences. The purpose is specific and unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions a requirement (management session token) but does not explain when deletion is appropriate, what prerequisites exist (e.g., domain must be verified), or when to use other domain-related tools like verify_domain or list_domains. The agent is left to infer context.

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

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

The annotations already communicate that the tool is destructive but not read-only. The description adds useful context beyond the annotations: the list is removed while contacts are preserved, and a management session token is required. It is transparent about scope and authentication requirements, though it does not disclose response 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?

The description is three short sentences, with the core action front-loaded. Every sentence contributes either the operation, the crucial non-destructive side effect (contacts preserved), or the authentication requirement. There is no filler or repetition.

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

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

For a tool with one parameter, clear destructive intent from annotations, and no nested structures, the description covers the action, scope, and auth requirement. It does not describe the success or error return shape, and no output schema exists, but this is a minor gap for a simple delete-list operation.

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

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

The single required parameter 'id' is covered by the schema, so the schema already supplies all parameter information. The description implicitly indicates that the id refers to the contact list, but it adds no deeper detail about the id's format, source, or lifecycle. Baseline 3 is appropriate for full schema coverage.

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

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

The description states a specific verb ('Delete') and resource ('contact list'), and adds a key distinguishing detail: the contacts themselves are kept. This clearly distinguishes it from sibling tools like mailkite_remove_list_contact, which operates on an individual contact rather than a whole 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?

No guidance is given about when to use this tool rather than alternatives, nor are exclusions or prerequisites stated beyond a management session token requirement. There is no mention of scenarios where deleting a list would be inappropriate or where mailkite_remove_list_contact or mailkite_delete_broadcast would be a better option.

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 description doesn't need to restate those. It adds value by noting the requirement for a management session token, which is a behavioral prerequisite not visible in the schema or annotations. It also frames the destructive action as a cleanup step, which is useful context. It doesn't contradict annotations.

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

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

The description is two sentences with no wasted words. The core action is front-loaded, followed by a practical pairing example and a security prerequisite. 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 single-parameter delete tool with annotations covering destructive/idempotent behavior, the description is nearly complete. It covers the action, the resource, the pairing context, and the auth requirement. The only minor gap is that it doesn't describe the return value or error behavior, but with no output schema and a simple delete operation, this is acceptable.

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

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

Schema description coverage is 100% (the 'id' parameter is described as 'Path parameter `id`.'), so the schema already documents the parameter. The description adds no additional meaning about the id beyond what the schema provides, but it does clarify the resource type ('inbound routing rule') which indirectly helps. Baseline 3 is appropriate given full schema coverage.

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

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

The description clearly states the action ('Delete an inbound routing rule by id'), identifies the resource ('inbound routing rule'), and distinguishes it from sibling tools like mailkite_delete_webhook and mailkite_delete_tracking_webhook by specifying 'routing rule'. It also names the paired creation tool (createRoute), which further disambiguates it.

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 explicitly explains when to use this tool: pair with createRoute to register and tear down a webhook destination, e.g., an automation platform subscribing on enable and cleaning up on disable. This provides clear context and an example use case, effectively guiding an agent on when to invoke it.

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

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

Annotations already cover destructiveness and idempotency. The description adds useful behavioral context: revocation takes effect immediately and requires a management session token, which goes beyond what the annotations alone state. There is no contradiction with the annotation values.

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 short sentences with zero filler. It front-loads the core action and then adds immediate-effect and authentication details, which is highly efficient for an AI agent.

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 single-parameter destructive operation, the description is reasonably complete. It states the effect, timing, and auth requirement. A slightly fuller note about what happens after revocation (e.g., dependent credentials stop working) could be added, but the annotation and immediate-effect statement make the behavior clear.

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

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

There is only one parameter and schema description coverage is 100%, so the baseline is 3. The description does not add explicit detail about the `id` parameter, but the resource is clear from the tool name and the phrase 'domain-scoped key'.

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 uses a specific verb ('Revoke') and resource ('domain-scoped key'), which clearly distinguishes this from sibling deletion tools such as delete_app_password, delete_sequence, and delete_domain. The purpose is instantly clear and not tautological.

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

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

The description implies the use case: revoke a domain-scoped key when it is no longer needed. It adds a prerequisite ('Requires a management session token'), but it does not explicitly contrast with related actions such as rotating a key or deleting an app password, so the selection guidance is only implied.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description doesn't need to restate those. It adds valuable context beyond annotations: the cascade effect on contacts ('retire every contact still walking it') and the response behavior ('reports how many were canceled'). It also discloses the API key requirement (mk_live_…). This is meaningful behavioral disclosure beyond the structured fields.

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

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

Two sentences, zero filler. The most important behavioral fact (cascade deletion) is front-loaded, followed by response info and auth requirement. 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 single-parameter destructive tool with annotations covering idempotency and destructiveness, the description is nearly complete. It covers the cascade effect, response content, and auth requirement. It doesn't describe error cases or whether deletion is reversible, but those are minor given the annotations and simple parameter set.

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

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

Schema description coverage is 100% and the only parameter is 'id' with description 'Path parameter id.' The description doesn't add parameter-level detail, but with a single self-explanatory parameter and full schema coverage, the baseline 3 is appropriate. The description's mention of 'a sequence' implicitly maps to the id parameter.

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

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

The description states a specific verb ('Delete'), a specific resource ('a sequence'), and a distinctive behavioral consequence ('retire every contact still walking it'). It clearly distinguishes this from sibling tools like mailkite_stop_sequence or mailkite_cancel_enrollment by describing the cascade effect.

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

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

The description implies when to use it: when you want to delete a sequence and retire its active contacts. It does not explicitly name alternatives or exclusions, but the cascade behavior ('retire every contact still walking it') gives clear context that this is the full-deletion tool rather than a stop or pause. A small gap: it doesn't explicitly say 'use stop_sequence if you only want to pause'.

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

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

Annotations already mark the tool as destructive and idempotent, and the description adds meaningful context beyond that: engagement events will stop after removal and a management session token is required. This gives the agent a concrete expectation of effects and prerequisites.

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

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

Two short sentences, no redundant phrasing, and the core action and consequence are front-loaded. The auth requirement is appended without unnecessary elaboration.

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

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

For a single-parameter destructive tool with rich annotations, the description provides sufficient information: what is removed, the consequence, and the required credential. No output schema exists, but the description does not need to explain return values for a simple delete operation.

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

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

Schema description coverage is 100%, with the 'id' parameter already explained as a path parameter. The description does not add additional parameter-level meaning, such as whether the id refers to the webhook or the domain, but it is not necessary given the schema and the tool's clear subject.

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

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

The description uses a specific verb and resource: 'Remove the domain's tracking-event webhook', with a clear behavioral consequence ('engagement events stop'). This clearly distinguishes it from sibling tools like mailkite_delete_webhook or mailkite_delete_webhook_events by specifying the tracking-event webhook.

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 makes the context clear: this tool removes the tracking-event webhook, and the statement about engagement events stopping implies the impact. It does not explicitly name alternatives or when-not-to-use conditions, but the targeted resource is clear enough among the webhook-related siblings.

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, so the description doesn't need to restate that. It adds useful context: 'stops future enrollments through that door and nothing else' – clarifying the scope of destruction (only future enrollments, not existing ones). It also mentions the API key requirement (mk_live_…) which is a behavioral prerequisite. However, it doesn't detail idempotency, though annotations already indicate idempotentHint=true. The description adds value but doesn't add much beyond annotations, so a 3 is appropriate.

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 two sentences with zero waste. The first sentence states the action, the second provides the key differentiation and the auth requirement. It's front-loaded with the core purpose and ends with a necessary practical detail. Perfectly sized for the tool's simplicity.

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 single-parameter deletion tool with annotations covering destructive and idempotent hints, and no output schema, the description is mostly complete. It explains the effect on future enrollments, which is the main behavioral nuance, and the auth requirement. It doesn't mention what happens to existing enrollments or whether it's reversible, but annotations and the simple nature of the operation make it less critical. A slight gap is the absence of the return value, but with no output schema, it's acceptable. Overall, it provides enough for an agent 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% for the only parameter 'id', but the description is minimal ('Path parameter id'). The tool description does not add any additional meaning to the parameter, as it doesn't explain what the id represents (trigger ID). However, given that the tool name is 'delete_trigger', it's reasonable to assume id is the trigger ID. Since coverage is high, baseline is 3, but the description's mention of 'trigger' and 'door' gives contextual clue about the parameter's purpose. The description adds a bit more than just the schema, so a 4 is warranted.

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 clear verb ('detach') and resource ('trigger'), and clarifies the effect ('stops future enrollments through that door and nothing else'). It distinguishes itself from delete_trigger by using 'detach' and emphasizing it's non-destructive to other parts, though it doesn't explicitly name sibling tools. The purpose is clear and specific.

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

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

The description implies when to use this tool: when you want to stop future enrollments without affecting existing enrollments or other settings. It provides a clear context ('through that door') and indicates it does nothing else. However, it doesn't explicitly contrast with related tools like mailkite_delete_trigger (if exists) or mailkite_cancel_enrollment, leaving some inference to the agent. Since the sibling list includes mailkite_stop_sequence and mailkite_delete_sequence, a more explicit differentiation would help, but the description gives enough guidance for most cases.

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 destructive and idempotent, so the description does not need to repeat that. It does add the auth requirement of a management session token, which is useful context, so the agent knows the caller must be authenticated. However, it does not describe any side effects beyond deletion, like whether the webhook will stop receiving events.

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

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

The description is only two sentences with no filler. The primary purpose is front-loaded in the first sentence, and the auth requirement is a concise but necessary addition in the second. Every word 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?

The tool is simple and the annotations take care of the safety profile. The description is acceptable for one-parameter delete action, but it does not eliminate the ambiguity about which webhook type is being targeted or what the `id` represents. That leaves room for a slight but manageable misinterpretation.

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

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

The schema covers the single `id` parameter at 100%, so the information is present, but the schema text only says 'Path parameter `id`.' The description does not clarify whether `id` is a domain ID or a webhook ID, leaving room for misinterpretation. Baseline is accepted because the schema owns it, but the description adds no value.

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 a resource: 'Remove the domain's webhook.' This is clear enough, but the text does not explicitly distinguish this from the sibling mailkite_delete_tracking_webhook, so an agent may not know whether this deletes the main webhook or a tracking-specific one.

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

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

There is no guidance about when to choose this tool over alternatives such as delete_tracking_webhook, set_webhook, or verify_webhook. The mention of the management session token tells the agent a prerequisite, but not which the webhook type this applies to or when this tool should be preferred.

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

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

Annotations already signal destructive and idempotent behavior; the description adds the meaningful detail that only the inbound email.received engagement event is affected and that a management session token is required. No contradictions with the annotations.

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

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

Two short sentences, mostly front-loaded and efficient. Minor awkwardness in 'opt the domain's inbound webhook back out of' but no 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?

The description covers auth requirement, event scope, and default behavior, and annotations cover idempotency/destructiveness. Missing: what the id identifiesay, whether any other engagement events are affected, and what response/state results.

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

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

Schema coverage is 100% but the description only says the parameter is the path id. It does not explain what entity id refers to (domain, webhook, or event subscription), which an agent would need for a confident call.

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

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

The description states the operation ('opt ... back out of engagement events'), the target (the domain's inbound webhook), and the scope (inbound email.received only — the default). It is understandable, though 'opt the domain's inbound webhook back out of engagement events' is roundabout and never explicitly says 'delete the webhook event subscription'.

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

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

There is no guidance about when to choose this over related webhook tools (set_webhook_events, delete_webhook, delete_tracking_webhook). The only implicit context is that it affects the default inbound email.received event; no conditions, preconditions, or alternatives are given.

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

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

Annotations only say readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds critical behavioral context: this operation requires a management session token, enforces a 50-id limit, returns a per-id `results` contract like retryDeliveries, and rejects non-webhook route types. These are exactly the behavioral traits an agent needs beyond the schema.

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

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

Though denser than a one-liner, every sentence earns its place: core action, key edge-case, discovery pointer, exclusion criteria, limits, contract reference, and auth requirement. The most important distinction is front-loaded, and no filler or repetition of schema details exists.

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 operation with no output schema, the description provides everything needed to invoke correctly: id and messageIds meanings are in the schema, while behavior, limits, auth, error cases, and result contract are explained. The reference to retryDeliveries' per-id results contract fills the return-format gap effectively.

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 slightly reinforces the meaning of messageIds by saying 'stored messages (msg_…) to deliver to this route's webhook' and 'at most 50 ids per request,' but the schema already documents both parameters well. It does not substantially extend the schema-provided 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 opens with a specific verb and resource: 'POST stored messages to one webhook route.' It immediately distinguishes this from retry-based delivery by explaining that messages arriving before the route existed cannot be reached by a retry, and it contrasts with forward/agent alternatives. The purpose is unmistakable.

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

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

The description explicitly tells the agent when this tool is needed: for pre-route messages that retries cannot replay. It names the discovery alternative, 'Use listRouteCandidates,' and gives hard exclusion criteria: forward and agent actions return 400 `route_action`. This is strong 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?

Given annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description adds valuable behavioral context beyond those hints. It discloses that the authorization code is single-use and expires quickly, with a replay returning invalid_grant. It also notes that the refresh token is single-use and is revoked upon rotation. These details help the agent understand the side effects and constraints of the operation. While it doesn't explicitly state that the operation mutates state (like revoking tokens), the description of token rotation and revocation implies it. No contradiction with annotations.

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

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

The description is concise and front-loaded: it starts with the core action and positions it as step 3. It then provides necessary context about the OAuth flow in a few sentences. There is no fluff, and each sentence contributes value. It could be slightly more structured by separating the two grant types, but it's still efficient.

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 complexity of an OAuth exchange with two grant types and six parameters, the description is fairly complete. It explains the overall flow, the need for a management session token, and points to the next step (getApiKey). However, it does not describe the response format (e.g., that it returns tokens), but since there is no output schema, the description could have mentioned what the tool returns. Still, the pointer to getApiKey implies the returned access token is used there. Minor gap, but solid overall.

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 each parameter thoroughly. The description adds a bit of context by describing the overall flow but does not provide additional parameter semantics beyond what's in the schema. For example, the schema already describes code_verifier as required and the grant_type enum. The description reinforces the sequence but adds minimal new information about parameters themselves. 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 clearly states the tool's purpose: exchanging an authorization code for an access token or rotating a refresh token, and positions it as step 3 of an OAuth linking flow. It mentions specific actions (exchange) and resources (authorization code, access token, refresh token), which distinguishes it from other OAuth-related tools like register_oauth_client and get_api_key.

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 a clear sequence: it explains the steps before (sending user to /oauth/authorize with specific parameters) and after (calling getApiKey with the access token and storing the key). It implicitly indicates when to use this tool (after obtaining the authorization code, before obtaining the API key) but does not explicitly mention alternatives or exclusions, which would justify a 5. However, it does mention the requirement of a management session token, which is useful context.

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?

Description says 'Read-or-create: the first call mints it,' implying a state-changing side effect, which directly contradicts the readOnlyHint=true annotation.

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?

Concise and grammatically sound, with the key detail upfront. The Windows-style ellipsis is slightly informal but does not harm clarity.

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?

Self-contained given the zero-parameter schema: it names the resource, the format, the precondition, and the read-or-create behavior. Only the contradiction with the readOnly annotation prevents a perfect score.

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 has zero parametersched, so the schema cannot clarify anything. The description adds contextual meaning about the key and behavior, but there are no parameter semantics to clarify.

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?

Clearly states the tool retrieves the account's unrestricted API key (mk_live_…), which distinguishes it from sibling tools like rotate_api_key or scoped-key creation.

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 context: obtain the unrestricted key with a management session tokencing. It implies when to use it versus scoped or rotated keys, though it does not name alternatives explicitly.

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 indicate readOnlyHint=true, and the description complements this with the additional requirement of a management session token and a preview of the response contents. It does not cover errors or response format details, but for a simple read operation this is a reasonable level of disclosure.

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

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

The description is two short sentences with no wasted words. It front-loads the action and result, then adds the auth requirement, making it highly scannable for an agent.

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 tool, the description covers the key aspects: what is fetched, what the response highlights, and the required token. Since there is no output schema, a bit more detail about the returned recipient summary fields could help, but nothing critical is missing for invoking the 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?

The only parameter, id, already has 100% schema coverage, so the description is not obligated to document it heavily. It adds the context that the id refers to a broadcast, but provides no extra format, source, or validation detail beyond what the tool name and schema already imply.

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

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

The description clearly states the action ('Get'), the resource ('one broadcast'), and the distinguishing output ('status and recipient summary'). It is unambiguous and easily differentiated from broadcast-list, create, update, delete, and send siblings.

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

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

The singular 'one broadcast' implies this tool is for individual retrieval rather than listing all broadcasts, and the token requirement sets an operational prerequisite. It does not explicitly name alternatives like list_broadcasts or state when not to use it, but the context is clear enough.

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

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

The annotations already include readOnlyHint=true, so the read-only nature is covered. The description adds the requirement of a management session token and states that the tool returns DNS records and webhook, which are useful behavioral details not present in the annotation. However, it does not discuss error cases, rate limits, or other side-effect-free behaviors beyond what is implied by the annotation.

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

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

The description is a single sentence that front-loads the core purpose ('Get one domain with DNS records + webhook') and then adds the essential token requirement. Every word is informative, with no redundancy or filler. It is appropriately concise for a simple get operation.

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

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

For a simple single-id get operation with no output schema, the description covers the essential information: what it does and what it returns. It also mentions the token requirement which is a key context for invocation. It does not mention error handling or edge cases, but these are not critical for a basic read operation when annotations already indicate safety. Overall, it is sufficiently complete for an agent 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?

The schema provides 100% coverage for the single parameter 'id' with description 'Path parameter `id`.' This is minimal and essentially just names it as a path parameter. The tool description does not add any further meaning or context about the id (e.g., format, where to find it, or its role). Since schema coverage is high, the baseline is 3, and the description adds no extra semantic value.

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

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

The description clearly specifies the action 'Get' and the resource 'one domain', and explicitly states what is returned: 'DNS records + webhook'. This differentiates it from sibling tools like mailkite_list_domains (plural) and other domain operations, making the purpose unambiguous.

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

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

The description does not provide any guidance on when to use this tool versus alternatives such as mailkite_list_domains or mailkite_get_sequence. It only notes a prerequisite (management session token), but no explicit when-to-use/when-not-to-use conditions or mention of sibling tools that might be preferred in certain situations.

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

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

The annotation readOnlyHint=true already signals a read-only operation, so the description appropriately adds the API key requirement and the specific fields returned. This is useful additional context beyond annotations, but it doesn't disclose potential errors or rate limits.

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

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

Two succinct sentences, with the main verb and resource first, and the auth requirement appended. No 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?

The tool is simple with one parameter and no output schema, and the description conveys what it returns and the auth requirement. It is complete enough for an agent to call correctly, though it doesn't cover error cases like not found.

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 parameter, so the schema already explains id as a path parameter. The description does not add extra meaning about id format or constraints, so it meets the baseline of 3.

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

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

The description clearly states the action and resource: retrieving a single enrollment, and specifies what information is returned (sequence, step, and next actions). This distinguishes it from list_enrollments which returns multiple, and from cancel_enrollment which modifies.

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

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

It implies use when you need details of one specific enrollment identified by id, but does not explicitly name alternatives or exclusion conditions. The context is clear enough given the sibling names, but it could have stated 'use list_enrollments to get all enrollments'.

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

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

The annotations already include readOnlyHint=true, and the description adds the meaningful behavioral context that a management session token is required. It also states the return includes the member count. No contradiction exists; the added auth and return context go beyond the annotation.

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

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

The description is a single, focused sentence with no filler. It front-loads the core action and scopes the result, then gives the prerequisite. Every word adds value.

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

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

For a tool with one simple parameter, a read-only annotation, and no output schema, the description covers the core elements: what it retrieves, the distinguishing output (member count), and the required token. Nothing essential is missing for an agent to correctly invoke this simple GET-style 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?

The schema already describes the only parameter `id` as a path parameter, with 100% schema description coverage. The description does not add any semantic detail about the id itself, only that it refers to a contact list. The baseline of 3 is appropriate because the schema handles the parameter documentation.

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 ('Get'), a specific resource ('one contact list'), and a distinctive output ('member count'). It is clearly differentiated from sibling tools like mailkite_list_lists by the singular 'one' and by not being a list-all operation.

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

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

The description clearly conveys that this tool is for retrieving a single contact list, which implies it should be chosen when a specific list is needed rather than when listing or mutating lists. It also names a prerequisite (management session token). However, it does not explicitly name alternatives or give when-not-to-use 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 mark readOnlyHint=truecars, and the description adds the output format ('raw RFC822 bytes') plus an auth prerequisite ('management session token'), which is beyond the annotation. No contradiction with readOnlyHint.

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 purpose. Minor deduction for the vague reference 'as the list,' which requires the agent to infer which sibling tool is meant.

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

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

For a read-only single-message fetch, the description covers the output format (raw RFC822 bytes) and the critical auth prerequisite (management session token). It does not explain the address parameter's role beyond the schema, but the operation is simple enough that nothing critical 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% but the schema descriptions are tautological ('Path parameter uid'). The description adds mild context by clarifying the message and mailbox, but does not explain uid semantics or address format beyond that. 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 begins with a specific verb and resource: 'Fetch one message's raw RFC822 bytes from a mailbox.' This clearly identifies the tool's exact function and distinguishes it from siblings like mailkite_get_message by emphasizing raw bytes.

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 notes 'Same app password auth as the list' and 'Requires a management session token,' giving some operational context. However, it does not explicitly state when to prefer this tool over alternatives (e.g., get_message for parsed output), leaving the selection logic 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 provide readOnlyHint=true, and the description adds a meaningful operational detail by requiring a management session token. It does not contradict annotations, but it also does not go substantially beyond them by discussing auth specifics, rate limits, or any edge-case behavior. This feels like a fair score given the annotation coverage.

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

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

The description is a single concise sentence that front-loads the core action and the resource content, and then follows with the necessary authentication requirement. There is no filler or redundancy.

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

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

For a simple single-parameter 'get message' tool, the description covers the returned contents (deliveries + attachments) and the authentication prerequisite. It does not overelaborate or leave major gaps, though it could theoretically specify response shape or error behavior, but these are not necessary for this minimal tool context.

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

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

Schema description coverage is 100%, so the parameter 'id' is already fully documented by the schema. The description does not add any interpretation of the parameter beyond what the schema says, 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?

The description states the verb 'Get' and the resource 'a message' with explicit subtopics 'deliveries + attachments', which is clear and specific. It does not explicitly name a sibling tool for differentiation, but the mention of deliveries and attachments helps distinguish it from similar listing or raw-message 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?

The description tells the agent that a 'management session token' is required and implies use when a message ID is known and full delivery/attachment info is wanted. However, it does not explicitly state when to prefer this tool over alternatives like list_messages or get_mailbox_message_raw, nor does it provide any exclusion 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 signal readOnlyHint=true, so the description's main contribution is noting the API key requirement and that the enrollment counts are 'live'. These details go beyond the structured annotations and help set expectations for auth and data 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?

The description is brief and functional, using two short sentences with no wasted words. The primary action is front-loaded and the API key requirement adds useful context, though a slightly tighter structure would be possible.

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

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

For a simple one-parameter read operation with robust annotations and full schema coverage, the description provides enough context: what is returned, which resource, and a auth requirement. The lack of an output schema is offset by the explicit mention of the returned data ('definition and live enrollment counts').

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

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

Schema description coverage is 100% and the only parameter 'id' is already documented as a path parameter. The description does not add explicit meaning about what the id refers to, though 'Get one sequence' strongly implies it represents a sequence identifier. This is adequate for a single well-documented 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 clear verb and resource, 'Get one sequence', and specifies what's returned: the definition and live enrollment counts. This distinguishes it from list_sequences, but it does not explicitly name sibling alternatives.

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

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

The description implies it is for fetching one specific sequence, but it does not explicitly state when to use this tool over list_sequences or get_enrollment, nor does it mention when not to use it. The guidance is inferred from 'one sequence' 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?

The annotation already exposes readOnlyHint=true, and the description adds meaningful behavior beyond that: it returns the complete template payload (subject, html, text, theme), covers both ownership scopes (tpl_ and base_), and mentions the authentication token requirement. This is valuable context that the agent needs before calling the tool and that is not present in the schema or annotations.

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

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

The description is two sentences that front-load the core purpose and output fields, then state the scope and the authentication requirement. There is no filler, tautology, or redundant repetition of the schema or annotations. 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 single-parameter read-only tool with no output schema, the description delivers everything an agent needs to call it correctly: the return fields are explicitly listed, the identifier conventions for both user and base templates are given, and the authentication prerequisite is stated. Nothing essential 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?

The schema provides full coverage for the single `id` param but merely labels it 'Path parameter `id`'. The description adds real meaning by explaining that `id` can be either a user template id (tpl_…) or a base template id (base_…), which is actionable for constructing a valid request. This exceeds the baseline of 3 for fully covered schemas.

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 uses a specific verb-resource pair ('Get one template') and explicitly enumerates the returned fields (subject, html, text, theme), which distinguishes it clearly from list-like siblings such as mailkite_list_templates or mailkite_list_base_templates. It also clarifies that it accepts both user templates (tpl_…) and base templates (base_…), leaving no ambiguity about which resource is handled.

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

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

The description implies when to use it—when you need the full content of a single template—and it states a prerequisite ('Requires a management session token'). However, it does not explicitly contrast with alternative tools (e.g., 'use list_templates when you only need summaries') or state exclusions. The usage context is clear but no direct routing guidance is given.

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

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

The readOnlyHint annotation already signals no side effects, and the description adds value by disclosing the authentication requirement ('management session token') and the behavioral consequence of overage state gating sending. This goes beyond the structured annotation.

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 deliver all essential information: what is measured, how it is used, and what access is required. No fluff, front-loaded with the core 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?

For a parameterless, read-only query, the description is complete: it defines the output fields, the use case, and the authentication requirement. It could optionally specify response formatting, but that is not essential 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?

The tool takes zero parameters narrativeschema covers everything; there is nothing for the description to clarify. The description appropriately focuses on the return semantics instead.

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

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

The description clearly states the tool returns billing-period usage metrics: emails used versus the included bucket, AI actions, and the overage state that gates sending. It names the specific resource and differentiates this read-only monitoring tool from the many send/management 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?

It provides a clear use case—powering quota meters in dashboards and integrations—and an implicit context of checking sending capacity via the overage state. It doesn't explicitly exclude alternatives, but no direct sibling competes with this function.

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

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

The readOnlyHint annotation already covers safety, and the description adds value beyond it by explaining what an app password is (accesses mail over IMAP and the mailbox API) and its scope (domain and address pattern). No behavioral surprises disclosed or needed for such a simple read-only listing.

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

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

Two compact sentences, front-loaded with the action, and all additional context earns its place: what an app password is, its scope, and the auth requirement.

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

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

For a zero-parameter read-only list tool, the description is complete: it identifies what is listed, what the items mean, their scope, and the token requirement. Minor gap is no mention of output shape or pagination, but the absence of params and presence of readOnlyHint make this a small concern.

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

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

The tool takes zero parameters, so there is nothing to document; the baseline of 4 applies. The description adds resource context (which app passwords are listed) beyond the schema.

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

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

The description states a specific verb ('List'), a clear resource ('the account's app passwords'), and explains what these passwords are for ('opens a mailbox over IMAP and/or the mailbox API, scoped to a domain and an address pattern'). This goes beyond the bare name and distinguishes it from other list_* 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?

Provides clear context that this operates on the account's app passwords and explains what app passwords doable. The auth prerequisite ('Requires a management session token') is a useful usage condition. It does not name alternatives explicitly, but as a standalone list operation 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 include readOnlyHint=true, so the description doesn't need to restate that. It adds that it returns light metadata (implying not full template) and requires a management session token, which is useful. However, it doesn't specify pagination or output structure beyond light metadata.

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 concise, two sentences, with no fluff. It front-loads the purpose, then provides actionable next stepsable (clone or send) and the prerequisite (management session token). Every word 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?

Given it's a simple list operation with no params, the description is quite complete. It mentions the output (light metadata) and the use cases, and the annotation covers read-only. The only gap is the structure of the output (e.g., fields), but that is minor for a list of base templates.

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 has no parametersujetes (0 params), so the schema is empty. The description adds value by explaining the return type (light metadata) and how the results can be used, which compensates for the lack of parameter details. Since there are no params, a baseline of 4 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 clearly states it lists base templates with light metadata, and distinguishes it from sibling tools like mailkite_list_templates (which likely lists all templates). It also mentions cloning or sending directly, giving a clear purpose.

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

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

The description implies when to use it: when you need to browse premade templates. It mentions actions (clone or send) but doesn't explicitly state when not to use it or alternatives (e.g., mailkite_list_templates). The context signal of having siblings is high, but no explicit exclusion is given.

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

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

Annotations already convey readOnlyHint=true, so the read-only nature is covered. The description adds useful behavioral context by specifying that results include status and send stats, and by explicitly calling out the auth requirement. It does not mention pagination, but that is a minor gap for a simple list 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?

The description is two short sentences with no filler. The core action is front-loaded, the parenthetical adds useful disambiguation, and the auth requirement is stated separately and concisely.

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

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

Given the low complexity, empty parameter schema, and readOnlyHint annotation, the description is complete enough for an agent to invoke the tool correctly. It identifies what is returned, the resource domain, and the required token, with no missing critical information.

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

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

There are no parameters in the input schema, so there is nothing for the description to explain beyond the schema. The baseline score of 4 applies because the empty schema already fully documents the absence of parameters.

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

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

The description states a precise verb and resource: 'List your broadcasts (one-to-many sends)'. Adding 'with status and send stats' clarifies what the listing returns, making it easy to distinguish from singular tools like mailkite_get_broadcast and from generic message listing.

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

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

The description gives clear context for when the tool is used: when you need a list of broadcasts with status and send stats. It also notes the required auth context ('management session token'). It does not explicitly name alternatives, but for a zero-parameter list operation the usage is evident.

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

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

The description discloses behavior not visible in annotations or schema: newest-first ordering, what is captured (request payload and response status/headers/body), the 45-day retention limit, and the management session token requirement. This is rich operational transparency.

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 compact and well-ordered: what is returned, ordering, purpose/alternative, retention, auth. Every sentence carries useful signal 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?

For a single-parameter read-only endpoint, the description covers the input concept, output contents, ordering, retention, and authentication; an agent has enough to decide and invoke 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?

The schema already documents the sole parameter as a required string 'id' with 100% coverage衣柜? Need not. The description adds that the id selects one delivery, but provides no additional parameter constraints or format. 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 uses a specific verb and resource ('Every captured attempt for one delivery'), states the ordering ('newest first'), and enumerates exactly what is returned (request headers/payload, response status/headers/body). It also distinguishes this from fetching the whole message, making its scope clear against sibling tools.

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

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

It explicitly positions the tool as the per-attempt record behind a webhook post-mortem and notes it avoids pulling the entire message. That gives an agent clear situational guidance for when to call this tool versus a message-fetching or retry 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 readOnlyHint=true, so the read-only behavior is covered. The description adds the meaningful prerequisite of a management session token, which is not in the annotations, and clarifies the return includes webhook URL. It does this without contradicting the annotation, so this extra context raises it beyond baseline.

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

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

Two short sentences with no filler: the first states the primary purpose and the return content, and the second adds the prerequisite. Every phrase earns its place, and the core action 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?

For a zero-parameter, read-only list with no predefined output schema, the description covers purpose, the key return field (webhook URL), and the token requirement. It does not mention pagination, ordering, or error behaviors, but the simplicity of the operation makes those gaps minor.

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

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

There are zero parameters and the schema is trivially 100% covered, so the description has no parameters to explain. Applying the baseline for a 0-param tool, it earns a 4; there is nothing else the description needed to add.

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

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

The description states a specific verb and resource: 'List your domains, each with its webhook URL.' It is clearly distinct from sibling tools like get_domain (single domain) or create_domain, and the scope ('your domains') removes ambiguity. The title 'List Domains' is reinforced rather than merely restated.

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 'List your domains' implies the primary use case, but it provides no explicit comparison to alternatives (e.g., 'for a single domain use get_domain') and no 'when not to use' guidance. The management-session-token requirement adds a precondition but does not help route the agent toward or away from siblings.

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, so the description correctly adds that it's read-only. It goes beyond that by describing the output content (steps, outcomes, reasons) and noting the API key requirement (mk_live_…). No contradiction with annotations; the description enriches the behavioral context without repeating the hint.

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 concise: three short sentences with no fluff. It front-loads the core purpose, then the use case, then the auth requirement. Every sentence earns its place and the structure is easy to scan.

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

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

For a simple read-only tool with one parameter and no output schema, the description covers the essential aspects: purpose, use case, and auth requirement. It describes the content (steps, outcomes, reasons) but doesn't mention pagination, error handling, or response structure—minor gaps given the tool's simplicity.

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% (the only parameter id has a minimal description 'Path parameter id.'). The description adds a weak implication that id refers to an enrollment via 'this enrollment,' but it does not clarify the parameter's format, source, or usage. Since coverage is high, the baseline is 3, and the description adds only marginal value beyond the schema.

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

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

The description clearly states what the tool does: it lists the steps executed for a given enrollment, including outcomes and reasons. The phrase 'why didn't step 3 fire' provides a concrete use case and differentiates it from sibling tools like list_enrollments (which lists enrollments themselves) and get_enrollment (which retrieves a single enrollment).

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

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

The description gives clear context for when to use the tool—debugging why a step didn't fire—which is useful for an agent deciding between this and related enrollment tools. However, it does not explicitly mention alternatives or state when not to use it, though the use-case phrasing strongly implies it's for execution debugging.

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

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

Annotations declare readOnlyHint=true, and the description is consistent ('List who...'). It adds the prerequisite of a live API key and the ability to filter by status, which are not conveyed by annotations or schema. The mention of a status filter is a behavioral trait, though it is not reflected in the schema, creating a minor inconsistency.

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 that immediately state the core purpose and the key actionable detail (status filter). No filler or redundancy; the structure is front-loaded with the primary action.

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 tool it is fairly complete, but the status filter mention without a corresponding schema property is a notable gap. It also does not describe what the output will be (though no output schema exists). The API key requirement is useful context. The mismatch between description and schema lowers completeness.

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

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

The schema description for the single parameter is uninformative ('Path parameter id'), but the description partially clarifies that id refers to the sequence. However, the description also references a status filter that is not a parameter in the schema, which could mislead an agent into passing an unsupported argument. It adds some meaning but with inconsistency.

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

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

The description states a specific action ('List who is in a sequence') with a clear resource (enrollments in a sequence) and the kind of data returned ('where each of them is'). This precisely distinguishes it from siblings like get_enrollment, cancel_enrollment, and list_enrollment_runs.

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

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

It clearly implies the use case: enumerate enrollments in a sequence, optionally filtered by status. It does not explicitly contrast with alternatives, but the phrasing 'in a sequence' and the filter mention provide sufficient contextual guidance for an agent to select it over get_enrollment or list_enrollment_runs.

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?

Beyond the readOnlyHint annotation, it discloses that results include both posted events (with counts and last-arrival time) and events referenced by sequences but never sent, and it explains why that matters. It also calls out the API key requirement. No contradiction with annotations.

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

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

The description is longer than average, but every clause earns its place: purpose, result composition, counts/timestamps, the trap rationale, and auth requirement. The structure flows logically from what it returns to why it returns it.

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

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

For a zero-parameter, read-only list tool with no output schema, it fully covers what is returned, the two categories of event names, the rationale for including unsent ones, and the authentication prerequisite. Nothing essential 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?

The tool has zero parameters, so there is no parameter meaning to add; the baseline of 4 for no parameters is appropriate. The description's information about output categories is not parameter semantics but is still useful context.

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

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

The description names the exact resource ('distinct event names this account works with') and the intended consumer ('so an editor can offer them'). It also distinguishes itself from a more naive events-only listing by explicitly covering sequence-referenced events, making it distinct from siblings like mailkite_list_events and mailkite_list_triggers.

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 provides a concrete usage scenario (editor needs to offer valid event names) and includes a warning that a sent-only list would be a trap, implying when this broader listing is the right choice. It does not explicitly name sibling alternatives, but the context and warning make the appropriate use 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 include readOnlyHint: true, which covers the safety aspect. The description adds value by specifying the API key requirement ('mk_live_...') which is not in annotations, and stating the ordering behavior. It is consistent with annotations, so no contradiction.

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

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

The description is two sentences with no fluff. It front-loads the core purpose and ordering, then quickly adds use cases, filters, and auth requirement. All information is relevant and efficiently stated.

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

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

Given the tool's simplicity (no params, read-only, no output schema), the description covers the essential aspects: purpose, ordering, filters, and auth. It doesn't describe the response shape, but given the lack of an output schema, the agent might still be partially in the dark about return fields. However, for a list tool with such a simple interface, this is adequate.

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 input schema has zero parameters, so the description's mention of filtering by 'name' and/or 'email' is the only source of parameter insight. Since the schema is empty)Skip scoring down as baseline 4 for zero params, and the description fully compensates by listing the expected optional filters.

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 clear verb and resource ('List recorded events') and adds a concrete ordering constraint ('newest first'), which distinguishes it from a generic list. It also hints at its specific role (confirming POSTs and debugging sequences), but it doesn't explicitly name a sibling, so it falls short of a 5.

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

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

It provides clear use cases ('surface for confirming a POST landed and for debugging a sequence that did not trigger') which guide when to call it. However, it doesn't explicitly contrast with the many sibling list tools (e.g., mailkite_list_routes, mailkite_list_event_names), so the guidance is contextual but not exclusive.

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?

Beyond the readOnlyHint annotation, it reveals ordering, the bare-array response shape, the exact pagination cursor mechanism, and the auth prerequisite. This is rich behavioral context an agent can act on.

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 primary purpose, followed by pagination mechanics and auth. No filler or repetition 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 simple read-only listing tool with one schema parameter, the description covers what is returned, the ordering, how to page, and what auth is required. The only completeness gap is that before/limit are described but not represented in the input schema, leaving a small invocation ambiguity.

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% (only id), but the description adds meaningful semantics by contextualizing id as the list whose members are fetched and by documenting the before/limit pagination parameters. The only caveat is that before/limit are absent from the input schema, so the agent must infer they are query-level parameters.

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

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

Opens with a specific verb-resource pair: 'List the contacts that are members of a list' plus ordering ('newest first'). This clearly distinguishes it from sibling tools like mailkite_list_lists (lists themselves), mailkite_add_list_contacts, and mailkite_remove_list_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?

The description gives clear context: it is the read-side list-membership operation and notes the management session token prerequisite. It doesn't explicitly name alternative tools or say when not to use it, 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 declare readOnlyHint=true, so the description only needs to add context beyond that. It adds the auth-token requirement and the member-count output, but does not describe pagination, return shape, or potential empty-list behavior. This is adequate but not rich.

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

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

Two short sentences with no wasted words: purpose, scoping, output content, and the auth requirement are all covered efficiently.

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

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

For a zero-parameter, read-only listing tool, the description is sufficient: it states the resource, the output detail (member count), and the session-token requirement. No output schema exists, and the description compensates by noting what the response includes.

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 are zero parameters and schema coverage is 100%, so the baseline is 4. The description adds useful scope in 'your contact lists' and clarifies result contents, but there is little parameter-specific meaning to add.

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 your contact lists') and adds clarifying scoping ('static, curated broadcast audiences') plus the member-count detail. This clearly differentiates it from sibling list_* tools such as list_broadcasts, list_routes, and list_list_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?

Gives clear context for when to use it: to enumerate static, curated broadcast audiences, and it adds the auth prerequisite ('Requires a management session token'). It does not explicitly name alternative tools or exclusion conditions, 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=true, so the safety profile is covered. The description adds useful behavioral context: authentication via app password with `api` scope, management session token requirement, and newest-first ordering. It does not disclose pagination, limits, or return format, but with readOnlyHint present, a 3 is appropriate.

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 with no filler. The core action and ordering are front-loaded, followed by authentication context and a requirement. 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 simple read-only list tool with one fully documented parameter and readOnlyHint annotation, the description is nearly complete. It covers purpose, ordering, authentication, and session requirement. The only minor gap is lack of pagination/limit details, but that is not critical for a basic list call.

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

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

Schema description coverage is 100%, so the schema already documents the `address` parameter. The description adds that this is a mailbox address and ties it to the agent's own inbox, but it doesn't add format or source details beyond the schema. Baseline 3 is correct.

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

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

The description states a specific verb ('List'), a resource ('a mailbox's messages'), and a clear ordering ('newest first'). It distinguishes itself from the sibling mailkite_list_messages by specifying mailbox context and the app-password/API authentication path, though it doesn't explicitly name the sibling alternative.

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

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

The description gives clear context: it is how an agent reads its own inbox without an IMAP client, and it requires a management session token. It does not explicitly say when not to use it or name alternatives like mailkite_list_messages, but the context is strong enough for an agent to select it appropriately.

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

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

The description goes well beyond the readOnlyHint annotation by disclosing the bare-array response shape, newest-first ordering, the pagination contract (pass the last received_at as the next before), and the auth requirement. There is no contradiction with the annotations.

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

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

Every sentence earns its place, with the main purpose front-loaded and filtering, pagination, default behavior, and auth kept compact. Backticks unambiguously highlight parameter names.

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 list tool with no output schema, the description covers default behavior, filtering, cursor pagination, response type, and authentication in one place. Nothing essential for a first correct call 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?

The description richly documents search, before, and limit with precise meanings: field matching, received_at cursor, pagination size, and default behavior. However, the input schema declares zero properties and disallows additional properties, so the documented parameters are not represented in the machine-readable schema—an inconsistency that prevents a 5.

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

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

The description clearly states the action and resource: 'List stored messages, newest first.' This is specific and more informative than a bare tool name. However, it does not explicitly contrast itself with close siblings like mailkite_list_mailbox_messages or mailkite_get_message, so it stops short of a 5.

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

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

The description gives concrete usage context: optional search semantics, pagination via before/limit, the default of newest 100, and the required management session token. It does not mention alternatives or say when to prefer this tool over sibling list/get tools, preventing a higher score.

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?

Beyond the readOnlyHint annotation, it discloses ordering ('newest first'), row semantics (delivered_here), a detailed pagination contract (bounded scan, short pages, continue until nextBefore is null), and the required management session token. This is substantial behavioral context that annotations do not provide.

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, each carrying a distinct piece of information: what the tool returns, how to use delivered_here, how pagination behaves, and what auth is required. The purpose is front-loaded and there is 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?

The description covers purpose, ordering, auth, and a pagination loop, but it references `before` and `limit` parameters that are absent from the input schema, so an agent cannot act on the pagination instructions through the declared interface. With no output schema, the row shape is also only partially specified.

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 100% schema coverage the baseline is 3, and the description at least suggests that `id` refers to 'this route'. However, it instructs the agent to page with `before` even though the input schema only accepts `id` and sets additionalProperties to false, so the parameter guidance is partly unimplementable and `id` is never explicitly defined.

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 identifies the resource ('stored inbound messages this route could be asked to deliver') and the purpose ('preview for replaying mail to a route defined after that mail arrived'). It does not state an explicit imperative verb like 'list' or name a sibling tool for contrast, so it is one notch below the clearest possible definition.

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 actionable context: use this preview before replaying mail, and use the delivered_here flag to send only messages the route has not seen. It does not explicitly enumerate alternatives or state when not to use it, but the context is clear enough to route an 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?

The annotations already declare readOnlyHint=true, so the safe read-only nature is known. The description adds the requirement of a management session token, which is extra operational context not implicit in the schema. No annotations are declared that contradict the description and no conflicting behavioral traits (e.g., pagination, result size) are hidden.

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 two sentences, with no filler. It front-loads the core operation and then supplies the single important prerequisite. Every word earns its place, making it ideal for an agent to parse quickly.

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

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

For a zero-parameter, read-only tool with no output schema, the description provides enough: what it does and when it can be invoked. It lacks only detail about the returned data structure, but such detail is often unnecessary for a list command and the readOnlyHint already aligns with a safe read operation. The definition is complete enough 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?

The input schema has zero parameters, so the baseline is 4. The description adds nothing parameter-specific (there are none), which is appropriate. Since there are no parameters to document, this dimension is fully satisfied by the absence of need.

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

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

The description states a specific verb and resource: 'List inbound routing rules.' It clearly distinguishes this from siblings like mailkite_create_route and mailkite_delete_route by focusing on the read-only listing of configured rules, and it is semantically different from mailkite_list_route_candidates. An agent can immediately know what the tool does without opening the schema.

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

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

The description includes the prerequisite 'Requires a management session token,' which is useful usage context. However, it does not specify when to prefer this over alternatives such as mailkite_list_route_candidates, nor does it describe exclusions or conditions around calling it. It implies usage but leaves the decision 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?

The readOnlyHint annotation already signals a safe read operation. The description adds useful behavioral context beyond that: scoped keys are isolated to one domain, and a management session token is required. It does not describe the response shape, but the annotation covers the safety profile.

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 compact and front-loaded, opening with the core action and resource. The second sentence earns its place by explaining the security model and practical use case, and the third provides the required auth context. 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 parameterless read-only list tool, the description covers purpose, usage context, and authentication requirements. It does not detail what fields the listing returns, but with no params, a simple list operation, and no output schema, this is a minor rather than blocking 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?

The tool has zero parameters, so the schema is already complete and the description has nothing to add. The description's mention of account scope and session token is auth context rather than parameter semantics, and the baseline for zero-parameter tools is 4.

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

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

The description clearly states the action ('List'), the resource ('account's domain-scoped API keys'), and the scope ('account's'). It also explains what a scoped key is, which distinguishes this tool from sibling credential-listing tools like list_app_passwords and get_api_key.

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

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

The description gives clear usage context: list scoped keys when you need per-domain credentials to hand to sites or CI jobs, and it notes the management session token requirement. It does not explicitly state when not to use it or name alternative tools, but the context is sufficient for an agent to choose it appropriately.

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

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

The readOnlyHint annotation already signals safe read-only behavior, and the description adds meaningful context: newest-first ordering, live enrollment counts in the output, archived-sequence filtering, and the required mk_live_ API key. It does not mention pagination or limits, but the added context goes well beyond the annotation.

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

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

Two compact sentences carry all essential information with no filler. The primary purpose and output characteristics are front-loaded, and the authentication note is placed last.

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 parameterless read-only list tool, the description adequately conveys what the response contains (sequences with live enrollment counts), the ordering, and the archive filter. Pagination behavior is not mentioned, but this is a minor gap for such a simple 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?

The input schema has zero parameters, so parameter semantics are vacuous and the baseline of 4 applies. The mention of the API key refers to authentication rather than an input parameter, so no additional parameter detail is needed.

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 uses a specific verb ('List'), a clear resource ('sequences'), and a scoping qualifier ('your'). It adds distinctive behavioral details—newest-first ordering, live enrollment counts, and omission of archived sequences—that separate it from sibling tools like list_routes or list_triggers.

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 read-only listing use case is clear, but the description does not explicitly state when to prefer this over related tools such as get_sequence or list_enrollments. Mentioning the API key requirement is a useful prerequisite, but no alternative selection guidance or exclusions are provided beyond archived sequences.

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

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

The description complements the readOnlyHint annotation and adds useful behavioral context beyond it, such as the management session token requirement and the fact that suppressed addresses cause sends to be dropped. It does not contradict the read-only annotation; the token requirement does not imply 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?

The description is two sentences with no filler, front-loading the core action 'List suppressed addresses' before supporting details. Every sentence earns its place by adding either scope, consequences, or a prerequisite.

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

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

For a zero-parameter read-only list tool, the description covers the resource, the specific suppression types, the operational consequence of suppression, and the required auth token. It omits response format details, but no output schema exists and the information provided is sufficient for an agent 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?

The tool has zero parameters and an empty input schema, so there is nothing for the description to document about parameters. The baseline of 4 is appropriate because the description adds no misleading parameter information and the schema is fully covered.

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 ('List') and resource ('suppressed addresses'), and names the categories (unsubscribes, hard bounces, spam complaints, manual) that define the scope. This clearly distinguishes it from sibling tools like mailkite_add_suppression and mailkite_remove_suppression, which mutate the same resource.

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 context by explaining that sends to suppressed addresses are dropped before delivery, which tells an agent why listing suppressions is useful before sending. It also states the prerequisite 'management session token,' but it does not explicitly mention alternatives or when not to use this tool.

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

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

annotations already mark readOnlyHint=true, and the description adds meaningful context: only light metadata is returned, not the body, plus a specific auth requirement. This goes beyond the annotation by setting expectations on payload scope.

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 with zero waste: the verb, scope, payload detail, alternative, and auth are each front-loaded and purposeful. Every sentence earns its place.

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

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

For a zero-parameter read tool with no output schema, the description states purpose, return granularity, alternative, and auth. Minor details like pagination or ordering are not broadly expected, so the coverage is solid but not flawless.

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 has zero parameters and the schema is already fully documented (empty object). With no parameters to elaborate on, the baseline 4 is appropriate for this 0-param case.

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?

Description states a specific verb and resource: 'List your saved email templates' with the clarifying scope 'light metadata only — no body'. It differentiates from getTemplate and implicitly from list_base_templates by emphasizing saved templates, so an agent can clearly tell it apart from 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?

Provides an explicit alternative ('Use getTemplate for the full template') and a precondition ('Requires a management session token'). It does not contrast with mailkite_list_base_templates, but the main decision between list and get template is well-specified.

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, and the description adds an authentication requirement (mk_live_… API key) not present in structured data. It does not enumerate return fields, but for a read-only list the important behavioral context is covered.

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

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

One sentence with no filler; the action and scope are front-loaded and the authentication note is relevant and compact.

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-only list with no output schema, the description conveys what is listed, the required identifier, and authentication. It could add pagination or return-shape details, but they are not essential for this simple list operation.

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

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

Schema coverage is 100%, but the id description is tautological ('Path parameter `id`'). The tool description supplies the missing semantics by identifying id as the sequence whose triggers are listed.

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

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

The description is specific: verb 'List' + resource 'triggers' + scoping 'attached to a sequence'. The 'doors into it' metaphor reinforces the role and distinguishes it from sequence-level tools and trigger mutation siblings.

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

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

Clear context is provided: this tool reads triggers belonging to a particular sequence. It does not explicitly name alternatives or exclusions, but the scoping makes the appropriate use case evident among the many sibling tools.

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

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

Annotations already declare readOnlyHint=true. The description adds useful context beyond that: it explains that sending is blocked until the account is verified, and that an API key (mk_live_…) is required. This enriches the agent's understanding without contradicting the annotations.

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

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

Three short sentences, each earning its place: the returned data, the intended use, and the credential requirement. It is front-loaded with the most important information and has 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 zero-parameter, read-only tool, the description covers the important context: the involved resource, verification gating, the use case, and the required API key. It does not list exact response field names, but this is a minor gap since the discovered values are named.

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 are zero parameters and schema description coverage is 100%, so there is no parameter ambiguity. The description appropriately focuses on what the credential lookup returns rather than trying to explain nonexistent inputs.

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 exactly what the tool returns: the account behind the credential (email, verification status, and plan). It also ties it to a concrete lifecycle use case (polling verification after register()), which differentiates it from the many resource-specific sibling tools.

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

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

It explicitly says when to use it: 'Use to poll verification state after register()'. It does not name alternative tools or state when not to use it, but for a zero-parameter account-info tool this is clear enough 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?

Description discloses behavior well beyond annotations: immediate API key return, verification email, blocked sending until verified, 409 on existing email, and session-token requirement. Annotations only provide readOnlyHint/idempotentHint/destructiveHint (all false), so the description carries full behavioral disclosure and does so comprehensively.

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

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

The description is a single focused paragraph with three sentences. It front-loads the core purpose, then adds return/verification details, then error behavior and use case. All sentences earn their place; only minor trimming (e.g., 'Powers plugin/CLI onboarding' could be omitted) but structure is strong.

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 registration tool with no output schema, the description fully covers what an agent needs: what it returns (API key), verification flow, error for existing email, requirement for session token, and mentions polling helper. There are no missing call-time details that would leave an agent unsure how to invoke or interpret results.

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

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

Schema coverage is 100% and each parameter (email, ref, channel, referrer) already has a descriptive explanation. The description adds no new param-level meaning beyond what schema provides (e.g., it doesn't clarify the format of ref or channel further). It's adequate but not additive beyond the schema's already good descriptions.

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

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

States a specific action (create account), the resource (MailKite), and key characteristics (no password, returns API key). It clearly distinguishes from siblings like mailkite_get_api_key or mailkite_rotate_api_key by focusing on account creation. The 409 existing-email case adds precision.

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