Wedyesday — wedding planning

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

Annotations already indicate a non-read-only, non-idempotent, non-destructive mutation. The description adds practical transparency by noting it writes to a real workspace and requires a connected Wedyesday account, providing context beyond the annotation booleans.

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

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

Two sentences, front-loaded with the primary action and then an important prerequisite/warning. 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?

The tool is a straightforward single-create mutation with all parameters covered in the schema. The description adds a key context warning about the real workspace and account requirement, though it could mention what a response looks like (no output schema exists).

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

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

Schema description coverage is 100%, so the schema already documents each parameter well. The description doesn't add significant parameter-level context, but the baseline of 3 applies because the schema carries the burden.

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?

Clearly states it adds a task to the couple's Wedyesday checklist, with a specific verb ('Add') and resource ('wedding task'). It is distinguishable from siblings like list_my_wedding_tasks or complete_my_wedding_task, though it does not 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?

Explicitly instructs to confirm wording and due date with the couple before calling, and warns that it writes to the real workspace. This effectively differentiates it from read-only sibling tools and establishes a clear when-to-use guideline.

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

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds that nothing is saved and no account is needed, which is specific behavioral context beyond the safety flags. It also assures authenticity ('nothing here is invented'), giving agents confidence in the data. It doesn't contradict the annotations.

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

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

The description is two sentences with no filler. The first sentence front-loads the core purpose and output components, and the second adds essential context about persistence and authenticity. Every sentence earns its place.

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

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

With no output schema, the description must convey the result shape, which it does by specifying the checklist, budget split, and comparison. It also mentions the follow-up tool and the no-save behavior. It could be more explicit about legal steps or the exact output format, but it's fairly complete for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description mentions that the budget and region drive the split and comparison, adding slight context, but it doesn't add substantial meaning beyond what the schema provides. The baseline of 3 is appropriate given the high schema coverage.

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

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

The description clearly states the tool's function: it builds a personalised wedding plan with a month-by-month checklist, budget split, and comparison to local spend. It distinguishes itself from siblings like get_wedding_cost_guide by specifying the comprehensive plan output, and it notes it's the same engine as the website.

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

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

The description implies when to use the tool (when the couple wants a full plan) and explicitly mentions a follow-up tool (create_wedyesday_workspace_link) for saving, but it does not explicitly contrast with other siblings like get_wedding_cost_guide or get_my_wedding_budget. It provides context but lacks clear exclusions or alternative selection criteria.

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

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

Annotations already indicate a write operation (readOnlyHint=false) and idempotency (idempotentHint=true). The description adds the account connection requirement and the confirmation step, which go beyond annotations. No contradiction exists.

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

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

Three sentences, each earning its place: purpose, prerequisite+confirmation, and account requirement. Information is front-loaded and no fluff.

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 mutation tool with no output schema and annotations covering safety, the description includes prerequisites, confirmation, and authentication. It could mention side effects (e.g., task status change) but that's implicit from the purpose. Adequate completeness for its 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% with descriptions for all parameters. The description reinforces the source of taskId (from list_my_wedding_tasks) but adds little for note or weddingId beyond schema. Baseline of 3 is appropriate since schema handles the semantics.

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

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

The description clearly states the action: 'Mark a task on the couple's Wedyesday checklist as done.' It specifies the resource (task on checklist) and distinguishes from siblings like add_my_wedding_task (which would add a new task). The mention of getting the task id from list_my_wedding_tasks also differentiates its use case.

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

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

It provides explicit prerequisite: 'Get the task id from list_my_wedding_tasks first' and advises confirming with the couple which task they mean. It also notes the account requirement. Although it doesn't explicitly contrast with alternatives, this guidance is clear enough for correct usage.

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

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

Annotations are all false and provide little signal, so the description carries the burden — and it delivers: it discloses that no account is created, no personal details are stored, the couple signs up themselves, and the link expires in 14 days. This adds genuine behavioral context beyond the structured fields. It doesn't state what the tool returns (presumably the link itself), a minor gap that keeps it from 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?

Three sentences with no filler, and the core purpose is front-loaded in the first sentence. The second covers privacy/account behavior and the third is actionable guidance. It's efficient and every sentence earns its place, though it could be marginally tightened — hence 4 rather than 5.

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 12-parameter tool with full schema coverage and no output schema, the description adequately covers the key behavioral facts an agent needs: the link's privacy posture, the 14-day expiry, that the couple self-signs-up, and what to tell the user. The only notable omission is an explicit statement of the return value format (the link itself), which is only implied. That minor gap keeps it at 4.

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 all 12 parameters are already documented in the input schema, including the required guestCount, the region slug reference, and the dateMode/eventDate/season interplay. The description adds no parameter-specific detail beyond pointing to 'the same answers used for build_wedding_plan', a cross-reference rather than new semantics. Baseline 3 is appropriate given the high schema coverage.

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

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

