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

The description clarifies that this registers guests (a side effect) rather than sending a soft invite, and that it requires confirmation before execution. This goes beyond the annotations (which don't indicate idempotency or confirmation) and helps the agent understand the tool's behavior without contradicting the provided hints.

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

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

Two sentences with no redundancy. The first sentence states purpose and key capabilities, the second gives actionable UX guidance. Every word earns its place, and critical information is front-loaded.

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

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

For a mutation tool with confirmation, the description covers the essential workflow (confirm before adding) and distinguishes from send_invites. While it doesn't mention return values or error handling, those are less critical given no output schema and the tool's direct nature. The guidance to show a summary before confirmation fills a key contextual gap.

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

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

Schema description coverage is only 43%, so the description partially compensates by referencing tickets, status, and email choice. However, it doesn't elaborate on the guests array structure, registration_answers, or the specific interaction between ticket and tickets parameters beyond what the schema descriptions already say. It adds some meaning but not full compensation for the coverage gap.

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

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

The description states a specific action (add guests), a resource (guests to an event), and key attributes (tickets, approval status). It explicitly contrasts with 'soft invite' to distinguish it from sibling tools like send_invites, making its purpose unambiguous.

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

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

The description differentiates this from sending a soft invite, implying when to use it (direct registration) versus alternatives. It also instructs to show event, recipient count, status, ticket assignment, and email choice before confirmation, providing clear usage context, though it doesn't explicitly name sibling tools or state 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 signal mutation and non-idempotency, and the description adds the confirmation requirement and the host/check-in staff scope. It does not disclose duplicate handling, permission requirements, or side effects on existing roles, but it does not contradict 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 a single concise sentence with no filler. The action, target, and confirmation precondition are all front-loaded and every word adds value.

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

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

For a six-parameter mutation tool with no output schema and very low schema coverage, this description is too thin. It omits the meaning of access_level values, how name and email are used, and what happens on duplicate additions. The confirmation requirement is mentioned but not explicitly tied to the confirmed parameter.

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 only 17%, and the description does not explain most parameters such as event_id, email, access_level, is_visible, or name. Only confirmed has a schema description. The phrase 'host or check-in staff member' hints at access_level but does not map parameters explicitly, so the description fails to compensate for low 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 uses a specific verb ('Add'), names the resource ('a host or check-in staff member'), and names the target ('to an event'). It clearly differentiates from sibling tools like update_host and remove_host. The precondition 'after explicit confirmation' adds useful precision.

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 this tool: adding hosts or check-in staff to an event, and only after explicit user confirmation. It does not explicitly contrast with update_host or remove_host, so it lacks full when-not/alternatives 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?

The description adds meaningful behavioral context beyond the annotations: 90-per-run rate-limit headroom, safe rerun/resume behavior, and the fact that email notification is a decision point. It aligns with the idempotentHint and does not contradict any annotation.

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

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

Three sentences carry all essential information with no filler. The most important operational constraint (90 per run) is front-loaded, and the prerequisite and resume behavior follow logically.

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 that there is no output schema, the description still tells the agent the stopping condition ('resume_required is false'), the precondition for invocation, and how to resume large operations. That is sufficient for a 5-parameter mutation tool.

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

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

The description supplements the 60% schema coverage by explaining the per-run 90-approval cap (max_approvals), the confirmation requirement (confirmed), and the email notification choice (send_email). It does not add much for event_id, but that parameter is self-explanatory and minimally constrained in the schema.

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

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

The description uses a specific verb ('Approve'), a clear resource ('currently waitlisted guests'), and a concrete constraint ('up to 90 per run'). This makes the tool's purpose unambiguous and easily distinguishable from sibling tools like add_guests, send_invites, or update_guest_status.

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

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

It explicitly states when the tool may be called: only after showing the event, waitlisted guest count, and email choice, and after explicit user confirmation. It also gives resumability guidance ('rerunning the tool until resume_required is false'), so the agent knows how to handle large waitlists safely.

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

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

Annotations already indicate this is a non-read-only, non-idempotent mutation, and the description's 'Create' wording is consistent. It adds the useful confirm-before-calling constraint, but does not disclose response behavior, side effects beyond creation, or whether the event is immediately published.

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 short and front-loaded: the action is stated first, followed by the important confirmation requirement. The first sentence is slightly redundant with the title, but the overall structure is efficient.

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

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

For a complex tool with 15 parameters, nested objects, and no output schema, this description is too sparse. An agent gets little guidance on optional fields, expected return value, or post-creation behavior, and the low schema coverage makes that gap more serious.

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 only 7%, so the description needed to compensate by explaining the many parameters. It mentions event name, date/time, timezone, and details, but leaves most of the 15 parameters—such as visibility, max_capacity, waitlist_status, and geo_address_json—unexplained.

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

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

The description clearly identifies the action as creating a Luma event, using a specific verb and resource. It is naturally distinguishable from sibling tools like update_event and delete_event, though it does not explicitly contrast itself with them.

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

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

The description gives a clear precondition: call only after the user has explicitly confirmed the event name, date/time, timezone, and details. It does not mention alternatives like update_event, but the confirmation gate is explicit and actionable.

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

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

Annotations already indicate a non-read-only, non-idempotent, non-destructive create operation. The description adds valuable behavioral context by requiring explicit confirmation before acting and by directing the agent to review key attributes prior to confirming. This goes beyond what the annotations alone 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 short sentences deliver the core action, the conditional confirmation gate, and a compact review checklist. No filler words are present, and the most important operational instruction is front-loaded.

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

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

With 14 parameters, low schema coverage, and no output schema, the description is not sufficient for an agent to reliably construct the call. Key details about price representation, flexible-price semantics, sale date formats, capacity requirements, and return behavior are absent.

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

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

Schema description coverage is only 7%, so the description must compensate. It names conceptual areas like price, currency, visibility, approval, sale dates, and capacity, which map to several schema parameters. However, it does not explain units, constraints, or relationships such as cents being in minor currency units, how free/paid/flexible interact, or which fields are required.

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 clear action ('Create') and resource ('ticket type'), and further specifies the variants: free, paid, or flexible-price. This distinguishes it from sibling ticket-type tools like get_ticket_type, update_ticket_type, and delete_ticket_type.

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 that this tool must only be used after explicit user confirmation and instructs the agent to review the event, price, currency, visibility, approval, sale dates, and capacity before confirming. It does not name alternatives or exclusions, but the confirmation gating is strong usage 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?

Although annotations already mark destructiveHint=true, the description goes further by explaining irreversibility, guest notification, and the non-destructive nature of the preview call. These details provide context beyond the structured annotations.

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

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

Three sentences with no filler. The key preview/confirm workflow is front-loaded, followed by the irreversible consequence, then the exact confirmation conditions. Every sentence contributes critical 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 description fully covers the two-phase deletion workflow, the irreversibility, and the refund decision. With no output schema, it still tells the agent what the preview returns (event details, guest count, refund-required status), making the tool self-sufficient.

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 67%, and the description enriches both confirmed and should_refund parameters: confirmed maps to preview vs. permanent deletion, and should_refund is tied to paid events and user confirmation. event_id is obvious from the tool's purpose.

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

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

The description states a specific action ('preview or permanently cancel and delete') on a specific resource ('one Luma event'), making it unambiguous what the tool does. It also distinguishes the destructive final action from the non-destructive preview mode.

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 explicit sequencing: call with confirmed=false first, then call with confirmed=true only after explicit user confirmation. It also clarifies the conditional use of should_refund for paid events, leaving little room for incorrect invocation.

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 adds useful behavioral context: Luma may refuse deletion when tickets have been sold or when this is the last visible ticket type. It also clarifies that preview is non-mutating and verifies ownership, which helps the agent anticipate real-world outcomes.

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

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

Three short sentences with no filler: the first front-loads the action, the second describes the preview behavior, and the third gives deletion caveats. Every sentence earns its place.

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

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

The definition covers the core workflow—preview before deletion, ownership verification, and refusal conditions—and the confirmed parameter is documented in the schema. It does not describe the response format, but there is no output schema and the preview's 'shows its exact settings' gives a reasonable expectation.

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

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

Schema coverage is only 33% with both ID parameters undocumented, but the description partially compensates by stating the ticket type 'belongs to the event' and that preview shows 'exact settings'. It does not explain how to obtain or format event_id and event_ticket_type_id, leaving the IDs to be inferred from their names.

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 'Preview or delete one ticket type', giving a specific action plus a precise resource, and immediately explains the tool's dual behavior. It is clearly distinct from sibling tools like list_ticket_types, get_ticket_type, create_ticket_type, and update_ticket_type because it centers on deletion with an optional preview.

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 usage: a preview verifies event ownership and settings, and deletion may be refused under certain conditions. However, it never explicitly contrasts this tool with get_ticket_type or list_ticket_types for pure inspection, nor states when not to use it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety and external-data expectations. The description adds only 'complete details,' which hints at the response breadth but provides no explicit behavior about missing events, freshness, or response format.

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, tightly worded sentence with no filler. It front-loads the action and resource and does not repeat information already present in 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 single-parameter retrieval tool, the description and schema are enough to construct the call. However, with no output schema, the description does not clarify what 'complete details' means, and the openWorldHint suggests external mutation but no re-fetch guidance is provided.

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 0%, and the description does not add meaning to event_id beyond the schema. Although the parameter is simple and self-named, the description should have compensated for the lack of schema descriptions and did not.

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 the specific operation 'Get' and the resource 'Luma event', and qualifies the action as retrieving one event, which distinguishes it from listing or mutating events. The description is immediately understandable and maps directly to the tool's name and title.

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

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

The phrase 'for one Luma event' implies this is for single-event retrieval, while the sibling list_events suggests the plural counterpart, but the description does not explicitly say when to choose this over list_events or any alternatives. No exclusions, prerequisites, or fallbacks are mentioned.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read. The description adds context about the response containing personal information and ticket-order details, which is useful but not extensive. No contradiction with annotations.

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

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

Two concise sentences with no filler. The core capability and return content are front-loaded, and 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 read-only get tool with no output schema, the description adequately conveys what is returned (personal info and ticket-order details) and the identifier options. It is complete enough for an agent to call it correctly, though it could mention the response shape more explicitly.

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 50% (only 'id' is documented). The description repeats the id types but adds nothing about 'event_id.' It does not compensate for the missing schema description, leaving the second required parameter under-explained.

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

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

The description clearly states the action ('Get') and the resource ('complete details for one event guest'), and specifies the supported identifier types. It distinguishes from list_guests by mentioning 'one event guest,' but does not explicitly route to alternatives.

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

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

No guidance is provided on when to use this tool versus siblings like list_guests or update_guest_status. The purpose implies a single-guest lookup, but there is no explicit when-to-use or when-not-to-use instruction.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so there is no contradiction. The description does not add behavioral context beyond the annotations, such as return format, error behavior, or implications of the open-world hint, but the safety profile is already covered.

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

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

The description is a single concise sentence that front-loads the verb and resource. There is no filler, redundancy, or unnecessary context.

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

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

For a one-parameter, read-only getter with a readOnlyHint annotation, this description is largely sufficient: it names the operation, resource, and lookup key. It does not describe the return shape or not-found behavior, but these are minor gaps for such a simple tool.

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

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

The schema provides 0% description coverage for the single parameter, so the description must compensate. It identifies event_ticket_type_id as the ticket-type ID, but that largely restates the property name and adds no details about where the ID comes from or any format expectations.

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

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

The description states a specific verb ('Get'), a precise resource ('one ticket type'), and a selection criterion ('by its ticket-type ID'). This immediately differentiates it from siblings like list_ticket_types and the mutation-focused ticket-type tools.

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

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

The description implies when to use it: when the agent has a specific ticket-type ID and needs a single record. However, it does not explicitly name alternatives or say when not to use it, such as 'use list_ticket_types to fetch all ticket types.'

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 adds meaningful behavior beyond the annotations: duplicate removal, suppressing guests already on the target event, batching, soft invitations, and privacy-preserving aggregate previews. These details clarify the tool's side effects and safety model. It could also mention batch sizes, rate limits, or irreversibility, but current disclosure is strong.

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

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

The description is two sentences with no filler. The core behavior is front-loaded, and the two-phase confirmed=false/true usage is placed immediately after. Every sentence earns its place.

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

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

The two-step preview/approval workflow is well covered and the deduplication behavior is explained. However, with no output schema, the description does not state the return format beyond 'aggregate counts,' nor does it address the optional message parameter or the exact consequences of sending after confirmation. These are notable gaps for a tool that sends invitations.

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

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

Schema coverage is only 20%, so the description must compensate. It partially does by referencing source/target events and 'selected guest statuses' for source_statuses, and it clarifies the confirmed false/true flow. However, it does not explain message, the default for source_statuses, or ID expectations, leaving clear gaps.

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+resource workflow: build an audience from guest statuses on a source event, remove duplicates, and send soft Luma invitations. It clearly differentiates this tool from sibling invite/send tools by the 'from another Luma event' and deduplication behavior.

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 explicit invocation guidance: call with confirmed=false first to preview, then call with confirmed=true only after explicit approval. It does not explicitly name alternative sibling tools or state when not to use this tool, which prevents a 5.

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

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

Annotations already cover the read-only and open-world nature of the operation, so the description does not need to restate safety. It adds useful authorization/source context ('configured API key'), but it does not disclose behavioral details like the default status filter or pagination behavior.

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

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

The description is a single front-loaded sentence with no filler. Every word contributes to identifying the action, resource, and data source.

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 five-parameter list operation with no output schema, the description is minimally adequate but leaves return shape, default status, and cursor semantics unstated. It relies heavily on the schema and agent inference rather than being self-sufficient.

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

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

The schema documents after, before, and status, but pagination_limit and pagination_cursor have no descriptions. The tool description adds no parameter-level meaning and does not compensate for the undocumented pagination semantics at 60% schema coverage.

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

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

The description clearly identifies the action ('List'), the resource ('events'), and the data source ('calendar attached to the configured API key'). It is not a tautology and naturally distinguishes this tool from event mutation siblings like create_event and 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?

The description implies this tool is for listing events from the configured API key's calendar, but it does not explicitly contrast it with alternatives such as get_event for a single event, list_guests, or registration_summary. There is clear context but no when-not-to-use guidance.

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

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

Annotations already mark the operation read-only and open-world, and the description adds a meaningful warning that guest data may include personal information. This goes beyond the structured annotations by giving the agent a data-handling constraint. No contradictory or missing behavioral disclosure is evident.

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

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

The description is two short sentences with the core action front-loaded and no filler. The privacy note is relevant and placed second, so it does not obscure the main purpose.

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

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

For a list operation with no output schema, the description communicates the core action but leaves return-format expectations unspecified, and it does not mention how approval_status filtering or pagination cursors behave. The annotations and schema carry some of this weight, so the description is minimally adequate but not complete.

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

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

Schema description coverage is 0%, and the description does not explain approval_status, pagination_limit, or pagination_cursor. It only implies the event_id parameter via 'for an event.' The enumerated values and defaults are visible in the schema, but the free-text description contributes almost no semantic value for the filter and pagination 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 uses a specific verb and resource — 'List guests for an event' — which clearly distinguishes the operation from single-guest retrieval (get_guest) and event listing (list_events). The event scope is stated up front, matching the required event_id parameter.

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

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

The only usage guidance is a privacy constraint: 'use only for event operations requested by the user.' It does not state when to prefer this over siblings such as get_guest, update_guest_status, or add_guests, nor does it specify exclusions. Usage context must be inferred from the name and title.

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 openWorldHint, so safety and external variability are covered. The description adds the optional hidden-ticket behavior, which is useful, but otherwise does not disclose pagination, ordering, or return format. 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?

A single, dense sentence with no filler. The primary operation and the optional modifier are front-loaded and each 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 two-parameter read-only list tool, the description covers the essential scope and the one notable flag. It lacks explicit mention of output shape or pagination, but these are not critical given the tool's low complexity and annotation coverage.

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 0%, so the description must compensate for both parameters. It does: 'for an event' maps directly to event_id, and 'optionally including hidden ticket types' maps to include_hidden. It does not restate the default or format but gives enough semantic grounding.

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 the specific verb 'List' and resource 'ticket types for an event', which clearly distinguishes it from singular get_ticket_type and mutating create/update/delete_ticket_type. 'All ticket types' reinforces the collection 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?

Implied usage is clear: call this when you need the full set of ticket types for a given event. However, it does not explicitly state when to prefer get_ticket_type for a single type or mention any exclusions, so the routing is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context that the aggregation spans all guest pages (handles pagination internally) and that it deliberately withholds guest identities. 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?

One sentence, no filler, with the essential scope and privacy guarantee front-loaded. 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 single-parameter, read-only summary tool, the description covers the action, scope, and privacy behavior. The lack of an output schema is offset by the description's mention of approval states and check-ins, though exact return shape is still unspecified.

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

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

Schema coverage is 0%, but the single parameter event_id is intrinsically meaningful and the description reinforces it by scoping the counts 'for an event'. The description compensates adequately for the lack of schema documentation.

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

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

Description is a clear verb-object construction: 'Count guest approval states and check-ins for an event across all guest pages'. It defines both the action and the resource, and the qualifier 'without returning guest identities' sets it apart from sibling tools like list_guests and get_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?

No explicit 'use when' or 'instead of' instructions are present, but the phrasing implies it is the aggregate, identity-free counterpart to list_guests and get_guest. The 'across all guest pages' and 'without returning guest identities' provide contextual cues, but no exclusions or alternatives are named.

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

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

The annotations already flag destructive behavior, and the description adds valuable context: the non-mutating preview mode, exact email resolution, and the nuanced handling of visible vs. hidden hosts including the unverified marker. This meaningfully enriches the agent's understanding 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?

Two sentences, front-loaded with the core action and mode distinction. Every clause adds useful information: preview behavior, exact email resolution, and host visibility handling. No wasted words.

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

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

For a mutating tool with no output schema, the description covers the important operational details: preview vs. confirmation, host visibility, and unverified markers. It does not describe response shape or error conditions, but the core decision-making context is present.

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

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

Schema description coverage is only 33%, so the description must compensate. It does clarify the 'confirmed' parameter and preview behavior, but it adds little detail about event_id or email beyond what the schema field names already imply. Partial compensation only.

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

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

The description uses a specific verb and resource: 'Preview or remove one host from an event.' It clearly separates the two modes (preview vs. actual removal) and distinguishes this tool from siblings like add_host and update_host by focusing on removal.

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 on when to use the tool: when you need to remove a host, with a safe preview beforehand. It explains the confirmation step but does not explicitly name alternatives or state when not to use it, so it stops 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 provide readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds that this is a 'soft' invitation, meaning it's not a forced registration, and mentions it sends via email and SMS when linked. It does not disclose side effects like whether invitations can be sent only once, if there are rate limits, or what happens if a guest is already invited. However, the annotations already indicate it's not read-only and not destructive. The description does add a confirmation requirement shown to the user, which is a behavioral trait not in annotations. Overall, it adds some context (soft, channels, confirmation step) beyond the annotations, but it doesn't go deep into edge behaviors. With openWorldHint=true, it's expected that the tool might have external side effects, and the description mentions SMS and email sending, which covers that. It's average: better than nothing but not rich on behavioral details like idempotency or failure modes.

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, front-loaded with the primary action and channels, and then explains the flow including a confirmation step. Every sentence earns its place: the first states what it does, the second explains the user experience and safety measure (confirmation). No padding or redundancy. It is concise and well-structured.

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 has 4 parameters, no output schema, and moderate complexity (sending emails/SMS), the description covers the key aspects: the invitation is soft (recipients choose), channels (email/SMS), and the confirmation step that requires `confirmed=true`. It mentions showing event, recipient count, and message before confirmation, which covers the important interaction. It does not mention how to construct the `guests` array in detail, but the schema handles that. It doesn't mention any limitations like invite expiration or SMS only if linked, which is mentioned. The description is fairly complete for a tool that sends invites, given the schema provides the required parameters. It lacks details on response or success/failure behavior, but since no output schema exists, the description could have hinted at what happens on success, but that's not strictly required. It's a minor gap. Overall, it's above average because it covers the workflow and key constraints.

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

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

Schema coverage is only 25% because only the 'confirmed' parameter has a description ('Must be true only after explicit user confirmation.'). The description adds context about the `guests` array (that they choose whether to register) and mentions 'Show the event, recipient count, and message before asking for confirmation,' which relates to `event_id`, `guests`, and `message`. However, the description does not add details about the `guests` object structure (e.g., name is optional, email required) beyond what the schema provides. The schema already has constraints like maxLength on `message` and maxItems on `guests`. The description does not clarify the `event_id` format. With 25% coverage, the description partially compensates by explaining the flow but not all parameters. It adds value for the confirmation mechanism and the soft-invite semantics, but it doesn't explain the purpose of `message` beyond being shown. Since the coverage is low, the description should have done more to describe each parameter's intent. It's adequate but not thorough.

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 'Send soft event invitations by email and, when linked to a Luma account, SMS.' It specifies the verb (send), the resource (event invitations), and the delivery channels. It distinguishes itself from siblings like 'add_guests' (which likely just adds guests without sending invites) and 'invite_guests_from_event' (which might be a different flow). The description implies a distinct purpose that is not a tautology.

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

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

The description does not explicitly name alternative tools or state when *not* to use this tool versus siblings. However, it implies that this is for 'soft' invitations, which hints at a non-committal, non-forced invitation style, differentiating from a hard invite or waitlist approval. The context of siblings (e.g., 'invite_guests_from_event' suggests another invitation route) is there, but the description doesn't explicitly contrast. It gives a clear scenario: 'Invited people choose whether to register,' which implies a voluntary registration flow. It could have been stronger with explicit alternatives or conditions, but it's adequate for basic usage.

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

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

Annotations already indicate a non-read-only, non-destructive, idempotent mutation. The description adds the confirmation prerequisite, which is useful behavioral context. It does not disclose partial-update semantics, side effects like notification behavior, or how fields combine, leaving the agent to infer those from parameters.

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 action first and the critical confirmation condition second. There is no filler, and every word contributes to operational clarity.

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

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

The tool has 17 parameters, no output schema, and zero parameter descriptions, so the description carries a heavy burden. It provides only a one-line action plus confirmation rule, leaving many unknowns: which fields are mutually exclusive, how confirmed interacts with other fields, what the update response is, and whether the API does a partial or full replace. This is insufficient for such a complex mutation.

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 0%, and the description does not compensate. With 17 parameters, several require explanation (confirmed, geo_address_json, suppress_notifications, max_capacity), but the description only refers generically to 'selected fields'. Parameter names and enums provide some clue, but the agent cannot know required semantics like the confirmation flag's exact role or how partial updates merge.

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

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

The description names the verb 'Update' and the resource 'Luma event', and clarifies it updates 'selected fields', distinguishing it from create/delete/get events. It does not enumerate which fields, so it is slightly less crisp than a definition that lists them, but it is unambiguous about the 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 explicit when-to-use guidance: only after showing the changes and receiving explicit confirmation. This handles the primary safety concern for a mutation tool. It does not contrast with siblings like create_event or delete_event, but those are sufficiently distinct by name that exclusionary guidance is less critical.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds valuable behavioral context by explaining that preview mode is non-mutating and that certain status changes force refund decisions. It does not contradict the annotations and meaningfully enriches them with the refund-required condition.

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 dense sentences deliver the essential tool behavior, the preview contents, and the most important constraint without fluff. The key idea — preview or update — is front-loaded, and every clause contributes useful 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 7-parameter mutation tool with no output schema, the description covers the preview behavior and the refund requirement, but it omits the message parameter, send_email behavior, and explicit update confirmation flow. An agent could call the tool correctly for simple cases but may miss important side effects without checking parameters individually.

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 only 29%, so the description carries some burden. It indirectly maps to should_refund ('refund choice') and send_email ('notification settings'), and clarifies the preview output, but it does not explain message, event_id, status enum meanings, or confirm the confirmation flow beyond what is already in the schema.

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

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

The description opens with a specific verb and resource — 'Preview or update one guest's status' — and clearly scopes the tool to a single guest's status. The focus on 'status' naturally distinguishes it from siblings like update_guest_tickets, and the added preview mode clarifies an important dual behavior.

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 a preview-then-update workflow and states a critical rule: moving an approved paid guest to a non-approved status requires an explicit refund choice. However, it does not explicitly say when to use this tool versus alternatives like approve_waitlisted_guests or update_guest_tickets, and it lacks any when-not-to-use guidance.

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

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

The description goes beyond the annotations by specifying concrete behavioral consequences: adding tickets may exceed capacity, removing tickets invalidates them without refund, and Luma sends in-app notifications even when email is disabled. These details are not present in the annotations (which only indicate destructiveHint=true, readOnlyHint=false, etc.) and give the agent a clearer picture of side effects. No contradictions with annotations are present.

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

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

The description is three sentences long and front-loads the core action ('Preview or add and remove tickets for one guest') before adding essential caveats. Every sentence provides distinct, non-redundant information: the action, the capacity/refund implications, and notification behavior. There is no filler or repetition, making it efficient and easy to parse.

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 that there is no output schema, the description adequately covers the operational context: it explains the two modes (preview vs. actual changes), the nature of add/removal, capacity limits, monetary consequences, and notification behavior. It also mentions the single-guest scope. While it does not cover every edge case (e.g., maxItems limits, which are in the schema) or authentication prerequisites, the core information needed to invoke the tool correctly is present. It falls slightly short of being fully complete due to the absence of guidance on handling partial failures or response expectations, but it is sufficient for most agent use.

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

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

Schema coverage is only 33%, with descriptions available only for guest_id and confirmed. The description compensates by explaining the overall behavior of key parameters: 'added tickets are complimentary administrative tickets and may exceed capacity' clarifies tickets_to_add; 'removed tickets are invalidated without a refund' clarifies ticket_ids_to_remove; and 'sends an in-app notification even when email is disabled' clarifies send_email. This adds meaning beyond the bare schema, though it does not provide per-parameter syntax or constraints (which the schema partially covers). The description effectively bridges the coverage gap.

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

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

The description opens with a precise, action-oriented statement: 'Preview or add and remove tickets for one guest.' It names the verb (preview/add/remove), the resource (tickets), and the scope (one guest), making it unambiguous. It also distinguishes itself from sibling tools by focusing specifically on per-guest ticket management, which no sibling addresses. The additional details about complimentary admin tickets clarify the nature of the 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 does not explicitly mention when to use this tool versus alternatives or when not to use it. It implies usage via the 'preview' vs 'apply' distinction (confirmed=false for preview) and clarifies that added tickets are complimentary admin tickets that may exceed capacity, which signals a specific use case. However, it lacks any comparison to sibling tools or exclusion criteria, leaving the agent to infer the appropriate context from the tool name and description.

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

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

Annotations already mark the tool as non-read-only, idempotent, and non-destructive. The description adds meaningful behavioral constraints: confirmation is required, and the event creator's access level is immutable. These details go beyond what the annotations express.

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

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

Two sentences with no filler. The operation is stated first, followed by the most important exception. Every word adds value.

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

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

For a 5-parameter mutation with low schema coverage, the description omits some useful details: whether at least one of access_level or is_visible must be supplied, what 'none' access level means, and what the result of the update is. However, it does cover the critical confirmation and creator-exception constraints.

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 only 20%, putting more burden on the description. It does explain that access_level and is_visible are the update targets, but it leaves the meaning of the 'none' enum value and the identifying roles of event_id/email to inference.

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

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

The description clearly states the specific operation: updating a host's access level or public visibility on a Luma event. It distinguishes this from add/remove host operations by naming the exact fields that can be changed.

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

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

It provides clear context for use, specifically after explicit confirmation, and includes a hard exclusion: the event creator's access level cannot be changed. It does not explicitly name alternatives like add_host or remove_host, so some alternative routing is left implied.

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

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

The description adds meaningful behavioral detail beyond the annotations: it requires explicit user confirmation before updating and explains that nullable fields clear their current value. This complements the annotations, which already indicate this is a non-read-only, non-destructive, idempotent operation.

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

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

The description is two sentences with no fluff, and the key behaviors are front-loaded: partial update, explicit confirmation, and null-clearing semantics. Every sentence contributes essential 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 14 parameters and no output schema, the description is lean. It captures core update semantics but does not describe the response format, error conditions, or constraints related to parameters such as cents/currency pairing, leaving some context for an agent to infer.

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

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

With only 7% schema description coverage, the description carries important parameter semantics: 'Nullable fields clear their current value' explains the behavior of nullable parameters, and 'Update selected fields' implies omitted fields remain unchanged. It does not document every parameter individually, but it covers the most consequential update semantics.

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

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

The description clearly states the action is 'Update' and the resource is a 'ticket type', which distinguishes it from create/delete/get ticket type tools. It specifies that only selected fields are updated, further clarifying its partial-update purpose, though it does not explicitly name sibling alternatives.

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

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

The phrase 'after explicit confirmation' provides a clear prerequisite for when this tool may be invoked, and 'update selected fields' implies it is for modifying an existing ticket type rather than creating one. It does not explicitly mention alternatives or exclusions, but the invocation condition is concrete.

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 and openWorldHint annotations already indicate a safe, read-only operation dependent on external configuration. The description adds that the tool validates a preconfigured API key and returns the authenticated user, but it does not disclose failure behavior when the key is missing or invalid, or what exactly the authenticated user object contains.

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 entire description is a single, efficient sentence that front-loads the action and result. Every word contributes meaning, with no redundant detail or filler.

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

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

For a parameter-less, simple verification tool with read-only annotations, the description fully explains its purpose and expected outcome. An agent has enough information to select and invoke it correctly without additional context.

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

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

The tool has zero parameters, so the schema is complete with 100% coverage and no parameter descriptions are needed. The description adds context about what is being verified, satisfying the baseline for parameter-less tools.

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

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

The description uses a specific verb ('Verify') and resource ('configured Luma API key') and clearly states the result ('return the authenticated user'). It is easily distinguished from the sibling CRUD tools, none of which perform connection or credential verification.

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 establishes this as the tool for checking Luma connectivity and authentication, which is distinct from all sibling operations. It does not explicitly state when-not-to-use or name alternatives, but no sibling tool offers this capability and the intended use is obvious from the context.

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