Which integrations are available for this server?

Provides tools for searching IKEA products, getting product details, checking store stock, comparing stock across stores, finding best stores for items or carts, and checking cart availability.

How do I use ikea-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ikea-mcp Find best store for BILLY bookcase in CA" 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.

ikea-mcp

by taejin5314

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

ikea-mcp

Read-only MCP server for IKEA product search and in-store stock lookup.

Transports: stdio (Claude Desktop / MCP CLI) · Streamable HTTP (remote clients) License: MIT · No auth required to run locally

Capabilities

Tool	What it does
`list_stores`	List known store IDs and labels, optionally filtered by country
`search_products`	Search IKEA products by keyword
`get_product_details`	Get details for a single product by item number
`check_store_stock`	Check cash-and-carry stock at one store
`check_multi_item_stock`	Check stock for multiple items at one store
`compare_store_stock`	Compare stock across explicit stores or a country catalog
`find_best_store_for_item`	Rank stores by in-stock quantity (optionally filter by country)
`check_cart_availability`	Check whether all items in a shopping list are available at one store
`find_best_store_for_cart`	Rank stores by cart fulfillment across multiple items

Related MCP server: kronan-mcp

MVP limitations

Uses unofficial public IKEA APIs — no SLA, may break without notice
Canada store coverage is complete (15 stores)
US coverage is incomplete — 4 small-format stores have unknown API IDs (Queens, Alpharetta, Indianapolis, Arlington)
San Francisco small-format store is intentionally excluded (known ID 3136 returns 405)
No extra stores are included
Cash-and-carry availability only — click-and-collect and home delivery not exposed
HTTP transport is open by default — set API_KEY env var to require x-api-key header on /mcp
Read-only — no cart, order, or account operations

Tools

`search_products`

Search IKEA products by keyword.

Input

param	type	default	required
`query`	string	—	yes
`countryCode`	string	`"US"`	no
`langCode`	string	`"en"`	no
`size`	number	`10`	no

Output

{
  "total": 97,
  "items": [
    {
      "itemNo": "20522046",
      "name": "BILLY",
      "typeName": "Bookcase",
      "salesPrice": { "amount": 69.99, "currencyCode": "USD" },
      "pipUrl": "https://www.ikea.com/us/en/p/...",
      "ratingValue": 4.8,
      "ratingCount": 1234
    }
  ]
}

`get_product_details`

Get details for a single IKEA product by item number.

Input

param	type	default	required
`itemNo`	string	—	yes
`countryCode`	string	`"US"`	no
`langCode`	string	`"en"`	no

Output

{
  "itemNo": "20522046",
  "name": "BILLY",
  "typeName": "Bookcase",
  "salesPrice": { "amount": 79, "currencyCode": "USD" },
  "pipUrl": "https://www.ikea.com/us/en/p/billy-bookcase-white-20522046/",
  "designText": "white",
  "measureText": "31 1/2x11x79 1/2 \"",
  "ratingValue": 4.6,
  "ratingCount": 2620
}

shortDescription and materials are not available from the underlying API.

`check_store_stock`

Check stock at a single IKEA store.

Input

param	type	default	required
`itemNo`	string	—	yes
`storeId`	string	—	yes
`countryCode`	string	`"US"`	no

Output

{
  "storeId": "399",
  "availableForCashCarry": true,
  "quantity": 110,
  "messageType": "HIGH_IN_STOCK",
  "errors": null
}

On error (e.g. item not carried):

{
  "storeId": "026",
  "availableForCashCarry": false,
  "quantity": null,
  "messageType": null,
  "errors": [{ "code": 404, "message": "Not found", "meaning": "item not stocked at this store" }]
}

`compare_store_stock`

Compare stock for one item across multiple stores. Provide explicit storeIds, or use countryCode to expand to all catalog stores for that country. At least one of storeIds or countryCode is required.

Input

