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

Beyond the annotations, the description discloses the confirmation flow, the two-step confirmToken fallback, the fact that nothing is emailed until evite_send, and the important caveat that guests only persist on finalized events. This adds substantial behavioral context not present in 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?

The description is dense but efficient: the primary action is front-loaded, followed by the key confirmation behavior and a critical persistence caveat. Every sentence earns its place with no fluff 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 3 parameters, no output schema, and moderate complexity, the description covers the main action, the confirmation workflow, the relation to sending, and the persistence caveat. 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 the schema fully documents event_id, guests, and confirmToken. The description adds minimal parameter-level meaning beyond what the schema already provides, 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 a precise verb and resource: 'Add guests to an event's draft (un-sent) guest list.' It clearly differentiates this from sibling tools like evite_update_guest and evite_remove_guest by emphasizing the draft state and the eventual evite_send flow.

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: use it for draft/un-sent guest lists, not finalized events, and it notes guests only persist on a finalized event. It does not explicitly name contrasting sibling tools, but the draft vs. sent distinction is enough to guide selection.

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 (destructiveHint=true, readOnlyHint=false), the description discloses the bulk-email side effect ('This really emails every guest') and fully specifies the two-phase confirmation protocol: a client confirmation prompt where supported, otherwise a phase-1 preview returning a confirmToken that must be echoed on a repeat call. This is substantial behavioral context consistent with destructiveHint=true.

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

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

Three tightly packed sentences with the purpose front-loaded, followed by the critical side-effect warning and the confirmation protocol. There is no filler; every sentence carries essential operational 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 bulk, destructive mutation with no output schema, the description covers the essential operational context: the real emailing side effect, the confirmation flow, and the preview/confirmToken fallback. Minor gaps remain — no mention of rate limits and the cryptic 'see MCP_CONFIRM_MODE' reference — but an agent has what it needs to invoke the tool correctly.

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

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

Schema description coverage is 100% and the schema is already rich — particularly for confirmToken, which documents the two-step token protocol in detail ('never on the first call, never invented, never reused'). The main description adds only the segment example and confirmation-flow context, which is marginal on top of the schema. Baseline 3 is appropriate.

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

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

The description names a specific verb (broadcast), resource (RSVP segments of an Evite event), and scope (whole segments at once), with a concrete example ('everyone who replied yes/maybe'). The 'whole...at once' phrasing differentiates it from siblings like evite_send_message without needing to open 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 description implies when to use the tool — reaching entire RSVP segments in a single blast — and the 'whole...at once' wording implicitly contrasts with evite_send_message. However, it never explicitly names an alternative or states when not to use it (e.g., for a targeted single-guest send), so the routing guidance 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?

Even with destructiveHint=true already present, the description adds critical behavioral detail: cancellation notices may be sent to guests, the operation is reversible, and a two-step confirmation flow with a confirmToken is used when the client lacks elicitation. This goes well 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 dense but every sentence earns its place: purpose, destructive side effect, reversibility, and confirmation protocol. It is front-loaded with the core action and avoids redundant restatement of the title.

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 fully covers what an agent needs: side effects, confirmation requirements, the two-step fallback, and the reversal tool. 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?

Schema description coverage is 100%, so the schema already fully documents both event_id and confirmToken. The description reinforces the confirmation flow but does not add substantial parameter-level meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Cancel an Evite event', and adds a second clear use case ('also used to delete a draft'). It is immediately distinguishable from siblings like evite_update_event and evite_reinstate_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?

The description clearly states when to use the tool: to cancel an event or delete a draft. It also names evite_reinstate_event as the reversal path. It does not explicitly say when not to use it or compare it with update/delete alternatives, 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?

The description discloses the critical quirk that Evite returns 500 even when the draft is created, explains the tool's compensating behavior (re-listing drafts), and defines the created:true/created:"unknown" result semantics. It also exposes the two-step confirmation behavior. Annotations only say the call is not read-only and not destructive, so the description carries the full behavioral burden and satisfies it.

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

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