The description states a specific verb and resource: turning a wedding plan into a private, shareable link that becomes a Wedyesday workspace. It lists the contained elements (checklist, budget, guest list, RSVPs, website) and distinguishes itself from build_wedding_plan by noting it reuses 'the same answers'. An agent can clearly tell this apart from its siblings.

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

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

It gives clear context: this is the tool to hand the couple a link rather than produce a plan, and it cross-references build_wedding_plan as the source of the same inputs. It also tells the agent what to do with the result ('Give them the link and tell them it expires in 14 days'). It stops short of an explicit when-not-to-use or naming alternatives beyond build_wedding_plan, so it earns a 4 rather than a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat safety. It adds a behavioral guarantee that email/phone are never returned—a privacy-related disclosure. It also mentions the account requirement. This goes beyond annotations. No contradiction.

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

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

The description is a single sentence that clearly states the purpose and includes a privacy note. No redundancy or fluff.

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 summary tool, this is adequate: it lists what's included, states what's excluded (contact details), and notes the account requirement. Has good annotations and a well-documented parameter.

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

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

The one optional parameter (weddingId) is fully described in the schema with 100% coverage. The description also explains when it's needed (only when multiple weddings). This is clear and complete.

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

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

The description clearly states the tool returns a summary of the couple's Wedyesday guest list, enumerating specific data points (headcount, groups, contact details, plus_ones, children). This specific verb+resource+scope distinguishes it from siblings like get_my_wedding_dashboard, which covers a broader overview.

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 mentions the prerequisite of requiring a connected Wedyesday account. However, it doesn't explicitly contrast with alternatives; the sibling list includes get_my_wedding_dashboard which might also show guest info, but the description doesn't point to that. For a read-only summary, it's clear enough when to use.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover safety. The description adds value by specifying the account requirement and detailing the output content (planned vs actual, remaining, due/overdue payments). This goes beyond the annotations and clarifies what the agent can expect.

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

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

The description is a single, concise sentence that immediately states the main purpose and key details. It contains no fluff or repetition, and every word adds value. It is appropriately front-loaded.

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

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

The tool is simple (one optional param, no output schema, no nested objects). The description covers purpose, prerequisite, and output specifics. It does not mention return format, but given the straightforward nature and existing annotations, it's sufficiently complete for an agent to use it correctly.

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

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

Schema coverage is 100% (the single parameter weddingId is described as 'Only needed when the account has more than one wedding'). The description does not add any additional parameter meaning beyond what the schema already provides. Since the schema fully documents the parameter, a baseline of 3 is appropriate.

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

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

The description clearly states the tool gets the couple's Wedyesday budget with specific breakdowns (planned vs actual by category, what is left, payments due/overdue). This distinguishes it from sibling tools like get_my_wedding_dashboard or get_my_guest_list, which focus on different resources.

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

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

The description gives a prerequisite ('Requires a connected Wedyesday account') but does not explicitly state when to use this tool versus alternatives like get_my_wedding_dashboard, which might also show budget info. There's no mention of when not to use it or which tool to prefer. The purpose is clear, but guidance on tool selection is absent.

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 destructiveHint=false, and the description does not contradict them. It adds useful behavioral context beyond annotations by clarifying it operates on the 'signed-in couple's' wedding, requires a connected Wedyesday account, and produces an aggregated overview including countdown, checklist progress, budget position, and next due item.

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

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

The description is concise: two sentences front-loaded with the core purpose and content. It packs useful details (what data is returned, a direct link, the 'start here' directive, the account requirement) with no filler or repetition of the name.

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 dashboard tool with a single optional parameter and no output schema, the description provides a thorough output expectations, including date, countdown, progress, budget, and next due item. It states the auth prerequisite and links to related dashboard content, giving enough context to confidently invoke the tool.

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

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

The description itself does not explain the weddingId parameter, but the schema already fully documents it: 'Only needed when the account has more than one wedding.' With schema description coverage at 100%, the baseline of 3 is appropriate the description doesn't need to repeat the schema but also adds little semantic value beyond it.

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

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

Description uses a specific verb ('Get an overview') with a clearly defined resource: the signed-in couple's Wedyesday wedding dashboard. It enumerates the contents (date, countdown, checklist progress, budget position, due next, dashboard link) and explicitly points to itself as the starting point for 'my wedding' questions, distinguishing it from more focused sibling tools like get_my_wedding_budget or get_my_guest_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?

The description provides clear contextual guidance: 'Start here for any question about my wedding' signals when this tool is the appropriate entry point. It also states the prerequisite of a connected Wedyesday account, which is an essential usage condition. However, it doesn't explicitly name alternative tools or state when not to use this tool, though sibling names imply the distinction.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds behavioral context by describing the return structure (low/typical/high totals and category breakdown), which is beyond annotations. It doesn't discuss data source or edge cases, but the annotation coverage lowers the burden.

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

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

The description is two sentences with zero filler. It front-loads the primary purpose and the output detail, then adds usage guidance. 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?

The tool is a simple read operation with two optional parameters and no required fields. The description explains the output format, and the schema covers parameter semantics. Annotations provide the safety profile. No essential information for an agent to call 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 description coverage is 100%, so both region and country are fully documented. The description mentions 'region' in the opening but adds no new parameter detail; the schema already explains the slug format, optionality, and default country. The description does not compensate for any gap, 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'), a clear resource ('typical wedding costs'), and defines the output scope (low/typical/high total plus category breakdown). It also differentiates from siblings like get_my_wedding_budget (personal budget) and list_wedding_markets (market list) by focusing on regional figures.

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 explicitly tells when to use this tool: to answer 'how much does a wedding cost' questions with real regional figures. It implies a distinction from estimates and from personal budget tools, but does not name alternatives or state when not to use it. Clear context without explicit exclusions.

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

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

Annotations already declare read-only and idempotent behavior. The description adds account requirement and default sort order, which are useful. It doesn't contradict annotations and provides context on expected behavior (e.g., requiring authentication) beyond the annotation hints.

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

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

Two sentences, no fluff. The first sentence states the core action and sort, the second covers filtering and authentication. All content 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, but the description sufficiently conveys that it returns a list of tasks with filter options. Given it's a straightforward list tool with good annotations, the description is adequate without explaining return format in detail.

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

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

Schema coverage is 100% with detailed parameter descriptions for limit, filter, and weddingId. The description adds the ordering detail ('newest deadlines first') but doesn't add meaning to the parameters themselves. Baseline 3 is appropriate.

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

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

The description clearly identifies the resource (tasks from the Wedyesday checklist) and the action (list), plus the default sort order (newest deadlines first). It distinguishes itself from sibling add/complete tools by indicating it's a read operation on tasks.

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

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

It states a prerequisite (connected account) and explains filtering options for different states (overdue, due soon, done). It doesn't explicitly exclude alternatives (e.g., 'use list_wedding_markets for vendor tasks'), but the purpose is clear enough for an agent to choose it over other list tools.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds useful behavioral context beyond annotations by explaining the output acts as a canonical source of exact values for downstream tools.

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 fluff, and the intended behavior is introduced immediately. The description is compact while still conveying both what is listed and when to invoke the tool.

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

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

The tool has one optional parameter, 100% schema coverage, and strong annotations. The description covers output scope and usage context, and no further detail is likely needed for an agent to invoke it correctly.

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

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

The input schema already fully describes the optional country parameter including ISO codes (AU, US, GB, NZ, IN) and its behavior. The description adds no new parameter-specific information, 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 clearly states the tool lists countries, regions, and vendor categories supported by Wedyesday, and it explicitly notes that these are exact values to pass to other tools. This verb-resource-scope combination makes it distinct from sibling tools like search_wedding_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?

The description gives an explicit when-to-use rule: call this first when you do not know a valid country code, region slug, or vendor category. It does not explicitly mention when not to use it, but the 'call first' directive provides clear context that other tools depend on this reference data.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by stating it 'Returns real published listings with ratings, price bands and a link to each profile', which informs the agent about the result content and that listings are real, not test data. No contradiction with annotations.

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

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

The description is two sentences with no fluff. The primary purpose is front-loaded in the first sentence, and the second sentence provides a concise, actionable routing to a sibling tool. 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?

With 8 optional parameters fully covered by the schema and no output schema, the description compensates by summarizing the return content (ratings, price bands, link). It also mentions the prerequisite tool for parameter decisions. While pagination and result structure aren't detailed, the combination of annotations, schema, and description is sufficient for a read-only search 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 coverage is 100% so all parameters are documented. The description adds value by advising to use list_wedding_markets if unsure about category or country code, which directly guides parameter selection beyond what the schema provides. This is a meaningful addition to parameter semantics.

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

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

The description clearly states the verb 'Search' and the resource 'Wedyesday's directory of wedding vendors', with a list of example categories. It also distinguishes itself from the sibling list_wedding_markets by advising when to use that tool instead, which prevents ambiguity.

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

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

Explicitly names a sibling tool (list_wedding_markets) and the condition under which it should be used first ('if you are unsure which category or country code to pass'). This gives clear guidance on when to use this tool versus the alternative, leaving nothing to inference.

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