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 arguments | |||
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.
Add one secure layer between your agents and this server.
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.
