webhallen-mcp

Check price & availability

check_price_availability

Retrieve current and 30-day-lowest price, campaign end date, and web plus physical-store stock for a Webhallen product by ID or URL.

Instructions

Lightweight price + stock snapshot for one product: current/regular price, lowest price in the last 30 days, campaign end date, web stock and stock in each physical store. Handy for price tracking or finding a store to pick up from.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "idOrUrl": "<idOrUrl>"
    },
    "name": "check_price_availability"
  }
}

Input Schema

Name	Required	Description	Default
`idOrUrl`	Yes	Webhallen product id or URL

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden, and it does disclose the read-only, single-product, point-in-time nature of the call ('lightweight', 'snapshot') plus the complete set of returned fields. It omits any note on the cost, caching or currency of the data; but for such a simple read, the gaps are minor.

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?

Two tight sentences: the first front-loads what the tool returns, the second gives the use case. No boilerplate or filler.

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

Completeness4/5

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

Because there is no output schema, the description must describe the return values; it does so exhaustively, which is exactly what an agent needs. Only minor details such as currency or the response shape are left implicit.

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?

There is only one parameter and schema coverage is 100%, so the schema already documents 'idOrUrl' fully. The phrase 'for one product' reinforces that the input scopes to a single item but adds no format or syntax detail beyond the schema.

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?

Names a specific operation and resource ('price + stock snapshot for one product') and enumerates the exact data points returned: current/regular price, 30-day low, campaign end date, web stock, and per-store stock. That field enumeration distinguishes it from get_product and compare_products without needing to name them.

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

Usage Guidelines4/5

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

Gives concrete use contexts ('price tracking or finding a store to pick up from'), which tells an agent when this tool is the right call. It stops short of naming alternatives or exclusions, e.g. it never says to use compare_products when checking multiple items at once.

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

Deploy Server