Server Quality Checklist

Tool Scores

• evite_list_guestsA
  3.5/5.0
  Behavior3/5

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

  The description explicitly identifies the operation as a GET and readOnlyHint is true, so the safety profile is consistent. It adds some context by previewing returned fields (name, RSVP response, head counts, delivery status), but it doesn't disclose pagination, auth requirements, or response envelope details.

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

  Conciseness5/5

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

  A single front-loaded sentence states the action, endpoint, and representative output fields with no filler. 'and more' is slightly vague, but the description remains tightly scoped and easy to scan.

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

  Completeness3/5

  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 schema covers the required event_id, optional view, and likely output content. It is incomplete around response shape, pagination, and authentication, and there is no output schema to fill those gaps, so the agent must infer some call details.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already explains event_id and the compact/full view behavior. The tool description adds no extra parameter meaning beyond the endpoint placeholder, so the baseline score of 3 applies.

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

  Purpose4/5

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

  The description uses a specific verb and resource: it 'List[s] the guests for an Evite event' and names the endpoint plus returned fields. It is clear but does not explicitly contrast itself with sibling tools such as evite_rsvp_summary or evite_get_event, so it stops short of full sibling differentiation.

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

  Usage Guidelines3/5

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

  The intended use is implied by the verb and resource—call this when you need the guest list, RSVP responses, head counts, or delivery status for an event. However, the description never states when not to use it or points to an alternative like evite_rsvp_summary for summarized RSVP data.

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

• evite_list_messagesA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description's 'GET' method is consistent with that. The description adds minimal behavioral context beyond the annotation, such as the Messages tab association, but no pagination, ordering, auth, or response-shape details.

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

  Conciseness5/5

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

  A single, front-loaded sentence that immediately identifies the action and resource, with the endpoint appended as useful context. No filler or redundancy.

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

  Completeness4/5

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

  For a simple read-only list operation with fully documented parameters, the description is largely sufficient. It lacks explicit notes on pagination or response contents, but the low complexity and strong schema coverage make those gaps minor.

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

  Parameters3/5

  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 view. The description adds no parameter-level meaning beyond the endpoint placeholder {id}, which aligns with event_id but does not improve on the schema.

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

  Purpose5/5

  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 the messages on an Evite event's Messages tab', and reinforces it with the exact GET endpoint. This clearly differentiates it from siblings such as evite_send_message and 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.

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives. It does not mention that evite_send_message should be used for sending messages, or exclude other list tools, leaving the agent to infer selection from the name alone.

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

• evite_rsvp_summaryA
  3.6/5.0
  Behavior3/5

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

  With readOnlyHint=true already revealing the safety profile, the description adds a little context by saying the summary is derived from the event guests endpoint. It does not describe pagination, staleness, or other behavioral traits, but it is not misleading and does not contradict the annotation.

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

  Conciseness5/5

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

  The description is two short sentences that front-load the core purpose and then add a single piece of contextual provenance. There is no filler or repetition of schema information.

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

  Completeness4/5

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

  For a read-only summary tool with complete parameter documentation and a readOnlyHint annotation, the description adequately conveys the response content (RSVP counts with adult/kid breakdown). It could be more explicit about the return shape, but it is enough for an agent to select and call the tool correctly.

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

  Parameters3/5

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

  The schema provides 100% coverage of event_id and view, including a detailed explanation of compact vs full response shapes. The description itself adds no parameter syntax beyond what the schema already documents, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'Get the RSVP summary for an Evite event' and enumerates the summary dimensions (yes/no/maybe/noReply plus adult/kid head counts). This makes it distinguishable from siblings like evite_rsvp (a write action) and evite_list_guests (raw guest details).

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to choose this tool over siblings; 'Derived from the event guests endpoint' hints at a data source but does not say when to use the summary instead of evite_list_guests. No exclusions or alternatives are provided.

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

