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.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.8/5 across 4 of 4 tools scored.
Each tool has a distinct, non-overlapping purpose: creation, status retrieval, pricing, and template listing. No ambiguity in which tool to call for a given task.
All tool names follow a consistent verb_noun pattern: create_wedding_draft, get_draft_status, get_pricing, list_templates. Clear and uniform.
Four tools is well-scoped for the service's purpose—covering pre-purchase info, creation, and status checks without unnecessary bloat or missing essentials.
Core workflow is covered: templates, pricing, creation, and status. No update/delete exists, but this is explicitly by design, so the surface is complete for its intended use.
create_wedding_draftAInspectCreate 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?
Given no annotations, the description fully discloses key behaviors: creates a new draft each call, no update/delete, confirms details before calling, emailing dashboard link, preview free but unlisted until paid, human must pay EUR 49 to publish, assistant cannot spend money, unpaid drafts deleted after 7 days. All critical side effects and limitations are covered.
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 paragraphs for purpose, usage, behavior, and returns. Every sentence carries meaningful information without redundancy. It is appropriately sized for the complexity and front-loaded with the most critical 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?
For a complex tool with 10 parameters and no output schema or annotations, the description provides a comprehensive picture: what it does, when to use, side effects, payment requirements, deletion policy, and return fields. It fully covers what an agent needs to invoke correctly and interpret results.
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 descriptions for every parameter. The description adds marginal value beyond schema, mostly referencing required fields (names, date, place, email) but not enriching individual parameter semantics. Baseline 3 is appropriate for high 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 creates an unpaid draft of a wedding invitation website and returns needed URLs. It distinguishes from siblings (get_draft_status, get_pricing, list_templates) by its creation purpose and specific resource.
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 states when to use (when human wants a website with required details) and when to call alternative tools first (list_templates if no look chosen, get_pricing if cost not agreed). Provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_draft_statusAInspectRead 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_pricingAInspectGet 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_templatesAInspectList 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
