Horse racing MCP: connect AI tools to RacingAPI.net

The Enterprise MCP server exists so compatible AI clients can discover and use RacingAPI.net tools in a structured way. In practice, that means the client can request racing data through the same account you already manage in the dashboard, instead of scraping pages or hard-coding ad hoc prompts.

Use it when you want an assistant to fetch live race information, compare published fields or explain what a tool returned. The value is in retrieval: the model can call the right RacingAPI.net endpoint, then summarise the response in plain language for your workflow.

An MCP client should be treated as a consumer of tools, not as a replacement for product support. It can retrieve data, report a field, or explain a race selection that already exists, but it should not be relied on to answer account, billing or access questions as if it were a human support agent.

This boundary keeps behaviour predictable. If a tool is unavailable, if your access has lapsed, or if a request is outside the published RacingAPI.net scope, the client should surface that clearly rather than guessing. For developer work, the safer pattern is to have the assistant call tools only when the response comes from RacingAPI.net itself.

MCP access follows the same account-controlled model as the rest of RacingAPI.net. Customers create and manage their own keys, and the key remains server-side. In a compatible client, access is granted through explicit OAuth consent or an API-key header in supported developer clients, which keeps the authorisation boundary clear.

This is important operationally because revocation should be immediate and practical. If a key is rotated or removed in the dashboard, the client should stop being able to call RacingAPI.net. That makes MCP suitable for controlled deployments where you want to grant access to a specific assistant, then withdraw it without changing your whole integration.

MCP calls count against your Enterprise usage model. Enterprise includes unlimited monthly requests, but that does not mean unlimited requests per second. The documented rate limit is 10 requests per second, and MCP feed calls share that same ceiling.

Treat the AI client as a consumer that needs a budget. If you allow an agent to ask for race data repeatedly, it can consume that budget quickly even when each individual call is read-only. For stable operation, design the assistant to ask once, reuse retrieved data where appropriate, and avoid repeated polling unless the workflow genuinely needs it.

MCP works only in clients that can speak the protocol and support the authorisation flow you choose. RacingAPI.net provides a read-only MCP server for compatible AI clients, but the client itself still needs to support connecting to that server in a reliable way.

In the dashboard, use the Connect AI flow, then follow the MCP guide. The practical goal is simple: the client should be able to discover available tools, call them with the right context, and return their results without exposing credentials in the prompt or pretending unsupported clients are compatible.

Do not assume MCP gives you extra response speed, unlimited concurrency, or a guarantee that every AI call will succeed. Source cadence, network response time and model response time are different things, and RacingAPI.net does not promise a millisecond update interval or an uptime SLA.

Likewise, do not treat the AI layer as validated trading or prediction logic. The point of the Enterprise MCP server is controlled retrieval from RacingAPI.net tools, with live tips and saved explanations where enabled, not a promise of perfect answers, guaranteed outcomes or free-form autonomous betting advice.