param	type	default	required
`itemNo`	string	—	yes
`storeIds`	string[] (min 2)	—	one of `storeIds`/`countryCode`
`countryCode`	`"US"` \| `"CA"`	—	one of `storeIds`/`countryCode`
`sortBy`	`"quantity"` \| `"storeId"`	—	no

storeIds takes precedence — if both are provided, countryCode only sets the IKEA API locale. sortBy: "quantity" sorts descending, null quantities last, storeId as tie-breaker. sortBy: "storeId" sorts ascending. Omitting sortBy preserves input order.

Examples

{ "itemNo": "20522046", "storeIds": ["399", "026", "921"] }

{ "itemNo": "20522046", "countryCode": "CA" }

Output — array of the same shape as check_store_stock (one entry per store).

Detecting partial failures: rows with errors containing any code other than 404 indicate a store-level or API failure (e.g. 405 = invalid store ID). Rows with only 404 errors mean the item is simply not stocked at that store — this is expected, not a failure.

`check_multi_item_stock`

Check cash-and-carry stock for multiple items at a single store in one call.

Input

param	type	default	required
`storeId`	string	—	yes
`itemNos`	string[] (min 1, max 20)	—	yes

Output — array of per-item stock entries in the same order as itemNos:

[
  {
    "itemNo": "20522046",
    "storeId": "399",
    "storeLabel": "399 (Burbank, CA)",
    "availableForCashCarry": true,
    "quantity": 104,
    "messageType": "HIGH_IN_STOCK",
    "errors": []
  }
]

Items not stocked at that store appear with availableForCashCarry: false, quantity: null, and a 404 error entry. An invalid storeId (405) returns that error on every entry.

`find_best_store_for_item`

Find stores with the highest in-stock quantity for an item. Queries stores in parallel, excludes invalid stores (405), out-of-stock stores (404), and stores with unknown quantity. Results sorted by quantity descending; ties broken by storeId lexicographically.

Input

param	type	default	required
`itemNo`	string	—	yes
`storeIds`	string[]	all known stores	no
`maxResults`	number	`3` (max 50)	no
`countryCode`	`"US"` \| `"CA"`	—	no
`minQuantity`	number (int ≥ 1)	—	no

storeIds takes precedence. If only countryCode is given, searches all catalog stores for that country. If neither is given, searches all ~65 known stores. minQuantity excludes stores with quantity below the threshold.

Output — array of matching stores, up to maxResults:

[
  {
    "storeId": "399",
    "storeLabel": "399 (Burbank, CA)",
    "availableForCashCarry": true,
    "quantity": 104,
    "messageType": "HIGH_IN_STOCK"
  }
]

Returns [] if no store has the item in stock. "All known stores" means the ~65 US and Canada entries in src/data/stores.ts.

Note on failures: stores that return a store-level error (405 invalid store ID) are silently excluded from results rather than appearing as rows. Use compare_store_stock with the same storeIds to inspect per-store errors directly.

`check_cart_availability`

Check whether all items in a shopping list are available in sufficient quantity at a single IKEA store.

Input

param	type	default	required
`storeId`	string	—	yes
`items`	array of `{ itemNo, quantity }`	—	yes
`items[].itemNo`	string	—	yes
`items[].quantity`	number	`1`	no

Output

{
  "storeId": "399",
  "storeLabel": "399 (Burbank, CA)",
  "allSufficient": true,
  "items": [
    {
      "itemNo": "20522046",
      "quantity": 2,
      "inStock": 42,
      "sufficient": true,
      "eligibleForStockNotification": false,
      "errors": []
    }
  ]
}

allSufficient is true only when every item has sufficient: true. Items not stocked appear with inStock: null and a 404 error. An invalid storeId (405) propagates to all items.

`find_best_store_for_cart`

Find the best store to buy multiple items in one trip. Ranks stores by how many cart items are available in sufficient quantity, then by total in-stock sum. Optionally filter by countryCode or provide explicit storeIds.

