Plendio price comparison

Get a shop's details

get_store

Read-onlyIdempotent

Returns what Plendio knows about an online shop, given its domain: its name and country, whether and to which markets it ships, shipping fee, free-shipping limit and delivery time where the shop has stated them, its returns text, how many products it lists, how often it is the cheapest, shoppers' reviews on Plendio and the url of its store page. Shipping, returns and trust marks are the shop's own statements and are not verified; a field is absent when the shop has not stated it.

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": {
      "host": "<host>"
    },
    "name": "get_store"
  }
}

Input Schema

Name	Required	Description	Default
`host`	Yes	The shop's domain, e.g. elgiganten.dk (a full address is accepted).
`market`	No	Market the shopper is in, for the ships-to answer: dk, se, de or no. Default: the market of the site you connected to.

Output Schema

Name	Required	Description
`url`	Yes	The shop's store page on Plendio.
`host`	Yes
`name`	Yes
`notes`	No
`trust`	Yes
`market`	Yes
`country`	No	ISO 3166 country the shop is in.
`returns`	No	The shop's own returns text, clipped. Written by the shop.
`reviews`	No
`shipping`	No
`ships_to`	No	Markets (dk, se, de, no) the shop ships to.
`active_offers`	Yes
`price_position`	No	Present when enough products are contested for the figure to mean something.
`listed_products`	Yes
`ships_to_market`	Yes	yes when the store index lists the market among the shop's delivery countries, no when it lists others, unknown when it lists none.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description still adds real behavioral context beyond them: which data are the shop's own unverified statements (shipping, returns, trust marks) and the rule that fields are simply absent when unstated, which materially changes how an agent should interpret gaps.

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 sentences, with the core purpose front-loaded before the field enumeration and the caveats last. The field list is dense but every item conveys scope; slightly tighter phrasing would earn a 5.

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?

An output schema exists, so return values need not be explained, yet the description still summarizes coverage and adds the crucial unverified/absent-field caveats. For a two-parameter read tool, nothing essential for correct invocation 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 both host and market are already documented, including the market enum and default. The description's phrase "whether and to which markets it ships" hints at what the market parameter affects, but adds no syntax or default detail beyond the schema, so 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?

Opens with a specific verb and resource, "Returns what Plendio knows about an online shop, given its domain," then enumerates the exact content (name, country, shipping, returns, product count, price-cheapest rate, reviews, store-page url). This makes it unmistakable versus product-level siblings like get_product or search_products.

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

Usage Guidelines3/5

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

The usage context is only implied: an agent infers it should call this when it already has a shop domain and wants shop-level facts. There is no explicit when-not guidance and no named alternative (e.g., pointing to search_products for discovering a host, or get_product for item-level data).

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?