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

Annotations declare destructiveHint=false and openWorldHint=true, but the description adds no behavioral context beyond that: it does not say whether the FAQ publishes immediately, how it interacts with display_order/defaults, or whether permissions or moderation apply. For a write operation with only partial annotation coverage, this is thin.

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

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

A single front-loaded sentence with no padding or redundancy. It is appropriately sized, though its brevity stems partly from saying less than it could rather than from dense 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?

With fully documented params and a safety annotation present, the core facts needed to invoke the tool are covered. However, for an add/mutation tool with no output schema, the description omits what happens on success (e.g., where the FAQ appears, whether it is immediately live), leaving a modest 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 question, answer and display_order (including its default of 0) are already fully documented. The description only restates question+answer and adds no format, length, or ordering semantics, 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 (add) and resource (FAQ = question + answer) and scopes it to the website FAQ page. It is distinguishable from siblings like update_faq, remove_faq and list_faqs by name, though the description 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?

There is no guidance on when to use this versus update_faq or list_faqs, no prerequisites, and no mention of when a FAQ should be added rather than modified. An agent must infer usage entirely from the tool name.

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

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

Annotations only declare openWorldHint=true and destructiveHint=false, so the description must carry the behavioral burden. 'Add' implies mutation, but nothing states whether this creates at wedding level vs event level, whether duplicates are rejected, or what permissions are needed.

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

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

A single, front-loaded sentence with no filler. Nothing to trim and the key concept (household grouping) appears immediately.

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

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

For a 7-param mutation tool with no output schema and thin annotations, the description omits permissions, duplicate handling, and crucially whether the guest is added to the wedding roster or a specific event — a real ambiguity given invite_guest_to_event and set_event_guests siblings.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds the 'guest group (household)' framing, which explains why plus_one fields and affiliation exist on a single 'add guest' call, but it doesn't document any parameter formats or defaults.

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

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

Specific verb+resource ('Add a new guest group (household) to the guest list'), and the parenthetical clarifies the household-grouping concept. However, it doesn't differentiate from siblings like invite_guest_to_event or update_guest, leaving ambiguity about which guest-related verb to pick.

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 when-to-use guidance, no exclusions, no mention of alternatives such as invite_guest_to_event for event-level invitations. The agent gets zero routing help despite a dense sibling cluster of guest 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 cover the safety profile (destructiveHint=false, openWorldHint=true), so the bar is lower, but the description adds almost no behavioral context: it doesn't say where the new section is inserted, what display_order defaults to, whether 'hidden' suppresses it immediately, or what the response returns.

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

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

A single front-loaded sentence with no filler; the parenthetical efficiently conveys the section's structure. It could have spent one more clause on the optional parameters without becoming bloated.

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

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

For a 5-parameter mutation tool with 0% schema description coverage and no output schema, the description should explain ordering, hidden-state behavior, and insertion point. Those gaps leave the agent guessing how the created section will appear.

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

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

Schema coverage is 0%, so the description carries the full parameter burden. It names only the three required fields and gives no meaning for 'hidden' or 'display_order', leaving 2 of 5 parameters completely undocumented.

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 ('Add') and resource ('story section to the home page'), and clarifies the composed shape (title + subtitle + description block). It is clearly distinguishable from list_home_sections, update_home_section and remove_home_section, though it doesn't name them explicitly.

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

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

No when-to-use guidance, no prerequisites, and no mention of the sibling tools (update_home_section, remove_home_section, list_home_sections) that an agent would need to consider. Usage is only implied by the verb.

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 openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say whether the new POI is immediately public, whether duplicates are detected via google_place_id, what permissions are required, or what a successful call returns.

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 front-loaded sentence with no padding or redundancy. It is efficient, but the brevity is partly under-specification rather than disciplined concision given the tool's 14-parameter surface.

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

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

For a mutation tool with 14 parameters, no output schema, and only one documented parameter, the description is far too thin. It omits return behavior, visibility/publication effects, deduplication behavior, and any field-level guidance the schema leaves uncovered.

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?

14 parameters with only 29% schema description coverage, and the description explains none of them – not the 13 optional fields, not required-vs-optional behavior, not the string-typed latitude/longitude quirk. With low coverage, the description was obliged to compensate and does not.

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

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

Clear verb + resource ('Add a point-of-interest') plus a concrete destination ('Things-to-Do page') and examples that disambiguate the concept from add_vendor, add_guest, or add_faq. It does not explicitly name sibling tools, but the 'point-of-interest' framing is specific enough to distinguish it.

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 when-to-use guidance, no prerequisites (e.g. needing an existing Things-to-Do page), and no mention of the natural alternatives list_pois / update_poi / remove_poi. The agent must infer the workflow from the sibling names 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 openWorldHint=true and destructiveHint=false, so the safety profile is covered and the description adds the default-collection auto-lookup behavior. It does not disclose duplicate handling, idempotency, or validation/failure behavior for an invalid SKU — meaningful gaps for a mutation 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?

Two sentences, no filler, with the core purpose front-loaded and the fallback behavior immediately after. Nothing could be removed without losing 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 low-complexity mutation tool with full schema coverage and no output schema, the description covers purpose and the one non-obvious default behavior. Remaining gaps — duplicate SKU handling and error behavior — are minor given how thin the tool's surface is.

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 are already documented in the schema, including defaults for quantity, most_wanted, and enable_group_gifting. The description only restates the collection_id default rule, adding no syntax or format detail beyond the schema, 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 and resource ('Add a product (by SKU) to the registry'), which clearly separates it from sibling tools like update_registry_item and remove_registry_item. It does not name siblings explicitly, but the add/update/remove distinction is self-evident from the verb.

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 one useful conditional rule ('If collection_id is omitted, the default collection is looked up automatically'), which is usage-relevant. However, it gives no guidance on when to use this versus update_registry_item, or what happens when the SKU already exists in the registry.

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 supply openWorldHint=true and destructiveHint=false, so the description is not the sole carrier of the safety profile, but it adds nothing on top: no indication that this is a write that becomes visible on the public Travel page, no ordering/duplicate behavior, no validation rules, and no response description. For a creation tool with 19 fields this is a thin 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?

A single front-loaded sentence with no filler. It is efficiently sized, though the brevity is partly the cause of the gaps elsewhere rather than a virtue earned by completeness.

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 creation tool with no output schema and only partial annotation coverage, the description omits everything an agent needs beyond the bare action: required-vs-optional intent, which address fields matter for which type (a HOTEL vs a FLIGHT), whether the item is published publicly, and what happens on duplicates. It is not adequate for the tool's complexity.

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

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

Schema description coverage is only 53%, leaving roughly nine parameters (city, address1, address2, postal_code, display_order, email_address, contact_number, state_province, google_place_id) undocumented in both schema and description. The one thing the description does contribute – the list of item types – merely repeats the type enum already in the schema, so it adds no new meaning.

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

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

