Plendio price comparison

Server Details

Price comparison and product search for Denmark, Sweden, Germany and Norway. Read-only, no login.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-30 16:23
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.1/5.0

Scored 2026-09-30 06:35 across 4 tools

Disambiguation4/5

compare_prices and get_product both return per-shop offers for a product, so there is some overlap in output. However, their primary purposes are largely distinct: one focuses on comparing shops by price, the other on full product details including specs and history. search_products and list_categories are clearly separate.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: compare_prices, get_product, list_categories, search_products. There are no deviations or mixed conventions.

Tool Count5/5

Four tools are well-scoped for a price comparison service: search, browse categories, retrieve product details, and compare offers. Each tool has a clear role and there is no redundant or filler tool.

Completeness4/5

The surface covers the core price comparison workflow: searching, browsing categories, getting detailed product info, and comparing shops. Minor gaps exist, such as no dedicated shop or market listing endpoint, but these are not blocking for typical agent use.

Available Tools

4 tools

compare_pricesCompare pricesA

Read-onlyIdempotent

Inspect

Returns the shops selling one product, one offer per shop (its best, with a count of its other offers), cheapest first by total price including shipping (price alone where a shop's shipping is unknown), with each amount also converted to the market's currency. Offers that are in stock come first. Out-of-stock offers are left out unless include_out_of_stock is true, and only shops that ship to the market are listed unless include_other_markets is true. The result includes the url of the product's Plendio page.

ParametersJSON Schema

Name	Required	Description
`market`	No	Market the shopper is in: dk, se, de or no. Default: the market of the site you connected to.
`product_id`	Yes	Plendio product id (the id field of a search result, or the number at the end of a Plendio product URL).
`include_out_of_stock`	No	Also list offers that are out of stock or discontinued. Default false: only offers a shopper can order now.
`include_other_markets`	No	Also list shops not known to ship to the market. Default false.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`url`	Yes	The product's page on Plendio, listing all its offers.
`notes`	No
`title`	Yes
`market`	Yes
`offers`	Yes	Cheapest first, by total price including shipping (price alone where shipping is unknown).
`currency`	Yes	Currency of the market.
`price_history`	No
`offers_omitted`	Yes	Offers left out because their shop does not ship to the market.
`out_of_stock_omitted`	Yes	Offers left out because they are out of stock or discontinued (set include_out_of_stock to list them).

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description goes well beyond them: sort order (cheapest first by total price including shipping), fallback when shipping is unknown, currency conversion, in-stock-first ordering, exclusion rules for out-of-stock and non-shipping shops, and the returned Plendio URL. That is substantial behavioral disclosure.

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?

The purpose and sort order are front-loaded, and the closing sentence about the returned URL is short and useful. However, the first sentence is a long run-on with several stacked clauses, which makes it denser than it needs to be for a four-parameter tool.

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 values need not be spelled out, yet the description still notes the included Plendio URL. Combined with the disclosed defaults, filtering rules and ordering, an agent has everything needed to call this correctly against its siblings.

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 baseline is 3. The description still adds meaning beyond the schema text by explaining the consequence of each flag ('only shops that ship to the market', 'offers a shopper can order now') and by disclosing the shipping-cost rule that governs the ordering the parameters influence.

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?

The description opens with a specific verb and resource ('Returns the shops selling one product') and immediately defines the granularity (one offer per shop, its best). This clearly separates it from get_product (product details) and search_products (product discovery) without needing to open any schema.

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?

Usage is implied by the scope statement and the flag semantics, but there is no explicit 'use this when...' or a named alternative for a shopper who only wants product facts rather than shop offers. The conditional behavior of include_out_of_stock/include_other_markets is described, which helps, but it is behavioral rather than routing guidance.

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

get_productGet product detailsA

Read-onlyIdempotent

Inspect

Returns one product by its Plendio id: specifications, one offer per shop (its best) with price, shipping, total, the same amounts in the market's currency, availability, condition and whether the shop ships to the market, a summary of the product's price history over the last year, and the url of its Plendio page. A product that was merged into another resolves to the current one.

ParametersJSON Schema

Name	Required	Description	Default
`market`	No	Market the shopper is in: dk, se, de or no. Default: the market of the site you connected to.
`product_id`	Yes	Plendio product id (the id field of a search result, or the number at the end of a Plendio product URL).

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`url`	Yes	The product's page on Plendio, listing all its offers.
`brand`	No
`notes`	No
`specs`	No
`title`	Yes
`images`	No
`market`	Yes
`offers`	Yes	Cheapest first.
`category`	No
`currency`	Yes	Currency of the market.
`in_stock`	Yes
`description`	No
`merged_from`	No	Set when product_id was merged into this product.
`offer_count`	Yes	Number of offers listed (shops that ship to the market, unless the tool was asked otherwise).
`price_history`	No

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: a merged product resolves to the current one, and each shop returns only its best offer with a market-currency conversion. No rate limits or error behavior, but solid added context.

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?

A single dense sentence that front-loads the verb and resource. The long tail enumerating return fields is informative but overlaps the output schema, making it slightly heavier than necessary; still, every clause carries real content.

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?

For a read-only two-parameter lookup with an output schema, the description is complete: it signals single-item scope, id provenance, currency conversion, offer selection, and the merged-product edge case. An agent has everything needed to call it correctly without guessing.

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 coverage is 100% and both parameters are documented in the schema (market enum with default, product_id format and source). The description only echoes the id concept and gestures at market currency; it adds no syntax or semantics beyond the schema, 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?

States a specific verb+resource ('Returns one product by its Plendio id') and enumerates the exact payload (specs, per-shop best offer with price/shipping/total, currency conversion, availability, condition, price history, URL). This is unmistakably the single-product detail tool, distinct from search_products and compare_prices.

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 description never says when to use this versus siblings or where the product_id comes from; that sourcing hint ('the id field of a search result, or the number at the end of a Plendio product URL') lives only in the parameter schema. Usage is implied by the single-id scope, but no explicit when/when-not guidance is given.

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

list_categoriesList categoriesA

Read-onlyIdempotent

Inspect

Returns Plendio's product categories with localized names, slugs and product counts: the top level, or the subcategories of parent. The counts are products available in the market.

ParametersJSON Schema

Name	Required	Description	Default
`market`	No	Market: dk, se, de or no. Default: the market of the site you connected to.
`parent`	No	Category path or slug whose subcategories to return. Omit for the top level.

Output Schema

ParametersJSON Schema

Name	Required	Description
`notes`	No
`market`	Yes
`parent`	No	Path of the category whose children these are; absent for the top level.
`language`	Yes	Language the names are in.
`categories`	Yes
`parent_name`	No

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safe-read profile is covered. The description adds useful scope context — that counts reflect products available in the given market — but says nothing about result size, hierarchy depth, or pagination behavior.

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?

A single well-constructed sentence that front-loads the resource and what it returns. It is slightly dense, packing the parent-mode behavior into the same sentence, but there is no wasted text.

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 only two optional parameters, full schema coverage, and an output schema handling the return shape, the description is nearly sufficient for correct invocation. The one remaining gap is result-set size/ordering behavior, which is minor.

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 parameters (market, parent) are already documented with enum values and defaults in the schema. The description restates the parent/top-level semantics without adding format or edge-case detail, so the baseline 3 applies.

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?

States a specific verb and resource ('Returns Plendio's product categories') and enumerates what each item contains (localized names, slugs, product counts), so the agent knows exactly what this retrieves. It does not explicitly distinguish itself from siblings like get_product or search_products, but the category-listing purpose is unambiguous.

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 clause 'the top level, or the subcategories of parent' implies when each mode applies, and the 'Omit for the top level' behavior signals the default. There is no explicit when-to-use guidance or routing against the sibling product tools, so usage is only implied.

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

search_productsSearch productsA

Read-onlyIdempotent

Inspect

Search Plendio's product catalogue: free text in Danish, Swedish, German, Norwegian or English ("laptop 32 GB RAM under 12000", "Sony WH-1000XM5", "running shoes women") plus optional filters. Spec words in the query (RAM, storage, screen size, price limits, in stock) are understood the way the Plendio website understands them. Each result has the cheapest current price, the number of shops selling it and the url of its Plendio page. Results are limited to shops that ship to the market unless include_other_markets is true. 24 results per page.

ParametersJSON Schema

Name	Required	Description
`page`	No	Result page, 24 products per page. Default 1.
`sort`	No	relevance (default), price_asc or price_desc.
`query`	Yes	What to look for, in any of the market languages or English: a product name, a type, or a description with specs and limits ("laptop 32 GB RAM under 12000"). Required unless category is given.
`shops`	No	Only offers from these shops, by domain, e.g. ["elgiganten.dk"].
`brands`	No	Only these brands (up to 25), e.g. ["Sony","Bose"].
`market`	No	Market to search: dk, se, de or no. Default: the market of the site you connected to (plendio.dk is dk).
`category`	No	Category slug to narrow the search to, e.g. computere.
`in_stock`	No	Only products that at least one shop has in stock.
`max_price`	No	Highest price, in the market's currency (major units).
`min_price`	No	Lowest price, in the market's currency (major units, e.g. 500 means 500 kr.).
`include_other_markets`	No	Also include products no shop ships to the market. Default false: only products the market's shoppers can have delivered.

Output Schema

ParametersJSON Schema

Name	Required	Description
`page`	Yes
`notes`	No
`query`	Yes
`total`	Yes	Number of matching products.
`market`	Yes
`applied`	No	Filters the search applied, including ones it read from the query text.
`currency`	Yes	Currency of the market.
`products`	Yes
`page_size`	Yes
`search_url`	Yes	The same search on the Plendio website.
`total_exact`	Yes	False when total is a lower bound ("at least").
`total_pages`	Yes
`did_you_mean`	No	Set when the results answer a corrected spelling of the query.
`understood_as`	No	Set when the query was a sentence: the product searches it was read as, which the results answer.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds real operational context beyond them: results are restricted to shops that ship to the market unless include_other_markets is true, and pagination is fixed at 24. It still doesn't hint at ranking behavior beyond the sort enum, but the added constraints are substantive.

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 purpose before the market/pagination caveats. Every sentence carries information, though the result-shape sentence slightly overlaps with what the output schema provides.

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?

With 11 parameters all documented, an output schema covering return values, and annotations covering safety, the description fills the remaining gaps (market-shipping restriction, page size, query interpretation) without redundancy.

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 baseline is 3, but the description adds meaning the schema does not: spec words in the query (RAM, storage, price limits, in stock) are interpreted the way the Plendio site interprets them, and the multi-language query framing clarifies the query field's intent.

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 ('Search Plendio's product catalogue') and immediately scopes it as free-text across five languages with optional filters. An agent can distinguish this from get_product (single retrieval), compare_prices, and list_categories without opening any 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?

Gives clear context for when the tool applies — free-text queries with embedded specs plus optional filters — and the example queries illustrate the intended input style. It does not explicitly name when to prefer a sibling (e.g. get_product for a known product), so it stops short of full when/when-not guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 30, 2026

Changedsearch_products1 field changed

addedOutput schema / properties / understood_as

Added value: +{
+  "description": "Set when the query was a sentence: the product searches it was read as, which the results answer.",
+  "items": {
+    "type": "string"
+  },
+  "type": [
+    "null",
+    "array"
+  ]
+}

1 tool updateSep 29, 2026

Changedcompare_prices1 field changed

addedOutput schema / properties / price_history

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "average": {
+      "type": "number"
+    },
+    "currency": {
+      "type": "string"
+    },
+    "current": {
+      "description": "Cheapest price now; absent when nobody sells it.",
+      "type": [
+        "null",
+        "number"
+      ]
+    },
+    "days": {
+      "description": "Length of the recorded history in days (at most 365).",
+      "type": "integer"
+    },
+    "highest": {
+      "type": "number"
+    },
+    "lowest": {
+      "type": "number"
+    },
+    "scope": {
+      "description": "What the history covers.",
+      "type": "string"
+    },
+    "since": {
+      "description": "First day of the recorded history (YYYY-MM-DD).",
+      "type": "string"
+    }
+  },
+  "required": [
+    "currency",
+    "lowest",
+    "average",
+    "highest",
+    "since",
+    "days",
+    "scope"
+  ],
+  "type": [
+    "null",
+    "object"
+  ]
+}

4 tool updatesSep 29, 2026
- First observedcompare_prices
- First observedget_product
- First observedlist_categories
- First observedsearch_products

Related MCP Connectors

glowjakt A
se.glowjakt
Nordic beauty price comparison: 500k+ EAN-matched products, 70+ stores, true landed-cost pricing.
E-commerce & Retail Search Web Scraping
71
BestPrice Shopping A
gr.bestprice
Read-only shopping decisions, product search, offers, and price history for Greece.
E-commerce & Retail Search
416
shelfatlas-catalog
io.github.SlambertDK
Danish grocery catalog as MCP tools: live offers across all major chains, stores, EAN lookup, stock.
E-commerce & Retail Search
1
Compera A
io.github.fredxhansson-cmyk
Live Swedish price & service comparison (products, broadband, mobile, electricity, loans)
E-commerce & Retail Finance Energy
91

Related MCP Servers

idealo MCP Serverofficial
E-commerce & Retail Search
idealo
A
license
Not graded
quality
F
maintenance
Enables product search, price comparison, and price history analysis across 6 European marketplaces (DE, AT, GB, FR, IT, ES).
Updated 4 months ago (2026-05-20 10:01 UTC)
19
MIT
Finland Shopping MCP
E-commerce & Retail Search Web Scraping
xtofuub
A
license
Not graded
quality
D
maintenance
Enables AI assistants to search and compare live prices from Finnish marketplaces (Hinta.fi, Tori.fi, Huuto.net) for new and used products like electronics, furniture, and more.
Updated 3 months ago (2026-07-03 00:47 UTC)
MIT
Shoptera Product Intelligenceofficial
E-commerce & Retail Search
shoptera-ai
A
license
Not graded
quality
D
maintenance
Search product catalogs across thousands of Central European e-shops. Semantic search, keyword matching, GTIN/EAN lookup — via REST API or MCP. \~2,500 e-shops | ~8.5M products | 7 countries (CZ, SK, PL, HU, RO, DE, AT)
Updated 5 months ago (2026-04-15 13:49 UTC)
MIT
Czech DIY Retail MCP Server
E-commerce & Retail Web Scraping
uskaritel
A
license
A
quality
C
maintenance
Enables searching products, retrieving product details, listing stores, checking stock availability, and comparing prices across Czech DIY retailers.
Updated a month ago (2026-08-30 19:48 UTC)
5
MIT