Plendio price comparison

Get gift ideas

gift_ideas

Read-onlyIdempotent

Returns popular gift ideas in a market: well-priced products that several shops sell, one per category and brand, refreshed hourly, with the cheapest current price and the url of each product's Plendio page. The recipient (mother, dad, a child, ...) and age choose the kind of ideas, a budget in the market's currency keeps them under a price, and the answer says how the request was understood. The ideas are popular picks for the market, not tailored to a person; the occasion is echoed in the answer and does not change the picks.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

Name	Required	Description
`age`	No	The recipient's age in years. Up to 12 gives ideas for children.
`budget`	No	Highest price per gift, in the market's currency (major units, e.g. 300 means 300 kr.).
`market`	No	Market: dk, se, de or no. Default: the market of the site you connected to.
`occasion`	No	The occasion, e.g. birthday or christmas. Echoed in the answer; it does not change the ideas.
`recipient`	No	Who the gift is for, in any market language or English: mother, dad, wife, a child, grandfather. Free text, up to 60 characters.

Output Schema

Name	Required	Description
`tab`	Yes	The kind of ideas chosen: all, her, him, kids or budget.
`ideas`	Yes
`notes`	No
`budget`	No
`market`	Yes
`currency`	No
`occasion`	No	The occasion as given. Not used to choose ideas.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the curation rule (one per category and brand, multiple shops), the refresh cadence (hourly), what the response contains (cheapest current price and Plendio page URL), and that the answer echoes how the request was understood. It also pre-empts a likely misconception by stating that occasion is echoed but does not change picks, which is exactly the kind of behavioral context annotations cannot convey.

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?

Three well-formed sentences, front-loaded with the resource definition before the parameter behavior and the personalization caveat. Dense but almost every clause carries information; the one soft spot is that the non-personalization point is spread across two sentences and partially repeats the occasion note already in the schema.

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?

An output schema exists, so return shape need not be explained, yet the description still names the salient returned fields (cheapest price, product URL) and adds the 'how the request was understood' note that helps an agent explain results to a user. With annotations covering the read-only/idempotent profile and all five parameters documented, nothing needed to invoke this correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already explains every parameter, including the market default, the age cutoff for children, and that occasion does not affect results. The description largely restates those facts ('a budget in the market's currency keeps them under a price', 'the occasion is echoed ... and does not change the picks') rather than adding new semantics, so the baseline 3 applies.

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?

Uses a specific verb and resource ('Returns popular gift ideas in a market') and immediately defines what those ideas are: well-priced products several shops sell, one per category and brand, refreshed hourly, with cheapest price and product URL. This is clearly distinguishable from sibling tools like search_products or get_deals, which have no such curation or per-category/brand claim.

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?

The description gives clear when-to-use context via the recipient/age/budget framing ('The recipient ... and age choose the kind of ideas, a budget ... keeps them under a price') and a strong caveat that results are not personalized ('popular picks for the market, not tailored to a person'). It never names an alternative sibling (e.g., search_products for a specific query) or states when not to use it, 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?