Skip to main content
Glama

Plendio price comparison

Reserve a gift on a wishlist

reserve_gift
Idempotent

Marks one product on a shared wishlist as taken by the giver, given the list's share link, so that nobody else buys the same gift. Takes the share link, the product's Plendio id and optionally the giver's first name (letters only, up to 40 characters; it is shown to other givers on the list's page, and not to the person the list is for). Returns a reservation_token: it undoes the reservation and reserves more products under the same name; one token holds at most 5 reservations on a list. A product somebody else already reserved is reported and not changed. The person who made the list is not shown who reserved what, so the gift stays a surprise. No login is needed. Reserving does not buy the product.

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": {
      "share_url": "<share_url>",
      "product_id": "<product_id>"
    },
    "name": "reserve_gift"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoThe giver's first name, shown to other givers on the list's page. Letters, spaces, hyphens, apostrophes and full stops only, up to 40 characters. Default: a neutral word in the market's language.
marketNoMarket for the urls in the answer: dk, se, de or no. Default: the market the list was made for.
share_urlYesThe wishlist's share link, or the share id at the end of it. The edit link is not accepted.
product_idYesPlendio product id of the gift (the id of an item on the list).
reservation_tokenNoToken returned by an earlier reservation on this list, to reserve another product under the same name. Empty for the first reservation.

Output Schema

NameRequiredDescriptionDefault
urlNoThe product's page on Plendio, listing all its offers.
notesNo
titleNoThe product's title.
reservedYesTrue when the product is now reserved under the token; false after an unreserve.
share_urlYesThe list's page on Plendio.
list_titleYesThe list's name, written by whoever made it.
product_idYes
reservation_tokenNoKeep this: it undoes the reservation and reserves more products under the same name. Anyone holding it can give the product back.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false, idempotentHint=true, destructiveHint=false; the description goes much further. It discloses no-login auth, the 5-reservation cap per token, the conflict behavior (already-taken products are reported and unmodified), privacy semantics (the list owner is not shown who reserved what), and that reserving is not purchasing.

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?

Two dense sentences with the purpose front-loaded and no filler; each clause carries distinct information. It is slightly overloaded, packing token, conflict, privacy and non-purchase facts into one long second sentence, which weakens scannability a little.

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

Completeness5/5

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

Return handling is partly covered by the output schema, and the description still highlights the key returned artifact (reservation_token) and its reuse rules. For a mutation tool with side effects and privacy implications, everything an agent needs to call it correctly is present.

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?

Schema coverage is 100%, so the schema already documents each field; the description still adds meaning — that the name is visible to other givers but hidden from the list owner, and that the token both undoes the reservation and permits up to 5 reservations on one list. Minor inconsistency: it says the name is 'letters only' while the schema also allows spaces, hyphens, apostrophes and full stops.

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

Purpose5/5

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

States a specific verb and resource — 'Marks one product on a shared wishlist as taken by the giver' — with the intent ('so that nobody else buys the same gift'). This clearly separates it from siblings like get_wishlist, add_to_wishlist and unreserve_gift.

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?

Usage context is clear: use when a giver wants to claim a gift via a share link, and reuse the returned reservation_token to claim more products. It also distinguishes the share link from the edit link and states that an already-reserved product is reported rather than changed. It never names unreserve_gift as the inverse operation, so the alternative is only implied.

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