The description is dense with dense parentheticals and a long compound final sentence, so it is not elegantly structured. However, every sentence earns its place: the confirmation protocol and the 500-error handling are both essential for correct invocation, and the core purpose 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 high-complexity tool with no output schema and minimal annotations, the description covers all critical operational aspects: required inputs, confirmation mechanics in both client modes, the error-ambiguity fallback, return-value semantics, and the prohibition on retrying. An agent has everything needed 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 the baseline is 3. The description names the three required parameters but that is redundant with the schema's required array; it does tie confirmToken into the confirmation workflow, yet the schema already explains confirmToken's two-step semantics in detail. The description adds modest value beyond the schema but does not meaningfully compensate beyond baseline.

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

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

The description states a specific verb and resource ('Create an Evite event (as a draft)'), and the draft qualifier distinguishes it from evite_send, evite_update_event, and evite_cancel_event among siblings. An agent can immediately tell what this tool does and how it differs from related 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 names the three required parameters upfront, describes the confirmation flow for both client modes, and gives explicit when-not-to-use guidance: never call again for the same event when created:"unknown" — check drafts instead. This is explicit, actionable routing advice that goes well beyond a basic 'use when you need X'.

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 annotations (readOnlyHint=false, destructiveHint=false) by disclosing that the tool creates a fresh draft, returns the new draft id, asks for user confirmation, and in fallback mode returns a preview and confirmToken requiring a repeat call. This is rich behavioral context that an agent needs to invoke the tool correctly.

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

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

Two tightly packed sentences deliver the core action, return value, and the entire confirmation behavior with no fluff or redundancy. The most important information is front-loaded, and the confirmation nuance is clearly separated.

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 moderate complexity, fully documented parameters, and absence of an output schema, the description covers everything an agent needs: what it does, what it returns, and how the confirmation flow works in both client modes. 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?

Schema description coverage is 100% for both parameters, so the schema already documents event_id and confirmToken in detail. The description reinforces the confirmToken's role in the two-step flow but does not add significant new meaning beyond the schema, matching the baseline 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 and resource ('Duplicate an Evite event into a fresh draft') and names the exact action ('Duplicate event'), making the tool's purpose unmistakable. It is clearly distinguished from sibling tools like evite_create_event or evite_update_event by the notion of copying an existing event into a draft.

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 and explains the conditional two-step confirmation flow (one-step with prompt vs. fallback with preview and confirmToken). It does not explicitly name alternative tools or state when not to use this tool, so it falls just short of full explicit exclusions.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds that it returns event, settings, location, and more, which is useful but not deeply behavioral (no error handling, rate limits, or field-level detail). It doesn't contradict annotations and adds minimal context beyond 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?

The description is a single sentence that front-loads the purpose and lists the key resource types. There is zero fluff, and the HTTP endpoint is a useful extra. 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 simple single-event read with readOnlyHint and full schema coverage, the description is largely complete. It states what the response contains (event, settings, location) though 'and more' is vague. Since there is no output schema, a bit more specificity about returned fields would be helpful, but the core usage is clear and sufficient for an agent to invoke correctly.

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

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

Schema description coverage is 100%, with both event_id and view fully documented. The view parameter has a detailed explanation of compact vs full behavior. The tool description itself doesn't discuss parameters, but the schema carries the burden, so the baseline 3 is appropriate.

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

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

The description states a specific verb ('Get') and resource ('single Evite event detail') and lists what it returns (event, settings, location, and more). It clearly distinguishes from list events by the singular scope, and includes the HTTP endpoint for precision. This is unambiguous and differentiates from sibling tools like evite_list_events.

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 this is for fetching a single event but does not explicitly state when to use it versus alternatives. The schema hint that event_id comes from evite_list_events gives some context, but the description itself offers no explicit when/when-not guidance or named alternatives. It's adequate but not 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?

The readOnlyHint annotation already declares this as a safe read operation. The description adds 'resolved auth mode' as a specific detail, but it does not disclose what 'status' encompasses, whether it makes network calls, how auth mode is resolved, or what the output format looks like. 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 a single, concise sentence that immediately conveys the tool's function. Every word earns its place, and there is no redundant or extraneous 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?

