Vendwiser

Compare prices across accounts

price_parity_check

Read-onlyIdempotent

[Analysis] Compare prices of the same SKUs between two accounts, across marketplaces and countries (for example two Trendyol countries, eMAG and Trendyol, or eMAG and Temu). Prices are put on one basis first: without VAT (each marketplace says whether its prices include VAT; give vat_a_pct / vat_b_pct when it does not say the rate) and, when commission_a_pct / commission_b_pct are given, minus that marketplace's commission. Currencies are not converted: the tool finds SKUs whose price ratio differs from the typical ratio between the two accounts.

Input Schema

Name	Required	Description
`account_a`	Yes
`account_b`	Yes
`max_pages`	No	Pages of 100 offers to scan (default: enough for 2000 offers).
`vat_a_pct`	No	VAT rate of account A in percent, used only when its prices include VAT and the marketplace does not report the rate.
`vat_b_pct`	No	Same for account B.
`tolerance_pct`	No	How far from the typical ratio counts as a mismatch (default 15).
`commission_a_pct`	No	Commission of account A in percent, to compare what the seller keeps instead of the price. Default 0.
`commission_b_pct`	No	Same for account B.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 15, 2026

addedInput schema / properties / commission_a_pct

Added value: +{
+  "description": "Commission of account A in percent, to compare what the seller keeps instead of the price. Default 0.",
+  "type": "number"
+}

addedInput schema / properties / commission_b_pct

Added value: +{
+  "description": "Same for account B.",
+  "type": "number"
+}

addedInput schema / properties / vat_a_pct

Added value: +{
+  "description": "VAT rate of account A in percent, used only when its prices include VAT and the marketplace does not report the rate.",
+  "type": "number"
+}

addedInput schema / properties / vat_b_pct

Added value: +{
+  "description": "Same for account B.",
+  "type": "number"
+}

First observedOct 9, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds genuinely useful behavior beyond that: prices are normalized to a VAT-exclusive basis, optionally net of commission, currencies are never converted, and mismatches are detected via deviation from the typical ratio. It stops short of describing result presentation or pagination behavior.

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?

Three front-loaded sentences that start with the purpose tag and then explain the normalization. Dense but no filler; the clause about VAT/commission is long yet each part carries information.

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?

An output schema exists, so return values need no explanation, and the description fully explains the comparison basis and the non-conversion of currency. It could still clarify where account_a/account_b identifiers come from (e.g., list_accounts) or the cost of scanning up to 2000 offers.

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?

Schema coverage is 75% and the description adds real meaning on top: vat_a_pct/vat_b_pct are only needed when prices include VAT and the marketplace doesn't report the rate, and commission_a_pct/commission_b_pct switch the comparison to what the seller actually keeps. tolerance_pct is left to the schema description.

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 ('Compare prices of the same SKUs between two accounts') plus the scope across marketplaces/countries. It is clearly distinguishable from sibling write/read tools like offers_update_price or offers_list.

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

Usage Guidelines3/5

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

It gives concrete scenarios where this applies (two Trendyol countries, eMAG vs Trendyol, eMAG vs Temu), which implies when to reach for it, but it never states when not to use it or names an alternative tool. Usage is inferable rather than explicit.

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

All Vendwiser 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?