Skip to main content
Glama

WEM Price Compare

List shopping categories

get_categories
Read-only

Lists the six broad shopping categories WEM covers (electronics, fashion, beauty, home, sports, collectibles), each with example products, the shops WEM has read a price from in the last 14 days (busiest first, with how many shops there are in all) and the default currency (GBP). Use it to help a shopper narrow a vague request. It returns no prices, the category names are labels for the shopper, not filter values, and a shop on the list is not a promise that WEM holds a given product there: compare_offers says which shops WEM has for one product.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
currencyYes
providersYesShops WEM has read a price from in the last 14 days, busiest first, at most 40: one row per shop, with how many of its products WEM read. Say which shops WEM covers from this list, never from a shop's absence: it is not every shop WEM has ever held, and a shop on it may not sell the product the shopper wants (compare_offers says which shops WEM holds for one product).
shopCountNoHow many shops WEM read a price from in the last 14 days, listed or not. Null with an empty `providers` means the list could not be read just now, not that WEM has no shops.
categoriesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedOutput schema / properties / providers / description
      Previous value: -"Retailers currently enabled. WEM compares only feeds it is licensed to use."New value: +"Shops WEM has read a price from in the last 14 days, busiest first, at most 40: one row per shop, with how many of its products WEM read. Say which shops WEM covers from this list, never from a shop's absence: it is not every shop WEM has ever held, and a shop on it may not sell the product the shopper wants (compare_offers says which shops WEM holds for one product)."
    • addedOutput schema / properties / providers / items / properties / products
      Added value: +{
      +  "description": "Products WEM read a price for at this shop in the last 14 days.",
      +  "type": "integer"
      +}
    • addedOutput schema / properties / shopCount
      Added value: +{
      +  "description": "How many shops WEM read a price from in the last 14 days, listed or not. Null with an empty `providers` means the list could not be read just now, not that WEM has no shops.",
      +  "type": [
      +    "integer",
      +    "null"
      +  ]
      +}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "categories": {
      +      "items": {
      +        "properties": {
      +          "examples": {
      +            "type": "string"
      +          },
      +          "name": {
      +            "type": "string"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "currency": {
      +      "type": "string"
      +    },
      +    "providers": {
      +      "description": "Retailers currently enabled. WEM compares only feeds it is licensed to use.",
      +      "items": {
      +        "properties": {
      +          "displayName": {
      +            "type": "string"
      +          },
      +          "name": {
      +            "type": "string"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "categories",
      +    "providers",
      +    "currency"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, non-destructive), and the description adds substantive behavioral context beyond them: it returns no prices, category names are labels rather than filter values, and a listed shop does not guarantee product availability. These are non-obvious caveats an agent would otherwise mis-infer.

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

Conciseness4/5

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

Content is front-loaded with what the tool returns, followed by usage and caveats. The second sentence is a dense run-on packing three separate caveats, which slightly hurts readability but every clause earns its place.

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?

An output schema exists, so return values need not be explained, yet the description still frames the semantics an agent needs (no prices, labels not filters). For a zero-param, read-only listing tool, nothing relevant is missing.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly spends no words on 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?

States a specific verb and resource ('Lists the six broad shopping categories WEM covers') and enumerates the actual content (examples, shops with prices read in last 14 days, default currency). It also names the sibling it is not, compare_offers, so an agent can separate the two without opening schemas.

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

Usage Guidelines5/5

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

Gives explicit when-to-use ('Use it to help a shopper narrow a vague request') and an implicit when-not by routing single-product shop questions to compare_offers. Nothing is left to inference about which tool to pick.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources