Skip to main content
Glama
Sign In

Fordeal

by ai.fordeal
OverviewDiscussionsAdmin

Register a shop for the comparison

register_shop

One call registers a shop (P01): name, domain, delivery country, contact e-mail, the feed (its address in feed_url, or the file in feed_content / feed_base64), how commission is paid and the accepted partner terms version. An address is read at once through the SSRF guard (public hosts only, 422 url_rejected otherwise) with a 12 s cap; a file is decoded (at most 8 MB, gzip allowed, ZIP refused: 422 upload_zip_unsupported, 413 upload_too_large) and only its sha-256 and size are kept. Either way the feed is diagnosed (P04) and the 202 answer carries feed.health ok | warn | fail with the top three issues; the full report is stored on the request, feed_source says url or upload. One open request per domain: a second call updates it and answers the same id with duplicate: true; a declined domain may register again. The contact gets the shop_registration_received mail (its language: locale, else the country's default) with the confirmation link and the status page; the operator gets one notice. verification.ownership carries the token for the meta tag or file proof (verify_shop_domain). A shop on the ČOI / SOI risk list is refused (403). A registration never lists a shop by itself: the operator decides. A shop registered with a file only is listed as still being added until it sends a feed address. Follow it with get_shop_registration. Six calls a minute per caller.

Input Schema

NameRequiredDescriptionDefault
noteNo
emailYesContact e-mail of the shop; it receives the confirmation link and the decision. Never shown.
domainYesThe shop's domain or URL, e.g. www.obchod.cz.
localeNoLanguage of the mails (cs, sk, en, …); the country's default language when absent.
countryYesDelivery country of the shop, ISO 3166-1 alpha-2 from GET /api/v1/deals/countries.
websiteNoLeave empty (spam trap: a filled value is discarded quietly).
feed_urlNoThe product feed (Heureka, Zboží, Google Merchant, Ceneo, Idealo, Árukereső XML or CSV). Read at once; the answer carries the diagnostics report. Public hosts only. Either this or a file.
affiliateYesHow commission is paid: "own" = forDeal's own programme (5 % of the net order value, partner portal), a network name the country lists (ehub, cj, awin, dognet, …), "other", or "none".
shop_nameYesThe shop's name as it should appear in the comparison.
feed_base64NoThe feed file's bytes as base64, for a gzip-packed file (.xml.gz, .csv.gz). ZIP is refused: unpack it first.
accept_termsYestrue = the contact accepts the partner terms of the given version.
feed_contentNoThe feed as a file instead of an address: the XML or CSV text itself (at most 8 MB). Checked once and dropped; only its sha-256 and size are kept. Regular price updates still need a feed_url later.
feed_filenameNoThe uploaded file's name, kept with its fingerprint.
terms_versionYesThe partner terms version being accepted; today 2026-10-09 (the terms are at /partner/smlouva).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / email / pattern
      Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Far exceeds the annotations: discloses the SSRF guard and 12 s cap for URL reads, decode limits (8 MB, gzip allowed, ZIP refused with 413/422 codes), that only sha-256 and size are kept, the 202 response shape with feed.health and the top three issues, the ČOI/SOI 403 refusal, the notification e-mails, and a 6/min rate limit. None of this is derivable from the readOnly/destructive/openWorld hints, and nothing contradicts them – a second call updating the same request is consistent with idempotentHint=false.

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?

Dense and front-loaded – the core action comes first, then feed handling, duplicate semantics, side effects and limits. Nearly every clause carries operational value, though the single unbroken paragraph and parenthetical error codes make it heavier than ideal for quick scanning.

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?

For a 14-parameter mutation tool with no output schema, the description covers what an agent needs: the write semantics, the 202 payload contents, duplicate/update behaviour, failure codes, rate limiting, and the follow-up tool. Little is left for the agent to guess.

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?

With 93% schema coverage the baseline is 3, but the description adds real meaning beyond the schema: it explains the feed_url vs feed_content/feed_base64 trade-off, why a file-only registration stays "still being added" until a feed_url arrives, and that locale falls back to the country default. It leaves minor fields (website spam trap, note, feed_filename) to the schema, which already documents them well.

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?

Opens with a specific verb+resource ("One call registers a shop (P01)") and enumerates the payload (name, domain, delivery country, e-mail, feed, commission, terms), so an agent knows exactly what the call does. It is clearly distinguishable from siblings like get_shop_registration, list_shops and verify_shop_domain, which are named in the text.

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 clear operating context: one open request per domain, a second call updates it and returns the same id with duplicate:true, a declined domain may re-register, and you should follow it with get_shop_registration. It also names verify_shop_domain for the ownership token. It stops short of explicitly excluding alternatives (e.g. when to use check_shop_feed or list_shops instead of registering).

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

All Fordeal toolsInspect
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