Input

param	type	default	required
`items`	array of `{ itemNo, quantity }`	—	yes
`items[].itemNo`	string	—	yes
`items[].quantity`	number	`1`	no
`storeIds`	string[]	—	no
`countryCode`	`"US"` \| `"CA"`	—	no
`maxResults`	number	`3` (max 50)	no

storeIds takes precedence. If only countryCode is given, searches all catalog stores for that country. If neither is given, searches all ~65 known stores.

Output — array of stores ranked by cart fulfillment, up to maxResults:

[
  {
    "storeId": "399",
    "storeLabel": "399 (Burbank, CA)",
    "allSufficient": true,
    "fulfilledCount": 3,
    "totalCount": 3,
    "items": [
      { "itemNo": "20522046", "quantity": 2, "inStock": 42, "sufficient": true },
      { "itemNo": "40477340", "quantity": 1, "inStock": 5, "sufficient": true },
      { "itemNo": "89268919", "quantity": 1, "inStock": 12, "sufficient": true }
    ]
  }
]

fulfilledCount = number of items with sufficient: true. Sorting: fulfilledCount desc → total stock desc → storeId asc. Stores with invalid IDs (405) are excluded.

Example workflows

1. Search → inspect → check one store

1. search_products       { "query": "BILLY bookcase" }
   → pick itemNo from results, e.g. "20522046"

2. get_product_details   { "itemNo": "20522046" }
   → confirms name, price, dimensions before checking stock

3. check_store_stock     { "itemNo": "20522046", "storeId": "399" }
   → { "availableForCashCarry": true, "quantity": 95, "messageType": "HIGH_IN_STOCK" }

2. Shopping list at one store

Check whether several items are available in a single trip:

{
  "tool": "check_multi_item_stock",
  "storeId": "399",
  "itemNos": ["20522046", "40477340", "89268919"]
}

Returns one entry per item in the same order — items not stocked appear with availableForCashCarry: false and a 404 error.

3. Best store from a mixed US + Canada subset

{
  "tool": "find_best_store_for_item",
  "itemNo": "20522046",
  "storeIds": ["399", "039", "216", "149", "026"],
  "maxResults": 3
}

Returns the top 3 stores by in-stock quantity across the mixed US/Canada subset. Omit storeIds to search all ~65 known stores.

4. Best store for a shopping list

Find which store can fulfill the most items from a multi-item cart:

{
  "tool": "find_best_store_for_cart",
  "items": [
    { "itemNo": "20522046", "quantity": 2 },
    { "itemNo": "40477340", "quantity": 1 },
    { "itemNo": "89268919", "quantity": 1 }
  ],
  "countryCode": "CA",
  "maxResults": 3
}

Returns the top 3 Canada stores ranked by how many items they can fully supply. Use check_cart_availability to then verify exact quantities at the chosen store.

Build and test

npm install
npm run build        # tsc → dist/
npm run typecheck    # type-check without emit
npm test             # unit tests
node smoke.mjs       # end-to-end stdio smoke test

smoke.mjs exercises all 4 tools against the live IKEA API and prints pass/fail lines to stdout.

Transports

stdio (default — for Claude Desktop / MCP CLI):

npx ikea-mcp          # after npm install (uses bin entry)
node dist/index.js    # after local build
npm run dev           # dev (tsx, no build needed)

Streamable HTTP (for remote / network clients):

node dist/http.js          # listens on http://localhost:3000/mcp
PORT=8080 node dist/http.js
# or during dev:
npm run dev:http

Requests must include Accept: application/json, text/event-stream. Stateless — no session management.

Deploy (HTTP transport)

Tested target: Railway (also works on Render, Heroku, or any Procfile-aware host).

# 1. build
npm install && npm run build

# 2. run (Procfile: web: node dist/http.js)
#    PORT is set automatically by the host
node dist/http.js

