Bestshopping Cashback — IT, DE, FR

prepare_cashback_link

Read-onlyIdempotent

Prepare a personal Bestshopping go.html link using an existing recipient nickname and a verified online cashback merchant. Does NOT activate cashback, follow the URL, set merchant cookies, register a purchase click or make a purchase. Show the returned link and tell the USER to click it in their shopping browser, allow tracking cookies and disable AdBlock. Never open or prefetch the link on the server. Never say cashback is already activated.

Input Schema

TableJSON Schema

Name	Required	Description
`market`	Yes	Bestshopping ACCOUNT market: it (Italy), de (Germany), fr (France). Ask the user if missing or ambiguous; never infer it from language or reuse IDs across markets.
`nickname`	Yes	Exact nickname for the selected Bestshopping market explicitly supplied by the user. Ask if missing. Never request a password.
`merchant_id`	Yes	Merchant ID returned by search_merchants. Never guess or reuse IDs from another market.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`status`	Yes
`message`	Yes
`merchant`	Yes
`checked_at`	Yes
`conditions`	Yes
`activation_url`	Yes
`tracking_rules`	Yes
`tracking_activated`	Yes
`user_click_required`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 21, 2026

removedInput schema / properties / market / default
```
Removed value: -"it"
```

changedInput schema / properties / market / enum

Previous value: -[
-  "it"
-]New value: +[
+  "it",
+  "de",
+  "fr"
+]

changedInput schema / required

Previous value: -[
-  "merchant_id",
-  "nickname"
-]New value: +[
+  "merchant_id",
+  "nickname",
+  "market"
+]

changedOutput schema / properties / merchant / properties / market / enum

Previous value: -[
-  "it"
-]New value: +[
+  "it",
+  "de",
+  "fr"
+]

Changed4 schema fields changedOct 21, 2026

changedInput schema / properties / market / description

Previous value: -"Bestshopping market. Only Italy is enabled."New value: +"Bestshopping ACCOUNT market: it (Italy), de (Germany), fr (France). Ask the user if missing or ambiguous; never infer it from language or reuse IDs across markets."

changedInput schema / properties / nickname / description

Previous value: -"Exact Bestshopping Italy nickname explicitly supplied by the user. Ask if missing. Never request a password."New value: +"Exact nickname for the selected Bestshopping market explicitly supplied by the user. Ask if missing. Never request a password."

removedOutput schema / properties / merchant / properties / market / const
```
Removed value: -"it"
```
addedOutput schema / properties / merchant / properties / market / enum
```
Added value: +[
+  "it"
+]
```

First observedOct 21, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations declare readOnly/idempotent/non-destructive, but the description goes well beyond them: it enumerates the side effects that are NOT performed (no cookie setting, no click registration, no purchase), forbids server-side URL open/prefetch, and prescribes the user-facing follow-up (show link, tell USER to click, allow cookies, disable AdBlock). This is exactly the behavioral context an agent needs for a link-preparation tool.

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 purpose, then a dense but purposeful run of negative constraints and follow-up instructions; every sentence carries an operational requirement. It is somewhat list-like and could be tightened, but there is no filler.

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?

An output schema exists, so return values need not be explained, and the description fully covers the remaining gaps: preconditions, prohibited side effects, and the post-call user workflow. Given the tool's read-only, single-purpose nature, nothing an agent needs to invoke it correctly is missing.

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 all three parameters are already fully documented, including the 'ask if missing / never guess or reuse IDs across markets' rules. The description adds only light framing ('existing recipient nickname', 'verified online cashback merchant') 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a precise verb and resource ('Prepare a personal Bestshopping go.html link') plus the required inputs (existing nickname, verified cashback merchant). The following negative clauses ('Does NOT activate cashback, follow the URL, set merchant cookies...') sharply distinguish it from any tool that might be mistaken for performing the activation, and it ties back to the sibling search_merchants as the ID source.

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 clearly frames the preconditions (existing recipient nickname, verified merchant from search_merchants) and gives strong when-not guidance by enumerating what the tool does not do. However, it never explicitly contrasts itself against the sibling tools (get_merchant, list_markets) or states the user intent that triggers a call, leaving some selection context implied.

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

All Bestshopping Cashback — IT, DE, FR 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?