GoalCast Server

A small, standards-compliant MCP server (using the official @modelcontextprotocol/sdk, Streamable HTTP transport) that wraps the PredictionPool CosmWasm contract deployed on Injective testnet. It exposes exactly two tools:

Tool	What it does
register_prediction	Signs and broadcasts RegisterPrediction to the contract
get_pool_status	Reads the current home/draw/away split for a match

This is what GoalCast's Next.js app (lib/injective.ts) connects to as a real MCP client — not a hand-rolled REST bridge.

Setup

cd mcp-server
npm install
cp .env.example .env

Fill .env:

INJECTIVE_PRIVATE_KEY=<testnet wallet private key, no 0x needed either way>
INJECTIVE_NETWORK=testnet
PREDICTION_POOL_CONTRACT_ADDRESS=inj1...   # from DEPLOY.md step 4
PORT=8787

Use a dedicated testnet-only wallet here — this key signs every prediction the server submits. In this hackathon MVP the MCP server's wallet is the signer for all predictions (see "Known limitation" below).

Run it:

npm run dev

You should see:

GoalCast MCP server listening on http://localhost:8787/mcp

Connect the Next.js app to it

In the main app's .env.local:

INJECTIVE_MCP_SERVER_URL=http://localhost:8787/mcp

Restart npm run dev in the app root. lib/injective.ts will now call the real tools instead of its simulated fallback.

Test it directly (without the app)

curl -X POST http://localhost:8787/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": { "name": "get_pool_status", "arguments": { "matchId": "m-usa-mex-01" } }
  }'

Or point the MCP Inspector at http://localhost:8787/mcp for a UI to browse and call the tools.

Known limitation (worth mentioning in your demo/judging notes)

Right now the MCP server's own wallet signs every prediction — a fan's "vote" is broadcast by the server, not by their own wallet. That's fine for a hackathon MVP (it proves the full MCP → contract → chain path works), but a production version should have the fan sign client-side (e.g. via Keplr) and have the MCP server only build the unsigned tx, or verify a fan-signed payload before relaying it. Worth a sentence in your submission write-up — judges tend to reward projects that name their own known limitations over ones that gloss over them.