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

Adds substantial behavior beyond annotations (which only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false): the confirmation gate, the confirmToken two-step fallback with reuse prohibition, and the critical caveat that guests only persist on a finalized event, not a bare draft. This is high-value disclosure an agent could not derive from schemas 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?

Front-loaded with the core action and the no-email guarantee, then progressively discloses the confirmation protocol and persistence caveat. Dense but every clause earns its place; the 'NB' and 'MCP_CONFIRM_MODE' references are slightly jargon-heavy.

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

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

Covers action, side effects, confirmation protocol, token lifecycle, and a persistence footgun – everything needed to call this mutation safely. No output schema exists, but the important response semantics (preview/confirmToken in phase 1) are described inline.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real semantics for confirmToken (fallback-only, never invented, never on first call, ignored under elicitation) that the schema description only partially covers. The 'guests' semantics ('draft/un-sent list') are also reinforced.

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

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

Specific verb (add) + resource (guests) + scope (a draft, un-sent guest list) that clearly distinguishes it from evite_update_guest, evite_remove_guest, and evite_send. An agent can route correctly 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?

Explicitly states when nothing is emailed ('until you evite_send') and gives the full confirmation flow, including the two-phase fallback when elicitation is unsupported. This is exactly the when/when-not/alternatives guidance the dimension asks for.

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

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

Annotations already flag destructiveHint=true and openWorldHint=true, and the description adds the behavioral detail that matters most: it genuinely emails all guests, a failed/timed-out call may still have sent, and a user confirmation (elicitation or preview+confirmToken round-trip) is required before sending. This goes well beyond what the annotations convey.

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

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

Three sentences, no filler, and the headline action is front-loaded before the side-effect warning and the confirmation mechanics. The confirmation sentence is dense but each clause (elicitation path, fallback path, token rule) carries distinct information.

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

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

For a destructive, no-output-schema send tool, the description covers the action, side effects, failure/retry semantics, and the required confirmation protocol. An agent has everything needed to invoke it safely without additional 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 groups, message, event_id, and confirmToken are already documented in the schema (including the strict 'never on the first call, never reused' rule). The description adds the overall preview/confirmToken flow but no parameter-level detail beyond it, so baseline 3 applies.

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

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

States a specific verb (broadcast) and resource (a message to RSVP segments of an Evite event), plus the bulk scope ('at once') that separates it from per-guest siblings like evite_send_message. An agent can identify the operation and its blast radius without opening the schema.

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

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

Gives clear usage context: it emails every guest in the selected segments, it routes the agent to evite_list_messages after a failure/timeout before retrying, and it documents the confirmation gate and MCP_CONFIRM_MODE fallback. It does not explicitly contrast with evite_send_message/evite_send for single-recipient sends, but the segment-scoped framing makes the boundary implicit.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, yet the description adds what those hints cannot: cancellation notices may reach guests, the action is recoverable via evite_reinstate_event, and the exact two-phase confirmation contract (preview + confirmToken, repeat call with same arguments, MCP_CONFIRM_MODE). That is real behavioral context beyond 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?

Front-loads the action, immediately flags DESTRUCTIVE, then explains reversibility and the confirmation mechanism in order of importance. Every clause carries decision-relevant information; nothing is filler despite the density.

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

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

For a destructive, open-world, confirmed-write tool with no output schema, the description covers side effects, reversibility, and the full confirmation protocol an agent must implement. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description supplies flow-level meaning the schema alone implies only locally: confirmToken is never sent on the first call, is never invented or reused, and is ignored entirely under elicitation. It also anchors event_id's origin (evite_list_events) alongside the schema.

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

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

States a specific verb+resource ('Cancel an Evite event') plus the secondary scope (draft deletion), and names the inverse sibling evite_reinstate_event. An agent can distinguish this from evite_update_event or evite_remove_guest without opening any schema.

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

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

Gives clear context for use (cancelling events, deleting drafts) and routes the agent to evite_reinstate_event when reversal is needed. It does not spell out explicit 'do not use for X' exclusions, but the destructive warning plus the named alternative covers the main routing decision.

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

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

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds genuinely non-obvious behavior: the mandatory confirmation gate, the elicitation vs. confirmToken fallback, and the upstream 500-on-success quirk with its re-list-and-report workaround. This is exactly the behavioral context structured fields cannot carry.

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

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

