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, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful transparency beyond the schema: 'Nothing is saved and no account is needed' and 'same planning engine as the Wedyesday website, so nothing here is invented.'

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 front-loaded purpose: the first sentence states what the tool produces, the second adds credibility, and the third handles the save/account boundary and next step. Every sentence earns its place and there is 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?

There is no output schema, but the description names the key output components: month-by-month checklist with real due dates, regional budget split, and comparison to typical local spend. Given the tool's 12-parameter complexity and conditional date fields, the output summary could be slightly richer, but it is sufficient for a read-only, fully schema-documented generation 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 input schema has 100% description coverage, so the schema already documents all 12 parameters, including conditionals like dateMode, season, and eventDate. The description reinforces the budget/region relationship but does not add per-parameter meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource—'Build a personalised wedding plan'—and immediately lists concrete deliverables: a month-by-month checklist, regional budget split, and comparison to typical local spend. It also distinguishes itself from siblings by clarifying that nothing is saved and that create_wedyesday_workspace_link is the follow-up tool.

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 clearly frames this tool as the generation step and explicitly names the sibling follow-up tool ('follow up with create_wedyesday_workspace_link when the couple wants to keep it'). However, it does not systematically state when to prefer this over other sibling tools such as get_wedding_cost_guide or list_wedding_markets.

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?

Beyond the generic annotations, the description adds meaningful behavioral details: no account is created, no personal details are stored, the couple signs up themselves, and the link expires in 14 days. This helps the agent set expectations and communicate the outcome to the user.

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 compact and each sentence earns its place: purpose, input relationship, privacy behavior, delivery guidance, and expiration. It front-loads the main purpose and avoids unnecessary 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?

Given the 12-parameter schema and no output schema, the description is reasonably complete: it clarifies the private-link output, what it contains, how it behaves regarding accounts and data, and the link's expiry. The only mild gap is no explicit statement of the exact response format beyond 'the link'.

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 documents all 12 parameters with 100% coverage. The description adds the useful instruction to reuse the answers from build_wedding_plan, but it does not meaningfully deepen parameter-level semantics beyond what the schema provides.

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

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

The description clearly states the tool's purpose: turning a wedding plan into a private Wedyesday workspace link. It also differentiates itself from sibling tools by referencing build_wedding_plan and explaining that the same answers are reused to generate the link.

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 workflow context: pass the same answers used for build_wedding_plan, give the link to the couple, and tell them about the 14-day expiry. It does not explicitly mention exclusions or alternatives beyond implicitly distinguishing from build_wedding_plan, so it stops just short of a 5.

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

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 readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the behavioral detail of returning a low/typical/high total and category breakdown, which is helpful. However, it does not provide additional context like auth needs or rate limits, but none are needed for a simple read. With annotations present, the bar is lower, and this minimal addition earns a 3.

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 purpose and output, then the usage intent. No unnecessary words, every sentence earns its place. Excellent structure.

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 tool with 100% schema coverage and no output schema, the description adequately covers what the tool returns and when to use it. It does not need to explain return values in detail since it briefly describes the structure. The context is complete given the simplicity and 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%, with both region and country already well-documented (region as a slug from list_wedding_markets, country as ISO code with defaults). The description does not add extra parameter meaning beyond what the schema provides, so it meets the baseline of 3 for 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 fetches typical wedding costs for a region, specifying the output as a low/typical/high total and category breakdown. It distinguishes itself from siblings like get_my_wedding_budget (personal budget) and list_wedding_markets (list regions) by focusing on regional typical costs vs. estimates. The verb+resource is specific and unambiguous.

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

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

The description explicitly says to use it for answering 'how much does a wedding cost' questions with real regional figures, giving a clear use case. It implies it's for non-personal, typical costs but does not explicitly mention alternative tools or when not to use it. Since the context is clear and it differentiates from siblings via the phrase 'rather than estimates,' a 4 is warranted.

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 establish read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful context beyond that by saying it returns real published listings and summarizing the returned data (ratings, price bands, profile link), which helps the agent set expectations.

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: the first states the tool's purpose, the second summarizes the return payload, and the third gives a cross-tool usage hint. The description is front-loaded and free of filler.

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

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

With no output schema, the description compensates by mentioning ratings, price bands, and profile links. It also addresses the most important ambiguity around category/country code. However, it does not clarify how the multiple optional filters interact or whether results may be empty, leaving a small completeness gap for an 8-parameter 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 description coverage is 100%, so the schema already documents all 8 parameters. The description adds only light semantic support by giving examples of vendor categories and pointing to list_wedding_markets for category/country code uncertainty, but does not add substantive parameter meaning beyond the schema.

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

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

The description clearly states it searches Wedyesday's wedding vendor directory and enumerates example vendor types. It also distinguishes the tool by noting what results include (ratings, price bands, profile links) and references list_wedding_markets as a related 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?

The description gives explicit usage guidance: use list_wedding_markets first when unsure about category or country code. This directly addresses when a sibling tool should be preferred and frames the main use case as a directory search.

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