Aggregator.gg

npx add-mcp 'https://mcp.aggregator.gg/mcp'

Aggregator.gg ships a hosted Model Context Protocol server, so an AI agent can browse the catalog, launch-prepare, and read integration state through tools instead of hand-written HTTP calls. It uses the existing Core API: the Worker forwards your own key per request. Cabinet OAuth, consent and database grants are not implemented in this deployed Worker.

Overview

• Endpoint: https://mcp.aggregator.gg/mcp
• Transport: stateless JSON-RPC 2.0 over HTTPS POST. One message per request, the reply comes back in the response body. There are no sessions, no server-push streams, and no JSON-RPC batching.
• Auth: an Authorization: Bearer header carrying your agg_ key on every request, the same key as the rest of the machine API.
• Health: public GET / and GET /healthz return fixed service metadata. The reported 0.1.0 version is not a build identifier. /mcp still requires authentication.

A quick identity check, no key required:

curl -sS https://mcp.aggregator.gg/healthz

{"name":"aggregator-mcp","version":"0.1.0","transport":"streamable-http","endpoint":"/mcp","documentation":"https://docs.aggregator.gg"}

The production Worker was deployed on 8 October 2026 from commit a60508fcd730896343124fad46ca794016690dad, active version 39df1dbd-a1ed-48eb-ba8f-844cacf0148f. Protocol, discovery and default-deny checks passed with synthetic keys; this is not real-tenant, payment, or end-to-end Cabinet acceptance. The public health routes have a narrow Cloudflare Super Bot Fight Mode exception; MCP authentication and mutation gates are unchanged.

The Worker is deployed separately from npm. The stdio package @aggregator-gg/mcp-server and CLI have independent release histories: publishing SDK 1.1.0 or deploying this Worker does not upgrade existing npm consumers.

Connection

Use a client that supports this stateless HTTP lane and protected Bearer injection. No universal MCP-client compatibility or Cabinet sign-in flow is certified here. The human configures the key without putting it in chat, shell arguments, logs or committed files. Read tools can return organization data to the client and its model, so confirm that destination before connecting. These credential-free terminal checks show the method and authentication boundary:

GET is refused, POST is the only lane:

curl -sS -i https://mcp.aggregator.gg/mcp | head -4

HTTP/2 405
allow: POST, OPTIONS

{"error":"method_not_allowed","message":"This MCP endpoint is stateless: POST one JSON-RPC message to /mcp. There are no sessions or server-push streams."}

A POST without a key is challenged:

curl -sS -i -X POST https://mcp.aggregator.gg/mcp \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | head -4

HTTP/2 401
www-authenticate: Bearer realm="aggregator-mcp", error="invalid_token"

{"error":"unauthorized","message":"Provide an Aggregator API key as 'Authorization: Bearer <key>'. Keys are issued in the operator cabinet; the Worker forwards them to Core and never stores them."}

With the header supplied, the same tools/list call returns the catalog below. Auth is Bearer-only: there is no OAuth discovery on this endpoint (/.well-known/oauth-protected-resource returns 404), so configure your MCP client with the static Bearer header rather than an OAuth flow.

Step check: the two curls above reproduce the 405 with allow: POST, OPTIONS and the 401 with the Bearer challenge; with your key added, tools/list answers with named tools.

Available tools

Ten remote reads, five denied remote actions, and two local advisories are registered. Discovery alone does not prove that a key can read a tenant resource.

Remote reads, subject to Core authentication, permissions and available evidence:

• list_games: list games from the aggregator catalog with optional filters.
• list_provider_games: list games for a specific provider, for operator-side launch preparation.
• list_truelabs_games: shortcut for listing TRUE LABS games from the catalog.
• get_game: full details for one game by its catalog ID.
• get_session: details for an existing session by its ID.
• list_readiness_scenarios: every scenario the readiness exam will fire at your wallet endpoint, with severity, so you build the wallet to the list before running the check.
• list_readiness_runs: your recent readiness runs with their final states.
• get_readiness_evidence: per-scenario evidence for one run, which scenario failed and what your wallet answered.
• list_transactions: the operator’s transactions using the deployed pagination contract.
• list_providers: registered game providers with supported currencies and blocked countries.

