MCP Server

Overview

The Groove MCP server exposes this entire documentation set — every endpoint, parameter, response and error code — as tools that an AI coding assistant (Claude Code, Cursor, Copilot, …) can call directly. Instead of reading these pages and hand-writing your integration, you connect your assistant to the MCP once and ask it.

It is a read-only oracle over the Groove integration specs. It serves documentation, computes and checks HMAC-SHA256 signatures, and generates code. It performs no wallet operations, holds no player data, and calls no Groove backend at runtime — so it is safe to point an AI assistant at while you build.

Info

**Always pass `integration: "reverse"`** on every tool call. That scopes every answer to the reverse integration documented on this site.

What you can do with it

Capability Tools
Look up any endpoint’s full spec — parameters, responses, status codes get_endpoint, list_endpoints
Search the docs by keyword search_docs
Compute the Authorization: HMAC-SHA256 Signature=… header for a request sign_request
Check whether an inbound signature is valid — the request checker verify_signature
Get a runnable example for one endpoint in Go / Java / Python / TypeScript / curl generate_snippet
Generate a complete, startable project/groove entry point, all 7 transaction ops, wallet seams generate_integration
Inspect the server itself list_tools, get_server_info

See the Tools Reference for every parameter, and Example Workflows for worked examples.

Endpoint at a glance

Property Value
URL https://<groove-gateway>/mcp
Transport MCP Streamable HTTP — JSON-RPC 2.0 over POST
Authentication Authorization: Bearer <MCP access token>
Token lifetime Constant — the token does not expire
Sessions Stateless — no session id, every call is independent
Max body size 4 MiB (larger requests are rejected with 413)
Tools served 9
Endpoints served 19 — every reverse-integration page on this site

Getting your access key

**Contact your Groove account manager** to receive: 1. Your **MCP access token** — the value you put in the `Authorization: Bearer` header. 2. The **gateway base URL** for your environment (staging and production differ). There is no self-service sign-up from the provider side: the token is issued by Groove. Treat it as a **shared secret** — store it in your secret manager, keep it out of source control, and tell your account manager immediately if it leaks so the signing key can be rotated.

How it fits together

graph LR A[Your AI assistant<br/>Claude Code / Cursor] -->|POST /mcp<br/>Authorization: Bearer| B[Groove Gateway] B --> C[Groove MCP Server] C --> D[(Reverse Integration<br/>Specs)] style C fill:#f9f,stroke:#333,stroke-width:4px style A fill:#e8e0f7,stroke:#333

Your assistant speaks MCP to the gateway; the gateway authenticates the bearer token and serves the tools in-process. Nothing you ask the MCP touches a live wallet, a player account or a real transaction.

Next steps

Page What it covers
Setup Getting your token, the HTTP call, auth header, and client config
Tools Reference Every tool, every parameter, with request and response examples
Example Workflows End-to-end examples: verify a signature, generate a full project

Subsections of MCP Server

Setup

Setup

This page takes you from nothing to a working MCP connection: obtain the access token, verify it with a plain HTTP call, then wire it into your AI assistant.

What you need

Item Where it comes from
Gateway base URL Your Groove account manager — differs per environment (staging / production)
MCP access token Your Groove account manager
An MCP client Claude Code, Cursor, VS Code, or any client supporting MCP over HTTP

You do not need a Groove backoffice login, a security key, or any firewall change: the MCP is a normal outbound HTTPS call from your machine or CI to the Groove gateway.

The gateway routes

The gateway exposes two MCP routes. Only the first one is for you — the second is how Groove issues your token.

Route Method Who calls it Auth header
/mcp POST (JSON-RPC) You, the game provider — your AI client or your own HTTP call Authorization: Bearer <mcp-token>
/mcp/token POST Groove internal only — mints the token from a backoffice login jwt-auth: <backoffice-session>
Info

You will never call `/mcp/token` yourself — you have no Groove backoffice login. Your account manager mints the token on that route and hands you the resulting value. Everything on the provider side goes to `/mcp`.

