Edwin by theButler.network

Get merchant offers for a product

get_offers

Read-only

Return the full list of current merchant offers for one product in a market: merchant, price, currency, stock status, source timestamp, match tier, and a purchase link, cheapest first. Use when the user wants to see every merchant for one product — search_products already carries the cheapest one.

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": "get_offers"
  }
}

Input Schema

Name	Required	Description
`pid`	Yes	Product id exactly as returned by a previous Edwin tool result. Never invent one — call search_products first if you do not have a pid.
`limit`	No	How many offers to return, cheapest first.
`market`	Yes	ISO 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.
`include_description`	No	Also return the merchant feed's product description and, for each listed offer, that merchant's own title and description, as plain text shortened to 1200 characters each. It is merchant copy, not a checked spec sheet. Leave it off unless the user asks what the product is like.

Output Schema

Name	Required	Description
`pid`	Yes
`name`	No
`note`	No	Plain-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.
`brand`	No
`market`	Yes
`offers`	Yes
`description`	No	Only with include_description: the merchant feed's product description, plain text, shortened. Null when the feed has none worth showing.
`empty_reason`	No	Machine-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_summaries`	No	Only for Edwin's app view: it can load short product summaries for these results. Ignore it; nothing to show or say.
`merchant_texts`	No	Only with include_description: the title and description each listed merchant sends for this product, plain text, shortened, duplicates removed, at most six.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.5/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 behavior beyond that: results are ordered cheapest first and represent the complete merchant set for one product, which is the key semantic distinction from the sibling. It does not discuss pagination or limits beyond the default, but that is largely schema territory.

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, zero filler: the first delivers purpose, fields and ordering; the second delivers routing. The scope constraint is front-loaded and nothing is repeated.

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?

With an output schema present, the description needn't explain return values, yet it summarizes the shape and ordering anyway. Annotations cover safety and the schema covers all four parameters, so an agent has everything needed to select and call this 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 the careful pid guidance and the include_description caveat, so the schema does the heavy lifting. The description only implies pid and market via 'one product in a market' and adds no new parameter detail. Baseline 3 is appropriate.

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?

Specific verb+resource (return merchant offers) scoped to one product in a market, and it enumerates the returned fields (merchant, price, currency, stock status, timestamp, match tier, purchase link). It also explicitly contrasts itself with search_products, so an agent can pick between them without opening either schema.

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?

States the triggering condition ('when the user wants to see every merchant for one product') and names the alternative that should be used otherwise (search_products, which already carries the cheapest offer). The selection rule is explicit rather than inferred.

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

All Edwin by theButler.network tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?