The tool is simple (no parameters, read-only), but without an output schema, the description could be more complete. It leaves ambiguity about what 'status' includes and what possible 'resolved auth mode' values might be. Still, it provides enough context for an agent to select the tool for a healthcheck purpose.

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 zero parameters, the baseline is 4. The description confirms that the tool requires no input, which is consistent with an empty schema. It adds no parameter-level details because there are none 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 clearly states the tool's purpose with a specific verb ('Report') and resource ('evite-mcp status and the resolved auth mode'). It unambiguously identifies this as a healthcheck/diagnostic tool, distinguishing it from sibling tools that manage events, guests, and messages.

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 is for checking status and auth mode, but it does not explicitly state when to use it versus the sibling tools. It lacks guidance on typical use cases like pre-flight checks or troubleshooting, and does not mention alternatives.

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

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

Annotations already declare readOnlyHint=true, so no safety caveat is needed. The description adds behavioral value beyond that by giving the canonical endpoint, disclosing that the response includes a totals breakdown, and specifying the guest-filter branch. It does not describe pagination or status defaults, but those are covered in the schema.

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

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

Three short sentences, each earning its place: endpoint/resource, return shape, and the key filter semantic. There is no filler and nothing redundantly restates the title or annotations.

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

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

With a 6-parameter schema that is 100% described, the description does not need to enumerate pagination or statuses; it supplies the endpoint and high-level result. Since there is no output schema, a bit more detail about the totals breakdown would have been useful, but the core invocation is complete.

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

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

Schema description coverage is 100%, so the baseline for parameter semantics is 3. The description's only parameter-level insight is 'filterBy=others returns events where you are a guest,' which largely restates what the schema enum already says; no additional syntax or interaction between parameters is added.

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 Evite events', and identifies the exact GET endpoint. It clearly distinguishes this list-events tool from sibling list tools by naming the events resource and noting that filterBy=others covers guest events.

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 clear when to call it: to list events and see a totals breakdown, with filterBy=others for events where the caller is a guest. It does not explicitly contrast with siblings like evite_get_event or evite_list_templates, but the resource scope is explicit and the intended use is unambiguous.

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 supply readOnlyHint=true, and the description's GET endpoint reinforces that this is a safe read with no side effects. It adds the return-field expectation but does not disclose pagination, limits, ordering, or other behavioral details; this is acceptable but not rich.

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

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

One sentence that front-loads the action, resource, endpoint, and key return fields with no filler. The empty title is not penalized because the description itself carries the content.

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

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

For a simple read-only listing tool, the description plus fully documented schema is sufficient: the agent knows what it does, what it returns, and that event_id comes from evite_list_events (per the schema). The only gap is explicit routing away from alternate summary/guest tools, which is more of a usage-guidance 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?

Schema description coverage is 100%; event_id and view are already well documented in the schema, including the compact/full distinction. The tool description adds no parameter-level meaning beyond pointing at the endpoint, so the baseline 3 applies.

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

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

The description opens with a specific verb-resource pair ('List the guests for an Evite event') and anchors it to the exact endpoint. It also names the return content (name, RSVP response, head counts, delivery status), making the tool's purpose unambiguous against siblings like evite_rsvp_summary or evite_add_guest.

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—when you need the guest roster for an event—but provides no explicit when-to-use/when-not-to-use guidance or named alternatives. An agent must infer the choice from the presence of sibling tools like evite_rsvp_summary rather than being told directly.

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 establishes that this is a safe read operation, and the GET endpoint is consistent with that. The description adds product context ('Messages tab') but does not disclose behavioral details such as pagination, ordering, authentication requirements, or result-size limits, which would be useful given there is no output schema.

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

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

The description is a single concise sentence that fronts the action and resource, with the endpoint as a useful parenthetical. No words are wasted and the structure is immediately parseable.

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?