Step 1 — Get your access token

Ask your Groove account manager for an MCP access token and the gateway base URL for the environment you are integrating against.

The token is a long opaque string. It is constant and does not expire — you set it once in your client and there is nothing to renew. It stays valid until Groove rotates the signing key.

**Handle the token as a shared secret.** It carries no user identity and no expiry, and it cannot be revoked individually — the only revocation is a key rotation on Groove's side, which invalidates every issued token at once. Store it in your secret manager, never commit it, and report a leak to your account manager straight away.

Step 2 — Verify it with a plain HTTP call

Before touching any client config, confirm the token works. This lists the available tools:

curl -s -X POST https://<groove-gateway>/mcp \
  -H "Authorization: Bearer <MCP_TOKEN>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

A healthy response lists 9 tools: list_tools, get_server_info, get_endpoint, list_endpoints, search_docs, sign_request, verify_signature, generate_snippet, generate_integration.

A second sanity check — ask it for the reverse endpoint catalogue:

curl -s -X POST https://<groove-gateway>/mcp \
  -H "Authorization: Bearer <MCP_TOKEN>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call",
       "params":{"name":"list_endpoints","arguments":{"integration":"reverse"}}}'

You should get 19 endpoints, grouped by category — the Transaction Flow operations, Game Launch, the Free Round Bonus calls, and the reference pages. If that comes back, your token and URL are both correct.

Step 3 — Connect your AI assistant

Use the HTTP (Streamable HTTP) transport, point it at https://<groove-gateway>/mcp, and pass the token in the Authorization header.

Claude Code (CLI)

claude mcp add --transport http groove https://<groove-gateway>/mcp \
  --header "Authorization: Bearer <MCP_TOKEN>"

Cursor, VS Code, and generic MCP clients (mcp.json)

{
  "mcpServers": {
    "groove": {
      "url": "https://<groove-gateway>/mcp",
      "headers": {
        "Authorization": "Bearer <MCP_TOKEN>"
      }
    }
  }
}

After adding the server, restart or reload your client — it should list the 9 tools. Ask it something simple to confirm, for example “Using the Groove MCP, list the reverse integration transaction endpoints.”

Calling the MCP directly over HTTP

You do not need an AI client. /mcp is plain JSON-RPC 2.0 over HTTPS, so you can drive it from a script, from your test suite, or from a build step.

Envelope:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "<tool name>",
    "arguments": { }
  }
}

Required headers:

Header Value
Authorization Bearer <MCP_TOKEN>
Content-Type application/json
Accept application/json, text/event-stream

Example — verify an inbound signature on a getbalance request:

curl -s -X POST https://<groove-gateway>/mcp \
  -H "Authorization: Bearer <MCP_TOKEN>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{
        "name":"verify_signature",
        "arguments":{
          "integration":"reverse",
          "pathAndQuery":"/groove?request=getbalance&gamesessionid=123&accountid=456",
          "key":"<your base64 Access Key Value>",
          "signature":"<the base64 signature from the Authorization header>"
        }}}'

The result is returned as text content — valid, or invalid signature (401).

Warning

The `key` you pass to `sign_request` / `verify_signature` is your Groove **Access Key Value** — the integration secret described in [Signature Validation](/transaction-api/signature-validation). It is **not** the MCP access token, and the two are never interchangeable.

Response and error codes

Code Meaning
200 Success — the JSON-RPC result is in the body
401 Missing, malformed or invalid Authorization: Bearer token, or the signing key was rotated
404 The MCP is not enabled on that gateway — check the base URL with your account manager
413 Request body over the 4 MiB limit

A tool-level failure (an unknown endpoint name, a malformed query) still returns HTTP 200 with isError: true and an explanatory message in the result content — that is normal MCP behaviour, not a transport failure.

Troubleshooting