The Procfile in the repo root declares web: node dist/http.js. PORT is read from the environment (default 3000). No other env vars required.

Endpoints after deploy:

POST /mcp — MCP Streamable HTTP (requires Accept: application/json, text/event-stream)
GET /health — returns {"status":"ok"}

Security note: Set API_KEY to protect the /mcp endpoint. Requests without a matching x-api-key header return 401. /health is always open. The server is read-only — no cart, order, or account operations are possible.
API_KEY=your-secret node dist/http.js

Connecting a local MCP client (stdio)

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "ikea-mcp": {
      "command": "npx",
      "args": ["-y", "ikea-mcp"]
    }
  }
}

Connecting a remote MCP client (HTTP)

Point your MCP client at https://<your-host>/mcp.

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "ikea-mcp": {
      "type": "http",
      "url": "https://<your-host>/mcp"
    }
  }
}

.mcp.json (project-local, Claude Code):

{
  "mcpServers": {
    "ikea-mcp": {
      "type": "http",
      "url": "https://<your-host>/mcp"
    }
  }
}

Manual / curl (for debugging):

curl -X POST https://<your-host>/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

The Accept: application/json, text/event-stream header is required by the MCP SDK — requests without it will be rejected with a -32000 error.

Store IDs

Store metadata (ID → city label) lives in src/data/stores.ts. ~50 US stores confirmed from ikea.com/us/en/stores/ pages; 15 Canada stores confirmed from ikea.com/ca/en/stores/ pages (all probed against the stock API).

Confirmed compatible storeId formats:

Standard 3-digit: "399" (Burbank, CA, US), "216" (Calgary, AB, CA)
Leading-zero 3-digit: "026" (Canton, MI, US), "039" (Montreal, QC, CA)
4-digit: "921" (Brooklyn, NY, US), "1129" (Syracuse, NY, US)

An invalid or unsupported storeId returns a 405 error in the errors array.

Limitations

Uses unofficial public IKEA APIs — no SLA, no auth required, may break without notice.
Read-only: no cart, no order, no account operations.
Country-wide fan-out (countryCode: "US" ≈ 52 stores, "CA" ≈ 15) is capped at 10 concurrent requests and retries once on transient 5xx/network errors.
Click-and-collect and home-delivery availability are not exposed (cash-and-carry only).
size in search_products is capped by IKEA's API (observed max ~24 per page; total reflects the full catalogue count).
US and Canada only — no other countries supported.

Item numbers

itemNo fields accept several formats — all are normalised to 8 digits internally:

Input	Normalised
`"20522046"`	`"20522046"`
`"522132"`	`"00522132"`
`"005.221.32"`	`"00522132"`
`"5-221-32"`	`"00522132"`

6- and 7-digit inputs are left-padded to 8 digits. 8- and 9-digit inputs are kept as-is. Values outside 6–9 digits after stripping are rejected.

Supported countries

Country	Code	Store count
United States	`US`	~52
Canada	`CA`	~15

Use list_stores to get the current catalog. Some store IDs in the catalog are unverified — they are listed but may return 405 from the stock API.

Rate limits & reliability

Fan-out requests (country-wide compare_store_stock / find_best_store_for_item) are capped at 10 concurrent outbound requests.
fetchJson retries once after 500 ms on 5xx, 429, or network errors. 404 and 405 are not retried (they are semantic responses, not transient failures).
Retry-After header is respected for 429 responses.
Do not use in high-frequency loops — the upstream IKEA API has no published rate limit but will block repeated bursts.

Troubleshooting

Symptom	Likely cause
`405` in `errors`	Invalid `storeId` — use `list_stores` to find valid IDs
`404` in `errors`	Item not stocked at that store
Empty `find_best_store_for_item` result	No store has the item in stock, or `minQuantity` is too high
Slow `countryCode` query	Normal — fan-out to all country stores (capped at 10 concurrent)
`itemNo` validation error	Input must resolve to 6–9 digits; see Item numbers above

