Skip to content
Home About Products Blog Contact
← Back to Blog

Designing APIs for AI agents, not just developers

The differences between developer-friendly and agent-friendly API design — and why MCP changes the equation for analytics platforms.

Developer APIs vs. agent APIs

When we built the first version of DunkSim’s API, we designed it like any other REST API: clear endpoints, good documentation, predictable response shapes. Developers could integrate it in an afternoon.

Then we started thinking about AI agents — and realized we’d built the wrong thing.

Developer APIs assume a human in the loop. The developer reads documentation, makes decisions about which endpoints to call, handles errors manually, and interprets responses in the context of their broader application. The API is a tool; the developer is the operator.

Agent APIs work differently. Claude or ChatGPT doesn’t read documentation the same way. It reads tool descriptions, infers intent from schema shape, and needs the API to be self-describing at call time — not just at docs-read time. Error messages need to be interpretable by a language model, not just a human engineer.

What MCP changes

The Model Context Protocol standardizes how AI agents discover, authenticate against, and call tools. DunkSim exposes 7 MCP tools:

  • simulate_game — run a full Monte Carlo simulation for a given matchup
  • get_player_params — retrieve current calibrated model parameters for a player
  • list_upcoming_games — get scheduled games with odds and context
  • commit_prediction — commit a prediction to the leaderboard
  • get_user_balance — check token balance for the requesting user
  • get_leaderboard — retrieve current accuracy standings
  • get_model_accuracy — fetch out-of-sample accuracy statistics

Each tool has a structured description Claude can read at inference time. The descriptions include not just what the tool does, but when to use it and what to do with the result.

The OAuth 2.0 / PKCE layer

Agents operating on behalf of users need to authenticate as those users — not as a service account. DunkSim implements OAuth 2.0 with PKCE (Proof Key for Code Exchange), which allows Claude to request tokens on behalf of a specific user without that user’s credentials ever leaving their device.

This means an agent session inherits the user’s prediction quota, token balance, and leaderboard standing. The agent isn’t a special API user — it’s a first-class participant in the same economy as human users.

Structured JSON output for agents

Every MCP tool response is strictly typed JSON with explicit field names designed for downstream agent consumption. We avoid:

  • Prose-heavy responses that require parsing
  • Optional fields that create branching logic
  • Ambiguous numeric types (we always specify units in field names)

The design principle: if Claude can use the response directly in a <tool_result> without further interpretation, we’ve done it right.

The future of agent-native products

Most analytics platforms are built for human consumption first, with APIs as an afterthought. We believe the next generation of analytics infrastructure will be agent-first: designed from the ground up to be operated by autonomous systems, with human interfaces layered on top.

DunkSim is our first demonstration of that principle. The MCP channel isn’t a feature — it’s the architecture.