Aisle

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: the record is created unpriced with no payment requirement, and the call requires authentication plus an Aisle membership. It does not explain duplicate-name handling, which would have pushed it to a 5.

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

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

Four short sentences with the core action and required inputs front-loaded and no filler. Slightly list-like, but every sentence carries information an agent needs.

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 an 11-parameter mutation tool with no output schema and annotations covering the safety profile, the description covers required inputs, auth/membership gating, and the unpriced nature of the created room. Only edge behavior (duplicates, multi-wedding selection) is left to the schema, which is acceptable.

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

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

Schema description coverage is 100% across all 11 parameters, so the schema already documents names, dates, capacity, and the multi-wedding condition on wedding_id. The description only restates that property_name and room_name are required and adds the no-payment attribute, so the baseline 3 applies.

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

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

States a specific verb and resource ('Adds an unpriced room under a named property in the selected wedding'), and the qualifier 'unpriced' distinguishes it from pricing-related siblings. It is clearly separable from add_my_event, add_my_guest, and update_my_accommodation without opening any schema.

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

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

The description supplies prerequisites (sign-in, Aisle membership, required property and room names) but never states when to use this versus update_my_accommodation or list_my_accommodations. Usage is implied by the prerequisites rather than explicitly framed as when/when-not.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description adds a genuine behavioral fact not in the annotations: the sign-in and Aisle membership requirement needed to invoke it successfully. It stops short of explaining what the destructive hint means in practice (no delete/undo semantics on the created event).

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, no filler, and the core action and its field list are front-loaded ahead of the prerequisites. Every clause carries 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 9-parameter, non-idempotent mutation with no output schema, the description covers the action, the populated fields, and the auth gate, which is enough to call it correctly alongside a fully documented schema. It leaves the conditional wedding_id requirement and the ISO date format to the schema, which is acceptable given 100% 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 100%, so all nine parameters are self-documenting; the baseline is 3. The description lists the same field set as the schema without adding format rules (ISO for date/end_time), enum constraints for type, or the conditional rule for wedding_id exposed in the schema.

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

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

States a specific verb+resource ('Creates an event in the selected wedding') and enumerates the fields it populates (name, type, date, time, venue, dress code, description). An agent can distinguish it from add_my_accommodation, add_my_guest, and especially update_my_event, whose write semantics are modifying rather than creating.

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

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

It gives prerequisites ('Requires sign-in and an Aisle membership') and scopes the target to 'the selected wedding', which is real guidance. However it never states when to use this versus update_my_event, nor when to supply wedding_id explicitly beyond what the schema already says. Usage is implied rather than spelled out.

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

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

Beyond the annotations (destructive, non-idempotent), it discloses auth requirements (sign-in + Aisle membership), the ordering constraint for age confirmation, and explicitly unsupported fields (guest notes, dietary details) – rich context the structured fields do not carry.

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

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

Front-loads the action and packs prerequisites, required/optional fields, and unsupported data into three dense sentences with no filler; slightly crowded but every clause earns its place.

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

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

For a destructive mutation with no output schema, it covers authorization, sequencing, required vs optional inputs, and unsupported data. It does not describe what is returned on success or the effect of omitting wedding_id, a minor remaining 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 coverage is 100% (baseline 3), and the description still adds value by clarifying that first/last names are required, phone/email optional, that age_band is an explicit eligibility confirmation, and that age cannot be derived from names or relationships.

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

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

States a specific verb+resource ('Adds a guest to the selected wedding') and scopes it to the signed-in account's wedding, clearly distinguishing it from add_my_event, add_my_accommodation, and update_my_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?

Provides explicit sequencing prerequisites (age confirmation before collecting name/contact details) and notes age cannot be inferred from names or relationships. It does not, however, name the sibling alternatives (e.g., update_my_guest, list_my_guests) or when to prefer them.

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 safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false). The description adds genuine behavioral context beyond that: results are deduplicated, deterministic in ordering, and are suggestions rather than verified/registered hashtags. A note on cost, rate limits, or handling of sparse input would push this higher.

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

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

Two sentences, zero filler, and the core capability is front-loaded before the clarifier. Every clause earns its place.

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

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

With no output schema, the description usefully characterizes the return (deduplicated, deterministically scored, not an availability check). It doesn't mention that all six parameters are optional or what happens with no input, which is a minor gap for a tool with zero required parameters.

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

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

Schema description coverage is 100% and each of the six parameters already carries a per-field description, so the schema does the heavy lifting. The description merely names the same input categories without adding format, default, or interaction semantics beyond what the schema provides.

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?

Names a specific verb and resource ('Generates deduplicated wedding hashtag suggestions') and enumerates the inputs it draws from (partner names, surnames, year, place), plus the output ordering. It also fences off adjacent concepts ('not registrations or availability checks'), so an agent can distinguish it from the get_/list_ siblings without opening the schema.

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

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

The description implies the usage context (name-based hashtag ideation) and explicitly excludes two misinterpretations, but it never states when to reach for this tool versus a sibling or what prerequisites exist. No alternative is named, so the routing guidance is only implied.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely useful behavior: rounding up to bottles/cases, rule-of-thumb basis, no consumption guarantee, and an explicit non-action (does not purchase alcohol). It stops short of describing return shape or units, but that is a minor gap given annotation coverage.

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

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

Two tight sentences, front-loaded with what it does, followed by the important disclaimer. Every clause earns its place with no repetition of the schema.

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

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

No output schema exists, so the description carries the return burden; it covers rounding and the caveat that results are estimates, which is enough for an agent to use the tool correctly. It could say more about output structure (e.g., itemized bottles/cases) but nothing critical is missing.

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

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

