Skip to main content
Glama

Edwin by theButler.network

Find alternative products

find_alternatives
Read-only

Find comparable products to a given product in the same market, optionally within a budget or with specific attribute changes. Use when the user asks for alternatives, cheaper equivalents, or "something like X but Y".

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": {
      "pid": "<pid>",
      "market": "<market>"
    },
    "name": "find_alternatives"
  }
}

Input Schema

NameRequiredDescriptionDefault
pidYesProduct id exactly as returned by a previous Edwin tool result. Never invent one — call search_products first if you do not have a pid.
limitNoHow many alternatives to return.
marketYesISO 3166-1 alpha-2 country code of the user's shopping market, e.g. DE, AT, NL, FR, GB, US. Infer from the user's context.
directionNoWhich way to look: 'cheaper' for lower-priced equivalents, 'better' for higher-priced ones, 'similar' for the same price class.similar
must_haveNoAttribute words the alternative must carry in its name, e.g. ["oled"] for "like this one but OLED". Matched against product title and brand.
budget_maxNoUpper price limit in the market currency, if the user states one.

Output Schema

NameRequiredDescriptionDefault
noteNoPlain-language explanation for the user. Set whenever the result is empty, and also when something about a non-empty result needs saying — for example that the ranking did not run and the order is the raw catalog order.
itemsYes
marketYes
directionYes
referenceYes
empty_reasonNoMachine-readable reason for an empty result. restricted_category: matches existed but fall into a product category this connector does not serve. no_match_in_market: nothing matched in this market. no_offers_for_product: the product has no merchant offer here at all. no_fresh_offers_for_product: the product has offers, but none is confirmed by the most recent import of its source, so there is no up-to-date price — do not quote an older one. query_too_short: the query carried no searchable terms. market_not_covered: no offers in this market at all. unknown_pid: no product with that id — call search_products for a real one. no_substantial_match: products matched, but none had a recognizable brand or publisher and the fields required for the product type — say so; the user can explicitly ask for unbranded or self-published items.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare a safe, closed-world read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description's main burden is scoping, and it does add the same-market constraint plus optional budget/attribute filters. It says nothing about how results are ranked, how many come back by default, or what happens when no alternative exists, which are the behaviors an agent would still need.

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 sentences with no waste: the capability and its scoping constraint come first, followed by the intent triggers. Nothing redundant, and the front-loaded statement is the one an agent needs to route the call.

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?

With an output schema present, return values need no explanation, and all six parameters are documented in the schema. The description covers purpose, scope, and invocation triggers, leaving only minor gaps around result ranking and the empty-result case.

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?

Schema description coverage is 100%, so the baseline is 3 regardless. The description contributes a little extra by mapping natural-language phrasings ('cheaper equivalents' to direction, 'something like X but Y' to must_have), but it does not explain the semantics of limit or how must_have matching actually narrows results.

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 gives a specific verb and resource ('Find comparable products to a given product') and bounds the scope to the same market. It does not explicitly distinguish itself from the sibling compare_products, which also operates on a product, so it stops short of a 5.

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?

It gives concrete user-intent triggers ('alternatives, cheaper equivalents, or "something like X but Y"'), which is clear when-to-use guidance. It names no exclusions or alternative tools to prefer instead, so the guidance is one-sided.

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