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