Available Tools

9 tools

check_cart_availabilityB

Check whether all items in a shopping list are available in sufficient quantity at a single IKEA store.

ParametersJSON Schema

Name	Required	Description	Default
`items`	Yes
`storeId`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must carry the full burden. It discloses the read-only 'check' nature and the single-store condition, but does not explain the return format, how missing/insufficient items are reported, or potential error behavior. For a tool with no output schema, this is a significant transparency gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every word contributes to specifying the tool's scope and condition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no annotations, no output schema, and a sparse description. While the core purpose is clear, the absence of parameter details, usage guidance, and return-behavior information makes it incomplete for an agent deciding how and when to invoke it, especially with several sibling tools available.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate for the two parameters. It indirectly references 'shopping list' (items) and 'single IKEA store' (storeId), but adds no semantics about the structure of items (itemNo, quantity constraints) or the storeId format. The property names are self-explanatory, but the description adds minimal value beyond them.

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 uses a specific verb ('Check'), names the resource ('availability of all items in a shopping list'), and adds a clear condition ('sufficient quantity at a single IKEA store'). This distinguishes it from sibling tools like find_best_store_for_cart, which optimizes by store, and suggests a single-store verification.

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

Usage Guidelines2/5

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

No explicit guidance is given on when to use this tool versus alternatives such as check_multi_item_stock or find_best_store_for_cart. The description states the core purpose but does not mention scenarios where this tool is preferred, required, or contraindicated.

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

check_multi_item_stockA

Check cash-and-carry stock for multiple items at a single IKEA store.

ParametersJSON Schema

Name	Required	Description	Default
`itemNos`	Yes
`storeId`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only says 'check', implying a read operation, but does not disclose return format, whether stock is real-time, or any side effects. The term 'cash-and-carry' is not clarified, leaving the behavior vague.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no unnecessary words. It clearly states the action and scope in minimal characters, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description must explain what the result looks like and any limitations. It does not describe the response format (e.g., per-item availability, errors for invalid item numbers) or mention batch size limits, leaving the agent uncertain about the tool's full behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It maps 'multiple items' to itemNos and 'single store' to storeId, but this is already evident from the schema property names. It does not explain array constraints, maxItems, or any value formats, adding minimal meaning.

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 uses a specific verb 'check' and a clear resource: 'cash-and-carry stock for multiple items at a single IKEA store'. It distinguishes from siblings clearly by limiting to a single store and multiple items, unlike compare_store_stock (multiple stores) or check_store_stock (likely single item).

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?

The phrase 'multiple items' and 'single IKEA store' provide clear context for when to use this tool versus alternatives like compare_store_stock or find_best_store_for_item. While there is no explicit exclusion or naming of alternatives, the context is unambiguous.

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

check_store_stockB

Check stock availability for an item at a specific IKEA store.

ParametersJSON Schema

Name	Required	Default
`itemNo`	Yes
`storeId`	Yes
`countryCode`	No	us

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries full responsibility. It states the action ('check stock availability') but does not disclose behavioral traits such as the return format (boolean vs. quantity), how invalid item numbers or store IDs are handled, or whether it checks in-store availability only. The word 'check' implies a read operation, but that is not confirmed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no redundant words. Every word adds meaning, making it highly concise and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of annotations, output schema, and param coverage, the description is minimally viable but incomplete. It does not explain what the tool returns (e.g., stock count or just in-stock/out-of-stock), nor does it mention the countryCode parameter. While the tool's core purpose is clear, gaps remain for an agent to invoke it correctly without additional inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It mentions 'an item' and 'a specific IKEA store,' mapping to itemNo and storeId, but completely omits countryCode. The parameter names are somewhat self-explanatory, but the description adds no additional nuances, such as what countryCode does or whether it is optional.

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 uses the specific verb 'check' with the resource 'stock availability' and context 'for an item at a specific IKEA store.' This clearly distinguishes it from siblings like compare_store_stock (comparing) and check_multi_item_stock (multiple items), making the tool's single-item, single-store scope unmistakable.

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 implies usage for checking one item at one store but does not explicitly state when to use this tool over alternatives like compare_store_stock or check_multi_item_stock. No exclusions or alternative tool names are provided, so the context is only implied, not made explicit.

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