Schema description coverage is 100%, so all five parameters (mix, crowd, hours, guest_count, champagne_toast) are already documented with defaults and enums. The description only references guest count, duration and drink mix generically and adds no syntax or formatting beyond the schema.

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

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

States a specific verb (estimates) and resource (wedding bar quantities) plus the inputs that drive it. It is clearly distinguishable from siblings like get_budget_estimate or get_cash_gift_suggestion.

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

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

Gives implied context (planning-rule-of-thumb estimate, does not purchase alcohol) but never states when to prefer this tool over alternatives such as get_budget_estimate, nor any prerequisites or exclusions. Usage must be inferred.

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 establish the safe read-only, idempotent, closed-world profile. The description adds real value beyond that: results contain category breakdowns and ranges, unsupported destinations behave differently, and figures are explicitly illustrative planning estimates rather than measured averages or supplier quotes — a meaningful accuracy caveat for a budgeting tool.

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

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

Five tight sentences, each carrying distinct information (estimate method, destination vs country sourcing, return contents, unsupported handling, disclaimer) with the core purpose front-loaded. Dense but without filler, though the disclaimer and coverage sentences could be marginally tightened.

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

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

With no output schema, the description compensates by explaining what comes back (category breakdowns, ranges, coverage information for unsupported destinations). For a four-parameter, fully annotated read-only estimator, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds the precedence relationship the schema only hints at: destination slug selects a destination-specific estimate, while country is the fallback when no slug is provided. It also reinforces that guest count and style tier are the estimate drivers.

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

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

States a specific verb (Estimates), resource (destination wedding budget), and the driving inputs (guest count and style tier). It is clearly distinguishable from adjacent estimators like get_alcohol_estimate or get_guest_travel_estimate.

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 effectively routes between input modes: a destination slug yields a destination-specific allowance, a country-only call yields a rough regional figure, and unsupported destinations return coverage info. It does not, however, explicitly compare itself to sibling estimators (alcohol, travel, who-pays), so the agent must infer when this tool is the right pick.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: results are illustrative US etiquette conventions rather than obligations, values are in USD, and the tool performs no money transfer.

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

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

Three short sentences, front-loaded with the return shape and followed by the two caveats that matter. Nothing is redundant or padding.

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

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

With no output schema, the description carries the burden of describing the return value and does so (low/typical/high range in USD), plus scoping disclaimers. Nothing an agent needs to call or interpret the tool is missing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters and their defaults. The description echoes the same dimensions (relationship, party, travel, wedding-party role) without adding format or constraint detail, so baseline 3 applies.

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

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

States a specific verb and resource ('Returns ... cash wedding gift range in USD') and names the determining inputs. It is clearly distinguishable from budget/payment siblings like get_budget_estimate or get_who_pays_split.

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

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

Usage is implied by the input dimensions and the closing disclaimer 'This tool does not transfer money,' which effectively rules out payment intent. However, it never states when to prefer this over adjacent siblings such as get_who_pays_split, so routing guidance 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 readOnly, idempotent, non-destructive, closed-world. The description adds genuine behavioral context beyond that: the output is a draft built from standard planning offsets, not confirmed vendor/venue/sunset schedules, which tells the agent how much to trust the result. It doesn't describe return format, but with annotations covering the safety profile this is solid.

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

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

Two tight sentences: the first states what it builds, the second states the key limitation. Zero filler and the purpose is front-loaded before the caveat.

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

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

For a read-only, no-output-schema generation tool with fully documented parameters, the description covers what an agent needs: what it produces and the caveat that timings are generic offsets rather than confirmed. Only the shape of the returned schedule is left unstated, which is a minor 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 100% and each of the three parameters is fully documented in the schema, including alternate time formats. The description only restates the parameter names at a high level, adding no format or edge-case detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource — builds a draft wedding-day schedule — and names the three inputs it keys on. It implicitly contrasts with the long-horizon get_planning_timeline sibling but never says so explicitly.

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

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

The description implies the use case (day-of schedule rather than long-term plan) but gives no explicit when-to-use versus get_planning_timeline or get_wedding_checklist. No exclusions or prerequisites are stated.

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

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful undisclosed context: matching is approximate, results include examples and an Aisle guide link, and the no-arg path returns a list rather than an error.

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

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

A single front-loaded sentence that covers the primary lookup, the fallback list mode, and the return contents with no filler. Every clause carries information an agent needs.

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

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

With no output schema, the description does the work of describing the return payload (definition, clothing examples, invitation wording, guide link), which is sufficient for a read-only lookup. Only the fuzzy-match failure behavior, e.g. what happens with a misspelled or unknown code, is left unstated.

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

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

Schema coverage is 100%, and the schema itself already states the parameter is optional and matched approximately, so the description adds essentially no parameter meaning beyond the structured field. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description names a specific verb and resource (returns a wedding dress code definition) and covers both operating modes: lookup by code vs. listing all codes. It does not, however, distinguish itself from the sibling get_invitation_wording, whose territory it partially claims by returning invitation wording.

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

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

Usage is implied through the conditional 'or lists the available dress codes when none is specified', which tells the agent how the absent-parameter case behaves. There is no explicit when-to-use guidance or pointer to an alternative such as get_invitation_wording for wording-only requests.

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 the safe read profile (readOnly, idempotent, non-destructive, non-open-world). The description adds real behavioral context beyond them: partial totals only include priced groups, unpriced guests and unsupported origins are reported separately, and it interprets the urlRestoresEstimate field. That is substantive disclosure the structured fields do not carry.

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

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