Remote actions, visible but unavailable on this Worker (descriptions name their intended operation):

• create_session: create a real-money player session for a game.
• create_demo_session: create a free-play session; no money moves, but remote state is created.
• run_readiness_check: run the real pre-live diagnostics suite against your configured wallet endpoint, launch, bet, win, refund, duplicates and security scenarios, synchronously.
• probe_provider_games: list the games actually enabled on the provider’s own stand, the launchable subset when the catalog is ahead of the provider’s casino.
• provider_health: run a live health check against one game provider and report its status.

Local advisories, computed from caller-supplied facts without touching the platform:

• assess_operator_readiness: an unverified local readiness advisory; never a go-live decision.
• plan_port_adaptation: an unverified local plan for adapting an existing operator integration as a donor port.

For platform accounts, create brands deliberately before using catalog tools. Core can lazily provision an unknown sub_operator_ref during a catalog GET when account policy permits it; the Worker’s remote-action denial does not turn that Core path into a side-effect-free lookup. Use existing explicit refs. The transactions tool has the same lack of a brand selector as the machine endpoint.

The read tools can inspect existing readiness evidence. A human runs the supported check described in Getting started, step 6; this Worker cannot start it. A local advisory, a demo and a verified ordinary API/wallet test are different evidence.

Safety boundaries

• The hosted surface is read-only today. All five remote actions remain visible but are denied before remote transport. The local tier gate classifies agg_ as unknown and refuses it before grant consumption. Legacy live keys are also refused; a legacy test key reaches the mutations-off refusal. No caller key, grant or setting enables actions in this Worker. Do not request a new test key or rewrite a prefix to bypass a denial.
• This is legacy Bearer forwarding. It is not the future Cabinet authorization-server, consent or database-grant flow. No hosted OAuth discovery or tenant consent/revoke acceptance is provided by this release.
• Output protection has limits. The Worker holds the key in request-scoped memory and uses the shared SDK redactor on outgoing messages, including its timeout reply. It does not persist keys; its redacted, argument-free audit records do persist in Workers Logs. This is not a guarantee about all client logs or Cloudflare telemetry. Never paste raw errors, headers or credentials into a conversation.
• Human control remains required. Registration, keys, callback configuration, tests, payment and Go live stay with the operator. MCP explains the next step and reads available evidence; missing evidence means not yet verified. See Agent guidelines.

Troubleshooting

405 method_not_allowed. You sent GET or connected with a client that expects a server-push stream. This endpoint is stateless: POST one JSON-RPC message per request.

401 unauthorized. The Authorization: Bearer header is missing or malformed, or the credential is refused. The Worker accepts the issued shape (agg_ plus 43 Base62 characters) and supported legacy shapes; Core decides validity for reads. Keys come from the operator cabinet; the header goes on every POST.

400 with a JSON-RPC error. The body was not valid JSON, was a batch array (unsupported: send one message per POST), or was not a JSON-RPC 2.0 message.

A remote action returns a denial. Expected on the hosted endpoint: mutations are off and the key-tier gates still apply. Denial text inherited from stdio may mention an enablement variable or a test key; neither enables this Worker. A human uses the supported cabinet or approved backend integration for tests and launches.

HTTP 413, JSON-RPC -32600. The Worker limits a request body to 64 KiB, including streamed requests. Reduce the request; do not split one JSON-RPC message into a batch.

Timeout answer with a JSON-RPC error. The Worker has a 150-second response budget and protects timeout output through the same redactor. That path has source and isolated-test coverage; the production verification did not force a 150-second timeout. For a failed read, use a bounded retry and check rate limiting. A timeout is not business success.