Remote Setup — yetdapay-mcp-gateway

Quick summary

The remote Gateway exposes seller-facing commerce tools over HTTP and forwards authorized requests to the existing REST API. It does not move your project source code.

Use a seller token for seller-scoped actions; public read tools may be anonymous. Check protocol and transport limitations before deploying.

The gateway (mcp/gateway/worker.js) exposes the YetdaPay MCP contract over Streamable HTTP from a Cloudflare Worker — one JSON-RPC 2.0 request per POST body, plain application/json responses. It is a thin adapter over the REST API: no business logic of its own, ported from the stdio server's contract (same tools, resources, prompts, merge-before-PUT semantics, receipts, error mapping).

• Protocol version: 2024-11-05
• serverInfo: yetdapay-mcp-gateway/0.1.0
• Capabilities: tools, resources, prompts

Routes

Route	Behavior
POST /mcp (and POST /)	JSON-RPC 2.0 dispatch
GET /health	{"ok":true}
OPTIONS *	CORS preflight
non-POST on /mcp or /	405 JSON-RPC error
anything else	404

Client config

{
  "mcpServers": {
    "yetdapay": {
      "url": "https://yetdapay-mcp-staging.<subdomain>.workers.dev/mcp",
      "headers": {
        "Authorization": "Bearer <seller-token>"
      }
    }
  }
}

The Authorization header is the seller credential — the gateway forwards it verbatim to upstream seller endpoints and never logs or stores it. Omit it and seller-scope tools fail closed with {code:"UNAUTHORIZED"}; public tools still work without it. See Authentication.

Configuration (wrangler.toml [vars])

Var	Default	Purpose
YETDAPAY_API_BASE	http://127.0.0.1:8080/api/v1	Upstream REST base URL
YETDAPAY_SITE_ORIGIN	http://127.0.0.1:3000	Site origin for hosted-link snippets ({origin}/h/{public_id})
YETDAPAY_REQUEST_TIMEOUT_MS	10000	Per-request upstream timeout
YETDAPAY_CORS_ORIGINS	* (unset)	Comma-separated allowlist; request Origin is reflected when listed, otherwise *

Deploy

cd mcp/gateway
npx wrangler deploy --config wrangler.toml

Operator gate

Deployment is a charter-gated operation (staging first; production needs explicit approval). Do not treat this doc as authorization.

Upstream coverage

All 20 tools run against the be-cloudflare Worker and the Axum be/ backend. The d3 parity port added the integration surface to be-cloudflare (/projects/:id/integration GET/PUT, /public/integrations/:pid, public feedbacks/donations POST), so the configure/validate tools no longer dead-end on the deployed Worker — see Tools Reference for the per-tool upstream map.

Resources & prompt

• yetdapay://docs/{donation-guide, feedback-guide, sdk-contract, install-checklist, manifest-schema} — embedded markdown.
• Prompt setup_donation_and_feedback ({store_id?}) — guided install: analyze → inspect → configure donation + feedback → fetch assets → install → validate → report.

Known limitations

• Single JSON-RPC request per POST; no batching, no SSE — clients that require text/event-stream responses are not supported in this MVP.
• notifications/* requests return 202 with an empty body.
• license_get has no upstream single-GET route (list-only contract on both backends); the tool fetches the seller-scoped list and selects — an absent id is honest NOT_FOUND, never a fabricated record.