Four tightly-packed sentences, front-loaded with what is estimated and in what currency. Each sentence carries distinct information (currency, partial-total behavior, link-restore field, non-live caveat), so little is wasted, though the density is on the high side.

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

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

With no output schema, the description must cover return semantics, and it does: partial totals, separately reported unpriced guests, and the meaning of urlRestoresEstimate. The main remaining gap is that it never explains the shape of the returned link or units/per-guest breakdown.

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

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

Schema description coverage is 100%, so the baseline is 3. The description rises above it by clarifying that origins must be supported US metros (implying some cities return no price) and by noting unpriced/unsupported inputs are reported separately, which explains the semantics of the `groups`/`city` input in the result.

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

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

States a specific verb (estimates) and resource (round-trip flights and typical-stay lodging in USD for guest groups), clearly distinguishing it from siblings like get_budget_estimate or get_alcohol_estimate by domain. It never names an alternative sibling, so sibling differentiation is implied rather than explicit.

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

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

Usage is implied through scope constraints (supported US metros, supported destination slugs) and the caveat that estimates are not live fares or bookings. There is no explicit when-to-use vs. when-not-to-use guidance or routing to a related estimator tool.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds meaningful behavior: the no-scenario path returns option lists, and the output follows etiquette conventions rather than legal requirements, which sets expectations about content and tone.

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 primary action and followed by the discovery fallback. Nothing is wasted, though the etiquette/legal caveat is slightly tangential to the core call mechanics.

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 an 11-parameter, zero-required, read-only composition tool with no output schema, the description covers the main use and the fallback mode adequately. It could say more about which parameters matter for which scenarios, but nothing critical is missing for a correct invocation.

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

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

Schema description coverage is 100%, so all 11 parameters are already documented in the schema. The description references names, event details and reception wording generically, adding little beyond the field-level docs, so the baseline of 3 applies.

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

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

States a specific verb ('composes') and resource ('wedding invitation text') and scopes it to a hosting situation and formality. No sibling tool competes for this function, and an agent can distinguish it immediately from the other get_*/list_* utilities.

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

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

The description notes that omitting a scenario lists available options, which is a useful discovery hint, but it never states when to reach for this tool versus, say, get_dress_code_guide or other planning helpers, nor any prerequisite (e.g. names needed for certain scenarios). Usage is implied rather than prescribed.

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 establish readOnly, idempotent, non-open-world, non-destructive behavior, so the bar is lower. The description adds genuine value beyond them by disclosing the authentication requirement ('signed-in account') and an ownership/authorization boundary ('weddings the account can manage'), though it says nothing about empty-state or error behavior when no wedding is selected.

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, no filler, and the most important information (what is returned) is front-loaded ahead of the access constraint. Every clause earns its place.

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

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

For a single-parameter read tool with no output schema, the description usefully enumerates the returned fields and covers authorization, and rich annotations cover the safety profile. An agent has everything needed to invoke it correctly.

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

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

With one optional parameter and 100% schema description coverage, the schema already explains wedding_id and its conditional requirement. The phrase 'selected wedding' in the description implies a selection concept but adds no syntax or behavioral detail beyond the schema, matching the baseline for fully-documented 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?

