MCP

There are two MCP surfaces, and they are different things. If you have an MCP client, you want the first one.

1. The live MCP server

A real MCP server speaking JSON-RPC over Streamable HTTP — tools/list, tools/call, the full protocol. Point an MCP client at:

https://mcp.bigballsdata.com/mcp

There are two ways to authenticate, and most clients should use the first.

Sign in with your BigBalls account

The server is an OAuth 2.1 protected resource. Add the URL above to any MCP client that supports OAuth — Claude among them — and it will discover the authorization server from the 401 challenge, register itself through Dynamic Client Registration, and take you through a consent screen. There is no client ID to create and no API key to paste. Tools then return the data your account is entitled to.

Or send an API key

Clients that do not speak OAuth can send the same key they use against the REST API as a bearer token (Authorization: Bearer <api_key>).

Both paths land in the same place: every plan gate, rate limit, and entitlement applies identically through MCP, because the server is a thin passthrough over the same gateway with no separate permission logic. Machine-readable details are in the server card and, for the OAuth specifics, the protected-resource metadata.

Call tools/list for the authoritative tool set. It is deliberately not restated here — a hand-copied list in the docs is a list that goes stale.

2. The static REST catalogue

Separately, a GET-able tool catalogue is served at /mcp and at the well-known path /.well-known/mcp. The body mirrors the MCP tools/list shape, but it is a static document describing REST endpoints, not the live server above — calling one of its tools means hitting the REST endpoint named on it against the gateway base URL. It exists for tool routers and integration tooling that consume static metadata rather than speaking MCP.

The two tool sets are not the same list. This catalogue describes 8 REST-shaped tools; the live server serves 6, and only get_standings appears in both. Do not treat either as documentation for the other.

Shape

{
  "schema_version": "v1",
  "server": {
    "name": "bigballsports",
    "display_name": "Big Balls Sports Data",
    "version": "1.0.0"
  },
  "transport": {
    "base_url": "https://api.bigballsdata.com",
    "auth": {
      "type": "bearer",
      "header": "Authorization",
      "format": "Bearer <api_key>",
      "key_url": "https://bigballsdata.com/dashboard/keys"
    },
    "openapi_url": "https://bigballsdata.com/openapi.json"
  },
  "mcp_server": {
    "endpoint": "https://mcp.bigballsdata.com/mcp",
    "transport": "streamable-http",
    "protocol_version": "2025-06-18",
    "server_card_url":
      "https://bigballsdata.com/.well-known/mcp/server-card.json",
    "auth": { "type": "bearer", "header": "Authorization", "...": "..." },
    "tools_note": "the array below is the REST catalogue, not this server's tools"
  },
  "tools": [
    {
      "name": "get_scores",
      "description": "...",
      "inputSchema": { /* JSON Schema */ },
      "endpoint": { "method": "GET", "path": "/v1/matches" }
    }
  ]
}

Tools

Calling a tool

Resolve tools[].endpoint.path against transport.base_url, substitute any {id} placeholders, and call with the bearer token. The inputs in inputSchema map to query params for list-style tools and path params for resource-by-id tools, the path in the endpoint object is unambiguous.

Caching

The manifest sets Cache-Control: public, max-age=300, s-maxage=300. The document changes only when tool definitions are added or modified; five-minute cache reduces fan-out on aggressive crawlers without delaying real updates for long.