• evite_healthcheckA
  3.9/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• evite_get_eventA
  4/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the HTTP GET method and response scope, but does not disclose additional behavioral traits such as auth needs, rate limits, or response shape details. 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.

  Conciseness5/5

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

  The description is a single front-loaded sentence containing the verb, resource, endpoint, and scope with no filler. It is appropriately sized for the tool's simple read-only nature.

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

  Completeness4/5

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

  For a simple read-only GET with one required parameter, the description plus the rich parameter schema and readOnlyHint give an agent enough to invoke it correctly. Since there is no output schema, exact return fields are only summarized ('event, settings, location, and more'), so a 5 would require more explicit return documentation.

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

  Parameters3/5

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

  Schema description coverage is 100%, and both parameters already have detailed descriptions—especially view, which explains compact/full behavior and the rationale for not doing field projection. The description adds no parameter-level meaning, so the high-coverage baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description starts with a specific verb ('Get') and precise resource ('single Evite event detail'), and includes the REST path plus content categories ('event, settings, location, and more'). This clearly distinguishes it from list-oriented siblings 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.

  Usage Guidelines4/5

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

  'Get a single...detail' clearly positions this as the one-event detail lookup versus evite_list_events for listing events. The event_id parameter description reinforces the workflow by pointing to evite_list_events as the source of IDs. However, alternatives are not named explicitly, 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.

• evite_list_eventsA
  4/5.0
  Behavior3/5

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

  The readOnlyHint annotation already establishes the safety profile; the description adds that this is a GET endpoint and returns events plus a totals breakdown. It doesn't disclose deeper behavior like pagination details or response structure beyond the totals note, so it adds moderate but not rich context.

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

  Conciseness5/5

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

  Three short sentences cover the action, the return shape, and the guest-filter mode with no filler or repetition of schema content. Every sentence earns its place and the main action is front-loaded.

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

  Completeness4/5

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

  For a simple read-only listing tool with no required parameters and a fully documented schema, this is nearly complete. Since there is no output schema, the description helpfully notes that the response contains events plus a totals breakdown. It could have explicitly routed the agent to alternatives, but the low complexity makes that a minor gap.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all six parameters, their defaults, enums, and constraints are already documented. The description's filterBy=others note adds no real meaning beyond what the schema provides.

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

  Purpose5/5

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

  The description states a specific action and resource: 'List your Evite events' with the REST endpoint GET /services/events/v1/. This clearly distinguishes it from related tools like evite_get_event and 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.

  Usage Guidelines4/5

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

  It clearly establishes this as the tool for listing the caller's Evite events and explicitly calls out the filterBy=others guest-mode use case. It doesn't name alternative tools for other operations, but the list semantics and sibling tool names make the boundary clear.

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

• evite_rsvpA
  4/5.0
  Behavior3/5

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

  The description mentions the dry-run preview and confirm gate, which goes beyond the readOnlyHint=false annotation. However, this information is almost entirely duplicated from the schema's confirm parameter description, so the added value is minimal. It adds a small clarification that nothing is sent without confirm, which is useful.

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

  Conciseness5/5

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

  Two sentences, first states purpose, second states the critical behavioral gate. Very concise and front-loaded; no wasted words.

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

  Completeness4/5

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

  The description covers the core purpose and the most subtle usage pattern (confirm gating). It doesn't describe return values or error behavior, but no output schema exists and the schema documents parameters well. For a mutation tool with 7 parameters, it is reasonably complete, though it could mention what a successful RSVP does (e.g., updates guest status).

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

  Parameters3/5

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

  Schema coverage is 100%, with all seven parameters described in the schema. The description does not add any parameter-specific semantics beyond what the schema already provides. Baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's function with a specific verb 'RSVP' and a resource 'a guest on an Evite event'. It distinguishes from siblings like evite_rsvp_summary by focusing on the action of responding rather than summarizing. The title is consistent and the purpose is unambiguous.

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

  Usage Guidelines4/5

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

  The confirm-gated behavior is explicitly described: without confirm:true, it returns a dry-run preview and sends nothing. This tells the agent when it is safe to invoke without side effects. It does not explicitly name alternatives, but the sibling list and names make the context clear.

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

• evite_list_templatesA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true. The description adds useful behavioral context beyond that: it returns each template's slug (= template_name) and display name, explains the category path format, and notes the free_only filter. It does not cover pagination or rate limits, but that is not critical for this read-only listing tool.

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

  Conciseness5/5

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

  The description is compact, with the core purpose and usage front-loaded. Each sentence earns its place: purpose plus integration with evite_create_event, category examples, and return value semantics. No filler or redundancy.

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

  Completeness4/5

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

  For a read-only template listing tool with three parameters and no output schema, the description covers the essential context: what it returns, how category paths look, and the free_only behavior. The view parameter is fully described in the schema, so the description need not repeat it. Minor gaps are lack of pagination or volume expectations, but these are not required for correct invocation.

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

  Parameters3/5

  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 adds only marginal value beyond the schema: one extra category example and the semantic link between slug and template_name. The view and free_only parameters are already well described in the schema.

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

  Purpose5/5

  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 invitation templates from a gallery category.' It clearly distinguishes the tool from event/guest/message siblings and explains its role as the source of template_name for evite_create_event.

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

  Usage Guidelines4/5

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

  The description explicitly says to use this tool to find template_name for evite_create_event, which is clear context. It does not explicitly state when not to use it or name an alternative, but no sibling tool provides template listing, so the guidance is sufficient.

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