Operation, endpoint, and both parameters are adequately covered, so the tool is callable. However, since there is no output schema, the absence of any indication of what the returned messages look like or whether results are paginated leaves a meaningful gap in 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%, with strong parameter documentation: event_id is traced to evite_list_events and view is given a detailed compact/full explanation. The tool description itself adds no parameter-level meaning beyond the schema, so it meets the baseline for schema-covered 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 specific verb ('List') and resource ('messages on an Evite event's Messages tab') and includes the exact GET endpoint. It is clearly distinct from sibling send/broadcast tools because it is the only message-listing 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 read-only listing intent is clear from the description and GET endpoint, so an agent can infer when to call it. It does not explicitly name alternative tools or exclusion conditions, but the alternatives differ so clearly in action (send/broadcast vs. list) that this is a minor gap.

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

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

Annotations already declare readOnlyHint, and the description adds concrete behavioral context: it returns slug (= template_name) and a readable display name, and supports free_only filtering. This is useful beyond annotation data, though it does not discuss pagination 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 focused sentences front-load the purpose, include concrete gallery path examples, and state the return contract. No filler or repetition of schema details.

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

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

With no output schema, the description appropriately supplies the key return information (slug/template_name and display name), explains the required category parameter, and connects the result to evite_create_event. This is enough for an agent to select and call it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces category examples and free_only semantics, but the schema already documents all three parameters well; the description adds limited new parameter-level meaning.

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

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

States a specific verb and resource ('List invitation templates from a gallery category') and explains the downstream purpose: finding the template_name evite_create_event requires. This clearly distinguishes it from the event/guest-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?

Explicitly tells the agent when to use it ('use this to find the template_name that evite_create_event requires'). It does not name exclusions or alternative tools, but no alternative template-listing sibling exists, so this is clear and actionable 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=false, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context by explaining the confirmation prompt and the two-step fallback with a confirmToken, which is beyond what annotations 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?

The description is two sentences, with the core purpose front-loaded and the confirmation flow explained efficiently. No superfluous words 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 a confirmation flow and no output schema, the description covers the essential workflow (preview + confirmToken) and references MCP_CONFIRM_MODE. It does not describe the return structure of the preview, but the flow is sufficiently explained for correct invocation.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description reinforces the confirmToken's role in the two-step flow but does not add significant new information beyond what the schema's detailed parameter descriptions already state. 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 ('reinstate'), the resource ('previously-cancelled Evite event'), and explicitly identifies it as the inverse of the sibling tool evite_cancel_event. This makes its purpose unambiguous and distinguishes it from all other 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 specifies the appropriate context (previously-cancelled events) and provides detailed instructions on the confirmation flow, including the two-step token mechanism. While it doesn't explicitly list exclusions, the inverse relationship and clear purpose make usage conditions obvious.

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 richly discloses the confirmation workflow and two-step fallback with a confirmToken. However, the annotation destructiveHint=false directly contradicts the description's removal semantics; removing a guest is a destructive user-data operation. Per scoring rules, a contradiction with annotations forces a score of 1.

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: the first sentence states exactly what the tool does, the second explains the confirmation behavior and fallback token flow. Every clause earns its place given the complexity of the described two-step confirmation.

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 the essential invocation context: draft-only removal, client-supported confirmation, and the token-based fallback for clients without elicitation. It lacks explicit output/response details, but the preview-and-token behavior is sufficiently described for an agent to call it correctly. The annotation contradiction slightly undermines completeness, but the description itself is operationally sound.

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 adds context around the draft-guest nature and the confirmation flow, but it does not materially go beyond the detailed schema descriptions for event_id, guest_id, and confirmToken.

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: 'Remove a draft (un-sent) guest from an Evite event.' This clearly distinguishes the tool from sibling tools like evite_add_guest, evite_update_guest, and evite_cancel_event. The draft/un-sent qualifier adds precision about scope.

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

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

The description provides clear context that this tool applies only to draft, un-sent guests, which helps an agent choose it over update or add operations. It does not explicitly name sibling alternatives or state when not to use it, but the draft-only constraint is a strong usage signal.

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

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

Beyond the destructiveHint annotation, the description explicitly discloses the two-phase confirmation behavior: it will either prompt the user or return a preview plus confirmToken, and only a repeat call with that token proceeds. This is important safety-relevant operational context that the annotations and schema do not fully convey.

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

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

Two tight sentences front-load the primary action and pack the confirmation behavior into the second sentence without redundancy. The flow explanation is dense but necessary and well-ordered, with every sentence earning 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 mutating tool with no output schema, the description explains the confirmation/token fallback and references MCP_CONFIRM_MODE. It does not describe what a successful repeat call returns or the post-confirmation result, but it is otherwise complete enough for an agent to call the tool correctly.

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

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

The input schema covers all 7 parameters with descriptions, including the special confirmToken behavior and provenance of event_id/guest_id. The tool description itself does not add parameter-specific meaning beyond the confirmation-flow context, so the baseline 3 is appropriate 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+resource ('RSVP for a guest on an Evite event') and makes the target clear: a guest on an event. It also differentiates from the sibling evite_rsvp_summary by describing the mutating RSVP action rather than a read/summary 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 gives clear context: this tool is for RSVPing a guest to an event, and the schema ties event_id and guest_id to evite_list_events/evite_list_guests. It does not explicitly name alternatives or state when not to use it, but the intended usage is clear enough to select it over 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 declare readOnlyHint=true, and the description is consistent with a read-only aggregation. It adds provenance (derived from event guests endpoint) and the composition of the counts, but does not disclose response shape, freshness, or pagination; however, the readOnly annotation lowers the burden, making this acceptable.

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 that front-loads the core action and includes the key output contents without filler. No redundant restatement of the title or schema.

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

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

For a simple, read-only, two-parameter aggregation, the combination of the description and the high-coverage schema is nearly complete. It explains what the summary contains and where the data comes from; the only missing piece is a concrete return-shape example, but the view parameter documentation partially covers response-shape behavior.

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 fully documents event_id and view; the view description is especially rich (compact vs full, no field projection). The tool description itself adds no parameter-level meaning, fitting 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 opens with a specific verb and resource ('Get the RSVP summary for an Evite event') and enumerates exactly what the summary contains (yes/no/maybe/noReply plus adult/kid head counts). The phrase 'Derived from the event guests endpoint' separates this aggregation from the raw guest-list sibling evite_list_guests.

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 evite_list_guests or evite_rsvp. The 'derived from' phrasing hints at a distinction, but it does not state conditions, exclusions, or alternative tools 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?

Beyond the annotations' destructiveHint, the description discloses that this action actually emails guests, that confirmation is required, and exactly how the two-step fallback works with a preview and confirmToken. This is exactly the sort of side-effect context an agent needs to invoke it safely.

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 packs the action, side-effect warning, confirmation requirement, and fallback token protocol into three dense sentences with no filler. The most important information is front-loaded in the first sentence and the warning.

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, side-effectful operation with no output schema, the description covers what happens, the confirmation paths, and the token contract. It does not detail the success response shape or failure cases, but it provides enough for correct invocation and references MCP_CONFIRM_MODE for the broader flow.

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 description coverage, the schema already documents event_id and confirmToken. The description adds crucial semantic value for confirmToken by explaining that it is only for the fallback flow, must come from the same tool's phase-1 response, and must never be invented or reused.

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 specific action ('Send the invitation'), the target resource ('ready-to-send (draft) guests of an event'), and the user-facing label ('Send now'), making it unambiguous and distinct from sibling messaging tools like evite_send_message. The uppercase warning reinforces that this is the actual invitation dispatch action.

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

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

It clearly establishes when to call the tool (when guests are in a ready-to-send/draft state and the user wants to email them), and the confirmation instruction explains the conditional flow. It does not explicitly name sibling alternatives or state when not to use it, so it falls just short of full 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 this as destructive and non-read-only. The description adds significant behavioral detail: it confirms real delivery, restricts to host role, and details the two confirmation modes (client prompt vs. two-step token fallback). This exceeds annotation coverage and gives the agent actionable expectations about side effects and user interaction.

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 primary purpose is front-loaded, and key constraints (host-only, confirmation requirement) are presented early. The two-step fallback is explained compactly 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 mutation tool with a confirmation mechanism, the description covers all necessary operational aspects: who can use it, what happens on first call, how to proceed with confirmToken, and the MCP_CONFIRM_MODE reference. No output schema exists, but the description mentions the phase-1 response contents (preview and token), sufficient for an agent to handle the flow 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 detailed descriptions for all parameters, including an extensive explanation of confirmToken. The tool description reiterates the confirmation flow but does not add new parameter-level meaning beyond the schema. Baseline 3 is appropriate when the schema already carries the semantic weight.

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: 'Send a private message to one Evite event guest.' It also clarifies scope ('one guest', 'private') and emphasizes actual notification ('really notifies'), distinguishing it from draft-only operations. Sibling tools like evite_broadcast are implicitly differentiated by the singular/private focus.

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 usage context: it is for private messaging to a single guest and requires host privileges. It explains the confirmation flow, which is essential for correct invocation. However, it does not explicitly name alternatives or exclusion cases (e.g., 'use evite_broadcast for multiple guests'), leaving some inference needed.

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 thoroughly discloses the confirmation-first behavior, explaining both the client-supported elicitation path and the two-step confirmToken fallback. It adds substantial behavioral context beyond the basic readOnlyHint/destructiveHint annotations, especially the requirement to confirm before changes proceed.

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 the core editing purpose front-loaded and the necessary confirmation mechanics in the second sentence. There is no redundant wording or filler; every sentence carries essential operational 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 mutation tool with no output schema, the description covers the key invocation details: editing semantics, partial updates, user confirmation, preview/token flow, and the rule for repeat calls. An agent has enough context to invoke the tool correctly and understand what will happen.

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?

All six parameters are already documented in the schema, so the baseline is 3. The description adds important semantic value with 'only the fields you pass change,' which clarifies partial-update behavior not stated in the schema, and reinforces the confirmToken lifecycle. This extra context justifies a 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 states a specific verb and resource: 'Edit an existing Evite event,' and clarifies that only supplied fields change. This clearly distinguishes it from sibling create, cancel, and duplicate tools, even without naming them explicitly.

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

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

The description gives clear context: use when editing an existing Evite event, with partial updates via only the fields passed. It does not explicitly name alternatives or say 'when not to use,' but the purpose is clear enough for an agent to select it over related 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 only mark the tool as non-read-only and non-destructive. The description adds crucial confirmation behavior: it prompts first, or returns a preview and confirmToken requiring a repeat call. This is meaningful behavioral context beyond what annotations 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?

Two sentences, front-loaded with action and scope, followed by the confirmation flow. Every sentence earns its place 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?

For a 6-parameter mutation with no output schema, it explains the confirmation flow and the draft-only scope. It doesn't describe the success response shape, but the confirmation mechanics are the main non-obvious behavior and are covered.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, including confirmToken's two-step semantics. The description's mention of confirmToken adds no new parameter 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 opens with a specific verb ('Edit') and a precise resource ('a draft (un-sent) guest's name/email/phone on an Evite event'). The 'draft (un-sent)' qualifier clearly distinguishes it from sibling tools like evite_add_guest, evite_remove_guest, and evite_update_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?