Front-loaded with purpose and required fields, then the confirmation protocol, then the failure handling. Every sentence carries information, though the run-on em-dash clauses in the middle make it denser than it needs to be.

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 and a mutation that can fail ambiguously, the description supplies the return contract itself (created:true with eventId, or created:"unknown"), which is the single most important thing an agent needs to avoid duplicate drafts. Nothing material is left unspecified.

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, but the description reinforces the three required fields and, more importantly, explains confirmToken's role in the phase-1/phase-2 flow and when it must never be sent. That is meaning beyond the schema's per-parameter text.

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

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

States a specific verb and resource ('Create an Evite event') plus a scope qualifier ('as a draft') that separates it from evite_duplicate_event and evite_update_event. An agent can identify the operation and its intended state without opening the schema.

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

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

Gives clear operating context: it asks for user confirmation first, describes both confirmation paths, and explicitly rules out repeat calls for the same event ('never call it again... check the drafts instead'). It stops short of naming the sibling tool (evite_list_events) as the alternative, so the routing is implied 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?

Annotations only declare readOnlyHint=false, destructiveHint=false and openWorldHint=true. The description goes further by disclosing that the result is a draft (not a live/sent event), that a new event id is returned, and that a confirmation gate with a confirmToken fallback governs execution — meaningful behavioral context beyond the structured fields, though permissions/auth requirements are still unstated.

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

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

Front-loaded with the action and return value, followed by the confirmation protocol; no sentence is wasted. The nested parenthetical about the fallback path is dense but earns its place by preventing misuse of confirmToken.

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 supplies the return value (new draft event id), the confirmation contract, and the token fallback — everything an agent needs to call this mutation safely and 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%, so both event_id and confirmToken are already documented in the schema, and the description largely restates the confirmToken protocol rather than adding new semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Duplicate an Evite event into a fresh draft') and names the exact UI action it mirrors. It is clearly distinguishable from siblings like evite_create_event and evite_update_event without opening any schema.

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

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

Gives clear operational context: confirmation is required first, and the two-step fallback applies only to clients without MCP elicitation. It does not, however, state when to prefer this over evite_create_event or any other sibling, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and network reach are covered. The description adds the endpoint shape and hints at returned sections (event, settings, location), but says nothing about auth requirements, error behavior for a missing/unauthorized event_id, 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?

One compact, front-loaded sentence that leads with the verb and resource and puts the endpoint reference in parentheses. The closing "and more" is vague filler that doesn't earn its place, but nothing else is wasted.

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

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

For a two-parameter read tool with full schema documentation, readOnly/openWorld annotations, and no output schema to explain, the description is nearly complete. It only lacks any note on error or permission behavior for invalid event ids.

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

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

Schema description coverage is 100% and both parameters (including the view enum with its compact/full tradeoff) are thoroughly documented in the schema itself. The description adds no parameter syntax or format detail beyond what the schema already carries, so the baseline 3 applies.

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

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

States a specific verb and resource ("Get a single Evite event detail") and names the underlying endpoint, so the agent knows this is a single-resource fetch. The word "single" implicitly distinguishes it from the evite_list_events sibling, but no sibling is named explicitly and the trailing "and more" leaves the payload scope fuzzy.

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

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

The description gives no explicit when-to-use or when-not-to-use guidance. The only routing hint is in the schema ("event_id from evite_list_events"), which implies a list-then-fetch flow and identifies the sibling to obtain the id from. Usage is therefore inferred rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing that the response includes the resolved auth mode, not just a bare up/down status, which is behavioral context an agent would not get from the annotation block alone.

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

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

A single front-loaded sentence with no filler; both what is checked and what is returned are stated 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?

With no parameters, no output schema, and annotations covering the read-only profile, the description supplies the one thing missing from structured data: the shape of what comes back (status plus auth mode). It stops short of enumerating possible status values or formats, a minor gap for a diagnostic endpoint.

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

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

The tool takes zero parameters, which sets the baseline at 4. There is nothing further for the description to clarify about arguments.

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

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

States a specific verb ('Report') and resource ('evite-mcp status and the resolved auth mode'), giving an agent an unambiguous sense of what the call returns. It is clearly a diagnostic among a sibling set composed entirely of event/guest/message operations, so no ambiguity with siblings exists.

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

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