Symptom Likely cause and fix
401 on every call Token missing the Bearer prefix, truncated on copy, or rotated. Re-copy it; ask your account manager for a fresh one.
404 on /mcp Wrong base URL, or the MCP is not enabled on that environment. Confirm the URL with your account manager.
Client connects but shows no tools Client is configured for stdio instead of HTTP, or the Authorization header is not being sent.
413 Payload Too Large The request body exceeds 4 MiB. Tool arguments are small — this normally means a malformed request body.
Tool returns no reverse endpoint named "…" Endpoint names are exact. Call list_endpoints with integration: "reverse" to get the canonical spelling (e.g. Wager And Result, Cancel FRB).
Results include endpoints not on this site integration was omitted. Always pass "reverse" so answers are scoped to this integration.

Tools Reference

Tools Reference

The MCP server exposes 9 tools. Your AI assistant picks them automatically from your prompt, but they are documented here in full so you can call them directly over HTTP or check exactly what your assistant is doing.

Every argument below goes in params.arguments of a tools/call request — see Calling the MCP directly over HTTP.

Tool summary

Tool Purpose Required arguments
list_tools List every tool with its description and input schema
get_server_info Server name, version, endpoint count, supported integrations
list_endpoints List every documented endpoint, grouped by integration and category
get_endpoint Full spec for one endpoint: parameters, responses, error codes integration, name
search_docs Free-text search across endpoint names, summaries and categories query
sign_request Compute the signature header for a request integration, key
verify_signature Check whether a signature is valid — the request checker integration, key, signature
generate_snippet A runnable example for one endpoint in your language integration, name, language
generate_integration A complete, startable project for the whole transaction flow integration, language
Info

**Always pass `integration: "reverse"`.** It scopes every answer to the reverse integration documented on this site.


Documentation tools

list_endpoints

Lists every documented endpoint, grouped by integration and category.

Argument Type Required Description
integration string Yes reverse — scopes the listing to the integration on this site
{ "name": "list_endpoints", "arguments": { "integration": "reverse" } }

Returns the 19 reverse-integration entries:

Category Endpoints
Transaction Flow GetAccount, GetBalance, Wager, Result, Wager And Result, Rollback, Jackpot
Game Launch Game Launch, Dynamic Game URL
Free Round Bonuses Create Bonus, Assign Bonus, Cancel FRB, Get FRB Status
Getting Started Groove Reverse Integration Overview, Transaction API Overview, Free Round Bonus API Overview
Reference Signature Validation, Error Code Appendix, Free Round Bonus FAQ

Endpoint names are matched **exactly**, including spacing and capitalisation — `Wager And Result`, not `wagerAndResult`; `Cancel FRB`, not `Cancel Bonus`. Run `list_endpoints` first if you are unsure of a name.

get_endpoint

Returns the full structured spec for one endpoint: request parameters, response fields, status codes, signature scheme and authentication.

Argument Type Required Description
integration string Yes reverse
name string Yes Exact endpoint name, e.g. Wager, Get FRB Status
{ "name": "get_endpoint", "arguments": { "integration": "reverse", "name": "Wager" } }

Returns JSON — the endpoint’s method, path, category, summary, every documented parameter with its type and whether it is required, the success response shape, and the applicable status codes.

search_docs

Free-text search over endpoint names, summaries and categories.

Argument Type Required Description
query string Yes Free text, e.g. balance, free spin, idempotency
integration string Yes reverse — scopes the search to this integration
{ "name": "search_docs", "arguments": { "query": "free round", "integration": "reverse" } }

Signature tools

Both signature tools implement the reverse scheme exactly as described in Signature Validation:

Signature = base64_encode(HMACSHA256(Path-And-Query, base64_decode(Access Key Value)))
Header    = Authorization: HMAC-SHA256 Signature={Signature}

Pass the Access Key Value as key — the tool performs the base64 decode for you.

sign_request

Computes the signature and returns the ready-to-send header.

