Skip to main content
Glama

Start a wishlist group

create_wishlist_group

Starts a wishlist group, such as "Harper Family Christmas", where family or friends each keep a wishlist and quietly claim items from each other's, with the signed-in person as its organizer. They join it with their own wishlist ("{First name}'s Wishlist"), and the reply includes the invite link for them to share; everyone who joins through it gets a wishlist too. Nothing is sent to anyone. Optionally ties the group to one of their gift lists (from get_my_gift_lists), so it shares that list's date, or sets the group's own date. Secret Santas are set up in the Wishpile app.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "create_wishlist_group"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoThe occasion's date (YYYY-MM-DD), when not tied to a gift list
nameYes
gift_list_idNoTie the group to this gift list and use its date

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare that this is a non-idempotent, non-destructive create; the description adds substantive behavior: the caller becomes organizer, their own wishlist is auto-created, the reply carries a shareable invite link, joiners get wishlists too, and critically "Nothing is sent to anyone" (no notifications on their behalf). It does not address repeated invocation (duplicate groups) or permission requirements. It also clarifies a boundary — Secret Santa setup is out of scope for this tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the action and the concept before the optional parameters, and each sentence carries information an agent needs (organizer identity, invite link, no notifications, date tie-in). The closing sentence about Secret Santas is tangential, though it does define a scope boundary rather than being pure filler.

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

Completeness4/5

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

With no output schema, the description usefully discloses what the response contains (the invite link) and the side effects of creation, covering most of what an agent needs for a 3-parameter create. Gaps remain around duplicate-name behavior and authorization, minor for this tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes date and gift_list_id, but the description adds real meaning: gift_list_id is sourced from get_my_gift_lists and its date is inherited, while the standalone date is only for the untied case, making the two parameters' interaction clear. The required name parameter has no schema description and is only implied through the group-name example and the "{First name}'s Wishlist" convention.

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

Purpose4/5

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

Opens with a specific verb and resource ("Starts a wishlist group") and elaborates what the object is: an organizer plus participants who each get their own wishlist and can claim items from each other. The example name "Harper Family Christmas" anchors it concretely. It does not explicitly contrast with create_wishlist or list_my_groups, so an agent must infer that this creates a group rather than an individual list.

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

Usage Guidelines4/5

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

Gives a clear usage scenario (family/friends coordinating wishlists and quiet claims) and a prerequisite: the date field applies only when not tied to a gift list from get_my_gift_lists. It points to the sibling that supplies gift_list_id. There are no explicit exclusions telling the agent when to pick create_wishlist instead.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources