Edwin by theButler.network

Compare products side by side

compare_products

Read-only

Compare two to five products side by side: brand, category, price range across merchants, merchant count, and the lowest current offer for each. Use when the user is choosing between named products.

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

Input Schema

Name	Required	Description	Default
`pids`	Yes	Two to five product ids from previous Edwin tool results.
`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.

Output Schema

Name	Required	Description
`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.
`market`	Yes
`products`	Yes
`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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A3.8/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered; a working output schema also means return values need no explanation here. The description adds the comparison dimensions (merchant count, price range, lowest current offer), which is genuine context beyond the structured fields, but it says nothing about latency, data freshness, or what happens when one product id is invalid or unavailable in the market.

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 purpose and compared attributes are front-loaded, and the usage trigger follows immediately. Nothing in the text is redundant with the name or title.

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 annotations, a full output schema, and 100% parameter coverage, the description carries only the burden of stating purpose and use case, which it does. The only real gap is guidance for edge cases such as fewer than two valid product ids or a market where a product is not listed, which an agent choosing this tool would plausibly want.

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%: pids is documented with the 2-5 bound and the provenance note ("from previous Edwin tool results"), and market is documented with a pattern and country examples plus "Infer from the user's context." The description only restates the "two to five products" bound already encoded in minItems/maxItems, 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?

The description gives a specific verb ("Compare") and resource ("two to five products") and enumerates exactly what is compared: brand, category, price range across merchants, merchant count, and lowest current offer. This is far more informative than the title. It stops short of naming a sibling, so an agent must still infer the boundary with find_alternatives or get_offers on its own.

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?

"Use when the user is choosing between named products" gives a concrete trigger condition that implicitly separates this from discovery tools like search_products and recommend_product. However, it offers no when-not guidance and never names an alternative for the overlapping case where a user wants substitutes rather than a comparison of already-chosen items.

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?