Query Your Vexo Analytics from Claude, Cursor, or ChatGPT with MCP

Most product questions are small and frequent: which screen threw the most errors yesterday, how many people used the app last week, is that new flow getting any traffic. Each one is a trip to a dashboard, a filter, a date range — minutes of context-switching for a one-line answer. Vexo now closes that gap by speaking the same protocol your AI tools already do. With a native MCP server built into the Vexo API, you can ask those questions in plain language from Claude, Cursor, or ChatGPT and get the numbers back without leaving what you were doing.

What MCP is

The Model Context Protocol (MCP) is an open standard for connecting large-language-model tools to outside data and actions. Instead of every app inventing its own plugin format, MCP defines one contract: a client (the AI tool — Claude, Cursor, ChatGPT) talks to a server (your data source) over a small set of methods. The client asks the server what it can do (tools/list) and then calls those tools (tools/call) on the user's behalf, feeding the results back into the conversation.

The practical upshot: any data source that speaks MCP becomes something the model can query directly, in the language you already use with it. You don't write API glue, and you don't teach the model your schema — the server advertises its tools, and the client figures out which one answers your question. Vexo implements the server half of that contract for your analytics.

What the Vexo MCP server exposes

Vexo's server is deliberately small and read-only — it answers questions, it never changes your data. It advertises three tools:

• list_apps — returns the Vexo apps (id and name) you have access to. This is where a session usually starts: you get an app id to hand to the other two tools.
• query_events — answers a plain-language analytics question about one app's events, such as “top 10 screens by errors last week.” It returns the matching rows plus the query it generated to get them, so you can see exactly what was asked. It takes an app_id and a question, and optionally a from/to window (defaulting to the last 28 days).
• get_stats — returns headline metrics for one app over a window: total events, distinct users, and distinct sessions. Good for a quick pulse check without phrasing a full question.

Every tool is app-scoped and authorized per call: you pass an app_id, and the server confirms the token you authenticated with is actually allowed to see that app before it runs anything. There are no write tools, so nothing an assistant does through MCP can modify your project.

Pointing an MCP client at Vexo

The endpoint is a single POST /mcp on the Vexo API. It speaks JSON-RPC 2.0 over plain HTTP — one request, one response, no long-lived connection to manage — and it authenticates with the standard Authorization header, the same bearer token the rest of the Vexo API uses. You'll find your token under the app's Data export & API settings; treat it like a secret.

MCP clients are configured with an mcpServers block that names the server and tells the client how to reach it. Exact key names vary between clients — and some desktop clients reach a remote HTTP server through a small local bridge — but the entry for Vexo is shaped like this:

{
  "mcpServers": {
    "vexo": {
      "url": "https://api.vexo.co/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_VEXO_TOKEN"
      }
    }
  }
}

Restart the client, and Vexo shows up as an available tool source. From the client's side, the handshake is the standard MCP one — initialize, then tools/list to discover the three tools, then tools/call when you ask something that needs them. You never call those methods yourself; the client does it when your question calls for it.

Why it matters

The value isn't a new dashboard — it's no dashboard. The questions you'd normally click through to answer become one sentence in a tool you already have open:

• “Which screens threw the most errors in my app last week?”
• “How many distinct users and sessions did we see over the last 28 days?”
• “List my Vexo apps, then give me the total event count for the production one this month.”

Because the assistant can chain the tools — list_apps to resolve which project you mean, then query_events or get_stats to answer — a vague question turns into a precise one without you copying an app id around. And because the results come back as structured rows alongside the generated query, the model can summarize the answer and show its work, which matters when you're about to make a call based on it.

Honest about the scope

This is a focused first release. The server is read-only and ships three tools — list_apps, query_events, and get_stats. It doesn't expose funnels, retention grids, session replays, or anything that writes to your project; those still live in the dashboard. What it does cover — asking a plain-language question about your events and pulling headline numbers — is the part you reach for most, and now you can reach for it from wherever you already work.

If you already use the Vexo public API, MCP is the conversational front door to the same data: the same token, the same app scoping, a different way in. Add the mcpServers entry once and your analytics are one question away.