• evite_remove_guestA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint:false, signaling a write operation. The description adds valuable transparency by explaining the confirm-gated dry-run behavior, which is not apparent from annotations. It does not cover all nuances (e.g., reversibility, permissions), but the core behavioral trait is disclosed.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core action and followed by the confirm-gating mechanism. No filler, every sentence earns its place.

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

  Completeness4/5

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

  For a relatively simple mutation tool with no output schema, the description covers the critical confirm-gated behavior and draft-only scope. It does not specify the return value on success or error handling, but these are not essential given the tool's simplicity and the clear schema.

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

  Parameters3/5

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

  Schema description coverage is 100%, with each parameter already documented (event_id, guest_id, confirm) including the confirm gating. The description adds no extra parameter-level semantics 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.

  Purpose5/5

  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 ('Remove') and resource ('draft guest from an Evite event'), distinguishing it from siblings like evite_update_guest and evite_add_guest. The scope restriction to 'draft (un-sent)' guests makes it unambiguous.

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

  Usage Guidelines4/5

  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 removing draft guests and requires confirm:true to actually execute; otherwise it's a dry-run. It does not explicitly mention alternatives for non-draft guests, but the draft-only scope implies the use case. No misleading guidance.

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

• evite_update_guestA
  4.2/5.0
  Behavior4/5

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

  The description clearly discloses the dry-run behavior: 'without confirm:true this returns a dry-run preview and changes nothing.' This adds significant value beyond the readOnlyHint:false annotation by explaining how to safely invoke the tool and what happens without confirmation. It also notes the 'un-sent' constraint. It does not mention other side effects or failure modes, but the confirm-gating is the key behavioral trait.

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

  Conciseness5/5

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

  The description is a single, information-dense sentence. It front-loads the purpose and immediately explains the critical confirm-gating behavior. Every word earns its place; there is no redundancy or filler.

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

  Completeness4/5

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

  The description covers the essential context: that the tool edits drafts, which fields are editable, and the confirm-gating mechanism. Since there is no output schema, it does not need to describe return values. It does not mention error conditions or how to obtain IDs, but those are already provided in the schema descriptions, making the overall context reasonably complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema already provides detailed meanings for all parameters. The description's mention of 'name/email/phone' aligns with the schema but does not add new semantic information beyond what is already documented. It also hints at the 'confirm' parameter's role, but that is already fully explained in the schema, so the description adds marginal value.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Edit a draft (un-sent) guest's name/email/phone on an Evite event.' It uses a specific verb ('Edit'), identifies the resource ('draft guest'), and distinguishes itself from siblings like evite_add_guest and evite_remove_guest by limiting scope to draft/un-sent guests.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use the tool ('draft (un-sent) guest') and specifies the confirm-gating behavior, implying that confirm:true is required to actually commit changes. However, it does not explicitly name alternative tools for non-draft guests or state exclusions beyond the 'draft' qualifier, so it falls slightly 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.

• evite_add_guestA
  4.4/5.0
  Behavior5/5

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

  Annotations are minimal (readOnlyHint=false), so the description carries the burden and delivers: no emails sent until evite_send, confirm-gated dry-run, and guests only persist on finalized events. These are beyond what annotations state, with no contradiction.

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

  Conciseness5/5

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

  Three concise sentences, each carrying distinct critical information: purpose, side-effect, and persistence caveat. Efficiently front-loaded with no filler or redundancy.

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

  Completeness4/5

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

  Without an output schema, the description explains the dry-run preview and confirm-gating, but does not specify what a successful confirmed response contains. Still, it covers the most crucial operational context: draft status, email absence, and persistence limitations.

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

  Parameters3/5

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

  Schema coverage is 100%, with each parameter already described. The tool description mostly restates the confirm gating already present in the schema, adding little new parameter-level meaning beyond what the schema provides.

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

  Purpose5/5

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

  States 'Add guests to an event's draft (un-sent) guest list' with a specific verb and resource, clearly distinguishing it from sibling tools like evite_remove_guest and evite_update_guest. It also adds 'Nothing is emailed until you evite_send', reinforcing the tool's scope.

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

  Usage Guidelines4/5

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

  Provides clear context: use for draft un-sent guest lists, confirm-gated with dry-run preview, and a persistence caveat telling when guests actually persist. It does not explicitly name alternatives like evite_update_guest, but the draft/sent distinction makes the intended usage apparent.

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

