Draft a bilingual wedding invitation website with RSVP and meal choice. Creates an unpaid draft with a live preview URL; publishing needs a human checkout, so an assistant cannot put the site live or spend money. No account and no credentials.
Scored across 4 tools
Each tool targets a distinct action: creating a draft, reading draft status, reading pricing, and listing templates. There is no overlap or ambiguity between them.
All tool names follow a consistent snake_case verb_noun pattern (create_, get_, list_). The convention is predictable and readable.
Four tools are well-scoped for the narrow domain of creating and checking a wedding website draft. Each tool earns its place without redundancy.
The surface covers create, read status, pricing, and templates, but lacks update and delete operations. Changing details requires creating a new draft, which is a notable gap in lifecycle management.
Create an unpaid draft of a wedding invitation website on wedding30s.com and return the URLs the couple needs.
Use it when the human wants a wedding website and has given both names, the date, the place and an email. Call list_templates first if they have not chosen a look, and get_pricing if the cost has not been agreed.
Behaviour: every call creates a NEW draft — there is no update or delete tool, so confirm the details with the human before calling. The couple is emailed a dashboard link. The preview URL is free and works immediately, but the page stays unlisted until it is paid for. Publishing requires a human to open the checkout URL and pay EUR 49: an assistant cannot publish the site and cannot spend money. Unpaid drafts are deleted 7 days after creation.
Returns: preview_url, checkout_url and expires_at.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Wedding date in ISO format YYYY-MM-DD | |
| Yes | Couple email. Receives the confirmation and the private dashboard link, so it must belong to the couple and not to the assistant | ||
| story | No | How the couple met, in their own words. Rendered as the "our story" section; the section is left out when omitted | |
| venue | No | Name of the ceremony or reception venue, shown under the location. Omit if not decided | |
| language | No | Language of the published page and of its RSVP form. Defaults to es | |
| location | Yes | City or town where the wedding takes place | |
| maps_url | No | Google Maps link to the venue. Adds a map and a directions button to the page | |
| template | No | Visual template id. Call list_templates for the options; omit to use the default | |
| partner1_name | Yes | Full name of the first partner, as it should appear on the page | |
| partner2_name | Yes | Full name of the second partner, as it should appear on the page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly: every call creates a NEW draft with no update/delete, the couple is emailed a dashboard link, the preview is free but stays unlisted until paid, publishing requires a human to pay EUR 49, the assistant cannot publish or spend money, and unpaid drafts are deleted after 7 days. This is exactly the side-effect, idempotency and lifecycle context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and return values are front-loaded, followed by usage conditions and a clearly labelled Behaviour paragraph. Three tight blocks with zero filler; the length is justified by the amount of behavioral risk (money, deletion, emailing) being disclosed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter, no-output-schema mutation tool, the description covers returns (preview_url, checkout_url, expires_at), prerequisites, side effects and expiry, so the agent has everything needed to call it correctly. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 10 parameters including enums and formats. The description adds little parameter-level detail beyond what the schema provides (it does not, for example, restate the email-ownership rule beyond the schema). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (create), resource (unpaid wedding invitation draft on wedding30s.com) and output (URLs the couple needs). It is clearly distinguishable from siblings like get_draft_status, list_templates and get_pricing 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?
Explicitly names the preconditions (both names, date, place, email) and routes the agent to alternatives by condition: list_templates if no look chosen, get_pricing if cost not agreed. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the current state of one wedding created with create_wedding_draft: whether it is still an unpaid draft or already published, its URLs, and how many guests have answered the RSVP.
Read-only: it changes nothing and stores nothing. Use it to answer "is my site live yet?" or "how many have replied?" without asking the human to open the dashboard.
Requires both the draft_id and the token returned by create_wedding_draft. The token is the only credential — there is no account — so keep it with the draft_id and never share it in public. An unknown draft_id and a wrong token give the same "not found" answer.
Returns: status, template, language, preview_url, dashboard_url, public_url once published, expires_at while unpaid, and RSVP counts (invited, attending, declined, pending). Guest names, emails and allergies are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The secret token returned by create_wedding_draft, also present in the preview URL as ?token= | |
| draft_id | Yes | The draft_id returned by create_wedding_draft |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility. It explicitly states 'Read-only: it changes nothing and stores nothing,' explains the token credential model, notes that unknown draft_id and wrong token return the same 'not found' response, and specifies that guest personal data is never returned. This is excellent behavioral 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?
The description is well-structured with clear sections: purpose, read-only guarantee, usage context, parameter requirements, and return values. Each sentence adds value with no fluff or repetition, achieving high information density without being overly long.
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 no output schema, the description lists all returned fields and their conditional presence (e.g., public_url once published, expires_at while unpaid). It also covers security behavior and what is never returned, making the tool fully understandable for an agent without needing additional documentation.
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 baseline is 3. The description adds meaningful context: it explains that both parameters are returned by create_wedding_draft, that the token is a secret credential, and that it appears in the preview URL. This goes beyond the schema's descriptions.
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 reads the current state of a wedding draft created with create_wedding_draft, including publication status, URLs, and RSVP counts. This specific verb+resource scope distinguishes it from siblings like create_wedding_draft, get_pricing, and list_templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells when to use the tool: to answer 'is my site live yet?' or 'how many have replied?' without asking the human to open the dashboard. It also clarifies the required credentials (draft_id and token) and contrasts with creating drafts, providing strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current price of publishing a wedding website on wedding30s.com and the list of what it includes.
Read-only: it creates no draft and stores nothing. Call it before quoting a price to the human, and before create_wedding_draft when the cost has not been agreed. Do not state the price from memory: it can change.
Returns: the one-time amount, its currency, and what is included.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description clearly states that the tool is read-only, creates no draft, stores nothing, and that price can change. This fully communicates safety and behavioral expectations beyond the minimal tool name.
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, with three short sentences, each adding substantive value. Key information is front-loaded: what it fetches, safety guarantee, usage timing, caveat about changing prices.
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 this is a simple zero-parameter lookup with read-only semantics and no output schema, the description fully covers the necessary context: what the tool does, its one-time vs. recurring payment nuance (one-time amount), currency, included items, and when to issue it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so this dimension is largely not applicable. The description doesn't need to explain parameter details, but it does add clarity about what the response will include, providing a useful baseline above the default for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get the current price of publishing a wedding website' and additionally states what it includes. It clearly stands apart from sibling tools like create_wedding_draft and get_draft_status by focusing on pricing and availability.
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 guidance on when to call it: before pricing, and before create_wedding_draft if cost is not agreed. It also warns not to state the price from memory. It doesn't explicitly mention when not to use it or name alternatives, but the timing guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the four wedding website templates with their id, name, style and preview image.
Read-only: it creates no draft and stores nothing. Use it before create_wedding_draft when the couple has not chosen a look, or to show them the options.
Returns: an array of templates. Pass the chosen id as the template argument of create_wedding_draft, or omit that argument to accept the default.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states 'Read-only: it creates no draft and stores nothing,' which fully discloses the lack of side effects. It also mentions the return type (array of templates), adding behavioral clarity beyond the bare statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place. The first sentence states the purpose, the second clarifies behavior and usage, and the third explains the return and how to use the output. No wasted words and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and a simple return, the description covers everything: what it does, when to use it, that it's read-only, what it returns, and how to use the output (pass the id or omit for default). It even notes the alternative of omitting the argument, which is valuable context for the agent.
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 the baseline is 4 per the rubric. The description cannot add parameter meaning beyond the schema, and it doesn't need to. It does indirectly reference how the output (the chosen id) is used as a parameter in create_wedding_draft, which is helpful context.
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 explicitly states it lists the four wedding website templates with id, name, style, and preview image. This is a specific verb+resource and clearly distinguishes it from siblings like create_wedding_draft, get_draft_status, and get_pricing by positioning it as a pre-step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use it before create_wedding_draft when the couple has not chosen a look, or to show them the options.' This provides clear when-to-use guidance and ties it to the workflow with the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_wedding_draft1 field changedInput schema / properties / email / patternPrevious value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"create_wedding_draftget_draft_statusget_pricinglist_templates
Add one secure layer between your agents and this server.