Usage is implied rather than stated: an agent can infer this is the call to make when verifying connectivity or the active auth mode, but the description never says when to prefer it or what conditions warrant running it. No alternatives exist among the siblings, so no explicit exclusion is needed, keeping this at the minimum-viable level.

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 openWorldHint=true, so the safety profile is covered. The description adds genuine value a schema cannot: it discloses the return shape ('events plus a totals breakdown') despite no output schema, and clarifies the guest view for filterBy=others. It omits pagination behavior, sort order, and any rate or auth constraints.

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

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

Three tight sentences with the core purpose and return shape front-loaded and no filler. The endpoint path '(GET /services/events/v1/)' is arguably noise for an agent, but it does reinforce the read-only nature of 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?

With six fully documented parameters, read-only/open-world annotations, and no output schema, the description covers the essentials: what it lists, what comes back, and the one non-obvious filter mode. Remaining gaps (ordering, pagination semantics beyond the schema, cross-tool sequencing) are minor for a zero-required-parameter listing tool.

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

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

Schema description coverage is 100%, so every parameter is already documented in detail, which sets the baseline at 3. The description's only parameter content ('filterBy=others returns events where you are a guest') largely restates the schema's own 'others (you are a guest)' text, adding no new syntax, defaults, or interaction rules.

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 Evite events') and even pins the underlying endpoint, so the agent knows this retrieves a collection rather than a single record. The resource name implicitly separates it from siblings like evite_list_guests, evite_list_templates, and evite_get_event, though no sibling is named explicitly.

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

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

Usage is implied rather than stated: the agent can infer this is the browsing entry point for events, and the filterBy=others note hints at a guest-perspective mode. There is no explicit when-to-use/when-not guidance, no mention of alternatives (e.g., evite_get_event for a single event), and no prerequisites such as authentication 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered and the description only needs to add context. It usefully previews the response contents but says nothing about pagination, result volume, freshness, or auth requirements, and 'and more' indicates the field list is deliberately partial.

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

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

A single front-loaded sentence with a parenthetical endpoint and a compact field list; nothing is padded. The trailing 'and more' is slightly filler but costs little.

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 responsibly sketches the return contents (name, RSVP, head counts, delivery status) so the agent knows what comes back. It is thin on pagination/volume behavior, but the schema exposes no paging parameters, so the gap is minor.

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

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

Schema description coverage is 100%, so the schema fully documents both event_id and the compact/full view enum, including the projection caveat. The description adds no parameter-level detail beyond referencing the endpoint path, so the baseline of 3 applies.

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

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

The description states a specific verb (List) and resource (guests) scoped to an Evite event, and enumerates the returned fields (name, RSVP response, head counts, delivery status). It is clear and agent-legible, but it does not distinguish itself from the overlapping sibling evite_rsvp_summary or evite_get_event, which also surface RSVP/head-count data.

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

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

There is no explicit when-to-use guidance and no mention of alternatives such as evite_rsvp_summary (aggregate counts) or evite_get_event (single event detail). The use case is only implied by the verb 'List', leaving the agent to infer routing on its own.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the endpoint path and the tab scope, but says nothing about pagination, ordering, or rate limits that a list tool would benefit from disclosing.

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

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

A single tight sentence front-loads the verb, resource, and scope, then appends the endpoint. Every clause earns its place with no redundancy.

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

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

For a simple two-parameter read tool with full schema coverage and readOnly annotations, the description is adequate but thin: it omits result ordering, pagination, and how 'Messages tab' content differs from other message endpoints. No output schema exists, so return-shape expectations are left unstated.

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

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

Schema description coverage is 100%, so both event_id and view are fully documented in the schema, including the compact/full enum semantics. The description adds no parameter-level detail beyond what the schema provides, matching the baseline 3.

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

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

