MESS

One command, user scope — every project you open from then on has the ledger.

$ claude mcp add --transport http --scope user mess https://mess.fyi/api/mcp \ --header "Authorization: Bearer mess_sk_YOUR_KEY" ✓ Added HTTP MCP server "mess"

Add this to ~/.cursor/mcp.json (or a project's.cursor/mcp.json).

{ "mcpServers": { "mess": { "url": "https://mess.fyi/api/mcp", "headers": { "Authorization": "Bearer mess_sk_YOUR_KEY" } } } }

Any MCP client that speaks streamable HTTP works the same way.

There is also a plain REST surface at /api/v1/accounts with the same keys, for scripts and CI.

The server sends instructions with the handshake, so agents know to log accounts unprompted — no per-session reminders, no custom prompts.

Log a service account the moment it is created — provider, human label, owning email, project, plan, cost, where the credentials live. Idempotent on provider + label: re-logging updates the row instead of duplicating it.

Find accounts by free text or provider — the first call when picking a project back up, plus which email owns something and whether an account already exists before creating a new one.

The whole ledger for this workspace, in one call.

Correct a row: record the owning email, fix a label, note where credentials live, or mark a dead account cancelled. There is no delete — history is kept.

Record the human’s answer that one project label belongs to another. An agent sees a directory name, not a project — two checkouts of one repo look like two projects, and a six-repo estate looks like six. Only ever from their answer, never guessed from similar names. Rows keep their labels; reads resolve.

Record what a project check actually found — the database’s free tier pauses, the domain expires in September, the production URL answers with a valid cert. Only ever what was observed: ‘attention’ needs the finding named, ‘na’ is an answer, and a correction is a new look, never an edit.

Who can still get into an account — a different question from who owns it, and the one that catches the contractor who left in March whose login still works. Recorded only from the human’s answer: from a session you can prove a key works, never see who else holds one. Team plan.

Read that back, for one account or across the ledger. No records means nothing has been recorded — never that nobody else has access. Team plan.

Exactly what the server tells your agent

The instructions arrive with the MCP handshake — that mechanism is the whole product, so here is the complete text, verbatim. If you'd rather your agent didn't volunteer writes, don't wire it in.

Every session — the keeping instructions

MESS is the ledger of the human's service accounts — which provider, which email owns it, which projects it serves, what it costs. Whenever you create or configure a service account (anything with a login), log it with log_account. Never store secret values in the ledger — it is the map, not the vault. The unit is one row per ACCOUNT — a login at a provider — never per project, database, or environment: a confirmed login gets one row listing everything it serves in project. Login boundaries are often unobservable (free tiers: often one account per project; different connection methods: DIFFERENT accounts) — never consolidate without a confirmed shared login; when unconfirmed, log one row per instance, "login boundary unconfirmed" in notes. A wrong merge hides an account. Before creating a new account — or provisioning any NEW service for a project — search_accounts first: reuse an existing account (or raise the choice to the human) instead of creating a parallel one; sprawl is the mess. When a row looks stale or wrong from where you stand (CLI auth state, env files, a dashboard you are in), correct it — re-logging is idempotent, corrections go through update_account. Only verify what you can actually observe; never guess. When you start or resume work on a project, search_accounts for that project as part of getting oriented — the ledger often knows accounts this machine cannot show you; raise the most important gaps at a natural moment. Unknown fields are fine — log anyway; but when a NEW account's owning email or cost is unknown while the human is present, ask them — one short question at a natural pause, never an interrogation — and record the answer with update_account. MESS tracks whatever remains as open questions for the human. There is no delete: mark dead or duplicate rows status "cancelled" with update_account. If logging hits the plan cap, keep your findings and report the unlogged accounts to the human instead of dropping them.

First connect to an empty ledger — the onboarding variant: it offers the dig, and never runs it without your say-so

MESS is the ledger of the human's service accounts — which provider, which email owns it, which projects it serves, what it costs. Whenever you create or configure a service account (anything with a login), log it with log_account. Never store secret values in the ledger — it is the map, not the vault. The unit is one row per ACCOUNT — a login at a provider — never per project, database, or environment: a confirmed login gets one row listing everything it serves in project. Login boundaries are often unobservable (free tiers: often one account per project; different connection methods: DIFFERENT accounts) — never consolidate without a confirmed shared login; when unconfirmed, log one row per instance, "login boundary unconfirmed" in notes. A wrong merge hides an account. Unknown fields are fine — log anyway; but when a NEW account's owning email or cost is unknown while the human is present, ask them — one short question at a natural pause, never an interrogation — and record the answer with update_account. MESS tracks whatever remains as open questions for the human. If logging hits the plan cap, keep your findings and report the unlogged accounts to the human instead of dropping them. …

The dig itself — the "sort out my mess" procedure, served whole as an MCP prompt (Claude Code: /mcp__mess__sort_out_my_mess)

Sort out my mess: inventory every service account this machine and my projects touch, and log each one to the MESS ledger. Work in three passes — first attempts routinely surface only half of what's really here, so don't declare done after one sweep. …

Every variant is budgeted to fit an agent's context whole — clients truncate long handshakes, so the instructions stay short and the dig procedure travels separately, as an MCP prompt your agent fetches in full only when you say“sort out my mess”. Nothing runs until you say it.

If you install the optional Claude Code hook, then the moment a session runs a provider CLI (vercel, supabase, stripe, …) it asks MESS whether the ledger already knows that provider for the current repo. The matching happens on your machine — only the matched provider name and the repo folder name are ever sent, never the command itself. If the ledger already has that account for that project, the answer is silence; repeats are silenced for an hour. Otherwise your agent hears one line like this:

Example — exactly what the agent hears, composed by the same code that serves it

MESS: this session just touched the Vercel CLI in "acme-web", and the ledger has no Vercel account on record. If an account was created, configured, or found here, log it with log_account (project: "acme-web") — provider, a human label, role, the owning email if visible from where you stand. If the owning email or cost is unknown while the human is present, ask them now, one short question at a natural pause. Unknown fields are fine — log anyway.

The hook itself — what runs on your machine, verbatim