• evite_broadcastA
  4.4/5.0
  Behavior5/5

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

  Annotations only state readOnlyHint=false, so the description carries the safety burden. It explicitly warns 'This really emails every guest in those segments' and explains the dry-run vs. actual send behavior with confirm:true. This is strong disclosure 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.

  Conciseness5/5

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

  Three concise, front-loaded sentences; first sentence states the action, second warns of real-world effect, third explains the confirm mechanism. No redundant words.

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

  Completeness4/5

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

  The tool has no output schema, but the description explains the dry-run preview and the actual send behavior. It doesn't describe the preview's contents or explicitly differentiate from similar messaging siblings, but it covers the core operational requirements.

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

  Parameters3/5

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

  All 5 parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds no new parameter-level details beyond what the schema already provides for groups and confirm; it emphasizes the same confirm gating already in the schema.

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

  Purpose5/5

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

  The description uses a specific verb ('Broadcast') plus resource ('message to whole RSVP segments of an Evite event') and scope ('whole segments'), clearly distinguishing from sibling tools like evite_send_message which likely target individuals. It is precise and immediately understandable.

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

  Usage Guidelines4/5

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

  It provides clear context: use for whole-segment broadcasts, not individual messaging, and explains the confirm gate as a prerequisite for actual sending. However, it doesn't explicitly name alternative tools or state when not to use it, so it stops short of a full 5.

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

• evite_create_eventA
  4.4/5.0
  Behavior5/5

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

  Beyond the readOnlyHint false, the description discloses that without confirm:true the tool returns a dry-run preview and sends nothing, and critically notes that the API may return a 500 despite successful creation. This is valuable behavioral context that the annotations don't provide.

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

  Conciseness5/5

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

  The description is three sentences, front-loaded with the main action, and each sentence adds essential information: required fields, confirm gating, and error handling. No filler or redundancy.

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

  Completeness4/5

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

  The description covers the draft behavior, confirm gate, and the unusual 500 error handling, which is critical for agents. However, it does not specify the return payload for a successful create or describe what the dry-run preview includes, leaving some ambiguity given there's no output schema.

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

  Parameters3/5

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

  Schema covers 100% of parameters with descriptions, including confirm, required fields, and datetime formats. The description restates required params and confirm-gating but adds no new information beyond what the schema already describes, so it meets the baseline.

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

  Purpose5/5

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

  Description opens with 'Create an Evite event (as a draft)' – a specific verb and resource, immediately clarifying the tool's role. The 'as a draft' qualification distinguishes it from sending or updating events, so the purpose is clear and differentiated.

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

  Usage Guidelines4/5

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

  The description explains the confirm-gated workflow (dry-run vs. actual creation) and instructs users not to retry on the 500 error but instead re-list drafts. However, it does not explicitly name sibling alternatives like 'send' or 'update_event' for when to use them, so it's clear context but not 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.

• evite_duplicate_eventA
  4.5/5.0
  Behavior5/5

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

  The description discloses crucial behavioral details beyond the annotations: confirm-gating, dry-run preview behavior, and that no event is created without confirm:true. It also states the return value (new draft event id). This provides the agent with a clear safety model, especially given the annotation only says readOnlyHint:false.

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

  Conciseness5/5

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

  The description is highly concise, consisting of two sentences that front-load the core purpose and then add the confirm-gating caveat. Every sentence adds distinct value and there is no redundant or filler content.

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

  Completeness5/5

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

  For a tool with only two simple parameters and no output schema, the description is complete: it explains the action, the return value, and the critical confirm behavior. It gives the agent everything needed to invoke the tool correctly and understand the dry-run flow.

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

  Parameters3/5

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

  The input schema already documents both parameters, including a description for confirm that matches the tool description ('Must be true to proceed. Without this, the tool returns a preview'). The description reinforces the confirm behavior but does not add new parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description begins with a specific verb 'Duplicate' and clearly identifies the resource ('an Evite event') and the result ('a fresh draft'). It also explicitly names the action ('Duplicate event') and notes the return value (new draft event id), distinguishing it from create/update tools.

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

  Usage Guidelines4/5

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

  The description clearly indicates when to use this tool: when duplicating an existing Evite event. It also provides important guidance on the confirm parameter, explaining that without confirm:true the tool only returns a dry-run preview. It does not explicitly name alternative tools like evite_create_event or state when not to use it, so it falls just short of full marks.

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

