Anomalia MCP
Anomalia exposes a Model Context Protocol server so coding agents (Cursor, Claude, and others) can manage brands, posts, plans, studio, SEO/GEO, and blog — with the same OAuth login as the CLI.
Your agent
│ stdio (local) → bun run mcp / anomalia-mcp
│ HTTPS (remote) → https://mcp.anomalia.so/mcp + Bearer
▼
Anomalia API (/api/v1/*) Quick start
Pick a transport: local stdio is simplest on your machine; remote HTTP is for cloud hosts.
Option A — Local stdio
Best for Cursor and other local agents.
- Install Bun and clone the anomalia-cli repo (or install the CLI binary so anomalia-mcp is on your PATH).
- Authenticate once:
anomalia login # or, after MCP is connected, call the login tool - Add to Cursor MCP config (absolute path required when using Bun):
{ "mcpServers": { "anomalia": { "command": "bun", "args": ["run", "/ABS/PATH/to/anomalia-cli/mcp/stdio.ts"] } } }If the binary is on PATH after install:
{ "mcpServers": { "anomalia": { "command": "anomalia-mcp" } } } - Restart Cursor / reload MCP. Call list_brands, then work with a brand slug.
Session file (shared with the CLI): ~/.config/anomalia/session.json.
Option B — Remote HTTP
- Confirm the server is up:
curl -sS https://mcp.anomalia.so/healthExpect a JSON health payload with ok: true and mcp: "/mcp".
- Cursor MCP config:
{ "mcpServers": { "anomalia": { "url": "https://mcp.anomalia.so/mcp" } } } - Clients that speak MCP OAuth (opencode, Claude Code, Cursor, the Inspector…) authenticate on their own: on first connect they open
anomalia.so, you approve, and the token is stored by the client. The initial 401 is the start of that handshake, not a crash.
Custom option — if your client cannot do OAuth, attach the token by hand: Authorization: Bearer <access_token>, using the Supabase access token that anomalia login saves in ~/.config/anomalia/session.json. Static API keys (anomalia_…) are not accepted by the remote server.
Option C — Local HTTP
bun install
bun run mcp:http
# → http://localhost:8787/mcp
# http://localhost:8787/health Auth: Bearer or the local session file.
Auth rules
| Context | How you authenticate |
|---|---|
| Local stdio / local HTTP | Browser login tool or anomalia login → session file |
| Remote HTTP | OAuth 2.1 + PKCE, or Authorization: Bearer <access_token> |
| Static API key | Not supported |
Protected resource metadata: GET /.well-known/oauth-protected-resource.
What to call first
list_brands— discover brand slugsget_dashboard— brand overviewlist_postswith status pending_user — approval queue- Prefer specific tools (approve_posts, edit_post, …) over chat for precise actions
Post and article ids accept short unambiguous prefixes from list results (same rule as the CLI).
Tool areas
| Area | Examples |
|---|---|
| Auth | login, logout, whoami, list_brands |
| Posts | list_posts, get_post, edit_post, approve_posts, regenerate_slide, make_video |
| Plans | get_plan, propose_plan, plan_week, produce_week |
| Studio | get_studio, add_note, research_competitors |
| Web | get_seo, get_geo, generate_article, chat |
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| 401 on /mcp | Missing or invalid Bearer on remote | Login locally and pass the access token, or use stdio |
| Tools missing | MCP not connected in the host | Check the Cursor MCP panel and restart the host |
| Auth works in CLI but not MCP | Different machine / no session file | Run login in the MCP process environment |
Next
- Agent skill — install the Anomalia skill so agents know when and how to call MCP or the CLI
- CLI — terminal commands when MCP is not available
- API reference — REST endpoints the MCP and CLI call
- anomalia-cli — source, tools map, and development notes