rakentaja-outlet
Server Details
Finnish e-commerce for electrical & construction supplies. Read-only MCP with 4 tools.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.7/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: cart link generation, product details, catalog search, and policy/FAQ search. No overlap or ambiguity.
All tools use a consistent verb_noun pattern in snake_case: create_cart_link, get_product_details, search_catalog, search_shop_policies_and_faqs.
With 4 tools, the set is well-scoped for a store assistant. It covers core shopping flows without being bloated. A category listing tool could be a minor addition.
Covers product search, details, cart creation, and policies. Missing user account or order management, but these are reasonable omissions for the assistant role.
Available Tools
4 toolscreate_cart_linkARead-onlyIdempotentInspect
Create a pre-filled shopping cart URL for Rakentaja Outlet.
Given a list of product IDs and quantities, returns a URL that the user can open in their browser. When they open the link, the items are added to their browser cart session, and they are redirected either to the cart page (default) or directly to checkout.
This tool is FULLY SIDE-EFFECT-FREE: it does not create the cart on the server, does not touch any database, and does not modify any state. The cart materializes only when the user chooses to open the URL. This is a deliberate security design — the user always approves cart contents visibly before the state change happens.
Args:
items: List of {"product_id": int, "quantity": int} dicts.
Maximum 20 items, maximum quantity 50 per line.
Use search_catalog + get_product_details to find IDs first.
checkout: If True, the link takes the user directly to checkout
(skipping the cart review page). Default False — user sees
the cart first, which is safer and more transparent.
Returns: JSON with: - url: the browser URL to give the user. Contains all cart items as query parameters. Opening it will populate their cart. - items: deduplicated items list that will be added (same product_id appearing multiple times is merged with combined quantity) - total_lines: number of unique products in the link - total_quantity: sum of quantities across all products - checkout: echoed checkout flag - disclaimer: legal notice about approval flow
On error, raises MCP ToolError → response has isError:true with
structured JSON: {"error": {"code": "empty_items" | "too_many_items"
| "invalid_item" | "quantity_too_large" | "products_not_found"
| "backend_unavailable", "message": "...", "field": null,
"retryable": true|false}}. The StructuredErrorMiddleware ensures
consistent format across all tools.Example: create_cart_link(items=[ {"product_id": 9437, "quantity": 2}, {"product_id": 4927, "quantity": 1}, ]) → {"url": "https://rakentajaoutlet.fi/mcp-backend/lisaa-kori?items=9437:2,4927:1", ...}
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Cart items (1-20 lines) | |
| checkout | No | If True, link goes directly to checkout; otherwise to cart review page |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Browser URL to give the user — opening it populates their cart |
| items | Yes | Deduplicated cart items |
| checkout | Yes | If true, link takes user directly to checkout |
| disclaimer | Yes | |
| total_lines | Yes | Number of unique products in link |
| total_quantity | Yes | Sum of quantities across all products |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states it is side-effect-free, does not create a server-side cart, and that the state change occurs only when the user opens the URL. This aligns with annotations (readOnlyHint, idempotentHint) and adds valuable security context.
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 with sections (Args, Returns, Example) and front-loaded with the purpose. It is slightly verbose but every section is informative and earns its place.
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 annotations, full schema coverage, and presence of an output schema in the description, the tool definition is complete. It explains return fields, error handling, and gives a concrete example, 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?
Schema coverage is 100%, and the description adds meaning beyond the schema: explains max items (20), max quantity (50), duplicate merging, and default behavior for checkout. Also includes an example and error code details.
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: 'Create a pre-filled shopping cart URL for Rakentaja Outlet.' It uses a specific verb ('create') and resource ('cart link'), and distinguishes itself from sibling tools like search_catalog and get_product_details.
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 explains when to use the tool (given product IDs and quantities), provides prerequisites (using search_catalog + get_product_details), and mentions the user approval flow. It lacks an explicit when-not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_detailsARead-onlyIdempotentInspect
Get full details for a single Rakentaja Outlet product.
Fetches both the product record and a real-time availability check
in parallel. Use this after search_catalog returns a product ID
to show the user complete information (full description, all images,
current stock).
Args:
product_id: Product ID from search_catalog results (integer).
Returns: JSON with product details: - id, name, sku, ean, brand, category - description (full HTML/text), description_short - price_gross (incl. 25.5% VAT), price_net, vat_percent, currency - available_for_order (bool), availability_status ("in_stock" | "supplier_stock" | "out_of_stock"), estimated_delivery_min_days, estimated_delivery_max_days - in_stock, stock_quantity, supplier_in_stock, supplier_stock_quantity (raw fields — prefer available_for_order + availability_status) - weight_kg, unit - product_url (direct link to product page) - image_url (main image), images (list of all image URLs) - availability: fresh stock check result (may be more current than stock_quantity if inventory changed since catalog was cached) - disclaimer: legal notice that prices are indicative
On error, raises MCP ToolError → response has isError:true with
structured JSON: {"error": {"code": "not_found" | "invalid_argument"
| "backend_unavailable", "message": "...", "field": null|str,
"retryable": true|false}}. The StructuredErrorMiddleware ensures
the format is consistent across all tools.Notes:
- Prices include Finnish 25.5% VAT. Business buyers see price_net
for VAT-registered net price.
- Pass product_url to the user for viewing or adding to cart —
do not attempt to add to cart via this tool (use create_cart_link).
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Product ID from search_catalog results |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Product ID (use with get_product_details for full info) |
| ean | No | |
| sku | No | |
| name | Yes | |
| unit | No | |
| brand | No | |
| images | No | All product image URLs |
| category | No | |
| currency | No | |
| in_stock | Yes | |
| image_url | No | |
| price_net | Yes | Net price for VAT-registered business buyers |
| weight_kg | No | |
| disclaimer | Yes | |
| description | Yes | Full product description (may contain HTML) |
| price_gross | Yes | Gross price incl. 25.5% Finnish VAT |
| product_url | Yes | Direct link to product page — pass this to the user |
| vat_percent | No | |
| availability | No | Fresh availability check (may be more current than stock_quantity) |
| stock_quantity | Yes | |
| description_short | No | |
| supplier_in_stock | Yes | |
| availability_status | Yes | Detailed status: in_stock = own warehouse, supplier_stock = from supplier |
| available_for_order | Yes | Whether customer can order this — TRUE if in own stock OR supplier stock available |
| supplier_stock_quantity | Yes | |
| estimated_delivery_max_days | No | Hitain toimitusarvio arkipäivinä (null = ei saatavilla) |
| estimated_delivery_min_days | No | Nopein toimitusarvio arkipäivinä (null = ei saatavilla) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds real-time availability fetch, VAT details, error format, and field clarifications (e.g., prefer available_for_order over raw fields). 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?
Description is well-structured with clear sections (overview, Args, Returns, Notes). Front-loaded with main purpose. Slightly verbose in Returns section but every sentence adds necessary detail. Could be trimmed slightly.
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 schema and annotations, description covers all needed aspects: purpose, usage, parameter, detailed return format, error handling, and practical notes (VAT, not for cart). Output schema exists but description still explains fields. No obvious 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?
Only one parameter (product_id) with 100% schema coverage. Description repeats schema info ('Product ID from search_catalog results') without adding new meaning about format or constraints. Adequate but adds no extra value beyond 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 that the tool gets full details for a single product, fetching both product record and real-time availability. It explicitly distinguishes from siblings by stating 'Use this after search_catalog returns a product ID' and warns against adding to cart (use create_cart_link 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: 'Use this after search_catalog returns a product ID to show the user complete information' and 'do not attempt to add to cart via this tool (use create_cart_link)'. This clearly defines when to use and when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_catalogARead-onlyIdempotentInspect
Search Rakentaja Outlet product catalog.
Rakentaja Outlet (rakentajaoutlet.fi) is a Finnish online store specializing in electrical and construction supplies at outlet prices (~4000 products). All prices in EUR including 25.5% Finnish VAT.
Args:
query: Free-text search — matches product name, SKU, EAN code, or
category name. Leave empty to browse without a search term.
category_id: Filter to products in a specific category (integer ID).
The full list of categories is available at
https://rakentajaoutlet.fi/api/categories — this is a public
REST endpoint, not an MCP tool. Combines with query if both given.
in_stock_only: If True (default), only show products currently in
stock (either in own warehouse or at supplier). Set to False
to include out-of-stock products in results.
sort: Sort order — "name" (default), "price_asc", "price_desc",
or "newest". Ignored when query is given; search results are
ordered by relevance instead.
limit: Maximum products to return (1-50, default 10). Use a small
limit for interactive queries; larger for bulk listing.
page: Page number for paginated results (default 1). Combine with
limit to page through results larger than the limit.
Returns: JSON with keys: - products: list of product summaries with: - id, name, category, brand, sku, ean, unit - price_gross (incl. 25.5% VAT), price_net, currency - description (max 200 chars, description_truncated=true for longer) - available_for_order: boolean — can the customer place an order? (TRUE if in own stock OR supplier stock available) - availability_status: "in_stock" | "supplier_stock" | "out_of_stock" - estimated_delivery_min_days / _max_days: delivery estimate (or null) - in_stock, stock_quantity, supplier_in_stock, supplier_stock_quantity (raw fields — prefer available_for_order + availability_status) - product_url, image_url - total: total matching products across all pages - page: current page number - per_page: products per page (== limit) - total_pages: total pages available - disclaimer: legal notice that prices are indicative and confirmed at checkout
Notes:
- Prices include Finnish 25.5% VAT (price_gross) and net price
(price_net) is shown for VAT-registered business buyers.
- product_url is a direct link to the product page — pass this to
the user for viewing or adding to cart.
- Use get_product_details(id) for full description and stock check.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (>= 1) | |
| sort | No | name | |
| limit | No | Max products to return (1-50) | |
| query | No | Free-text search term | |
| category_id | No | Category ID (see https://rakentajaoutlet.fi/api/categories for the list) | |
| in_stock_only | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| total | Yes | Total matching products across all pages |
| per_page | Yes | |
| products | Yes | |
| disclaimer | Yes | |
| total_pages | Yes | |
| suggested_queries | No | Alternative queries that would return results — populated when total=0 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds significant behavioral context: returns JSON structure, prices include 25.5% Finnish VAT, sorting is ignored when query is given, available_for_order combines multiple stock sources, and delivery estimate fields. It fully explains the tool's behavior without contradicting 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 with Args, Returns, and Notes sections, and is front-loaded with purpose and context. It is relatively long but each sentence adds value. Slightly more conciseness could improve, but overall it is appropriately sized for the tool's complexity.
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 (6 parameters, rich output, pagination, sorting rules, external category list), the description is remarkably complete. It covers all output fields, explains edge cases (sorting ignored when query given), references sibling tools, and includes legal disclaimers. No gaps observed.
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 description adds substantial meaning beyond the schema: query is free-text matching name/SKU/EAN/category, category_id links to external public endpoint, in_stock_only default True explained, sort enum values fully described, and limit/page with defaults and pagination notes. Schema coverage is 67%, and the description compensates fully.
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 it searches the Rakentaja Outlet product catalog and distinguishes itself from siblings like get_product_details (for full details) and create_cart_link (for cart actions). It explicitly notes that product_url can be passed to the user for viewing or adding to cart, and mentions using get_product_details for full description, which differentiates the tools.
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 extensive usage guidance: when to use (searching products), when to use alternatives (get_product_details for full details), pagination advice (small limit for interactive queries, larger for bulk), sorting behavior (ignored when query is given), and how to obtain category list from an external REST endpoint. It also notes that leaving query empty allows browsing without a search term.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_shop_policies_and_faqsARead-onlyIdempotentInspect
Search Rakentaja Outlet shop policies, FAQ, and store info.
Searches across 8 pages: About Us (tietoa-meista), FAQ (usein-kysyttya), Delivery terms (toimitusehdot), Privacy Policy (tietosuoja), Terms of Use (kayttoehdot), Return Form (peruutuslomake), Payment Methods (maksutavat), AI Agent Guide (ai).
Use this tool when the user asks about:
Delivery times and costs ("toimitusaika", "toimituskulu")
Returns and refunds ("palautus", "peruutus", "hyvitys")
Payment methods ("maksutavat", "lasku")
Privacy or GDPR ("tietosuoja", "GDPR")
Terms of use ("käyttöehdot")
Company information ("Sanere Oy", "yhteystiedot", "Y-tunnus")
Any general question about buying from the store
Args: query: Free-text search term (Finnish). Case-insensitive. Leave empty to get an overview of all policy pages. limit: Maximum sections to return (1-10, default 5). Each section is a paragraph or Q&A pair; longer content is truncated.
Returns: JSON with: - sections: list of matching sections, each with: - page_slug: e.g. "usein-kysyttya" - page_title: e.g. "Usein kysyttyä" - page_url: full URL to the page - heading: section heading if any - text: matching text content (may be truncated) - is_faq: True if this is a Q&A from the FAQ page - total_matches: total sections matched - query: echoed query - available_pages: list of all policy page slugs - disclaimer: legal reminder to check the full page
Notes: - Policies are the authoritative source; if unclear, direct the user to the page_url for the full text. - Some FAQ entries are marked with FAQPage schema.org markup — these show up as Google rich results.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max sections to return (1-10) | |
| query | No | Free-text search term (Finnish) |
Output Schema
| Name | Required | Description |
|---|---|---|
| query | Yes | Echoed query |
| sections | Yes | Matching sections (limited by `limit`) |
| disclaimer | Yes | |
| total_matches | Yes | Total sections matched (may be > len(sections) if limited) |
| available_pages | Yes | All 8 policy page slugs |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: lists exact pages searched, mentions resulting sections, FAQ flag, disclaimer, and schema.org markup. Annotations already show it is read-only and idempotent.
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 clear sections (purpose, usage, args, returns, notes). Slightly lengthy but all sentences are informative and not redundant.
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 tool complexity (searching multiple pages, 2 params, output schema exists), description fully covers what the tool does, how to use it, and what to expect in return. 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?
Description adds meaningful details beyond schema: query is Finnish case-insensitive, empty for overview; limit defines sections as paragraphs or Q&A pairs with truncation. Schema coverage is 100% but description enriches understanding.
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?
Description clearly states it searches shop policies, FAQ, and store info across 8 specific pages, with a verb ('search') and specific resource. Distinct from sibling tools like search_catalog or get_product_details.
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 lists when to use with example queries (delivery, returns, payment, etc.). Does not explicitly state when not to use, but context implies for policy-related queries only.
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!