States a specific verb (Returns) and resource (the signed-in account's wedding details) and enumerates the returned fields (partner names, date, location, venue), which helps separate it from update_my_wedding. However, it never explicitly distinguishes itself from nearest siblings like get_my_wedding_stats or get_venue_details, whose scope overlaps with 'location and venue'.

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 access constraint ('limited to weddings the account can manage') implies this is the authenticated account's own wedding, but there is no explicit when-to-use guidance nor any mention of when to prefer get_my_wedding_stats, get_venue_details, or update_my_wedding instead. Usage is inferable but not stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses that outputs are aggregates only, that identities and individual answers are excluded, and that authentication is required.

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

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

Three short sentences, each earning its place: what is returned, what is excluded, and the auth prerequisite. The core content is front-loaded in the first sentence.

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

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

With no output schema, the description carries the burden of describing return values and does so by enumerating the aggregate categories. It is nearly complete; only the behavior when wedding_id is omitted is unaddressed in the description (the schema hints at it).

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

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

Schema coverage is 100% and there is only one optional parameter, whose conditional requirement ('required when the account has multiple weddings') is fully documented in the schema. The description adds nothing further about wedding_id, so the baseline 3 applies.

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

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

States a specific verb and resource ('Returns aggregate wedding statistics') and enumerates the scope: guest totals by age band, RSVP counts, event counts, registry progress. The explicit exclusion of guest identities and individual event answers distinguishes it from list_my_guests and list_my_events without naming 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 implies when it applies (a summary view rather than per-record listing) and states the prerequisite 'Requires sign-in', but never names an alternative tool or an explicit when-not-to-use condition. Usage is inferable but not spelled out.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful output content categories (clothing, weather essentials, travel documents, practical supplies) but does not disclose return format, length, or generation logic.

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 sentence with zero waste, front-loading the verb, resource, and scoping dimensions. Every phrase contributes to explaining the tool's output.

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 generator with rich annotations and full schema coverage, the description is nearly complete. It omits only return format details, which are minor given the absence of an output schema and the simplicity of the tool.

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

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

Schema description coverage is 100%, and both parameters are documented with enums and defaults. The description only repeats 'by climate and role' and adds no extra syntax, filtering, or behavioral detail beyond what the schema already provides, so baseline 3 is appropriate.

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

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

States a specific verb ('Returns') and resource ('destination wedding packing list') with scoping dimensions (climate, role). It does not explicitly contrast with sibling tools such as get_wedding_checklist, so it falls 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.

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

No explicit when-to-use or when-not-to-use guidance is provided, and no alternative sibling is named. Usage is only implied by the resource name, leaving the agent to infer context.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety behavior is fully covered. The description adds only that results are sorted by months-out and span venue planning through day-of logistics, which describes content but no filtering, pagination, or edge-case 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?

A single well-formed sentence that front-loads the resource and scope with no filler. Every clause contributes: what is returned, how it's organized, and the range of content covered.

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

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

No output schema exists, and the description does explain the shape of the return (timeline bucketed by months, spanning venue planning to day-of). Combined with annotations covering the safety profile and a fully documented optional parameter, this is nearly complete, though the absence of any mention of defaults for months_out is a small 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?

With one parameter and 100% schema description coverage, the schema already documents months_out including its filtering purpose. The description's phrase 'organized by months before the wedding' loosely aligns with the parameter but adds no format or syntax detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (Returns) and resource (destination wedding planning timeline), plus the organizing dimension (months before the wedding). It implicitly separates itself from get_day_of_timeline and get_wedding_checklist via the month-based framing, but never names those siblings, so an agent must infer the distinction.

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

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

Usage is only implied: the month-based framing suggests this is for long-range planning rather than day-of logistics. There is no explicit when-to-use statement and no mention of alternatives such as get_day_of_timeline or get_wedding_checklist, which is a notable gap given the many sibling timeline tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds real value beyond that by stating the 'published' scoping constraint and enumerating what the payload contains (services, FAQs, ratings, photos, links), though it omits what happens for an unpublished or missing slug.

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

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

A single front-loaded sentence: verb, resource, scope, key, and return contents in order of usefulness. No filler and nothing that should be trimmed.

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 with full annotation coverage and high schema coverage, the description is nearly sufficient, and with no output schema it appropriately describes the returned contents. The only minor gap is the behavior when the slug is unpublished or unknown.

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

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

Schema description coverage is 100% and the single slug parameter is already well documented there as the unique identifier of a published vendor. The description merely restates 'by its slug' without adding format, source, or validation detail, so baseline 3 applies.

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

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

States a specific verb and resource ('Returns a published wedding vendor') and identifies the lookup key ('by its slug'), which distinguishes it from the sibling search_vendors. However, it never names get_venue_details or search_vendors as the near alternatives, so sibling differentiation is only implicit.

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 'by its slug' implies this is a follow-up lookup after a search, but the description never states when to use this versus search_vendors or get_venue_details, nor any prerequisite for obtaining a slug. Usage is inferable but not explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds genuinely new behavioral context beyond them: only published venues are returned, and estimates are explicitly not supplier quotes or live availability, which prevents the agent from misrepresenting the data. It still omits the failure mode for a missing/unpublished slug.

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 what is returned, followed by the one caveat an agent most needs. Every clause earns its place with no restatement of the title.

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

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

With no output schema, the description carries the burden of describing the return payload and does so concretely, including the provenance character of the sourced facts. The only gap is error/edge behavior for unpublished or nonexistent slugs.

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

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

Schema description coverage is 100% for the single slug parameter, and the schema already states it uniquely identifies a published Aisle venue. The description adds no format, casing or sourcing detail beyond that, so the baseline 3 applies.

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

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

States a specific verb (returns) and resource (a published wedding venue, keyed by slug) and enumerates the payload: photos, highlights, travel information, planning estimates and sourced facts. It is clearly distinguishable from search_venues in kind, but it never names the sibling lookup it is paired with (e.g. search_venues to obtain the slug, or get_vendor_details for the vendor equivalent).

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

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

Usage is only implied: 'by its slug' and 'published' hint that the caller must already hold a valid slug from a prior search, but the description never says to use search_venues first, nor what to do when the venue is unpublished or the slug is unknown. No exclusions or alternatives are stated.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint false). The description adds useful behavioral context about what is returned (milestones across eight phases, spanning eighteen months before through the day) and how the optional month limit filters results, but it does not describe the return format or pagination.

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

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

Two tightly written sentences with zero waste. The core behavior is front-loaded, followed by the optional filtering note; every phrase 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 read-only getter with one optional parameter, no output schema, and annotations that carry the safety profile, the description sufficiently explains what the tool returns and how filtering works. It could be improved by clarifying its relationship to the similar get_planning_timeline sibling.

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

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

Schema description coverage is 100%, so the single parameter months_out is already documented in the schema. The description adds that it is optional and that it narrows the milestones shown, which is marginally useful but does not add syntax or format details beyond the schema.

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

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

States a specific verb (Returns) and resource (destination wedding planning milestones) with scope detail (eight phases, eighteen months before through the day itself). However, it does not distinguish itself from the sibling get_planning_timeline, leaving ambiguity about which timeline tool to use.

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 when-to-use, when-not-to-use, or alternatives are named. The description implies usage for destination wedding checklists, but given the sibling get_planning_timeline, the lack of routing guidance is a clear gap.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the bar is lower. The description still adds real value by clarifying it is a pure calculator ('does not transfer money') and that traditional assignments are etiquette, not obligations — behavioral framing not present in structured fields.

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

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

Three short sentences, front-loaded with the purpose and each sentence pulling weight (purpose, etiquette caveat, no-money clarification). No redundancy 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?

No output schema exists, but the description tells the agent what comes back in substance (percentages and amounts), and the safety profile is covered by annotations. Complete enough for a simple two-parameter calculator, though the enum model names remain unexplained.

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

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

