Zovo Gift List
Server Details
Make a wishlist page that friends and family can claim gifts from.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
Score is being calculated.
Available Tools
3 toolscreate_gift_listCreate gift listInspect
Use this when the user wants a wishlist or gift registry page that friends and family can claim gifts from, for a birthday, Christmas or another holiday, a baby shower or a wedding. Takes a title, 1 to 80 items (name, optional note, price range text, store name and quantity up to 20) and whether the owner wants to see claims (hidden by default). Publishes a hosted page: friends see what is still available and claim it with their first name. Returns a shared link for friends and a private owner link. Does not accept links in items (name the store instead). Does not buy or track gifts.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Short note for friends, e.g. Sizes: shirt M, shoes 38. No links. | |
| items | Yes | The wishlist, e.g. [{"name":"Wool scarf","price":"$20-30"},{"name":"Hiking socks","quantity":2}]. | |
| title | Yes | List title shown on the page, e.g. Maya's 8th birthday. | |
| time_zone | No | IANA time zone for claim times, e.g. Europe/Berlin. Default America/New_York. | |
| owner_name | No | First name of the person the gifts are for, e.g. Maya. | |
| occasion_date | No | Date of the birthday or holiday as YYYY-MM-DD, e.g. 2026-12-25. | |
| show_claims_to_owner | No | true = the owner page shows who claimed what. Default false (claims hidden to keep the surprise). |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| title | Yes | |
| closed | Yes | |
| changes | Yes | |
| warnings | Yes | |
| manageUrl | Yes | |
| publicUrl | Yes | |
| expires_at | Yes | |
| item_count | Yes | |
| claim_count | Yes | |
| items_shown | No | |
| claims_hidden | Yes | |
| fully_claimed | No | |
| occasion_date | Yes | |
| removed_claims | No | |
| removed_claims_total | No |
show_gift_list_statusShow gift list statusARead-onlyIdempotentInspect
Use this when the list owner asks how their gift list is going, how many claims it has, or (when they chose to see claims) who is getting what. Takes the private owner link (it contains /m/). When claims are hidden, returns only the number of claims, not which items were claimed. Does not change anything. Does not work with the shared link.
| Name | Required | Description | Default |
|---|---|---|---|
| manage_link | Yes | The private owner link from when the list was made, e.g. https://gift-list.zovo.one/m/AbC.../XyZ... (it contains /m/). |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| title | Yes | |
| closed | Yes | |
| changes | Yes | |
| warnings | Yes | |
| manageUrl | Yes | |
| publicUrl | Yes | |
| expires_at | Yes | |
| item_count | Yes | |
| claim_count | Yes | |
| items_shown | No | |
| claims_hidden | Yes | |
| fully_claimed | No | |
| occasion_date | Yes | |
| removed_claims | No | |
| removed_claims_total | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint=true, it discloses a conditional return shape: when the owner hid claims, only the claim count comes back, not which items were claimed. It also states the authentication requirement (private owner link containing /m/) and that the call is non-mutating, which is exactly the context annotations cannot express.
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?
Front-loaded with the trigger and tight throughout, with no filler sentences. The only near-waste is 'Does not change anything,' which restates readOnlyHint=true already visible in annotations.
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 single-parameter read tool with an output schema and full annotation coverage, this covers the trigger, the credential, the failure mode, and the one conditional return case. An agent has everything needed to call it correctly and interpret the hidden-claims result.
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% and the link format is already documented there, so the description adds limited syntax detail. It does, however, add the negative constraint that a shared link will fail, which meaningfully narrows what value is acceptable beyond the schema's string type.
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 and resource plus the exact questions it answers: how the list is going, how many claims, and who is getting what. The scope is distinct from the create/update siblings, so an agent can route without opening either 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?
Opens with a concrete trigger ('when the list owner asks how their gift list is going'), then names an explicit exclusion ('Does not work with the shared link') and the required credential ('private owner link'). Nothing about selection 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.
update_gift_listUpdate gift listDestructiveInspect
Use this when the list owner wants to change an existing gift list: add items, remove items, change a quantity, show or hide claims, rename it, or close or reopen it for claims. Takes the private owner link. Removing an item hides it from friends and from the list export; claims already made on it are kept and count in the claim total (the owner page and export list them only when the owner chose to see claims). Does not edit friends' claims and does not make a new list.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | New note for friends; an empty string removes it. | |
| title | No | New title, e.g. Maya's 9th birthday. | |
| closed | No | true = close the list to new claims; false = reopen it. | |
| add_items | No | Items to add, e.g. [{"name":"Puzzle 1000 pieces","price":"$15"}]. | |
| manage_link | Yes | The private owner link from when the list was made, e.g. https://gift-list.zovo.one/m/AbC.../XyZ... (it contains /m/). | |
| remove_items | No | Exact names of items to remove, e.g. ["Wool scarf"]. | |
| set_quantities | No | New quantities, e.g. [{"name":"Hiking socks","quantity":3}]. | |
| show_claims_to_owner | No | true = show who claimed what on the owner page; false = hide claims. |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| title | Yes | |
| closed | Yes | |
| changes | Yes | |
| warnings | Yes | |
| manageUrl | Yes | |
| publicUrl | Yes | |
| expires_at | Yes | |
| item_count | Yes | |
| claim_count | Yes | |
| items_shown | No | |
| claims_hidden | Yes | |
| fully_claimed | No | |
| occasion_date | Yes | |
| removed_claims | No | |
| removed_claims_total | No |
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
- First observed
create_gift_list - First observed
show_gift_list_status - First observed
update_gift_list
Related MCP Connectors
Track the gifts you're buying, share wishlists, and claim family wishes without spoiling surprises.
Manage gift wishlists, reserve gifts on friends' lists and run a Secret Santa from a chat.
Hand-picked gift ideas for Valentine's Day, turned into shareable wishlists fast.
Hand-picked gift ideas for her (partner gifts), turned into shareable wishlists fast.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to browse public wishlists, check available gifts within budget, reserve items, and draft coordination messages without scraping or clicking through the UI.MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to create, manage, and discover family gift registries. Users can add links from Amazon, Target, and more through natural language.MIT

@shareawish/mcpofficial
AlicenseBqualityBmaintenanceEnables creators to build and manage Share a Wish affiliate shops and lets developers integrate wishlist baskets and save buttons directly from AI assistants like Claude and Cursor.3116 npmMIT- AlicenseNot gradedqualityBmaintenanceEnables AI agents to create password-protected, link-shareable lists and then read, edit, and restyle them — managing typed columns, rows, and per-list CSS, and looking up product pages to fill in prices, photos, and names. It exposes eighteen tools over Streamable HTTP with per-agent bearer tokens, so agents can build and maintain a shared list end to end.MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.