compare_store_stockA

Compare stock availability for an item across multiple IKEA stores. Provide explicit storeIds, or use countryCode ('US' or 'CA') to compare all catalog stores for that country.

ParametersJSON Schema

Name	Required	Description	Default
`itemNo`	Yes
`sortBy`	No
`storeIds`	No
`countryCode`	No

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It only states the core operation and store selection modes, but does not disclose return format, sortBy behavior, or what happens if neither storeIds nor countryCode is provided. The required parameter itemNo is not explained, and there is no mention of output structure or edge cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the purpose, and the second sentence provides usage modes without any redundant wording. It is concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 4 parameters, no output schema, and no annotations. The description covers the two store selection modes but omits sortBy semantics, default behavior when no store selection is provided, and any performance or output expectations. Sibling tools add context but the description itself leaves too much to inference.

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?

The description adds meaning to storeIds and countryCode by explaining their roles, but it does not explain itemNo (though it's obvious from context) or sortBy. The schema already defines enums for sortBy and countryCode, but with 0% schema description coverage, the description should compensate more; it partially does but leaves gaps.

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 states 'Compare stock availability for an item across multiple IKEA stores' which clearly identifies the verb (compare), resource (stock availability for an item), and scope (across multiple stores). It differentiates from siblings like check_store_stock (single store) and find_best_store_for_item (best store selection).

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?

The description provides explicit invocation modes: 'Provide explicit storeIds, or use countryCode' with valid country codes. This gives clear context on how to use the tool, but it doesn't explicitly mention when not to use it or compare it to alternatives like check_store_stock.

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

find_best_store_for_cartA

Find the best store to buy multiple items in one trip. Ranks stores by how many cart items are available in sufficient quantity, then by total in-stock sum. Optionally filter by countryCode ('US' or 'CA'). Explicit storeIds take precedence over countryCode.

ParametersJSON Schema

Name	Required	Description	Default
`items`	Yes
`storeIds`	No
`maxResults`	No
`countryCode`	No

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the ranking logic (items available in sufficient quantity, then total in-stock sum), the optional countryCode filter, and the precedence of storeIds over countryCode. However, it does not describe edge cases, output format, or behavior when no store matches, leaving notable gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, delivering the essential purpose, ranking criteria, and filtering options in two sentences with no wasted words. It is front-loaded with a clear verb and resource, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (ranking, optional filters, precedence) and the lack of both annotations and an output schema, the description covers the core logic but misses key contextual details such as return format, default behavior for maxResults, and handling of invalid storeIds. It is adequate for a high-level understanding but incomplete for fully uninformed invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides semantics for countryCode and storeIds, but fails to explain the items parameter structure (itemNo, quantity) and the maxResults parameter. The phrase 'cart items' hints at items but does not clarify the schema details, leaving the agent under-informed about how to construct valid inputs.

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 clearly states the tool's purpose: finding the best store for purchasing multiple items in one trip. It specifies the ranking criteria (number of items available and total in-stock sum) and distinguishes from sibling tools like find_best_store_for_item by focusing on multiple items.

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?

The description implies when to use the tool ('buy multiple items in one trip') and provides a clear context for the ranking. It does not explicitly name alternatives or exclusions, but the context is sufficient to differentiate from single-item tools like find_best_store_for_item.

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

find_best_store_for_itemA

Find stores with the highest in-stock quantity for an item. Returns up to maxResults stores sorted by quantity descending. Optionally filter by countryCode ('US' or 'CA'). Explicit storeIds take precedence over countryCode.

ParametersJSON Schema

Name	Required	Description	Default
`itemNo`	Yes
`storeIds`	No
`maxResults`	No
`countryCode`	No
`minQuantity`	No

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions sorting, limit, country filter, and storeIds precedence, but omits behavior regarding minQuantity, zero-stock stores, and no-match scenarios. This leaves significant gaps for a tool with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences that front-load the core purpose and sorting behavior, then add filter and precedence details. No redundant or wasted words; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema or annotations exist, so the description must explain return values and edge cases. It provides a high-level return format but lacks detail on actual fields, error handling, and how minQuantity influences results. The tool has moderate complexity, so the description is adequate but not complete.

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?

With 0% schema description coverage, the description adds meaning to maxResults, countryCode, and storeIds (including precedence), but fails to mention itemNo (the required param) and minQuantity. It partially compensates but does not fully document all parameters.

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 clearly states the tool's purpose: find stores with the highest in-stock quantity for a single item. It distinguishes itself from siblings like check_store_stock or find_best_store_for_cart by specifying the item-level search and the sorting by quantity descending.

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 name and description, but there is no explicit guidance on when to choose this over alternatives like compare_store_stock or check_multi_item_stock. It does provide contextual info about optional filters and precedence, but no direct exclusions or comparisons.

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

get_product_detailsB

Get details for a single IKEA product by item number.

ParametersJSON Schema

Name	Required	Default
`itemNo`	Yes
`langCode`	No	en
`countryCode`	No	us

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states it 'gets' details, implying a read-only operation, but does not disclose any potential side effects, authentication requirements, rate limits, or what exactly 'details' includes. The lack of any behavioral caveats leaves the agent to infer the operation'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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that is front-loaded with the core action. It is appropriately sized for the tool's simplicity, and every word adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 3 parameters and no output schema or annotations. The description is minimal and does not cover the role of langCode/countryCode, return format, or any potential errors. For a tool with multiple parameters, this is insufficient context. Sibling tool distinctions are only implied, not explicitly stated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains that itemNo is used to look up the product, but langCode and countryCode are not mentioned at all. The description adds no meaning for these parameters, leaving the agent to guess their purpose (e.g., localization, currency).

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 clearly states the tool's purpose: 'Get details for a single IKEA product by item number.' It specifies a verb ('Get'), a resource ('details for a single IKEA product'), and the input method ('by item number'). This distinguishes it from sibling tools like search_products (searching) and list_stores (stores).

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 implies use when you have a specific item number and want product details, but it does not explicitly state when to use this tool versus alternatives like search_products or check_store_stock. No exclusions or alternatives are mentioned, only the condition 'by item number'.

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

list_storesA

List known IKEA store IDs and display names. Use countryCode ('US' or 'CA') to filter by country, or omit to return all stores.

ParametersJSON Schema

Name	Required	Description	Default
`countryCode`	No

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral disclosure burden. It clearly states the tool lists stores and describes filter behavior. 'List' implies a read-only operation, and the omit behavior is a meaningful disclosure, though it does not mention auth, output shape, or pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary purpose, and every word adds value. It avoids unnecessary detail or repetition, making it optimal for quick AI parsing.

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?

Given the tool's simplicity—one optional parameter, no output schema—the description provides all necessary context: what is returned, how filtering works, and the default behavior. It is complete enough for an agent to select and invoke the tool without further clarification.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema only provides an enum without descriptions, giving 0% schema coverage. The description fills this gap entirely by explaining that countryCode filters by country ('US' or 'CA') and that omitting it returns all stores, adding meaning beyond the raw enum values.

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 starts with a specific verb 'List' plus a clear resource: 'IKEA store IDs and display names'. This clearly distinguishes it from sibling tools that search products or check stock, leaving no ambiguity about what the tool does.

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?

The description states how to use the optional countryCode parameter and what happens when it is omitted ('omit to return all stores'). It provides clear usage context, though it does not explicitly mention when not to use the tool or name alternatives.

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

search_productsC

Search IKEA products by keyword.

ParametersJSON Schema

Name	Required	Default
`size`	No
`query`	Yes
`langCode`	No	en
`countryCode`	No	us

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden, but it only states a generic search action. It does not disclose behaviors like pagination, locale sensitivity, result sorting, or return format, which are important for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that directly states the core purpose. There is no redundant or vague wording; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, no output schema, and no annotations, this description is incomplete. It lacks essential context about how locale parameters affect results, what 'size' controls, and what the response will contain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate by explaining at least the key parameters. It only mentions 'keyword', which maps to 'query', but leaves 'size', 'langCode', and 'countryCode' unexplained in terms of their purpose or effect.

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?

The description states a specific action ('Search') on a specific resource ('IKEA products') with a clear modifier ('by keyword'). It distinguishes from sibling tools like list_stores and check_store_stock, though not explicitly from get_product_details, but the keyword-based search intent is clear.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives. There is no mention of when to choose search_products over get_product_details or check_store_stock, nor any context about typical use cases.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation4/5

Most tools are distinct, but some overlap exists: compare_store_stock and find_best_store_for_item both operate across stores, and check_cart_availability and find_best_store_for_cart serve similar purposes. Descriptions clarify the differences, so misselection is unlikely but possible.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (list, search, check, compare, find, get). No mixed conventions or vague verbs; names clearly indicate the action and target.

Tool Count5/5

9 tools is well within the ideal 3-15 range. Each tool serves a distinct part of the IKEA shopping workflow: product discovery, stock checking, and store selection.

Completeness5/5

The tool set covers the core domain: listing stores, searching and getting product details, and checking availability for single/multiple items across stores. Cart-level operations fill the last major gap, making the surface complete for common use cases.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

SeekOnMe Product Discovery
me.seekon.fast
Remote MCP server for product discovery catalog and retrieving product details.
E-commerce & Retail Search
2
kalicart-global A
io.github.giuseppesocci-bot
Federated commerce search across independent WooCommerce merchants. Keyless, read-only MCP server.
E-commerce & Retail Search
53
VeryChic Hotel Deals A
io.github.jordantete
Unofficial read-only MCP server for VeryChic hotel offers
Travel & Transportation E-commerce & Retail
221
eansearch-mcp-serverOAuth
io.github.eansearch
MCP server for real-time product search by barcode (EAN, UPC, GTIN) or keyword on ean-search.org
E-commerce & Retail Search App Automation
22

Related MCP Servers

inventory-mcp
Databases Search AI & Machine Learning
golem15com
F
license
Not graded
quality
B
maintenance
MCP server for Inventory (whereiput.it) that enables searching, full CRUD operations on items/locations/areas, and AI-powered photo recognition flow from MCP-compatible clients.
Updated 22 days ago (2026-08-12 20:59 UTC)
kronan-mcp
E-commerce & Retail Search
sandsower
A
license
A
quality
C
maintenance
MCP server for the Krónan grocery store API, enabling product search, shopping notes management, checkout, and order tracking.
Updated 4 months ago (2026-04-19 23:15 UTC)
33
45
15
MIT
posokanei-mcp
E-commerce & Retail Search Open Data
charistas
A
license
A
quality
B
maintenance
Read-only MCP server for Greek supermarket product and price data from PosoKanei. Enables product search, barcode lookup, price comparison across retailers, and basket evaluation.
Updated 11 days ago (2026-08-23 09:25 UTC)
10
63
2
MIT
Placera MCP
Finance Web Scraping Search
Advance-xd
A
license
Not graded
quality
C
maintenance
Read-only MCP server for accessing Placera headlines, articles, company tags, and Telegram search data.
Updated a month ago (2026-08-06 16:53 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/taejin5314/ikea-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server