Argument Type Required Description
integration string Yes reverse
pathAndQuery string Yes The request path plus query string, e.g. /groove?request=getbalance&accountid=1
key string Yes Your Access Key Value (base64, as issued by Groove)
{
  "name": "sign_request",
  "arguments": {
    "integration": "reverse",
    "pathAndQuery": "/groove?request=getbalance&gamesessionid=123&accountid=456",
    "key": "<your Access Key Value>"
  }
}

Result:

Authorization: HMAC-SHA256 Signature=<base64 signature>

verify_signature

The request checker: confirms a signature matches the request. Use it when a signature is being rejected and you need to know whether the fault is yours or the sender’s.

Argument Type Required Description
integration string Yes reverse
pathAndQuery string Yes The path plus query string exactly as received
key string Yes Your Access Key Value
signature string Yes The base64 signature to check

Result is valid, or invalid signature (401).

Warning

`Path-And-Query` must be the **exact** string that was signed: absolute path, the `?`, and the query in its original parameter order with original encoding. Re-ordering, decoding or dropping a parameter changes the hash and produces a false `invalid`.


Code generation tools

generate_snippet

A single runnable example for one endpoint, with the signing or verification step shown explicitly.

Argument Type Required Description
integration string Yes reverse
name string Yes Exact endpoint name, e.g. Wager
language string Yes go, java, python, typescript, or curl
{
  "name": "generate_snippet",
  "arguments": { "integration": "reverse", "name": "Wager", "language": "python" }
}

generate_integration

Generates a complete, startable project — not a snippet. You get the files of a working skeleton:

  • A real /groove entry point wired for all 7 reverse transaction operations: getaccount, getbalance, wager, result, rollback, jackpot, wagerAndResult.
  • Inbound Authorization HMAC verification, implemented against the documented scheme.
  • The documented success responses and the full error catalogue — HTTP 200 with the status in the body, as this API specifies.
  • One wallet seam per operation family: the small set of files you fill in with your own logic, routed per brand.
Argument Type Required Description
integration string Yes reverse
language string Yes go, java, python, or typescript
{ "name": "generate_integration", "arguments": { "integration": "reverse", "language": "go" } }

Returns a JSON list of files, each with a path, content, and an action:

action Meaning
overwrite Regenerated on every call — protocol plumbing, do not hand-edit
create-if-absent Written once and never clobbered — the wallet seams and config are yours to edit

That split means you can re-run generate_integration after a docs update to refresh the plumbing without losing your own code.

Info

The generated project emits the full core transaction flow — there is no per-endpoint subsetting. For `java`, you get an opinionated Spring Boot blueprint.


Server tools

list_tools

Returns every registered tool with its description and full JSON input schema. No arguments. Useful for confirming your client is talking to the server you expect.

get_server_info

Reports the server’s identity and the size of its loaded catalogue. No arguments.

Field Meaning
name Always groove-mcp
version The tool catalogue version, e.g. 1.0.0
endpoints_loaded How many endpoint specs the server has in memory

Use it as a liveness check: a successful response means your token is valid and the server is serving.

Example Workflows

Example Workflows

Once the MCP is connected, you work with it in plain language — your assistant chooses the tools. These are the requests that come up most often during a reverse integration, plus the raw HTTP equivalents for when you want to script them.

Prompts that work well

Exploring the API

  • “List the reverse-integration transaction endpoints.”
  • “Show me the full spec for the reverse Wager endpoint — every parameter and status code.”
  • “What does the reverse integration require me to store to handle a later Rollback?”
  • “Search the reverse docs for anything about free rounds.”

Signatures

  • “Compute the Authorization header for /groove?request=getbalance&gamesessionid=123&accountid=456 with access key <key>, reverse scheme.”
  • “This request came in with signature <sig> — is it valid for path-and-query <path> with key <key>?”
  • “My signature check keeps failing on Wager. Show me exactly what string should be hashed.”

