Point an MCP-compatible AI agent at your app and let it see what is actually happening - subscribers, funnels, cohorts, a single user’s history. The Insights MCP server exposes twelve tools over the same data your dashboard reads. Every tool is read-only by construction - there is no write path, so there is nothing an agent can break.

What you can ask

An agent connected to the server picks the right tool from your question. A few examples:

Connect

The server speaks Streamable HTTP at a single endpoint, https://www.vevee.org/api/mcp, authenticated with a bearer sk_live_ or sk_test_ key - the same secret keys you already use for metering. Replace sk_live_YOUR_KEY below with a real key from API Keysin your app’s dashboard.

Claude Code (CLI)

claude mcp add --transport http vevee https://www.vevee.org/api/mcp \
  --header "Authorization: Bearer sk_live_YOUR_KEY"

Claude.ai / Claude Desktop (custom connector)

Open Settings → Connectors → Add custom connector and fill in:

Cursor (.cursor/mcp.json)

{
  "mcpServers": {
    "vevee": {
      "url": "https://www.vevee.org/api/mcp",
      "headers": {
        "Authorization": "Bearer sk_live_YOUR_KEY"
      }
    }
  }
}

Stdio-only clients (via mcp-remote)

Any MCP client that only speaks stdio - no direct HTTP transport - can still reach the server through mcp-remote, a small bridge process:

{
  "mcpServers": {
    "vevee": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://www.vevee.org/api/mcp",
        "--header",
        "Authorization: Bearer sk_live_YOUR_KEY"
      ]
    }
  }
}

Tools

All twelve tools are scoped to the single app your key belongs to - there is no appId parameter to pass or get wrong. Descriptions below are copied verbatim from the tool definitions, so this table never drifts from what the agent actually sees.

Privacy

The MCP surface obeys the exact same privacy gates as the dashboard and the REST API - there is no separate, looser code path for agents.

• End users who opted out of ai_personalization(or opted out entirely) never appear in person-level results, whether that’s list_persons, list_users, get_user, list_events, or get_event. Aggregates such as get_app_overview still count them - only per-person detail is withheld.
• Persons pending deletion are excluded from person-level results the same way.
• Prompt and response text is exposed only when prompt logging is enabled for the app (the same log_promptssetting that gates the dashboard’s event-detail view), and never for opted-out or pending-deletion users - their events are excluded from list_events and get_event entirely, so there is no path for their prompts to reach an agent.
• Anonymous pre-login traffic is aggregate-only by construction: it has no person to attach to, so it can only ever show up in counts, never in a per-person tool result.
• Everything described on this page is read-only. No tool accepts a write, a delete, or a key that could perform one.

Example conversation

A short, invented transcript showing an agent chain two tools together to answer a plain question:

You: How's retention looking this month, and is anything obviously broken
     in the funnel?

Agent: [calls get_subscriber_stats { windowDays: 30 }]
       -> 412 active subscribers, 37 canceled in the last 30 days
          (churn 8.2%), 19 new, 4 reactivated.

Agent: [calls run_funnel { funnelId: "fnl_signup_to_paid" }]
       -> signed_up: 1,240 entered
          onboarding_completed: 812 converted (65.5%)
          paywall_shown: 790 converted (97.3% of prior step)
          checkout_completed: 301 converted (38.1% of prior step)

Agent: Churn is a manageable 8.2% this month, but your funnel's real
       leak is onboarding: only 65.5% of signups finish it, and every
       later step converts fine once people get there. Fixing the
       onboarding drop-off would move more people than anything else
       in this funnel.