kuantokusta-mcp
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@kuantokusta-mcpsearch for iPhone 15 and show cheapest price"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
kuantokusta-mcp
MCP server for KuantoKusta.pt — Portugal's main product price comparator.
Tools
search
Search for products with optional filters. Returns up to 48 products per page sorted by your chosen order (default: cheapest first).
Parameters:
query— search keywords (e.g."frigorifico","iphone 15","tv 55")area— category filter (e.g."Electrodomésticos","Informática","Televisores")sort—"cheap"(default) |"expensive"|"popular"|"alphabetical"|"newest"price_min/price_max— price range in EUR (integers)brands— list of brand names (e.g.["Samsung", "LG"])page— page number (default 1)
get_product
Get full details for a product URL from a search result: name, description, 45+ tech specs, and all store offers sorted by total price (product + shipping).
Related MCP server: ksp-mcp
Install
cd tools/kuantokusta-mcp
python -m pip install -e .Add to Claude Desktop
Merge claude_desktop_config.snippet.json into your Claude Desktop claude_desktop_config.json:
{
"mcpServers": {
"kuantokusta": {
"command": "python",
"args": ["-m", "kuantokusta_mcp.server"]
}
}
}Available Tools
2 toolsget_productA
Get full details and all store prices for a KuantoKusta product.
Pass the product URL from a search result. Returns the product name,
description, technical specs (45+ attributes), and all store offers sorted
by total price (product + shipping) — so you always see the true
cheapest option, not just the lowest sticker price.
Args: url: KuantoKusta product URL from a search result, e.g. "https://www.kuantokusta.pt/p/1967884/mini-com-congelador-smeg-fa120e"
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations exist, the description reveals key behaviors: returns 45+ attributes, sorts offers by total price for true cheapest option. It does not explicitly state read-only, but the nature of a 'get' is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs with a bulleted args section. No redundant text; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description doesn't need to detail return structure. It covers use case, input, and key output features, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'url' parameter is fully described with a clear explanation and example URL. Schema coverage is 0%, so the description compensates completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full details and store prices for a KuantoKusta product, which is distinct from the sibling 'search' tool that returns search results. The verb 'get' and resource 'product' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to pass a product URL from a search result, indicating it should be used after search. No when-not-to-use is stated, but context makes it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchA
Search for products on KuantoKusta.pt — Portugal's main price comparator.
Returns up to 48 products per page plus available_filters showing all
filter options that can be applied to narrow the results. Filters are
dynamic and change per product type — always read available_filters
from the response rather than guessing values.
Recommended workflow:
Call search with just
query(and optionallysort/price range).Read
available_filtersin the response to see areas, brands, and product-specific filters (color, capacity, energy class, typology…).Call search again with the desired filter values to get refined results.
Args:
query: Search keywords, e.g. "frigorífico", "iphone 15", "tv 55 polegadas".
area: Top-level category — use a value from available_filters where
field="area". Example: "Electrodomésticos", "Informática".
family: Sub-category within an area — use a value from available_filters
where field="family". Example: "Grandes Electrodomésticos".
sort: "cheap" (default) | "expensive" | "popular" | "alphabetical" | "newest".
price_min: Minimum price in EUR (integer).
price_max: Maximum price in EUR (integer).
brands: List of brand names — use values from available_filters where
field="brand". Example: ["Samsung", "LG"].
features: Dict of product-type-specific filter values — keys and valid values
come from available_filters where field is NOT area/family/brand.
Example: {"tipologia_s": "combinados", "cor_s": "inox",
"classe_energetica_s": "classe a"}.
For a laptop search the keys would be different (ram_s, os_s, etc.)
— always derive them from the previous call's available_filters.
page: Results page number (default 1; ~48 products per page).
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | ||
| page | No | ||
| sort | No | cheap | |
| query | Yes | ||
| brands | No | ||
| family | No | ||
| features | No | ||
| price_max | No | ||
| price_min | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pagination up to 48 products, dynamic filters, and iterative refinement. Although no annotations exist, it adequately describes read-only behavior without explicit mention of non-destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections and bullet-pointed args. Slightly lengthy but every sentence adds value; front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: workflow, parameter usage, dynamic filters, and output schema existence. Suitable for complex multi-parameter search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema lacks parameter descriptions (0% coverage), but the tool description compensates with thorough explanations, examples, and derivation rules for each parameter, adding significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for products on KuantoKusta.pt, a price comparator. It distinguishes from sibling get_product by focusing on multi-product search with filters and pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a recommended 3-step workflow using available_filters dynamically. However, it doesn't explicitly contrast with the sibling tool or state when not to use this tool.
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. Dates show when Glama detected each change.
2 tool updates
v0.1.0- First observed
get_product - First observed
search
TDQS
Each tool has a clearly distinct purpose: search finds products and get_product retrieves full details for a specific product URL, eliminating any ambiguity.
Both tools follow a consistent verb_noun pattern: 'search' and 'get_product', making the naming predictable and clear.
With only two tools, the server is minimal but covers the core workflow of searching and viewing product details. It is slightly under the typical range but reasonable for a focused price comparator.
The tool surface covers searching and retrieving product details, which are the primary actions. Minor gaps exist, such as no direct category browsing or comparison tools, but agents can work around these.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Search ~8.5M products from 2,500+ Central European e-shops. Semantic, keyword, GTIN lookup.
Search products, compare prices and discover deals across 6 European markets with your AI assistant.
Cross-merchant product search with real price history, comparisons, and demand signals.
Shopping search across 100M+ products, with every retailer's offer and live price in one place.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables product search and retrieval from e-commerce APIs, returning markdown-formatted product listings with clickable links and prices for easy shopping assistance.6MIT
- AlicenseNot gradedqualityDmaintenanceEnables searching and browsing products on KSP.co.il, one of Israel's largest electronics and retail stores, using natural language.325MIT
- AlicenseAqualityBmaintenanceEnables searching geizhals.de for products and retrieving shop prices and offers to assist with price comparison.2MIT
- FlicenseNot gradedqualityDmaintenanceEnables searching and comparing products across Pakistani e-commerce platforms Daraz, Telemart, and iShopping, filtering by price and ratings.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ThiagoJacobLannes/kuantokusta-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server