Shoptera Product Intelligence
Server Details
Search ~8.5M products from 2,500+ Central European e-shops. Semantic, keyword, GTIN lookup.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- shoptera-ai/shoptera-product-intelligence
- GitHub Stars
- 0
- Server Listing
- Shoptera Product Intelligence
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 3 of 3 tools scored.
The tools have distinct purposes with clear boundaries: lookup_by_gtin for barcode queries, search_products for natural language discovery, and search_products_by_text for exact keyword matching. However, the distinction between search_products and search_products_by_text could cause some confusion as both handle text-based queries, though their descriptions clarify when to use each.
All tool names follow a consistent snake_case pattern with clear verb_noun structure: lookup_by_gtin, search_products, and search_products_by_text. The naming is predictable and readable throughout the set.
With only 3 tools, the set feels thin for a product intelligence server covering price comparison across 2,500+ e-shops. While the tools cover core search functionality, the lack of filtering, sorting, or analysis tools limits the server's scope and utility.
The server has significant gaps in its tool surface. It only provides search/lookup capabilities without any filtering, sorting, price tracking, alerting, or data analysis tools. For a product intelligence domain, this is severely incomplete as agents cannot perform common tasks like price trend analysis or setting up notifications.
Available Tools
3 toolslookup_by_gtinARead-onlyIdempotentInspect
Identify a product and compare prices across e-shops by its GTIN/EAN/UPC barcode.
Looks up the exact barcode across ~8.5M products from 2,500+ CEE e-shops.
Returns all listings for the same product so you can compare prices and availability.
Returns a dict with 'results' (list of product objects) and 'total_found' (int).
Each product contains: title, description, price, currency, brand, category, gtin,
image_url, product_url, availability, eshop_name, eshop_domain, origin_country,
target_countries, and cart_action.
The cart_action object tells you how to add the product to cart:
- method="GET": navigate to cart_action.url — product is added automatically.
- method="browser_click": navigate to cart_action.url, then click the button matching cart_action.button_text.
- method="view_product": show the product page URL to the user.
Use this tool when you have a barcode number. For natural language queries, use search_products instead.| Name | Required | Description | Default |
|---|---|---|---|
| gtin | Yes | GTIN, EAN, or UPC barcode number. Must be 8-14 digits without dashes or spaces. Supports EAN-8, EAN-13, UPC-A, and GTIN-14 formats. | |
| limit | No | Number of results to return. Range: 1-50. Default: 10. | |
| fields | No | List of field names to include in each result. Reduces response size by up to 70%. Available: title, description, price, currency, brand, category, gtin, image_url, product_url, availability, eshop_name, eshop_domain, origin_country, target_countries, cart_action. Default: all fields. | |
| origin_country | No | 2-letter ISO country code where the e-shop is based. Supported: CZ, SK, PL, HU, RO, DE, AT. | |
| target_country | No | 2-letter ISO country code to filter products available in that market. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it specifies the data source ('~8.5M products from 2,500+ CEE e-shops'), describes the return format in detail, and explains the cart_action object with specific methods. While annotations cover read-only, open-world, and idempotent properties, the description provides practical implementation details that help the agent understand how to use the results.
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?
The description is well-structured and efficiently organized: it starts with the core purpose, provides data scope context, details the return format, explains cart_action behavior, and ends with usage guidelines. Every sentence adds value without redundancy, and the information is appropriately front-loaded.
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?
Given the tool's complexity and the absence of an output schema, the description provides comprehensive context: it explains what the tool does, when to use it, the data source scope, detailed return format including nested objects, and practical usage guidance for cart_action. The annotations cover safety properties, and the description fills in the remaining behavioral gaps effectively.
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?
With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description doesn't add significant parameter semantics beyond what's in the schema, though it does mention the barcode format contextually. This meets the baseline expectation when schema coverage is complete.
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's purpose: 'Identify a product and compare prices across e-shops by its GTIN/EAN/UPC barcode.' It specifies the exact resource (product), verb (identify and compare prices), and distinguishes it from sibling tools by mentioning 'For natural language queries, use search_products instead.'
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?
The description provides explicit guidance on when to use this tool ('Use this tool when you have a barcode number') and when to use an alternative ('For natural language queries, use search_products instead'). It clearly differentiates this tool from its siblings based on input type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_productsARead-onlyIdempotentInspect
Search ~8.5M live products from 2,500+ Central European e-shops using natural language.
Understands intent, synonyms, and context in 7 languages (CS, SK, PL, HU, RO, DE, EN).
Use for product discovery, price comparison, gift ideas, or finding alternatives.
Faster and more structured than web crawling — returns real-time prices and stock status.
Returns a dict with 'results' (list of product objects) and 'total_found' (int).
Each product contains: title, description, price, currency, brand, category, gtin,
image_url, product_url, availability, eshop_name, eshop_domain, origin_country,
target_countries, score (0-1 relevance), and cart_action.
The cart_action object tells you how to add the product to cart:
- method="GET": navigate to cart_action.url — product is added automatically.
- method="browser_click": navigate to cart_action.url, then click the button matching cart_action.button_text.
- method="view_product": show the product page URL to the user.
Use 'fields' parameter to return only needed fields and save tokens.
Prefer this tool for open-ended queries. Use search_products_by_text when you know the exact product name,
or lookup_by_gtin when you have a barcode number.| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | Exact brand name filter (case-sensitive). Applied after semantic ranking. | |
| limit | No | Number of results to return. Range: 1-50. Default: 10. | |
| query | Yes | Natural language search query. Understands intent, synonyms, and context across Czech, Slovak, German, Polish, Hungarian, Romanian, and English. Examples: 'dárek pro zahradníka do 500 Kč', 'children shoes size 28', 'silver pendant with amethyst'. | |
| fields | No | List of field names to include in each result. Reduces response size by up to 70%. Available: title, description, price, currency, brand, category, gtin, image_url, product_url, availability, eshop_name, eshop_domain, origin_country, target_countries, score, cart_action. Default: all fields. | |
| category | No | Category keyword filter. Matches against the product's category field. | |
| currency | No | ISO 4217 currency code for price filters. Supported: CZK, EUR, PLN, HUF, RON. | |
| max_price | No | Maximum price filter as a decimal number. Requires 'currency' to be set for meaningful results. | |
| min_price | No | Minimum price filter as a decimal number. Requires 'currency' to be set for meaningful results. | |
| availability | No | Product availability filter. Values: 'in_stock', 'out_of_stock', 'preorder'. | |
| eshop_domain | No | Filter results to a specific e-shop by its domain, e.g. 'fantasyobchod.cz'. | |
| origin_country | No | 2-letter ISO country code where the e-shop is based. Supported: CZ, SK, PL, HU, RO, DE, AT. | |
| target_country | No | 2-letter ISO country code to filter products available in that market. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety aspects (readOnlyHint=true, destructiveHint=false, idempotentHint=true), but the description adds valuable context beyond that: it explains the multilingual understanding, real-time data, performance advantage over web crawling, and detailed return structure including cart_action behaviors. No contradictions with annotations.
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?
The description is well-structured and front-loaded with key information, but it includes some redundancy (e.g., listing all product fields when the schema already documents them). Most sentences earn their place by adding value, though it could be slightly more concise by avoiding duplication of schema details.
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?
Given the complexity of the tool (12 parameters, no output schema), the description provides comprehensive context: it explains the data source, multilingual capabilities, use cases, return format, cart_action details, and sibling tool differentiation. This compensates well for the lack of output schema and ensures the agent understands how to use the tool effectively.
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 description coverage is 100%, so the schema fully documents all 12 parameters. The description adds minimal parameter-specific information beyond the schema, mentioning the 'fields' parameter to save tokens and implying natural language querying, but most parameter semantics are already covered in the structured schema.
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 '~8.5M live products from 2,500+ Central European e-shops using natural language,' specifying the verb (search), resource (products), and scope (Central European e-shops). It distinguishes from siblings by explaining this is for 'open-ended queries' versus exact product names or barcode lookups.
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?
The description provides explicit guidance on when to use this tool ('open-ended queries'), when not to use it (when you know the exact product name or have a barcode number), and names specific alternatives ('search_products_by_text' and 'lookup_by_gtin'). It also suggests use cases like product discovery and price comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_products_by_textARead-onlyIdempotentInspect
Find specific products by exact keyword matching in titles across ~8.5M products from 2,500+ CEE e-shops.
Deterministic and fast — use when you know the exact product name, model number, or brand.
Returns real-time prices and stock availability for direct comparison.
Returns a dict with 'results' (list of product objects) and 'total_found' (int).
Each product contains: title, description, price, currency, brand, category, gtin,
image_url, product_url, availability, eshop_name, eshop_domain, origin_country,
target_countries, and cart_action.
The cart_action object tells you how to add the product to cart:
- method="GET": navigate to cart_action.url — product is added automatically.
- method="browser_click": navigate to cart_action.url, then click the button matching cart_action.button_text.
- method="view_product": show the product page URL to the user.
For open-ended natural language queries, use search_products instead.| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | Exact brand name filter (case-sensitive). Applied after keyword matching. | |
| limit | No | Number of results to return. Range: 1-50. Default: 10. | |
| title | Yes | Keywords to search in product titles. All words must be present in the title (AND logic). Examples: 'stříbrný přívěsek ametyst', 'Nike Air Max 90', 'dětské boty vel 28'. | |
| fields | No | List of field names to include in each result. Reduces response size by up to 70%. Available: title, description, price, currency, brand, category, gtin, image_url, product_url, availability, eshop_name, eshop_domain, origin_country, target_countries, cart_action. Default: all fields. | |
| category | No | Category keyword filter. Matches against the product's category field. | |
| currency | No | ISO 4217 currency code for price filters. Supported: CZK, EUR, PLN, HUF, RON. | |
| max_price | No | Maximum price filter as a decimal number. Requires 'currency' to be set for meaningful results. | |
| min_price | No | Minimum price filter as a decimal number. Requires 'currency' to be set for meaningful results. | |
| origin_country | No | 2-letter ISO country code where the e-shop is based. Supported: CZ, SK, PL, HU, RO, DE, AT. | |
| target_country | No | 2-letter ISO country code to filter products available in that market. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only, non-destructive, idempotent operation with open-world data. The description adds valuable behavioral context beyond annotations: it specifies the search is 'deterministic and fast,' returns 'real-time prices and stock availability,' and details the return structure including the 'cart_action' object with three distinct methods (GET, browser_click, view_product) that explain how to interact with results. This enriches the agent's understanding of the tool's behavior.
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?
The description is well-structured and front-loaded with the core purpose and usage guidelines in the first two paragraphs. Every sentence adds value: it explains the tool's function, when to use it, what it returns, and how to handle results, with no redundant information. The length is appropriate for the complexity of the tool.
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?
Given the tool's complexity (10 parameters, no output schema), the description provides complete context. It explains the purpose, usage guidelines, behavioral traits (like real-time data and cart_action details), and return structure. With annotations covering safety and idempotency, and the description adding operational context, this is sufficient for an agent to understand and use the tool effectively.
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 input schema has 100% description coverage, thoroughly documenting all 10 parameters with examples and constraints. The description does not add any parameter-specific information beyond what the schema provides. According to the rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.
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 'finds specific products by exact keyword matching in titles' across a defined dataset of ~8.5M products from 2,500+ CEE e-shops. It specifies the exact verb (find), resource (products), and scope (titles across specific e-shops), and distinguishes itself from its sibling 'search_products' which is for open-ended natural language queries.
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?
The description provides explicit guidance on when to use this tool ('use when you know the exact product name, model number, or brand') and when not to ('For open-ended natural language queries, use search_products instead'). It clearly names the alternative tool and specifies the deterministic and fast nature as context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.