Plendio price comparison

Update a wishlist's details

update_wishlist

DestructiveIdempotent

Changes a wishlist's title, who it is for (recipient) and the day of the occasion (occasion_date, YYYY-MM-DD, today or later), given its edit link or the token at the end of it. Only the fields given are changed; clear_recipient and clear_occasion_date empty those two. The products on the list are not touched. Returns the list as it is now. The token stops working once the list has been saved to a Plendio account.

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": {
      "edit_token": "<edit_token>"
    },
    "name": "update_wishlist"
  }
}

Input Schema

Name	Required	Description
`title`	No	New name of the list. Up to 80 characters; markup and links are removed.
`market`	No	Market for the urls in the answer: dk, se, de or no. Default: the market the list was made for.
`recipient`	No	Who the list is for. Up to 80 characters; markup and links are removed.
`edit_token`	Yes	The wishlist's edit link as returned when it was created, or just the token at the end of it.
`occasion_date`	No	The day of the occasion as YYYY-MM-DD, today or later.
`clear_recipient`	No	True to remove the recipient.
`clear_occasion_date`	No	True to remove the occasion date.

Output Schema

Name	Required	Description
`items`	Yes
`notes`	No
`title`	Yes	The list's name, written by whoever made it.
`market`	Yes
`currency`	No	Currency of total_from.
`recipient`	No	Who the list is for, written by whoever made it.
`share_url`	Yes	The list's page on Plendio, read-only.
`item_count`	Yes
`total_from`	No	Sum of price_from over the available items; absent when their currencies differ or none has a price.
`occasion_date`	No	Day of the occasion, YYYY-MM-DD.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety bar is lower, but the description adds genuinely non-obvious traits: partial mutation, explicit clear_* semantics, that list products are unaffected, and the token's lifecycle expiry. 'Returns the list as it is now' is a useful response note though the output schema already covers shape.

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?

Four sentences, front-loaded with the mutation verb and affected fields, with mutation scope and clearing behavior following in logical order. Minor redundancy in the return-value sentence given an output schema exists.

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?

For a 7-parameter partial-update tool with full schema coverage, annotations, and an output schema, the description covers mutation scope, clearing, side effects on products, and token invalidation. It omits failure behavior (invalid/expired token, gone list), which would be the last gap.

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 baseline is 3, but the description adds cross-parameter meaning the per-field schema cannot: only supplied fields mutate, and clear_recipient/clear_occasion_date are the explicit removal mechanism for the other two fields. The YYYY-MM-DD and today-or-later constraints merely restate schema content.

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 (changes) plus the exact resource and the three mutable fields (title, recipient, occasion_date), and identifies the list via edit link or trailing token. It is clearly distinguishable from create_wishlist and get_wishlist in the sibling set without opening the schema.

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?

Explains the partial-update contract ('Only the fields given are changed') and how to clear the two date/recipient fields, and adds a real precondition: the token stops working once the list is saved to a Plendio account. It does not name a sibling alternative for read-only inspection, so it stops short of a 5.

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

All Plendio price comparison tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?