The description states a specific verb (add) and resource (travel item) and enumerates the item categories, so an agent can tell it apart from list_travel_items, update_travel_item, and remove_travel_item by name alone. It stops short of explicitly naming those siblings or the parent resource (a wedding website's Travel page), which is the only thing keeping it from a 5.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no routing to the alternatives (update_travel_item for existing entries, add_poi for non-travel places). The agent must infer usage entirely from the verb.

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=false and openWorldHint=true, so the safety profile is partly covered. However, the description adds no behavioral context of its own: it does not say whether the vendor is persisted immediately, whether it is associated with the current wedding/event, or what reference_vendor_id does.

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 words with no filler, so nothing is wasted, but the sentence is under-specified rather than efficient. The core intent is front-loaded, which is the only structural merit.

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 mutation tool with no output schema, the description should at minimum clarify creation semantics, required vs optional data, and any side effects. Annotations cover part of the safety story, but the description itself leaves a large 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 all 9 parameters are already documented, including the vendor_type enum values and the ISO 8601 event_date note. The description contributes no additional parameter meaning, so the baseline 3 applies.

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

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

The phrase names a resource (vendor) and a creation intent, so an agent can guess this creates a vendor record. But the verb 'Book' is loose and at odds with the schema's plain create semantics (vendor_type, name, city, state_province), and it does not differentiate this tool from update_vendor, remove_vendor, or search_vendors.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as search_vendors for finding an existing vendor or update_vendor for changing one. Only the word 'new' hints at the create use case.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds genuine value beyond that by disclosing the irreversible consequence: no tool exists to unseat a guest once assigned, and reassignment is the only way to change it.

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

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

Two tight sentences with no filler. The core action is front-loaded and the second sentence delivers the one piece of behavior an agent most needs to know.

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 4-param mutation tool with full schema coverage and annotations carrying the safety profile, the description covers the key risk (irreversibility). It doesn't address failure modes (e.g., assigning already-seated guests or occupied seats), but nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, so all four parameters already document their source (get_seating_chart, list_unseated_guests, list_seating_charts). The description adds nothing param-specific, 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 (assign) and resource (guest to a seat in a seating chart), which is unambiguous. It is clearly distinct from read-oriented siblings like get_seating_chart and list_unseated_guests, though it doesn't explicitly name those alternatives.

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

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

Implies usage by noting a guest can be moved later but not unseated, which is useful context for deciding whether to call it. However, it gives no explicit when-to-use instruction or alternative, and the precondition that the guest must be unseated is only inferable from the schema's guest_uuid source.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description goes beyond them with the concrete consequence that a project cannot be deleted afterward, which is exactly the kind of irreversible-effect detail an agent needs before committing. It stops short of saying whether creation consumes an order or what is returned.

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 is front-loaded ahead of the caveat. The irreversibility note is placed second, where it functions as a decision gate rather than burying the purpose.

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

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

For a three-parameter creation tool with a fully described schema and no output schema, the description covers purpose and the key irreversible side effect. The remaining gap is that it never says what the caller gets back (project UUID?) or whether 'quantity to order' implies a real purchase, which an agent would want before firing a destructive create.

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 three parameters (suite_uuid, lead_variation_uuid, quantity with default 150) are already fully documented, including the origin of the UUIDs. The description only gestures at the same concepts, adding no format or value detail beyond the schema, which is the baseline-3 case.

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

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

States a specific verb and resource ('Create a new invitation project') plus the two inputs it is built from ('a design suite and a lead variation'). This clearly separates it from siblings like get_card_project, list_card_projects, validate_card_project, and swap_card_project_variation, so an agent can pick it without opening a schema.

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

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

Usage is implied by the shape of the operation, and the irreversibility warning gives real decision-relevant context. However, it names no alternative tool and no prerequisite conditions (e.g. that suite_uuid must come from search_card_catalog or get_card_suite), so the agent has to infer when this is the right call.

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?

readOnlyHint=true already covers the safety profile, so the bar is lower, and the description still adds useful context by disclosing the returned fields (total budgeted, actual cost, paid, plus all budget items). With no output schema, that enumeration is the only signal about what comes back. It omits pagination/scoping behavior, keeping it from 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?

A single sentence that front-loads the verb and resource and then lists the payload contents. Every clause earns its place with no repetition of the name or filler.

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

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

For a no-param, read-only tool with annotations covering safety and no output schema, listing the returned fields closes the main information gap. It does not clarify aggregation scope (e.g., whether figures are per-wedding or whether items are paginated), which is the one remaining ambiguity.

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 there is nothing to document and the schema is trivially complete. Baseline 4 applies; the description adds no parameter meaning because none exists.

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

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

States a specific verb and resource ("Get the wedding budget summary") and enumerates what it contains (total budgeted, actual cost, paid, budget items), which clearly separates it from mutation siblings like update_budget_item and from get_wedding_dashboard. It never explicitly names a sibling to disambiguate against, so it stops 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 implied — an agent can infer this is the read path for budget data, with update_budget_item as the write counterpart. There is no explicit when-to-use statement, no guidance on how it relates to get_wedding_dashboard (which may also surface budget info), and no exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. With no output schema, the description's enumeration of returned content (customizations, paper/color options, per-customization pages) adds genuine value, but it says nothing about authorization requirements, missing-project behavior, or response size.

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 opens with the verb and resource and then spends its words on concrete return contents rather than filler. The parenthetical enumeration is dense but every item earns its place given there is no output schema.

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

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

For a simple single-parameter read with annotations covering safety and no output schema, this is close to complete: the agent knows the input source and roughly what comes back. A note on empty/missing projects or an explicit sibling reference would close the 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?

Only one parameter and schema description coverage is 100%; the schema already documents project_uuid and even its source (list_card_projects). The description adds no format, casing, or example detail beyond that, so this is the baseline 3 for high-coverage schemas.

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

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

States a specific verb and resource (get full details for one invitation project) and enumerates the sub-resources returned: invitation, envelope, RSVP card, details card, paper/color options, per-customization pages. This is clearly distinct from list_card_projects (collection) and get_card_suite, though it never names those siblings explicitly.

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

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

Usage is implied by the resource: fetch the single project you already have a UUID for. There is no explicit when-to-use statement or routing to alternatives like list_card_projects, get_card_project_guests, or get_card_suite; the schema's 'Project UUID from list_card_projects' carries the only real sequencing hint.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds useful payload context (font-size overrides tied to printed addressing) but says nothing about permissions, pagination, or behavior when a project has no guest groups.

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 resource, the scope, and the distinguishing detail with no filler. Nothing is wasted or 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?

There is no output schema, so the description must hint at the return shape; it does so by naming guest groups and font-size overrides. For a one-parameter read tool this is nearly complete, missing only edge-case behavior such as empty results or ordering.

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 a single parameter at 100% schema description coverage, the schema already carries the semantics, including the pointer to list_card_projects as the source of the UUID. The description adds no format 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?

The description states a specific verb and resource: listing guest groups assigned to an invitation project, plus a notable detail (per-group font-size overrides for printed addressing). This clearly separates it from the write-side sibling set_card_project_guests, though it never names that counterpart explicitly.

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

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

Usage is only implied — the read counterpart to set_card_project_guests. There is no explicit statement of when to call this versus listing all guests via list_guests, nor any prerequisite callout beyond the schema's mention of list_card_projects in the parameter description.

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

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

The annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful specifics about what details are returned (paper types, sizes, price range), going 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, front-loaded sentence that clearly defines the resource and lists the returned details. 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 lookup with one required parameter fully documented in the schema and safety annotations present, the description provides enough context about the returned content. No output schema is needed.

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 parameter's own description provides examples of source tools. The description adds no additional meaning about the suite_uuid parameter, so baseline 3 is appropriate.

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

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

The description states a specific verb (Get) and resource (card suite), and defines what a suite is with concrete examples (invitation + RSVP + details cards). It does not, however, distinguish this tool from siblings like search_card_catalog or get_card_project, so it falls 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?

The description gives no guidance on when to use this tool versus alternatives. While the parameter schema notes where to obtain a suite_uuid, the description itself offers no context about when fetching a suite is appropriate.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the return field list (key, name, swatch color, layout type), which is genuinely useful given no output schema exists, but says nothing about freshness, caching, or partial-data 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?

One front-loaded sentence that names the resource first and the payload fields second, with zero filler. 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 zero-parameter, read-only getter with annotations covering the safety profile, the description tells the agent what it retrieves and what it gets back. Only the absence of guidance on stale/empty results and sibling routing keeps it from a 5.

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 there is nothing for the description to disambiguate; baseline 4 applies. Schema coverage is 100% and the description appropriately adds no parameter noise.

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 (Get) plus resource (currently-selected website theme) and enumerates the returned attributes, which lets an agent distinguish it from search_themes and update_current_theme. It does not explicitly name a sibling, so it falls short of the top mark.

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 'currently-selected' qualifier signals a read of the active theme, but there is no explicit when-to-use, when-not-to-use, or alternative routing to search_themes/update_current_theme. Adequate but with 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by naming the data categories returned (totals, values, note status), which matters because there is no output schema. It does not mention scope, freshness, or permissions.

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

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

A single front-loaded sentence with no filler; the resource and its contents come first. Every word earns its place.

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

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

For a zero-parameter read-only tool with no output schema, enumerating the returned data categories in the description is the right compensating move. It does not cover how the data is scoped (which event/account) or how thank-you status is derived, leaving 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?

The tool takes zero parameters, so the baseline is 4. The description correctly implies a no-argument dashboard-style retrieval and adds nothing misleading about inputs.

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 ('View') and resource ('gift tracking') and enumerates what the view contains: total gifts received, values, thank-you note status. It is distinguishable from read-only siblings like get_registry or get_wedding_dashboard, though it never explicitly contrasts itself with get_registry, which covers overlapping gift/registry data.

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

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

There is no guidance on when to use this tool versus get_wedding_dashboard or get_registry, nor any stated prerequisites or context. Usage is only implied by the fact that it is a read-only view.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds only that the response includes messages and inquiry details; it says nothing about pagination, thread size limits, or how much history is returned.

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

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

A single front-loaded sentence with no filler, but it is terse enough that the returned payload is described only in vague terms ('inquiry details').

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

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

No output schema exists, so the description should characterize the return value; it does so at a high level ('messages and inquiry details'). Annotations cover the safety profile, leaving only pagination/volume details 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?

Only one parameter and schema description coverage is 100%, so the schema carries the semantics and explains the uuid comes from list_inquiries. The description adds nothing about the parameter, which is the expected baseline here.

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: 'Get full conversation for a vendor inquiry'. It clearly distinguishes the retrieval of a single inquiry's thread from list_inquiries and mark_inquiry_read, though it doesn't name those siblings 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 offers no when-to-use guidance, prerequisites, or alternatives. The only hint of a usage chain comes from the schema ('Inquiry UUID from list_inquiries'), not the prose.

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 that this is a safe read (readOnlyHint=true, openWorldHint=true). The description adds genuine value by naming the derived fields (requested_qty, purchased_qty, marked_fulfilled, availability, inconsistent) and the paging mechanism, but it never explains what 'inconsistent' or 'availability' actually mean, which is the ambiguous part of a derived-state read.

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 no filler; the core purpose is front-loaded and the field list is packed into a parenthetical rather than padded into prose. Slightly dense but nothing wasted.

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

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

For a read-only list tool with no output schema and no annotations covering return shape, naming the returned fields is a real contribution. However the derived-state semantics are left unexplained and there is no routing guidance among the many registry-adjacent siblings, so it is adequate rather than complete.

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

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

Schema coverage is 100% with only two parameters, both fully documented in the schema (limit default 100, offset default 0). The description's 'Paged via limit/offset' adds no syntax or semantics beyond what the schema already states, 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?

Specific verb (View) and resource (couple's registry items), plus an enumeration of the derived state fields returned. It implicitly distinguishes itself from mutation siblings like add_registry_item/update_registry_item, but never names an alternative or mentions reconcile_registry, which also touches registry state.

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

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

There is no when-to-use or when-not-to-use guidance. The description merely states what the tool shows; an agent must guess whether this or search_registry_products, get_gift_tracker, or reconcile_registry is the right call for a given registry question.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description contributes the concrete contents of the response (title, intro copy, visibility, customization), which is useful. It adds nothing about permissions, rate limits, or defaults, so it neither contradicts nor significantly enriches 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 with the verb and resource front-loaded and no wasted words. The parenthetical field list is efficient rather than padded, though it slightly overlaps with what an output schema would normally 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 zero-parameter, read-only getter with no output schema, the description is largely sufficient: it states the target and enumerates the returned settings. The absence of output schema means the field list does useful work, though a note on how this relates to the page/customization siblings would close the 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies. The field enumeration describes output content rather than inputs, which is harmless but not required.

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

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

The description names a specific verb ('Get') and resource ('RSVP page settings') and enumerates the fields involved (title, intro copy, visibility, customization), so the agent knows exactly what is fetched. It does not, however, distinguish itself from near-neighbors like list_pages, get_website_customizations, or track_rsvps, leaving sibling selection to inference.

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

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

There is no statement of when to use this tool versus alternatives such as get_website_customizations or list_pages, and no prerequisites or context are given. Usage must be inferred entirely from 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=true and openWorldHint=true, so safety is covered. The description adds useful content scope (tables, seats, occupants) but says nothing about result size, pagination, or completeness for large charts, and there is no output schema to fall back on.

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 the resource and returned contents front-loaded, and zero filler. Nothing is restated from the name and nothing extraneous is included.

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 full parameter coverage and annotations, the description covers what is returned (tables, seats, occupants) at an adequate level. Without an output schema it could say more about the shape or ordering of the result, hence not a 5.

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%, so the schema fully documents the uuid and its origin. The description adds no format, source, or constraint 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 ('Get') and resource ('seating chart') plus the scope of what is returned: all tables, seats, and current occupants. This implicitly separates it from the sibling list_seating_charts (a list view) without naming it, so differentiation is inferable but not 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 rather than stated: an agent infers it should call this with a chart uuid to see a full chart, and the schema note routes back to list_seating_charts for the identifier. There is no explicit when-to-use, precondition, or named alternative in the description itself.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context by enumerating the returned facets (pricing, reviews, photos, about, FAQs), which is meaningful since there is no output schema. It does not discuss pagination or auth, but the bar is lower here.

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

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

A single front-loaded sentence with a compact parenthetical list of contents; no filler or redundancy. 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?

No output schema exists, so the description carries the return-value burden, which it does by listing the data facets returned. Combined with annotations covering the read-only/open-world profile, it is nearly complete, missing only minor details like result size or pagination.

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

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

With 100% schema description coverage, the single uuid parameter is already fully documented in the schema, including its source tools. The prose adds no additional parameter meaning, 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 (Get) and resource (vendor storefront) and enumerates the payload (pricing, reviews, photos, about, FAQs). It is distinct from search_storefronts by being a single-storefront detail fetch, but it never names or differentiates itself from that 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?

Usage is implied: fetch full details for one storefront, which contrasts naturally with the search-oriented sibling. However, the description states no explicit when-to-use, prerequisites, or alternatives, leaving the agent to infer that search_storefronts/list_favorites supply the uuid (that hint lives only in the schema).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully adds that it returns both current settings AND available options (a getter plus an options-lister), but says nothing about return format or pagination. With annotations carrying the safety burden, this is adequate.

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

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

A single front-loaded sentence with no waste; every clause earns its place by naming a distinct data category the tool returns.

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 no-param, read-only tool with no output schema and annotations covering safety, the description names the three categories of data returned, which is enough to call it correctly. It stops short of describing return shape, but that is a minor gap given the tool's simplicity.

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?

Zero parameters, so the baseline is 4. There are no parameter semantics to explain, and the description correctly adds no parameter noise.

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 (Get) and resource (website customizations) and enumerates what is returned: current colors, font settings, and available font/color options. This clearly distinguishes it from read-only siblings like get_current_theme, though it never names an alternative to route the agent 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?

No when-to-use guidance, prerequisites, or alternatives are given. An agent can infer this is the read step preceding update_website_customization, but the description never says so, leaving usage to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that this is an 'overview' spanning invites/paper/planning progress, implying a read-only aggregate, but says nothing about auth requirements, scope, or whether it summarizes or returns raw lists.

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

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

A single front-loaded sentence with the verb and resource first and the content areas in a compact parenthetical. Nothing is wasted, though the parenthetical is terse enough that 'paper' and 'planning progress' are left unexplained.

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-param aggregate read with annotations covering safety and no output schema, the description is close to sufficient, but vague labels like 'paper' and 'planning progress' leave the agent guessing at what data actually comes back and how complete the overview is.

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 is 4 and there is no schema surface the description could add to. Nothing in the description misrepresents the parameterless interface.

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 (Get) and resource (wedding planning dashboard overview) and enumerates the content areas (invites, paper, planning progress). It reads as an aggregate summary tool, which distinguishes it in spirit from single-domain getters like get_budget or get_registry, though it never names a sibling to make that contrast 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?

No when-to-use guidance and no alternatives are mentioned. Among dozens of siblings (get_budget, get_registry, get_gift_tracker, get_wedding_settings) an agent gets no signal for when the dashboard is the right entry point rather than drilling into a specific domain.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. With no output schema, the field enumeration (title, slug, partners, date, city, hashtag, guest count, visibility) usefully discloses what comes back, but it says nothing about auth, caching, or freshness.

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

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

A single front-loaded sentence with a colon-delimited field list; no filler or redundancy.

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

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

For a zero-param read tool with no output schema, the description compensates by enumerating the returned settings, which is about as complete as needed. The only gap is not routing the agent away from similar tools like get_wedding_dashboard.

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 and schema coverage is 100%, so there is nothing for the description to clarify; baseline 4 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 ('Get') and resource ('top-level wedding settings') and enumerates the fields returned, which sharpens what 'settings' means. It distinguishes the read tool from its write sibling update_wedding_settings by implication, though it never names alternatives.

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

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

No when-to-use guidance, no exclusions, and no mention of the closely related get_wedding_dashboard. The agent must infer that this is the retrieval call and guess how it differs from the dashboard 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 declare idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds meaningful scope behavior beyond those flags: the operation is additive and does not affect other events. Its 'Idempotent' sentence largely restates the annotation rather than extending it.

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

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

Three tight sentences with zero filler; the additive scope is front-loaded and the parameter rule follows immediately. 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?

For a three-parameter mutation with full schema coverage and annotations covering safety, the description supplies everything needed to call it correctly: scope, exclusivity rule, and idempotency. No output schema exists, so no return-value explanation is required.

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

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

Schema coverage is 100%, so each parameter is already documented, establishing a baseline of 3. The description adds value beyond the schema by stating the XOR constraint (exactly one of guest_group_id/guest_id) and clarifying that each option maps to a different invitation scope.

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 ('Invite a single guest or guest group to an event') and pins down the scope with 'additive — does not affect other events.' This distinguishes it from nearby siblings like set_event_guests and remove_event_invitation without needing to open their 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 the key selection rule — 'Pass exactly one of guest_group_id ... or guest_id' — so the agent knows the two parameters are mutually exclusive. It does not explicitly name an alternative tool or a when-not condition, but the additive framing supplies clear usage context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that by enumerating the returned fields (UUID, name, customizations, suite, quantity), which is important since no output schema exists. It does not mention ordering or result caps beyond what the schema states.

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. The scope-defining parenthetical is front-loaded and the return-value sentence follows immediately, so an agent gets purpose and payload in one pass.

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 list tool with fully documented parameters and annotations covering the safety profile, the description is nearly sufficient. The return-field enumeration compensates for the absent output schema; only sibling routing 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% — both limit (default 30) and include_completed (default false, drafts only) are fully documented inline. The description adds no syntax or behavioral nuance 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?

Specific verb ("List") plus a clearly bounded resource ("card" projects) with a parenthetical narrowing scope to invitation / save-the-date / shower-invite, paper or digital. It implicitly separates itself from the singular get_card_project, but it never names siblings, so differentiation is left to inference 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?

The description says what it returns but never states when to reach for this versus get_card_project, list_favorite_card_suites, or search_card_catalog. No prerequisites, no exclusions, no alternative routing — the agent must infer the usage context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description usefully adds that results include RSVP counts, but says nothing about ordering, pagination, or scope of the returned event set.

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

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

A single front-loaded sentence with no redundant or filler wording; the core verb and resource lead and the qualifier follows.

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-parameter listing tool with no output schema, the description covers what is returned at a high level ('with RSVP counts'), which is enough for an agent to decide to call it. The absence of any return-shape detail keeps it short of a 5.

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 per the baseline there is no parameter semantics to explain and the description incurs no deficit here.

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

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

States a specific verb ('List') and resource ('wedding events') and enumerates examples (ceremony, reception, rehearsal dinner), plus the payload detail 'with RSVP counts'. It is clear what the tool does, though it never explicitly differentiates itself from related siblings like update_event or track_rsvps.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as track_rsvps or get_wedding_dashboard. The agent must infer the context entirely from the description.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered structurally, and the description adds nothing beyond them — no ordering, pagination, or indication of what an FAQ record contains (e.g., whether IDs surface for later update_faq/remove_faq calls). With no output schema, that return-shape ambiguity is left entirely unaddressed.

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

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

A single front-loaded sentence with zero filler — the verb and resource come first and nothing is repeated from the title or schema. It is arguably too terse to carry the context a caller needs, but the sentence itself is efficiently structured.

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

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

For a parameterless read tool whose annotations cover the safety profile, the description is minimally sufficient to invoke correctly. It still omits what the listing returns and in what order, which matters because downstream FAQ edits likely depend on identifiers exposed by this call.

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 there is no parameter semantics to document and the baseline of 4 applies. Nothing in the description conflicts with the empty schema.

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

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

States a specific verb and resource ("List all FAQs") plus a scope qualifier ("on the wedding website"), so an agent immediately knows this is a read of FAQ entries rather than the sibling add_faq/update_faq/remove_faq mutations. It does not, however, differentiate itself from the other list_* siblings (list_pages, list_home_sections, list_inquiries), leaving resource disambiguation to the name alone.

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

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

There is no when-to-use or when-not-to-use guidance, and no reference to alternatives such as get_wedding_dashboard or the FAQ mutation tools. The zero-parameter shape makes the omission relatively low-risk, but the description itself contributes no routing information.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one useful behavioral nuance by clarifying that 'favorited' means hearted, but says nothing about ordering, pagination, or what a suite record contains.

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

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

A single short sentence that front-loads the verb and resource with zero filler. Nothing could be removed without losing meaning.

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

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

For a simple, zero-parameter read with no output schema, the description supplies enough to call it correctly: what it lists and which subset it returns. The one real gap is the absence of any pointer to list_favorites, which would help with sibling disambiguation.

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 there is nothing for the description to disambiguate; baseline for a no-param tool is 4. The description correctly communicates that filtering is implicit (favorites only) rather than parameterized.

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+resource ('List invitation design suites') and qualifies the scope as 'favorited (hearted)', which is more precise than the bare tool name. It does not, however, distinguish itself from the closely-named sibling list_favorites, which an agent could easily confuse it with.

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

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

There is no when-to-use guidance and no mention of alternatives, even though siblings like list_favorites, search_card_catalog, and get_card_suite sit adjacent to this capability. The only signal is the name itself, which leaves the agent to infer that this is the suite-specific subset of favorites.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the agent already knows this is a safe read operation that may return external data. The description adds no further behavioral details such as pagination, sorting, or rate limits. With annotations covering safety and openness, the description is minimally adequate but adds little.

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

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

A single, front-loaded sentence with no redundant words. Efficiently states the action and result.

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 no-param read tool, the description is functionally complete. However, given the many sibling tools that also list vendors or favorites, it lacks the disambiguation that would make it fully useful. The absence of an output schema is acceptable, but the description could clarify the return shape or scope.

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 no parameters; the schema is empty and 100% covered. The description correctly implies a parameterless retrieval, and no additional parameter semantics are needed. Baseline for zero params is 4.

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

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

Clear verb 'List' and resource 'favorited/saved vendors', specifying the collection being returned. However, it does not distinguish itself from the sibling 'list_favorite_card_suites' or from 'list_vendors', leaving ambiguity about what constitutes a 'favorite' versus a general vendor list.

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

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

No guidance on when to use this tool versus 'list_vendors' or 'list_favorite_card_suites'. The description provides no context about prerequisites or scenarios that would select this tool over alternatives.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantive behavioral context by enumerating exactly which fields the default view includes and which it omits (contact details), and what full unlocks. It stops short of covering pagination, ordering, or whether the list includes uninvited/removed guests.

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

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

Front-loaded with the verb and resource, then the field-availability caveat. Two sentences, no filler, though the second sentence partially re-explains the enum already spelled out in the schema. Slightly tight for the payload it carries.

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 must carry the return-shape burden and largely does, enumerating fields per view. Missing only operational details (pagination, sort order, inclusion of uninvited guests) that an agent might want before calling a household listing.

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

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

Schema description coverage is 100% and the view enum is already fully documented in the schema, so the schema carries the load. The description's restatement of compact-vs-full adds a use-case framing but no format or syntax detail beyond what the schema provides — the baseline 3 is appropriate.

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

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

States a specific verb and resource — 'List all guest groups (households)' — and clarifies both the grouping semantics and the stats returned (total, invited, missing addresses). 'All' implicitly scopes it against list_unseated_guests, but no sibling is named explicitly, so it falls just short of full 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?

The description gives explicit conditional guidance for the view mode ('pass view:"full" for addresses, emails and phone numbers', default view has no contact details), which is genuinely actionable. However it says nothing about when to choose this tool over the many sibling guest/card-project listing tools (list_unseated_guests, get_card_project_guests), leaving tool-level selection 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 already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read against external-facing content. The description adds only the object being read ('story sections on the website home page') and nothing about ordering, pagination, or what the sections contain.

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

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

A single front-loaded sentence with no filler; every word (verb, resource, scope) 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 trivial no-argument list tool with annotations covering the safety profile and no output schema to explain, the description is nearly sufficient. It could note ordering or that it returns sections for the live home page, 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?

The tool takes zero parameters, and the schema is fully described, so there is nothing for the description to compensate for. Baseline 4 applies for a parameterless tool.

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

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

States a specific verb ('List') and resource ('story sections on the website home page'), which an agent can immediately distinguish from add_home_section/update_home_section/remove_home_section. It stops short of naming or contrasting those siblings explicitly, so it is clear but not differentiated by reference.

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 scope ('website home page') implies when the tool applies, but there is no explicit when-to-use statement, no prerequisites, and no pointer to an alternative for editing home sections. Usage is inferred rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context by naming the fields surfaced in the response, but says nothing about ordering, completeness, pagination, or whether the vendor's inquiries span all events.

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

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

A single front-loaded sentence with no filler or redundancy. It is appropriately sized, though it is thin enough that a few more words of scoping would not have hurt.

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

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

With no output schema and no parameters, the description carries the burden of explaining what comes back; it names three fields but omits any notion of ordering, pagination, or whether results are filtered by event or vendor. Adequate but with clear gaps for a list tool.

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

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

The tool takes zero parameters and the schema is fully self-describing (empty object, 100% coverage), so per the baseline there is no parameter semantics for the description to compensate for. No penalty 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+resource ("List all vendor inquiries") and even enumerates the fields returned (status, vendor name, unread flag). It does not, however, distinguish itself from the closely related siblings get_inquiry_conversation and mark_inquiry_read, so an agent must infer the boundary.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the read-only sibling get_inquiry_conversation or the mutation sibling mark_inquiry_read. The agent is left to infer usage purely from the tool name.

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 carry readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the returned-field inventory, which helps the agent know what it gets back, but discloses nothing about pagination, ordering guarantees, or auth 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?

One front-loaded sentence, no filler. Every clause (resource, ID, type, display order, visibility, theme) 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?

No output schema exists, so describing the returned fields in the description is a real contribution. The tool is a trivial zero-param list, so it is nearly complete, though return-shape details (e.g., ordering, count) are absent.

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

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

Zero parameters, so the baseline is 4. The description doesn't need to explain parameters, and it helpfully documents what the call returns instead.

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

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

States a specific verb (List) and resource (wedding-website pages) and enumerates the exact fields returned (IDs, types, display order, visibility, theme info). An agent can distinguish this from sibling mutation tools like update_page or reorder_pages 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?

No explicit when-to-use or alternatives stated, but the read-only list semantics combined with siblings set_page_hidden/reorder_pages/update_page imply this is the discovery step before those mutations. 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=true and openWorldHint=true, so safety and openness are covered structurally. The description adds the useful scope constraint that results are limited to the 'Things to Do' page, but says nothing about ordering, pagination, or whether hidden/unpublished POIs are included.

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 short sentence that front-loads the verb and scoping context with no filler. Every word earns its place.

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

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

For a zero-parameter read-only listing with annotations covering safety, the agent has enough to invoke it correctly. The only omission is return-shape or ordering expectations, which is minor given no output schema and an obviously list-shaped result.

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 there is nothing for the description to disambiguate; the schema is effectively complete by construction. Baseline 4 applies for a no-parameter tool.

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

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

States a specific verb (List) and resource (points-of-interest) plus a scoping qualifier ('Things to Do' page), which separates it from the mutating siblings add_poi/update_poi/remove_poi. It does not explicitly name an alternative listing tool, but the purpose is unambiguous.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives or exclusions. Usage is only implied by the verb 'List', leaving the agent to infer that this is the read path for POIs.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description adds useful context about what each listed item contains (UUID and event name), but says nothing about pagination, result volume, or ordering.

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

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

A single front-loaded sentence with the return fields appended; there is no filler and nothing redundant. It earns every word.

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 trivial parameterless list tool with read-only annotations and no output schema, the description is nearly sufficient, telling the agent what it will get back. Only minor operational details (ordering, whether results can be empty or paginated) are absent.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline for parameterless tools applies; the description correctly does not invent parameter guidance.

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

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

The description states a specific verb ('List') and resource ('seating charts') and even names the fields returned (UUID and event name). It is clearly distinguishable from the singular sibling get_seating_chart, though it never makes that contrast 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?

The phrase 'List all seating charts' implies a browsing/enumeration use case, so the context of use is inferable. However, it offers no explicit guidance on when to use this versus get_seating_chart, and no prerequisites or exclusions 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 declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the useful scoping fact that results are the wedding website's Travel page items rather than all user travel data, but says nothing about ordering, filtering, or result size.

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 names the resource, the sub-types returned, and the surface they live on. No filler or redundancy.

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

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

For a parameterless read-only list tool with annotations carrying the safety profile and no output schema, the description is nearly sufficient. It could note what happens when the Travel page is empty or how items are ordered, 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?

There are zero parameters, so there is nothing for the description to disambiguate and the schema is inherently complete. Baseline 4 applies for a no-argument tool.

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?

Clear verb (List) plus specific resource (hotels, flights, transportation) and scope (the website Travel page). It is readily distinguished from add_travel_item / update_travel_item / remove_travel_item by the verb, though it never names a 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?

The phrase 'on the website Travel page' implies the context in which the tool is relevant, but there is no explicit when-to-use statement, no prerequisites, and no named alternative for related needs (e.g., list_pois or get_budget).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the meaningful filter semantic (only unseated guests), but says nothing about result size, ordering, or pagination behavior for what could be a long list.

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

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

A single front-loaded sentence with no filler, restating nothing beyond the tool's name in expanded form. Every word earns its place.

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

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

For a trivial read-only list tool this is nearly sufficient, but with no output schema the description gives no hint about what a returned guest record contains or how results are ordered/limited. Adequate but with a clear informational 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a param-less tool applies. No parameter-related guidance is needed or missing.

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

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

States a specific verb (List) and a well-scoped resource (guests not yet assigned a seat). The 'not yet been assigned a seat' scope implicitly distinguishes it from the generic list_guests sibling, but it never names that sibling or the seating-chart tools, so differentiation is left to inference.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as list_guests (all guests) or list_seating_charts / assign_seat (the seating workflow). The agent must infer the tool's place in the seating flow entirely on its own.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and scope of access are covered. The description adds the qualifier 'booked,' indicating it returns only booked vendors rather than the full vendor set, which is useful but limited additional behavioral context.

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 short sentence with the scope qualifier ('booked') front-loaded after the verb. No padding, no redundancy, nothing that fails to earn 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 zero-parameter read-only list tool with no output schema, the description conveys enough to invoke it correctly. The phrase 'with details' is vague about what is returned, but with no output schema there is little more an agent needs to select and call this tool.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond the absence of filtering, and the schema coverage is reported at 100%.

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

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

States a specific verb and resource ('List all booked vendors') and scopes it to booked vendors, which implicitly separates it from search_vendors in the sibling set. It stops short of naming the alternative sibling explicitly, so it is clear but not fully differentiated.

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

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

The description gives no when-to-use or when-not-to-use guidance. Given that search_vendors exists as a sibling, an agent must infer on its own that this is the unfiltered enumeration path; nothing in the text states that condition or any prerequisite.

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

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

The destructiveHint annotation already flags this as mutating, but the description adds the non-obvious behavioral fact that the state change is irreversible because no unread counterpart exists. It does not mention permissions or what the call returns, but the irreversibility disclosure is genuine added value.

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. The action is front-loaded and the irreversibility warning follows immediately after, which is the right ordering for a caution.

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 mutation with no output schema, the description covers purpose and the key irreversible side effect. It could say a bit more about permissions or failure modes, 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?

Schema coverage is 100% and the single uuid parameter is documented in-schema with its source (list_inquiries). The description adds nothing 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 and resource ('Mark a vendor inquiry conversation as read'), which cleanly separates it from the read-only siblings get_inquiry_conversation and list_inquiries. An agent can identify what it operates on (a single inquiry conversation) 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 second sentence establishes a crucial usage constraint: the action is one-way, since no unread tool exists. That effectively tells the agent when to be cautious, but it never names an alternative or states positive conditions for calling it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that the call substitutes text and returns 'the template structure including page layouts', which tells the agent the response shape in the absence of an output schema — genuinely useful behavioral context.

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

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

Three tight sentences with the action front-loaded, the usage cue second, and the return value last. No filler or restatement of the tool name, though the return-value sentence slightly overlaps the usage 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?

For a read-only preview tool with six fully documented parameters, the description covers purpose, substitution intent, and return content. The absence of an output schema is partly compensated by naming the returned structure, though nothing is said about rendering cost, rate limits, or invalid-UUID handling.

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 including the placeholder-substitution fields and variation_uuids is already documented in the schema. The description only gestures at 'couple's names and wedding date' and adds no syntax, format, or default details beyond what the schema provides, so the baseline 3 applies.

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

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

The description states a specific verb (render/preview) and resource (invitation template) and adds the key qualifier 'with text substituted in', which separates it from pure metadata tools like get_card_suite. It is not explicitly differentiated from the other preview tool (preview_qrcode), but the resource noun is distinctive enough that an agent can route correctly.

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?

'Use to see how a design would look with your couple's names and wedding date' gives implied usage context, which is more than nothing. However, it names no alternatives and sets no conditions for when-not to use it versus swap_card_project_variation or get_card_suite, leaving the agent to infer the boundary.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful behavioral context that annotations cannot: the return payload is an image rendered for inspection, which matters because there is no output schema. It stops short of noting any cost, rate limit, or caching 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?

Two tight sentences with zero filler; the core action and the return behavior come first, and the disambiguation with the sibling is placed last where it belongs.

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 a fully documented 4-parameter schema, the description covers purpose, output shape, and the alternative. With no output schema present, a bit more on the image format or dimensions returned would close the 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 description coverage is 100%, so url, enabled, url_type, and dimension are already fully documented in the schema, including defaults and enum-like values. The description adds no formatting or sizing nuance 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 and resource ("Generate a QR-code PNG for an invitation") and explicitly distinguishes itself from the sibling that commits the artifact ("Use set_card_project_qrcode to actually place it on a card"). An agent can separate this preview tool from the setter without opening either schema.

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

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

Names the alternative tool and the condition that selects it: use this to inspect, use set_card_project_qrcode to persist. That is a clear routing rule, though it doesn't spell out when a preview is unnecessary or whether it has side effects on the card project.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the 'Read-only' note is largely redundant. However, the description goes well beyond annotations by enumerating the exact outcome classes returned (DUPLICATE_RISK, UNATTRIBUTED, ORPHAN_ORDER, MATCHED count) and explaining what each anomaly means, which is genuinely useful behavioral context.

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 action is front-loaded, and the parenthetical glosses on each return category add meaning without padding. 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 parameters and no output schema, the description carries the full burden of explaining return values, and it does so completely by naming every result category. Nothing an agent needs to invoke 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the 0-parameter baseline of 4 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 (reconcile) and the two resources being cross-checked (registry against gift tracker), which is clearly distinct from sibling readers like get_registry or get_gift_tracker. An agent can tell this is a diagnostic cross-reference operation 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 explains what reconciliation surfaces, which implies when the tool is useful (after orders/fulfillment drift), but it never explicitly states when to run this instead of get_registry or get_gift_tracker, nor any prerequisites. Usage is inferable but not 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 declare destructiveHint/idempotentHint, and the description goes further by naming the concrete data loss (RSVP response and meal choice discarded, not restored on re-invite) and the blast radius ('Other events' invitations are preserved'). It also discloses the two-phase confirmation protocol and the confirmToken contract, which no annotation conveys.

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 dense sentences, front-loaded with purpose and the parameter rule before the confirmation mechanics. Slightly long, and the confirmToken explanation partly duplicates the schema field description, but nothing is 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 destructive 4-parameter tool with no output schema, the description covers the mutation scope, irreversibility, idempotence, cross-event safety, and the full two-phase return/confirmation flow an agent must handle. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds a genuine constraint the schema does not encode: exactly one of guest_group_id/guest_id must be supplied, with the differing blast radius for each. The confirmToken semantics largely restate the schema's own lengthy description, hence not a 5.

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 ('Remove an event invitation') and immediately scopes it to 'a single guest or guest group', distinguishing it from the sibling invite_guest_to_event. An agent knows exactly what entity is mutated.

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 selection rule: 'Pass exactly one of guest_group_id (removes for all guests in the group) or guest_id (removes for just that guest).' It also spells out the confirmation sequencing (prompt first, or preview+confirmToken fallback), leaving no decision 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 destructiveHint=true and openWorldHint=true, and the description goes well beyond them: it discloses the confirmation protocol, that phase 1 returns a preview plus confirmToken, that only a repeat call with that token proceeds, and points to MCP_CONFIRM_MODE. This is exactly the extra behavioral context a destructive tool 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?

Two sentences with the purpose front-loaded and the confirmation mechanics second. No filler; every clause carries operational information.

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

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

For a two-parameter destructive tool with no output schema, the description covers purpose and the critical confirmation protocol, so an agent knows how to complete the call safely. It omits whether deletion is reversible and whether the FAQ is hard-deleted or archived, which are minor gaps given the annotations.

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

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

Schema description coverage is 100% and the confirmToken field already documents when it may be passed and when it must not be. The description references the token flow but adds no format, range or constraint detail beyond what the schema states, 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 ("Remove an FAQ") plus scope ("from the public website"), which is unambiguous against the sibling add_faq, update_faq and list_faqs. An agent can immediately tell this is the deletion operation 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 gives strong guidance on HOW to invoke the tool (confirm prompt, two-step fallback with confirmToken) but says nothing about WHEN to choose it over alternatives such as update_faq or set_page_hidden, nor any exclusions or prerequisites. Usage is implied by the destructive verb rather than stated.

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

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

Far exceeds the destructiveHint/openWorldHint annotations: it discloses the cascade (RSVPs, event invitations, seat assignments), the irreversibility ('no trash'), and the two-phase confirmation protocol with confirmToken. This is exactly the behavioral context an agent needs before a destructive call.

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

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

Front-loads the action, then the destructive scope, then the confirmation mechanism. Every sentence carries load 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?

Covers what is destroyed, the irreversibility, and the confirmation path for both elicitation-capable and fallback clients. With annotations covering the safety profile and no output schema needed, nothing an agent requires to call this correctly is missing.

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

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

Schema coverage is 100% and the confirmToken parameter is already richly documented in the schema, so the description adds little beyond tying the token to the confirmation flow. Baseline 3 for full schema coverage.

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

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

States a specific verb (Remove) and resource (guest group/household from the guest list), and clarifies the unit is a group, distinguishing it from the single-guest tools (list_guests, add_guest, update_guest_address) among its siblings. An agent can immediately tell what this operates on.

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

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

Gives clear context for invocation, including that it asks for confirmation first and how the fallback path works. It doesn't name alternative tools or explicitly state when-not-to-use, but no sibling is likely to be confused with a group removal.

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

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

Annotations only declare destructiveHint and openWorldHint; the description adds substantial context beyond them, spelling out the two-phase confirmation flow, the confirmToken fallback for clients without elicitation, and the reference to MCP_CONFIRM_MODE. This is exactly the kind of gating/authorization behavior an agent needs before firing an irreversible call.

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

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

Purpose is front-loaded in the first clause, with confirmation mechanics following; nothing is wasted. The second sentence is dense with nested parentheticals, which slightly slows parsing but remains appropriate for a tool with a non-obvious two-step flow.

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 phase-1 "confirmation-required" response and its confirmToken, and annotations cover the destructive profile. It leaves MCP_CONFIRM_MODE as an external reference and says nothing about reversibility after removal, a minor gap for a delete tool.

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

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

Schema description coverage is 100%, so confirmToken and homepage_entity_id are already fully documented in the schema. The description adds no format or constraint details beyond what the schema states, 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+resource pair ("Remove a story section") and scopes it to the public home page, which cleanly separates it from add_home_section, update_home_section, and list_home_sections without opening a schema. The scope qualifier ("from the public home page") also disambiguates it from page- or POI-removal siblings.

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

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

The description explains the confirmation protocol thoroughly, which is real usage guidance for how to call it, but it never states when to remove a section versus alternatives such as update_home_section (e.g. hiding/reordering instead of deleting). Usage is implied by the verb rather than explicitly routed against siblings.

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

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

Annotations only declare destructiveHint and openWorldHint; the description goes well beyond that by disclosing the mandatory confirmation protocol, the two-phase preview/confirmToken fallback, and the MCP_CONFIRM_MODE dependency. This is precisely the behavioral context an agent needs to avoid making an unconfirmed destructive call.

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

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

Two sentences, front-loaded with the action and target, then the confirmation mechanics. No filler, and every clause carries operational meaning.

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

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

For a destructive tool with no output schema, the confirmation flow is the critical missing piece and it is covered thoroughly. The only gap is that the description never states the consequence of the operation (irreversibility / loss of the public page listing) or failure behavior on a bad or expired token.

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

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

Schema description coverage is 100%, and the confirmToken parameter already documents its full semantics (only after preview, never invented, never reused, ignored under elicitation). The description adds little beyond what the schema and the mention of MCP_CONFIRM_MODE provide, so the baseline 3 applies.

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

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

States a specific verb (remove), resource (point-of-interest), and scope (the public Things-to-Do page), which cleanly distinguishes it from sibling removers like remove_faq, remove_vendor, and remove_travel_item. An agent knows exactly what this tool affects.

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 explicit procedural guidance for the confirmation flow (prompt first where supported; otherwise preview + confirmToken on a repeat call), which is the key thing an agent must get right. It does not, however, mention alternatives such as update_poi for merely hiding a POI instead of removing it, so it stops short of full alternative routing.

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

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

Goes well beyond the destructiveHint=true annotation by disclosing the full confirmation protocol: an elicitation prompt where supported, otherwise a phase-1 preview returning a confirmToken and a required second call. This is exactly the behavioral context an agent needs to avoid an accidental deletion.

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: the purpose is front-loaded, followed by the confirmation behavior. No filler, and the branching logic is expressed compactly with a pointer to MCP_CONFIRM_MODE for deeper detail.

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

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

For a destructive tool with no output schema, the description adequately explains the confirmation lifecycle. It stops short of stating that removal is permanent or describing the preview contents, though the destructiveHint annotation partly covers the risk profile.

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

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

Schema description coverage is 100%, so both parameters (collection_item_id and confirmToken) are already thoroughly documented in the schema, including the confirmToken usage rules. The description adds only the high-level flow that produces the token, not new parameter-level meaning, 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 ("Remove an item from the registry that guests shop from"), clearly distinguishing it from add_registry_item and update_registry_item in the sibling list. An agent can identify the operation 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 gives clear context for use (removing a guest-facing registry item) and details the mandatory confirmation flow, but it never explicitly contrasts with update_registry_item or reconcile_registry as alternatives. Usage is implied rather than delimited against siblings.

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

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

Goes well beyond destructiveHint=true: it discloses the interactive confirmation behavior, the preview/confirmToken fallback for clients lacking elicitation, and the MCP_CONFIRM_MODE switch. This is exactly the behavioral context an agent needs before a destructive call.

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

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

Two sentences, front-loaded with the action and followed by the confirmation contract. Slightly dense parenthetical but no wasted wording.

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 compensates by explaining the phase-1 'confirmation-required' preview and token round-trip. Combined with annotations marking it destructive and open-world, the agent has enough to act correctly; only irreversibility/error behavior is left implicit.

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 confirmToken property carries a thorough description already, so the schema does the heavy lifting. The description names the confirmToken concept but adds no syntax beyond what the schema documents; 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+resource ('Remove a travel item from the public Travel page') and the scope ('public Travel page'), which distinguishes it from list_travel_items, add_travel_item and update_travel_item among siblings.

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

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

Explains the confirmation flow and the two-step fallback that governs how to invoke it, and implies the user-approval precondition. It does not contrast with alternative removal tools or note irreversibility, but the context for calling is clear.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond that: no statement of reversibility, permission requirements, or what happens to associated data when a vendor is unbooked.

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 words are front-loaded and waste nothing, but for a destructive operation this is under-specification rather than genuine conciseness. It is efficient but too thin to earn a higher mark.

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

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

The tool is simple (one fully documented parameter) and annotations carry the destructive signal, so little is strictly missing. Still, a destructive removal should say what is destroyed and whether it can be undone, and the description is silent on both.

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 uuid parameter is documented in the schema as coming from list_vendors. The description adds no parameter meaning of its own, 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 verb and resource ("Unbook a vendor"), so the agent knows it removes a vendor relationship. However, "unbook" is ambiguous about whether the vendor record is deleted entirely or just its booking/event association is cleared, and it does not differentiate from siblings like update_vendor or remove_guest.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as update_vendor for modification versus remove_vendor for removal. The agent is left to infer everything from the name.

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 openWorldHint=true and destructiveHint=false, so safety is partly covered. The description adds one useful behavioral detail: the list must be complete and ordered, implying full-replacement semantics rather than an incremental move. It does not state the consequence of omitting a page, permission needs, or the response.

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 with zero filler, and the core operation is front-loaded before the calling constraint. Nothing could be trimmed without losing 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 one-parameter, non-destructive operation with no output schema, the definition covers what an agent needs to call it correctly: what it does and that the ID list must be complete and ordered. It is thin on failure behavior and permissions, but not inadequate at this complexity.

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 description ("Full ordered list of page IDs in desired nav order") already conveys the same information as the description's sentence. The description therefore adds no semantics beyond the structured field, which is the baseline-3 case for a single fully documented 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 (Reorder) and resource (pages in the website navigation), which is clearly distinct from siblings such as update_page, set_page_hidden, and list_pages. It does not explicitly name an alternative, but the operation is unambiguous.

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

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

"Pass the complete ordered list of page IDs" is an invocation constraint rather than when-to-use guidance. There is no mention of prerequisites, when to prefer this over update_page, or what happens if the list is partial.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that results are aggregated as suites filtered by card type, but says nothing about pagination, result ordering, or what facets are actually available, despite the "faceted" claim.

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, front-loaded sentences with no filler; the verb and resource lead immediately. Slightly wasted by the vague "faceted search" phrase that is never substantiated.

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?

Adequate for a simple read-only search with no output schema, but it advertises faceted search while only one facet (card_type) is exposed in the schema, and the limit/return-shape behavior is left to the schema. An agent can call it correctly, but the description overpromises relative to what it explains.

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

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

Schema coverage is 100%, so both limit and card_type are fully documented with defaults and an enum-like list in the schema. The description only echoes the card_type filter ("matching the requested card type") and adds no syntax or behavioral 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 (Search) and resource (invitation design catalog) and clarifies the return unit is "suites" matching a requested card type. This reasonably separates it from sibling searches like search_themes or search_vendors, though it doesn't explicitly name a contrasting sibling.

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 when-to-use guidance and no alternatives named. The agent must infer that this is the browse/discovery step versus get_card_suite for fetching a specific suite, or search_themes for website themes; nothing in the text routes that decision.

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