Schema description coverage is 100% with only two parameters, so the schema fully documents model and total_budget. The description only gestures at 'selected model' and never explains the enum values or budget units, adding nothing beyond the schema. Baseline 3.

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

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

Names a specific verb (Calculates) and resource (percentages and amounts for dividing a wedding budget), plus the actor scope (couple and families). It is distinguishable from most siblings, though it does not explicitly contrast itself with the nearby get_budget_estimate.

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?

'under a selected model' implies the input needed, and the etiquette disclaimer gives context, but there is no explicit statement of when to reach for this tool versus get_budget_estimate or get_alcohol_estimate, nor any exclusions.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely new context: guest assignments and occupant identities are excluded from the payload, and authentication is required. It stops short of describing ordering guarantees or empty-state 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?

Three short sentences, front-loaded with what the tool returns, followed by exclusions and the auth precondition. No filler, no repetition of the title.

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

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

With no output schema, the description carries the burden of describing the payload, and it does so by naming the returned fields and explicitly excluding guest/occupant data. It could be more complete about ordering or pagination, but an agent has enough to call it correctly.

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

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

Schema description coverage is 100% and the single wedding_id parameter is fully documented in the schema, including the multi-wedding requirement. The description adds no syntax or format detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb (Lists) plus the resource (selected wedding's accommodation options) and enumerates the returned fields: room descriptions, addresses, property order. This is easily distinguished from sibling list tools like list_my_events or list_my_guests.

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

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

The description states a precondition ('Requires sign-in') and scopes the result set, but never says when to use this versus alternatives such as get_my_wedding or the update/remove accommodation siblings. Usage is only implied by the name and field list.

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, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds genuine context beyond that: the auth requirement ('Requires sign-in') and the shape of what is returned (dates, times, venues, dress codes, descriptions).

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

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

Two tight sentences with zero filler, and the primary purpose is front-loaded before the auth note. Every clause carries information the agent can use.

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

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

For a read-only, single-parameter list tool with full annotation coverage and no output schema, the description supplies the auth requirement and enumerates return fields, which is enough to call it correctly. It omits any note on result ordering or whether an empty list is possible, but nothing essential is missing.

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

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

Only one parameter and schema description coverage is 100%; the schema already explains that wedding_id is required only when the account has multiple weddings. The description's phrase 'the selected wedding's events' loosely aligns with this but adds no syntax, format, or selection semantics. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a concrete verb (lists) and resource (the selected wedding's events) plus the specific fields returned (dates, times, venues, dress codes, descriptions). This is clearly separable from the other list_* siblings, but it does not explicitly name an alternative or route the agent, so it falls just short of a 5.

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

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

Usage is only implied: an agent can infer it should call this to view events rather than add/update/remove them. The only stated condition is 'Requires sign-in', which is an auth prerequisite rather than when-to-use guidance. No exclusions or alternatives (e.g. get_day_of_timeline) 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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real context beyond that: guests under 13 and guests with unconfirmed ages are excluded, notes and dietary details are omitted from results, and authentication is required before calling.

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 ordered by importance: what is returned, how to narrow it, what is excluded and the auth requirement. Every sentence carries distinct information with no redundancy.

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

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

With no output schema, the description does well by naming the returned fields and the exclusions, so an agent knows the shape of the response. It does not mention result limits or pagination, which is the only notable 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 100%, so each parameter is already documented, including the enum for rsvp_status. The description confirms the filter dimensions (RSVP status, name) but adds no syntax or matching nuance beyond what the schema states.

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

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

The description names a specific verb and resource ('Lists guests in the selected wedding'), scopes it by age (13+) and enumerates the fields returned (contact details, RSVP status). An agent can immediately distinguish this from sibling mutations like add_my_guest or update_my_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?

It states that filters are optional and that sign-in is required, which implies the calling context, but it never says when to reach for this tool versus sibling listers or how to follow up (e.g. update_my_guest to change an RSVP). Usage is implied rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: donor identities are suppressed (privacy), no payment/contribution side effects, and an auth requirement.

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 zero filler, front-loaded on what is returned followed by exclusions and prerequisites. 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?

With no output schema, the description usefully enumerates what the list contains and what is deliberately omitted, and annotations carry the safety profile. An agent has everything needed to decide and call correctly.

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

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

There is a single parameter with 100% schema description coverage, and the schema already explains that wedding_id is required only when the account manages multiple weddings. The description references 'the selected wedding' but adds no format or selection guidance beyond the schema, so baseline 3 applies.

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

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

States a specific verb ('Lists') and resource ('the selected wedding's registry and honeymoon fund items') and even enumerates the returned fields (descriptions, goal amounts, received totals). It is clearly distinct from the add_/remove_/update_/get_ siblings. It stops short of explicitly naming a sibling to contrast against, which keeps it just below 5.

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

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

Gives a clear negative boundary ('does not collect contributions or initiate payments') and a prerequisite ('Requires sign-in'), which helps an agent avoid routing payment flows here. No alternative tool is named for the excluded cases, so it does not reach the explicit when/when-not/alternatives level.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's only added behavioral detail is that counts are 'published' listings, which is modest context 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?

A single tight sentence that front-loads the resource and return content, then the optional filter. 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 simple read-only listing tool with no output schema, the description covers what is returned (categories and their published counts) and the optional filter. It stops short of explaining count semantics or ordering, but the essentials are 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 100% and the single 'location' parameter is already documented with a slug example in the schema. The description's mention of location filtering adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Lists) and resource (wedding vendor categories) plus what is returned (published listing counts) and the optional filter. It does not explicitly differentiate itself from the other list_* siblings (e.g. list_venue_countries), which would be needed for a 5.

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

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

The phrase 'optionally filtered by location' implies the usage context, but there is no explicit when-to-use guidance, no when-not-to-use, and no named alternative among the many sibling list/search tools. Usage must be inferred.

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, idempotentHint=true, and openWorldHint=false, so the safety profile is fully covered. The description adds useful behavioral content by disclosing what data comes back (countries plus their venue counts), but says nothing about ordering, completeness, or whether the set is cached. Adequate but not rich.

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

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

A single sentence, front-loaded with the verb and resource and ending with the distinguishing detail (counts per country). No filler, no repetition of the title.

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

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

With no parameters, no output schema, and full annotation coverage, the description carries nearly all the burden and does so competently by stating the result shape. Minor gap: it does not say whether results are exhaustive or how they are ordered, but for a simple listing endpoint nothing essential is missing.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to clarify beyond the scope of the result set, which it already does by naming 'published' venues.

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

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

States a specific verb (Lists) and resource (countries), plus the exact scope: countries with published wedding venues on Aisle and per-country venue counts. This is far more precise than a sibling like list_vendor_categories would imply. It doesn't explicitly contrast itself with search_venues, but the purpose is unambiguous on its own.

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 its role as a browse/facet lookup, but never says when to use this versus search_venues or get_venue_details, nor any precondition. Usage is inferable from the stated output (country + count), which is the minimum-viable level.

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

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

Annotations already cover the destructive/idempotent profile, yet the description adds substantial beyond them: guest assignments are removed too, payment history is retained, sign-in and an Aisle membership are required, and specific payment/checkout states block the operation. That is exactly the side-effect and precondition detail an agent needs.

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 operation is front-loaded in the first sentence, with safeguards, preconditions, and retention behavior following in tight, information-dense sentences. No filler or restated name/title content.

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

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

For a destructive, no-output-schema tool the description covers preconditions, auth, and side effects well. It stops short of describing the confirmation/error surface after a removal attempt, which is the one remaining detail an agent might want.

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

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

Schema description coverage is 100%, so both wedding_id and accommodation_id are already documented in the schema. The description adds only the notion of an 'identified room' in a 'selected wedding' and does not supplement formats or edge cases, so baseline 3 applies.

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

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

States a specific verb (Removes) and resource (an identified room and its guest assignments) scoped to the selected wedding. It is immediately distinguishable from sibling removal tools like remove_my_event and remove_my_guest, and from update_my_accommodation.

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

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

Gives concrete blocking conditions (uncharged checkouts without a payment method need confirmed cancellation; completed/refunded/processing payments and active card checkouts prevent removal). It clearly frames when the tool will and will not succeed, though it never names an alternative tool for the blocked cases.

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

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

Annotations already declare the full safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true), so the description's main added value is the auth/membership requirement, which is genuinely useful. It does not disclose cascade effects — e.g. what happens to guests or RSVPs tied to the removed event — which is the kind of detail a destructive tool should carry.

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

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

Two short sentences, purpose front-loaded, with the prerequisite as a follow-up. Nothing is redundant or padded.

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

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

For a two-param destructive tool with complete schema documentation and rich annotations, the description covers purpose and access prerequisites adequately. The remaining gap is blast-radius behavior after deletion, which annotations partially cover via destructiveHint.

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

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

Schema description coverage is 100%, so both event_id and wedding_id are already documented by the schema, including the multi-wedding condition for wedding_id. The description only echoes the required identifier implicitly ('an identified event') and adds no format or constraint detail beyond the schema.

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

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

States a specific verb ('Removes') plus the resource ('an identified event') and the scope ('from the selected wedding'). The removal verb inherently separates it from add_my_event and update_my_event, though it never names an alternative sibling explicitly.

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

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

It gives a real precondition ('Requires sign-in and an Aisle membership') but says nothing about when to use this versus update_my_event or list_my_events, or any when-not-to-use case. Usage is largely implied by the verb alone.

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, idempotentHint=true, and openWorldHint=false, so safety semantics are covered. The description adds auth/membership requirements and the age-eligibility gate, which are not in the structured fields. It does not state what happens to related records on removal, a minor gap.

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

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

Three tight sentences that front-load the action, then eligibility, then prerequisites. No redundant restatement of the tool name or 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?

With annotations covering safety and a fully documented 2-param schema, the description supplies the missing operational context: eligibility rules and auth requirements. Return-value behavior is unspecified, but no output schema exists, so a minor omission remains.

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

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

Schema coverage is 100% with both parameters fully described in the schema. The description's 'selected wedding' phrasing alludes to the wedding_id context but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (removes) and resource (guest) with scope (from the selected wedding) and an eligibility condition (recorded as 13 or older). An agent can distinguish this from update_my_guest and list_my_guests without opening schemas.

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

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

Gives clear when-not conditions: guests under 13 or with unconfirmed ages are ineligible. It also states prerequisites (sign-in, Aisle membership). It stops short of naming update_my_guest as the alternative for ineligible guests, so not a full 5.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, so the safety profile is largely covered. The description adds real value beyond that: the operation is a full-list replacement, partial/invalid input is rejected with the current order returned, and matching normalizes case and whitespace. It does not state whether changes are reversible or how the response is shaped, but the destructive semantics are clear from 'Sets the order of all properties'.

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

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

Three tight sentences, front-loaded with the action and scope, then input contract, then failure/auth constraints. No filler and every sentence carries a distinct requirement.

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

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

For a two-parameter mutation with no output schema, the description covers scope, input completeness, matching rules, rejection behavior, and auth requirements. Minor gaps remain around the response body and whether the prior order can be restored, but nothing essential to invoking the tool correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by specifying that place_names must be the COMPLETE list and that matching is case- and whitespace-insensitive, which materially affects how the agent constructs the array.

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

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

States a specific verb ('Sets the order') and resource ('all properties on the selected wedding's guest site and accommodation screen'), and no sibling tool competes with reordering, so the agent can place it immediately. Scope is limited to the selected wedding, which is a meaningful qualifier.

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

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

Gives concrete preconditions (sign-in, Aisle membership) and the failure mode for partial or invalid lists, which tells the agent what inputs are acceptable. It does not name an alternative or explicitly say when-not-to-use, but no sibling offers a competing reorder capability.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds genuinely useful behavior beyond that: results are excerpts (not full documents) and each includes a link to the full article, which is valuable given there is no output schema. It 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?

One sentence, front-loaded with the verb and resource, then the return shape. Every clause earns its place and nothing is padded or redundant.

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

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

For a simple single-parameter search with full annotation coverage and no output schema, the description supplies what the agent needs: what corpus is searched and what comes back. Minor gaps remain around result limits/pagination and whether an empty query is valid, but nothing critical for invocation is missing.

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

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

There is a single optional parameter with 100% schema description coverage, including inline examples of query strings, so the schema carries the parameter burden entirely. The description only reiterates 'by keywords' without adding format, matching, or empty-query semantics. Baseline 3 applies.

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

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

The description gives a specific verb (Searches), a specific resource (Aisle wedding planning guides), and the nature of the result (relevant excerpts with links to full articles), so it is not a tautology of the name. It implicitly separates itself from siblings like search_vendors/search_venues by naming a different corpus, but it never explicitly contrasts 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?

Usage is only implied: the phrase 'by keywords' tells the agent this is a keyword lookup over guide content, but there is no explicit statement of when to reach for this tool over search_vendors, search_venues, or the get_* guides. No prerequisites, exclusions, or alternative routing are provided.

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 readOnly, idempotent, non-destructive, and non-open-world behavior, so the safety profile is covered. The description adds genuine context beyond that: what a result contains (business details, listing links) and, importantly, that availability is not verified — a distinction the annotations cannot 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?

Three sentences, each doing distinct work: what it searches, what it returns, and what it explicitly does not do. Front-loaded with the verb and resource, no filler.

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

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

With no output schema, the description usefully summarizes result contents and the no-availability limitation, and annotations cover safety. It is nearly complete; only a pointer to the next step after selecting a vendor is absent, which is a minor 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 coverage is 100%, with the category enumeration, location slug format, and price_range values all documented in the schema itself. The description only restates the same three filter names without adding syntax, defaults, or combination rules, so the baseline 3 applies.

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

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

States a specific verb (searches) plus resource (published wedding vendors) and the three filter axes (category, location, price range). This cleanly separates it from sibling tools with different scopes such as search_venues, get_vendor_details, and list_vendor_categories.

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

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

Gives an explicit exclusion — 'does not check live availability or make bookings' — which tells the agent this is a discovery-only tool and that booking flows live elsewhere. It stops short of naming the follow-up tool (e.g. get_vendor_details) to use once a candidate is found.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description goes beyond them by disclosing the return payload (descriptions, photos, listing links) and the scope limitation (no live availability, no bookings), which is meaningful additional context given there is no output schema.

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

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

Three tight sentences: scope first, then what you get back, then the boundary condition. No filler and nothing important is buried.

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

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

For a zero-required-parameter, read-only search with no output schema, the definition covers purpose, result contents, and limitations adequately. Minor gaps remain around result volume/ordering and whether filters combine as AND, but nothing blocks correct invocation.

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

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

Schema description coverage is 100% and the enums for type and price_range are self-documenting, so the schema carries the burden. The description merely restates the same dimensions (country, venue type, capacity, price range) without adding syntax, defaulting, or combination 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 gives a specific verb and resource ("Searches published destination wedding venues") and enumerates the four filter axes, so an agent knows exactly what this returns. It never names the adjacent siblings (search_vendors, get_venue_details, list_venue_countries), so the separation is inferred from the name rather than stated.

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 carves out the negative case — "does not check live availability or make bookings" — which tells the agent when this tool is the wrong choice. However, it never points to the alternative (e.g. get_venue_details for availability, search_vendors for non-venue vendors), so routing still requires 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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that: redirects from the previous address are retained, and sign-in plus membership are required. It stops short of describing failure behavior when an address is unavailable.

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

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

Three tight sentences, front-loaded with the action and its main effect (redirect retention), followed by format rules and prerequisites. No filler or repetition.

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

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

For a mutation tool with solid annotations and full parameter coverage, the description covers the effect, the format validation, the auth requirements, and the redirect side-effect. With no output schema, little else is needed for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real constraints not in the schema: length (2-63), allowed character set, and the availability/unreserved requirement. This meaningfully extends what the agent knows about the address parameter.

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

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

States a specific verb (Changes) and resource (the selected wedding's guest-site address within aisle.wedding), making the scope immediately clear. No sibling tool performs anything comparable, so there is no ambiguity to resolve.

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 clarifies operation context ('the selected wedding') and lists prerequisites (sign-in and Aisle membership). It does not name exclusions or alternatives, but no sibling tool overlaps with this action, so clear context is enough.

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

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

Goes well beyond the annotations: partial-update behavior, the side effect that setting a price enables payment unless disabled, that zero makes a room free, how null clears deposit/balance schedules, that results report payment availability, and the explicit carve-out 'This tool does not initiate a charge' alongside destructiveHint=true. This is rich behavioral context an agent cannot get from the annotations alone.

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

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

Four tight sentences, front-loaded with what gets updated and the partial-update rule, then the payment side effects and preconditions. Dense but every sentence carries information; nothing is padding.

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

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

For a 19-parameter mutation tool with no output schema, the description covers patch semantics, key side effects, the no-charge clarification, and auth prerequisites, and briefly notes what results indicate. It is close to complete, though the many deposit/balance date interactions are left to the schema.

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

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

Schema coverage is 100% and the field descriptions are detailed, so the baseline is 3. The description adds cross-field interaction semantics the schema does not spell out — that pricing implies payment enablement and that a zero price means free — which is genuine added meaning over the per-field docs.

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

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

States a specific verb and resource: 'Updates supplied room details, pricing, payment requirements or deposit and balance schedules in the selected wedding.' The scope (which fields can be edited) is enumerated clearly and distinguishes it from add_my_accommodation, remove_my_accommodation, and list_my_accommodations, though no sibling is named explicitly.

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

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

The patch semantics ('Omitted fields remain unchanged') and the precondition ('Requires sign-in and an Aisle membership') imply this is for modifying an existing room, but the description never states when to use this over add_my_accommodation or remove_my_accommodation. Usage is implied rather than directed.

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

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

Annotations declare destructiveHint=true and idempotentHint=true, and the description adds genuinely new context: omitted fields are left untouched and existing invitations/responses are preserved. It also surfaces authentication/membership requirements. It does not explain the actual destructive surface (which fields, once changed, cannot be reverted), so it stops short of full disclosure.

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

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

Three sentences, front-loaded with the action and affected fields, followed by the partial-update guarantee and the auth prerequisite. Every sentence earns its place with no filler.

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

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

For a 10-parameter mutation with no output schema, the definition covers scope, partial-update behavior, and auth requirements adequately, and the rich schema covers the parameters. The main missing piece is guidance on how to handle the multi-wedding case (wedding_id) and what a successful response contains.

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

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

Schema coverage is 100%, so every parameter is already documented in the schema. The description recaps the updatable field groups (name, type, schedule, venue, dress code, description) but adds no syntax, format, or enum guidance beyond that. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb (Updates) and resource (event in the selected wedding) plus the exact field set affected, so an agent can distinguish it from add_my_event, remove_my_event, and the update_* siblings for guests/accommodations/wedding. No ambiguity about what is being modified.

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?

Discloses prerequisites (requires sign-in and an Aisle membership) and the partial-update contract, but never states when to choose this over siblings such as add_my_event or update_my_wedding, nor any when-not condition. Usage is implied rather than guided.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the bar is lower. The description adds genuine value beyond them: required sign-in plus Aisle membership, and an explicit list of immutable attributes, which tells the agent the blast radius of the write. It does not explain the destructive/clearing semantics (empty string wipes a field), though the schema covers that.

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

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

Three sentences, front-loaded with what can be updated, then constraints, then requirements. Minor redundancy: 'The guest identifier is required' restates the schema's required list and could be dropped without loss.

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 10-parameter mutation with no output schema, the description covers scope, eligibility, exclusions, and auth, which is most of what an agent needs. It could say a bit more about partial-update behavior (only supplied fields change) and the empty-string clearing convention, but nothing critical is missing.

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

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

Schema description coverage is 100%, so every parameter is already documented with enums and clear semantics (including the empty-string clearing behavior). The description merely echoes the updateable field groups, adding no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Updates) with a clear resource (guest) and enumerates the mutable field groups, which cleanly separates it from add_my_guest and remove_my_guest. The eligibility constraint ('guest already recorded as 13 or older in the selected wedding') further sharpens its identity.

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

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

Gives clear when-to-use context (guest must be 13+ in the selected wedding) and explicit exclusions (cannot change age bands, guest notes or dietary details), plus an auth precondition. It stops short of naming which sibling to use instead when those exclusions apply (e.g. for dietary details), so it is not a full 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 destructive/idempotent/open-world traits, so the bar is lower, and the description still adds real value: sign-in plus Aisle membership prerequisite, clearing semantics for nullable fields, the cannot-be-empty partner rule, and what the response identifies. It does not, however, elaborate on the consequences of unpublishing beyond what the is_published schema already says.

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

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

Four tight sentences with the purpose front-loaded and no filler. The return-value sentence earns its place because there is no output schema, though the whole is slightly denser than necessary given how much the schema and annotations already carry.

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 10-parameter mutation tool with no output schema, the description covers the mutation semantics, clearing rules, auth requirements, and response shape, which is close to complete. The only meaningful gap is the lack of sibling routing guidance (e.g., when to use this versus set_my_site_address).

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

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

Schema description coverage is 100%, so the baseline is 3. The description's parameter-related content (nullable clearing, partner names replace-only, omitted fields unchanged) largely restates constraints already spelled out in the schema, adding little beyond what the agent will read there.

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

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

States a specific verb and resource ('Updates supplied wedding settings') plus a distinctive capability ('can publish or unpublish the guest site'), so the agent can tell it apart from get_my_wedding or the add_/remove_ siblings. It stops short of naming a sibling it is not, so it lands at 4 rather than 5.

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

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

The partial-update contract ('omitted fields remain unchanged') is implied usage guidance for callers, but there is no explicit when-to-use statement and no routing to alternatives such as set_my_site_address or get_my_wedding. Adequate but leaves the agent to infer context.

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