• evite_sendA
  4.5/5.0
  Behavior5/5

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

  The description goes beyond the readOnlyHint:false annotation by warning 'THIS EMAILS GUESTS' and explaining that without confirm:true it returns a dry-run preview and sends nothing. This is crucial behavioral disclosure for a mutating tool and prevents accidental sends.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the main action and the critical safety warning. Every phrase earns its place with no redundancy or filler.

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

  Completeness5/5

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

  For a simple tool with two well-documented parameters and no output schema, the description fully covers the action, safety gate, and dry-run behavior. It leaves no important gaps for an agent to misinterpret.

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

  Parameters3/5

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

  Schema description coverage is 100% and already documents both parameters, including the confirm gate. The description adds the term 'dry-run' but essentially mirrors the schema, providing no significant extra meaning beyond what structured data already offers.

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

  Purpose5/5

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

  The description clearly states the tool sends the invitation to 'ready-to-send (draft) guests' of an event, using a specific verb+resource. It distinguishes from sibling tools like evite_send_message or evite_broadcast by focusing on the main invite and the 'Send now' action.

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

  Usage Guidelines4/5

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

  The description provides clear context by specifying the target guests and the send action, and it explains the confirm-gating behavior. However, it does not explicitly name alternative tools or exclusion criteria, so it falls short of a 5.

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

