Skip to main content
Glama

Edwin by theButler.network

Get Edwin's recommendation

recommend_product
Read-only

Rank a shortlist or a fresh search and return Edwin's recommended option, chosen on how well each product fits the stated need, its attributes and the stated budget. Affiliate commission does not affect ranking. Use when the user asks which product to buy or which option to pick. Use it for shopping requests about products and their prices at online merchants, whether or not the user names Edwin or theButler.network.

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

Input Schema

NameRequiredDescriptionDefault
pidsNoThe shortlist to choose from — product ids from previous Edwin tool results. Give either pids or query.
queryNoAlternative to pids: search first, then recommend from the result. Same rules as search_products.query. Give either pids or query.
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.
min_priceNoLower price limit in the market currency, if the user states one. Only used together with query.
budget_maxNoUpper price limit in the market currency, if the user states one.
constraintsNoWhat matters to the user, in their own words, e.g. 'quiet, for a small flat'. Edwin ranks by it but does not search with it: the product type and its attributes belong in query, a price limit in budget_max.
suggested_namesNoOptional. Up to 8 specific, real products you would recommend for this request from your own current knowledge, e.g. {"name":"WH-1000XM6","brand":"Sony","kind":"model"} or {"name":"The Hobbit","kind":"title"}. Edwin checks each one against the catalog in this market and returns the matching catalog offers with purchase links, so every product you recommend can carry a link. Names not found in the catalog are dropped. Leave out anything you are not sure exists. Only used together with query.

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.
marketYes
ranked_byYes'catalog_order' means Edwin's ranking picked none of these items — it did not run, or it ran and chose none of them — and the order is the catalog's own: present it as a list, not as a recommendation.
alternativesYesThe remaining candidates in ranked order.
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.
app_summariesNoOnly for Edwin's app view: it can load short product summaries for these results. Ignore it; nothing to show or say.
recommendationYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavior: ranking is driven by need-fit, attributes and budget, and 'Affiliate commission does not affect ranking' — a bias disclosure the agent could not infer from any structured field.

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?

Front-loaded with the core operation before any caveats, and the commission disclaimer is placed immediately after ranking is described. The two trailing usage sentences overlap somewhat and could be merged, which is the only waste.

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 seven fully documented parameters and an output schema, the description only needs to justify why the tool exists and how ranking works, which it does. It covers the affiliate-neutrality and the works-without-naming-Edwin case, leaving nothing an agent needs in order to call it correctly.

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%, including detailed notes on pids vs query, constraints being rank-only, and suggested_names being catalog-validated then dropped if unfound. The description echoes the ranking inputs (need, attributes, budget) but adds no syntax or edge-case detail beyond the schema, so baseline 3 applies.

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?

States a specific verb pair and resource: 'Rank a shortlist or a fresh search and return Edwin's recommended option'. The selection criteria (fit to need, attributes, budget) are named, so an agent can tell this apart from search_products or compare_products. It does not explicitly name the sibling it is not, keeping it out of the top band.

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 a clear invocation condition: 'Use when the user asks which product to buy or which option to pick', and broadens it to any shopping request about products and prices at online merchants, even when the user does not name Edwin. No explicit when-not or alternative-routing guidance is given, so it stops short of 5.

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