MCP server

xeve speaks the Model Context Protocol, so an AI assistant can answer questions about your own measured activity — "how much did I code last week", "what broke my focus on Tuesday", "does my sleep track with my productive hours" — from the data your trackers already collect.

Two ways to connect. Both expose the same read-only tools and enforce the same scopes.

Hosted (Streamable HTTP)

https://api.xeve.io/mcp

Transport: Streamable HTTP. Authorization: OAuth 2.0, discovered from the WWW-Authenticate header on the first unauthenticated request, or read directly from https://xeve.io/.well-known/mcp.

Any MCP client that supports remote servers can add that URL. It will register itself (RFC 7591), open a browser for consent, and receive a token carrying only the scopes the user approved. Nothing is pasted anywhere.

For Claude Code:

claude mcp add --transport http xeve https://api.xeve.io/mcp

Sessions are stateless — no Mcp-Session-Id, no SSE stream. Every request carries its own credential, which is all a read-only tool needs.

Local (stdio)

The published package, for clients that run servers as subprocesses:

{
  "mcpServers": {
    "xeve": {
      "command": "npx",
      "args": ["-y", "xeve-mcp-server"],
      "env": { "XEVE_API_TOKEN": "xeve_dt_…" }
    }
  }
}

Create the token at xeve.io/dashboard/settings → API Access and grant it only the scopes you want the assistant to have.

Tools

Every tool is read-only, answers for the authenticated user alone, and takes dates as YYYY-MM-DD (defaulting to today).

Tool	Scope
get_daily_summary	read:activity
get_app_usage	read:activity
get_category_breakdown	read:activity
get_coding_summary	read:activity
get_hourly_activity	read:activity
get_focus_streaks	read:activity
get_context_switches	read:activity
get_recent_sessions	read:activity
get_devices	read:activity
get_music_history	read:music
get_github_activity	read:code
get_health_summary	read:health
get_heart_rate	read:health
get_locations	read:location
get_insights	read:content
get_profile	read:profile

A tool called without the scope it needs answers 403 with a WWW-Authenticate challenge naming the missing scope, so a client can ask the user to widen the grant instead of failing silently.

What it cannot do

• It cannot write. Every tool is a read.
• It cannot read anyone else's data. No tool takes a user id; the server derives the user from the token and row-level security does the filtering.
• It cannot exceed its grant. A token scoped to read:activity gets 403 on health, music and location tools — the same answer the API gives.