• evite_upload_photoA
  4.5/5.0
  Behavior5/5

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

  Beyond annotations (readOnlyHint=false), the description discloses key behaviors: the confirm-gated dry-run preview, the requirement for a valid guest_id, and the fact that it truly performs the upload. This goes well beyond the minimal annotation and adds significant operational context.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary purpose, then adds essential usage constraints. Every word earns its place; no fluff or redundancy.

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

  Completeness5/5

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

  Given the tool's moderate complexity (5 params, no output schema), the description covers the essential operational aspects: what it does, the prerequisite, and the confirm-gating behavior. The schema handles parameter details, so the description is complete enough for an agent to select and invoke the tool correctly.

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

  Parameters3/5

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

  The schema already provides 100% description coverage for all parameters, including details on path, confirm, event_id, guest_id, and mimetype. The description adds little beyond repeating the confirm behavior and guest_id source, 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.

  Purpose5/5

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

  The description clearly states the action ('Upload a local image to an Evite event's shared photo gallery') and emphasizes the real effect ('This really adds the photo to the event album'). It distinguishes this tool from siblings by specifying the unique resource (photo gallery) and action (upload).

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

  Usage Guidelines4/5

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

  It provides a clear prerequisite ('Needs your guest_id on the event') and explains the confirm-gating mechanism ('without confirm:true this returns a dry-run preview and uploads nothing'). While it doesn't name explicit alternatives, none exist among siblings; the usage context is sufficiently clear.

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

• evite_cancel_eventA
  4.6/5.0
  Behavior5/5

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

  The description discloses critical behaviors beyond annotations: 'DESTRUCTIVE,' potential guest notification, dry-run behavior, and reversibility. This significantly enriches the agent's understanding of side effects. The readOnlyHint=false annotation is consistent with the destructive warning; no contradiction.

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

  Conciseness5/5

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

  Three compact sentences front-loaded with the action, followed by the essential safety caveats. Every sentence contributes necessary information with no redundancy or fluff.

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

  Completeness4/5

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

  The description covers the destructive nature, confirm-gated workflow, and reversibility, which are the key contextual concerns for a cancel operation. No output schema exists, so return details are not described, but the dry-run preview is mentioned. A slightly more detailed preview description could push this to 5, but it is sufficiently complete for invocation.

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

  Parameters4/5

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

  Schema coverage is 100% for both parameters, and the description adds further meaning by explaining the confirm parameter's role in dry-run vs. actual cancellation. The event_id parameter is already described in the schema with its source (evite_list_events), so the description adds value beyond the schema.

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

  Purpose5/5

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

  The description opens with a specific action, 'Cancel an Evite event,' and clarifies 'also used to delete a draft.' This distinguishes the tool from siblings like evite_list_events, evite_get_event, and evite_create_event, and explicitly names evite_reinstate_event as the reversal tool, making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  Clear usage guidance is provided: the tool is confirm-gated ('without confirm:true this returns a dry-run preview and cancels nothing') and reversible via evite_reinstate_event. It doesn't explicitly list exclusions or when-not-to-use, but the context is sufficient for an agent to decide when to invoke it.

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

• evite_update_eventA
  4.6/5.0
  Behavior5/5

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

  The description discloses critical behavioral traits: confirm-gated dry-run preview, no action without confirm, and partial update semantics (only passed fields change). This adds value beyond the readOnlyHint=false annotation by detailing the mutation's safety mechanism and side effects. There is 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.

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary action, and immediately followed by the most important caveat. Every word earns its place, with no filler or repetition of schema details. This is exemplary conciseness.

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

  Completeness4/5

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

  Given 100% schema coverage, the description focuses on the only missing context: the confirm-gating behavior and partial update semantics. It mentions the dry-run preview output, which partially covers the lack of an output schema. It does not describe the exact preview format, but that is a minor gap for an edit tool. Overall, it is complete enough 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.

  Parameters4/5

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

  The schema already provides 100% parameter descriptions, so baseline is 3. The description adds collective parameter semantics: 'only the fields you pass change' clarifies that all parameters are optional for partial updates. It also reinforces the confirm parameter's purpose, which is already in schema but is critical enough to warrant emphasis.

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

  Purpose5/5

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

  The description clearly states a specific verb and resource: 'Edit an existing Evite event'. It also distinguishes this from sibling tools like evite_create_event and evite_cancel_event by specifying 'existing event' and noting that only passed fields change. This is unambiguous and precisely scoped.

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

  Usage Guidelines4/5

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

  The description implies usage for modifying an existing event and the confirm-gated workflow is clearly explained. It does not explicitly name alternatives, but the sibling tool names and the 'existing event' phrasing make the intended context obvious. The confirm:true requirement is a crucial usage guideline that is clearly stated.

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

• evite_reinstate_eventA
  4.7/5.0
  Behavior5/5

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

  Beyond the annotations (readOnlyHint=false, idempotentHint=true), the description discloses the dry-run preview behavior and that confirm:true is required to actually change anything. This is valuable behavioral context not present in the structured data.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary purpose and inverse relation, followed by the key behavioral gate. Every sentence earns its place without redundancy.

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

  Completeness5/5

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

  For a tool with only two parameters and no output schema, the description covers purpose, the prerequisite (previously-cancelled event), and the critical confirm-gate behavior. It is complete for effective selection and invocation.

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

  Parameters4/5

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

  Schema coverage is 100% with both parameters documented, so the description adds marginal value. However, it reinforces the meaning of confirm by explaining the dry-run behavior, which goes slightly beyond the schema description.

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

  Purpose5/5

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

  The description uses a specific verb 'Reinstate' with a clear resource 'previously-cancelled Evite event' and explicitly positions it as the inverse of evite_cancel_event, which distinguishes it from sibling tools.

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

  Usage Guidelines4/5

  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 reinstating cancelled events and includes the critical confirm-gated behavior. It does not explicitly name alternatives, but the inverse-of relation and confirm-gate instructions give sufficient guidance.

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

• evite_send_messageA
  4.7/5.0
  Behavior5/5

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

  The description discloses key behaviors beyond the readOnlyHint annotation: it actually notifies the guest, is sent as the host, uses Firebase rather than REST, and is confirm-gated with a dry-run preview. This is rich, non-redundant context.

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

  Conciseness5/5

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

  Three sentences, front-loaded with the primary action, then a constraint, then the confirm behavior. No filler; every sentence provides necessary information.

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

  Completeness5/5

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

  The description is complete for a mutation tool: it explains the purpose, the sender/authorization constraint, the delivery mechanism, and the confirmation requirement. Given the rich schema and annotations, nothing important is missing.

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

  Parameters4/5

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

  Schema covers 100% of parameters, so baseline is 3. The description adds meaning to the confirm parameter by explaining that without confirm:true, the tool returns a dry-run preview and sends nothing—this goes beyond the schema's simple 'Must be true to proceed.'

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

  Purpose5/5

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

  The description opens with a specific verb+resource+scope: 'Send a private message to one Evite event guest.' It clearly distinguishes from siblings like evite_broadcast (multiple guests) and evite_list_messages (reading messages) by emphasizing 'one guest' and 'private message.'

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

  Usage Guidelines4/5

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

  Provides clear contextual guidance: only the host can use it, and confirm=true is required. This effectively tells the agent when the tool is applicable and what prerequisite must be met, though it does not explicitly name alternatives or exclusions.

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