Writing code

  • “Generate a Python snippet for the reverse Result endpoint, including the signature verification.”
  • “Generate a full Go project for the reverse integration and write the files into ./groove-integration.”
  • “Regenerate the reverse TypeScript blueprint and tell me which files are safe to overwrite.”
Info

Say **"reverse"** in your prompt. That is what makes your assistant pass `integration: "reverse"`, scoping every answer to the integration documented on this site.


Workflow 1 — Look up an endpoint before implementing it

Ask: “Show me the full spec for the reverse Wager endpoint.”

Your assistant calls:

{
  "jsonrpc": "2.0", "id": 1, "method": "tools/call",
  "params": {
    "name": "get_endpoint",
    "arguments": { "integration": "reverse", "name": "Wager" }
  }
}

You get the documented request parameters, the success response shape, and the status codes — the same content as the Wager page, but structured, so your assistant can generate matching code from it directly.

Follow up with “now generate the handler in Java” and it chains straight into generate_snippet.

Workflow 2 — Debug a failing signature

This is the fastest use of the MCP. When a signature is rejected, the question is always whose side is wrong — and verify_signature answers it against a reference implementation.

Give your assistant the exact path-and-query you received, the signature from the Authorization header, and your access key:

curl -s -X POST https://<groove-gateway>/mcp \
  -H "Authorization: Bearer <MCP_TOKEN>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{
        "name":"verify_signature",
        "arguments":{
          "integration":"reverse",
          "pathAndQuery":"/groove?request=wager&gamesessionid=123&accountid=456&transactionid=789&betamount=1.00",
          "key":"<your Access Key Value>",
          "signature":"<signature from the Authorization header>"
        }}}'

Reading the result:

Result What it means
valid The signature is correct — your own validation code has the bug. Compare your Path-And-Query construction against the string you just passed.
invalid signature (401) Either the key is wrong for this environment, or the Path-And-Query you reconstructed is not the one that was signed.

Then have it compute the expected value for comparison:

{
  "name": "sign_request",
  "arguments": {
    "integration": "reverse",
    "pathAndQuery": "/groove?request=wager&gamesessionid=123&accountid=456&transactionid=789&betamount=1.00",
    "key": "<your Access Key Value>"
  }
}

Diffing that against what your code produces isolates the fault in one step.

Warning

Your **Access Key Value** is a production secret. Prefer running these checks against your staging key, and never paste a production key into a chat log or a shared transcript you do not control.

Workflow 3 — Generate a working skeleton

Ask: “Generate a full Go project for the reverse integration and write the files into ./groove-integration.”

Your assistant calls generate_integration and writes out the returned files:

{
  "name": "generate_integration",
  "arguments": { "integration": "reverse", "language": "go" }
}

What you get is startable, not illustrative — a /groove entry point handling all seven transaction operations, inbound signature verification, and the documented response and error catalogue already wired up.

Then do the work that is actually yours:

  1. Open the create-if-absent files — these are the wallet seams, one per operation family.
  2. Implement your balance, bet, win, and rollback logic behind them.
  3. Fill in your access key and Groove endpoint configuration.
  4. Run it, and use verify_signature (Workflow 2) to confirm the inbound checks pass.

The overwrite files are protocol plumbing. Leave them alone — re-running generate_integration after a docs update refreshes them without touching your seams.

Workflow 4 — Keep implementation and docs in step

Because the MCP serves the same specs published on this site, it is worth re-asking after any Groove docs update:

  • “Compare the reverse Wager spec to my handler in wager.go — am I missing any parameter?”
  • “List every status code the reverse Rollback endpoint can return, and check my switch statement covers them.”
  • “Regenerate the reverse Go blueprint and show me a diff of the overwrite files.”

This turns the certification checklist into something your assistant can verify against the source of truth rather than against your memory of it.


Getting help

Need Contact
MCP access token, gateway URL, key rotation Your Groove account manager
Integration questions during onboarding Your Groove integration channel (Slack / Teams)
API behaviour This documentation, or the MCP itself — ask it