It clearly states the applicable context: editing a draft, un-sent guest. It does not explicitly name sibling alternatives or state when not to use it, but the draft/un-sent qualifier provides enough routing guidance for 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 only indicate readOnly=false and destructive=false, while the description adds meaningful non-obvious behavior: the photo is actually committed to the album, user confirmation is required first, and the two-step confirmToken fallback is explained for clients without elicitation. This is exactly the kind of behavioral detail an agent needs to avoid surprising the user or inventing a token.

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 first sentence is a strong, front-loaded purpose statement, and the prerequisite and confirmation sentences are informative. However, the second sentence ('This really adds the photo to the event album.') is redundant with the first and adds informal filler, so the description is good but not maximally 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?

The definition covers the essential invocation context: which IDs are needed, where to get them, accepted file types and sizes, and exactly how the confirmation and confirmToken flow works in both client modes. It does not describe the final success response after the confirmToken call, and there is no output schema to fill that gap, so it stops just short of complete.

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

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

Schema description coverage is 100%, and the input schema already documents path formats and limits, event_id and guest_id provenance, mimetype override rules, and the confirmToken restrictions. The description reinforces guest_id provenance and the token flow but does not add substantial meaning beyond the schema, so the high-coverage 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 opens with a specific verb, resource, and destination: 'Upload a local image to an Evite event's shared photo gallery.' This clearly distinguishes the tool from the messaging, RSVP, and event-management siblings, and the annotation title reinforces the same action. There is no ambiguity about what the tool does.

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 names the required prerequisite (guest_id from evite_list_guests) and spells out the confirmation workflow, giving an agent clear context for when and how to invoke it. It does not explicitly name alternatives or state when not to use it, but no sibling tool overlaps with photo upload, so this is only a minor gap.

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