States a specific verb (List) and resource (messages on an Evite event's Messages tab), and includes the underlying endpoint. It doesn't differentiate from the closest sibling evite_send_message, though the read/write distinction is implied.

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

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

Usage is implied by 'List the messages on an Evite event's Messages tab' — an agent infers it's for reading event messages — but there is no explicit when-to-use versus evite_send_message or evite_broadcast, and no stated prerequisites beyond needing an event id.

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

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

Annotations declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds value beyond that by disclosing the return shape ('each template's slug (= template_name) and a readable display name'), filling in the absence of an output schema. It doesn't mention rate limits or result volume, hence not a 5.

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

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

Three sentences, front-loaded with the core action and purpose, then parameter notes. Every sentence carries information that isn't duplicated elsewhere; nothing is padding.

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

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

With no output schema, the description supplies the needed return-value account (slug plus display name), names the consuming tool, and documents all three parameters. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3. The description goes further by giving realistic category path examples and restating free_only's effect, and it uniquely maps the returned slug to the `template_name` string other tools expect — meaning not 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?

States a specific verb+resource ('List invitation templates from a gallery category') and immediately explains the downstream purpose: finding the `template_name` that evite_create_event requires. This clearly distinguishes it from read siblings like evite_list_events or evite_get_event.

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

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

Explicitly names the condition that selects this tool — locating `template_name` before calling evite_create_event — and shows concrete category path values. An agent knows both when to call it and what to do with the output.

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 the safety profile (readOnly=false, destructive=false, idempotent=true, openWorld=true), and the description adds genuinely new behavioral context the annotations cannot convey: a mandatory user confirmation step, an elicitation-capable prompt path, and a two-phase preview/confirmToken fallback with the rule that the token is never sent on the first call. That is exactly the kind of invocation-critical behavior this dimension rewards.

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, purpose front-loaded, then the confirmation protocol. No filler, no restatement of the title, and the parenthetical pointer to MCP_CONFIRM_MODE is a compact way to offload 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?

For a two-parameter mutation with no output schema, the description covers what an agent needs: scope, the inverse relationship, and the full confirmation choreography including the confirmToken return path. It does not describe the success outcome of the reinstate itself, a minor gap given no output schema exists.

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

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

Schema description coverage is 100%, so both parameters, including the detailed confirmToken contract, are already documented in the schema. The description's mention of confirmToken and the preview response reinforces but does not add syntax or format meaning beyond that. Baseline 3 applies when the schema carries the parameter burden.

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

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

States a specific verb and resource ('Reinstate a previously-cancelled Evite event') and immediately anchors it to its sibling by calling itself 'the inverse of evite_cancel_event'. An agent can distinguish it from the cancel tool without opening either schema.

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

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

The inverse-of-cancel framing makes the applicable context clear (only for already-cancelled events), and the description spells out the two confirmation paths so the agent knows how to invoke it. It stops short of explicitly stating preconditions (e.g. that the event must currently be cancelled) or an alternative sibling to use otherwise.

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

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

Annotations already declare destructive/idempotent/openWorld, but the description adds the operationally decisive detail they cannot: a mandatory user-confirmation step, with two distinct modes (native elicitation vs. preview-then-confirmToken) and a pointer to MCP_CONFIRM_MODE. This tells the agent what the first call actually does and prevents an accidental unconditional delete.

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 what/scope before the confirmation mechanics. The second sentence is dense with nested clauses but each one carries real procedural information, so nothing is padding.

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

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

For a destructive tool with no output schema, the description covers the confirmation contract, which is the main ambiguity. It leaves minor gaps: whether removal is permanent/reversible, what happens if the guest is not actually a draft, and whose authorization is required.

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 confirmToken field already carries an unusually thorough description of its lifecycle. The description only restates the token gating at a high level, adding little semantic detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (remove) and resource (guest), and narrows scope with the crucial qualifier 'draft (un-sent)', which immediately separates it from anything touching already-invited guests. An agent can pick this out from the 19 siblings without opening a schema.

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

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

Gives clear context: this is for un-sent draft guests, and it lays out the confirmation gate the agent must respect. It stops short of naming an alternative or stating explicitly what to do when the guest has already been sent (e.g. that no tool covers that case), so it is clear context without full exclusions.

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

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

Annotations already flag destructive (writes an RSVP) and openWorld. The description adds crucial non-annotation behavior: a confirmation step, a preview + confirmToken two-step fallback, and that the token must never be reused or invented. This is exactly the extra detail annotations can't convey.

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

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

One dense but efficient sentence. It front-loads the action and then qualifies the confirmation behavior. Slightly packed but no filler sentences.

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

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

Given a mutation tool with annotations covering safety and a confirmation path that must be understood to call correctly, the description covers the non-obvious flow. It doesn't explain required preconditions (event/guest existence) or return shape, but no output schema exists to cover that, so a small gap remains.

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

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

Schema coverage is 100%, so the schema already documents all 7 params. The description adds no param-level detail beyond the schema, which is acceptable given full coverage — baseline 3.

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

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

States a specific verb+resource: 'RSVP for a guest on an Evite event.' Clearly distinguishes from siblings like evite_update_guest or evite_add_guest — this sets an attendance response, not guest metadata.

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

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

Explains the confirmation flow, which is useful context, but doesn't say when to choose this tool over alternatives (e.g., why not evite_update_guest) or the precondition that the event/guest must exist and the event allow RSVPs.

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 openWorldHint=true, so the safety profile is covered. The description adds useful context about the returned fields and the fact that it is a derived/aggregated view rather than raw guest records, but says nothing about freshness, staleness of the aggregate, permissions, 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 short sentences, zero waste, with the resource and returned content front-loaded. The trailing provenance sentence is short and genuinely informative about data origin.

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

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

With no output schema, the description usefully names the returned fields (yes/no/maybe/noReply plus adult/kid counts), which is enough for a read-only aggregate tool. Minor gaps remain around whether derived counts can lag behind guest updates, but nothing critical for invocation is missing.

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

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

Schema description coverage is 100% and the view enum is documented at length in the schema itself, including the compact/full tradeoff. The description adds no parameter information beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get the RSVP summary for an Evite event') and even enumerates the returned buckets, so the agent knows exactly what comes back. It does not explicitly distinguish itself from the sibling evite_rsvp or evite_list_guests, which is the only thing keeping it from 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?

There is no when-to-use guidance and no named alternative, despite evite_rsvp and evite_list_guests being obvious candidates an agent might confuse it with. The note that it is 'derived from the event guests endpoint' hints at its relationship to the guest data but stops short of routing advice.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description goes further by disclosing that real guests are emailed (irreversible external effect), that a timeout may still have sent the invitation (non-idempotency), and that a confirmation gate applies. It does not cover rate limits or per-invitee partial-failure behavior, which keeps this short of a 5.

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

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

Front-loaded with the action and the caps-lock warning, and every clause carries information; nothing is filler. It is dense to the point of being hard to scan, with nested parentheticals in the confirmation sentence, so it falls short of a model two-sentence structure.

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

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

For a destructive, no-output-schema, one-required-param tool, the description covers the safety gate, the retry hazard, the recovery tool, and the confirmation-token protocol. An agent has everything it needs to call this correctly and to avoid double-sending.

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, and the description earns an extra point by framing confirmToken as a phase-2-only artifact tied to the preview and MCP_CONFIRM_MODE, which is context the schema field alone does not convey. event_id semantics are left entirely to the schema.

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

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

States a specific verb and resource ('Send the invitation to the ready-to-send (draft) guests of an event') and scopes it to draft/ready-to-send guests, which cleanly separates it from siblings like evite_send_message, evite_broadcast and evite_rsvp. An agent can identify the tool without opening the schema.

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

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

Gives explicit pre-call conditions (user confirmation first), an explicit failure path ('If a call fails or times out... check evite_list_guests before calling again'), and names the alternative tool to consult. It also states what the token-based path is for versus clients with elicitation support.

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

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

Goes well past the annotations: it discloses that the message is actually delivered ('This really notifies the guest'), that it is sent as the event host over Firebase rather than REST, that host privileges are required, and it details the two-phase confirmation behavior including preview, confirmToken, and MCP_CONFIRM_MODE. This is exactly the extra behavioral context annotations cannot carry.

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, front-loaded with the action and immediately followed by the critical 'really notifies' caveat and the auth constraint. Dense but nearly every clause carries information; a minor typo ('This really notifies') and the parenthetical about Firebase are the only slack.

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 still explains what the confirmation-required response contains (a preview and a confirmToken) and how to proceed, and it covers the auth requirement and the mutation's real-world effect. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value by framing confirmToken as a conditional, second-call-only artifact tied to the confirmation fallback and cross-referencing MCP_CONFIRM_MODE, which the schema field alone does not establish as a flow.

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

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

States a specific verb and resource ('Send a private message to one Evite event guest'), and the word 'one' plus 'private' implicitly distinguishes it from broadcast-style siblings like evite_broadcast and evite_send. An agent can select it without opening the schema.

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

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

Gives clear preconditions: only a host can use it, it targets a single guest, and it requires confirmation before proceeding. It does not explicitly name an alternative (e.g. evite_broadcast) for the many-guests case, so it falls just short of full when/when-not routing.

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

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

Annotations already flag destructiveHint/openWorldHint, but the description adds the crucial behavior that this mutation is gated behind user confirmation, including the exact two-phase preview + confirmToken fallback and the MCP_CONFIRM_MODE reference. That is a substantial disclosure an agent cannot get from the annotations alone, and it is consistent with them.

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

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

Front-loads the action and the patch contract before the longer confirmation detail, with no filler sentences. The second sentence is dense and long, but every clause carries operational meaning.

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

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

No output schema exists, and the description partially compensates by describing the phase-1 preview/confirmToken response shape. Combined with 100% schema coverage and destructive annotations, an agent has enough to call it correctly, though it never states required permissions or what happens to unmentioned fields beyond preservation.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above baseline by stating the partial-update contract ("only the fields you pass change"), which tells the agent that unspecified fields are preserved. It adds little else about individual parameters, since the schema already documents event_id, confirmToken, and the datetime fields.

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

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

States a specific verb ("Edit") and resource ("an existing Evite event") plus the patch semantics ("only the fields you pass change"), which separates it from evite_create_event and the other event lifecycle siblings. It stops short of naming a sibling directly, but the distinction is inferable without opening any schema.

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

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

The description spends its guidance budget on the confirmation mechanism (confirm first, or the two-step confirmToken fallback), which is procedural rather than selection guidance. It never says when to prefer this over evite_create_event, evite_duplicate_event, or evite_cancel_event, so tool-selection context is only implied by the word "existing".

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 openWorldHint=true; the description goes further by disclosing the full confirmation protocol, including that the first call may return only a preview plus confirmToken and that the token must never be invented or reused. It does not explain why the operation is destructive (e.g., whether the guest is re-notified), which leaves one behavioral gap.

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

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

Two sentences, front-loaded with the core action before the confirmation caveat. The second sentence is long but every clause (preview, token, repeat call, MCP_CONFIRM_MODE pointer) carries necessary operational 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?

For a mutation tool with no output schema, the description covers the unusual two-phase confirmation contract well enough for correct invocation. It omits what a successful edit returns or side effects on the guest's invite status, which would round out the picture.

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

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

Schema description coverage is 100%, so name, email, phone, event_id, guest_id and confirmToken are already documented in the schema. The description confirms which fields are editable but adds no format, validation, or sourcing detail beyond the schema text; the baseline of 3 applies.

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

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

States a specific verb (edit), resource (guest), the editable fields (name/email/phone), and a scope constraint (draft/un-sent only), which implicitly separates it from evite_add_guest and evite_remove_guest. It stops short of naming any sibling tool outright, so it is clear but not fully self-differentiating.

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

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

The 'draft (un-sent)' qualifier tells the agent when this tool applies and implicitly excludes already-sent guests, and the confirmation protocol explains the call sequence. No alternative tool is named for the sent-guest case, so the routing guidance is contextual 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?

Annotations only say non-read-only, open-world, destructive; the description goes well beyond them by disclosing the two-phase confirmation protocol, the confirmToken round-trip, the MCP_CONFIRM_MODE fallback behavior, and the guest-membership requirement. That is exactly the operational context an agent needs before a mutating call.

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

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

Front-loaded with the action, then prerequisites, then the confirmation mechanics — a sensible priority order. Dense but each sentence carries load; the parenthetical "(see MCP_CONFIRM_MODE)" is a slight deferral rather than an inline explanation.

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 mutating tool with no output schema, the description covers the confirmation path and its return shape (preview + confirmToken) but says nothing about the success response after the upload actually lands. That is a modest gap in an otherwise thorough definition.

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

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

Schema coverage is 100%, so the baseline is 3, but the description usefully ties guest_id to its source call and explains the lifecycle of confirmToken (phase-1 response, repeat call with identical arguments, ignored under elicitation). It does not add new meaning for path/mimetype beyond the schema.

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

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

States a specific verb and resource ("Upload a local image to an Evite event's shared photo gallery") and disambiguates further with "This really adds the photo to the event album," ruling out any preview/dry-run reading. No sibling tool touches photo galleries, so the agent can select it unambiguously.

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

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

Gives concrete prerequisites and routing (event_id from evite_list_events, guest_id from evite_list_guests) plus the mandatory confirmation sequence. It never states when NOT to use it or names an alternative, but for a one-of-a-kind upload tool the omitted exclusions are minor.

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