MESS

Conecte seu agente. Uma colagem.

MESS é um servidor MCP remoto. Conecte-o uma vez e todo agente de codificação que você executar — Claude Code, Cursor, qualquer coisa que fale MCP — registra as contas com as quais trabalha no seu ledger, sem aviso: criadas, implantadas ou encontradas em um arquivo env. E ele verifica o ledger antes de provisionar qualquer coisa nova.

Endpoint

https://mess.fyi/api/mcp

Transporte

HTTP streamable

Autenticação

Authorization: Bearer mess_sk_…

Chaves

Conta gratuita → pegue uma chave em Settings → Agent keys

Configuração

Claude Code

Um comando, escopo de usuário — todo projeto que você abrir a partir de então terá o 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"

Configuração

Cursor

Adicione isto a ~/.cursor/mcp.json (ou a .cursor/mcp.json de um projeto).

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

Configuração

Claude.ai e todo o resto

Qualquer cliente MCP que fale HTTP streamable funciona da mesma forma.

No Claude.ai ou Claude Desktop, adicione um conector personalizado com a URL do endpoint e sua chave como cabeçalho bearer. Para qualquer outro cliente, aponte-o para https://mess.fyi/api/mcp com o cabeçalho Authorization definido.

Há também uma superfície REST simples em /api/v1/accounts com as mesmas chaves, para scripts e CI.

As ferramentas

8 ferramentas. Essa é toda a superfície.

O servidor envia instruções com o handshake, para que os agentes saibam registrar contas sem aviso — sem lembretes por sessão, sem prompts personalizados.

log_accountwrite

Registre uma conta de serviço no momento em que ela é criada — provedor, rótulo humano, e-mail do proprietário, projeto, plano, custo, onde as credenciais estão. Idempotente em provedor + rótulo: registrar novamente atualiza a linha em vez de duplicá-la.

search_accountsread-only

Encontre contas por texto livre ou provedor — a primeira chamada ao retomar um projeto, além de qual e-mail possui algo e se uma conta já existe antes de criar uma nova.

list_accountsread-only

O ledger inteiro deste workspace, em uma única chamada.

update_accountwrite

Corrija uma linha: registre o e-mail do proprietário, corrija um rótulo, anote onde as credenciais estão ou marque uma conta morta como cancelada. Não há exclusão — o histórico é mantido.

confirm_project_aliaswrite

Registre a resposta do humano de que um rótulo de projeto pertence a outro. Um agente vê um nome de diretório, não um projeto — dois checkouts de um repositório parecem dois projetos, e um conjunto de seis repositórios parece seis. Somente a partir da resposta deles, nunca adivinhado por nomes semelhantes. As linhas mantêm seus rótulos; as leituras resolvem.

record_checkwrite

Registre o que uma verificação de projeto realmente encontrou — o nível gratuito do banco de dados pausa, o domínio expira em setembro, a URL de produção responde com um certificado válido. Somente o que foi observado: 'attention' precisa do achado nomeado, 'na' é uma resposta, e uma correção é um novo olhar, nunca uma edição.

record_accesswrite

Quem ainda pode acessar uma conta — uma pergunta diferente de quem a possui, e a que pega o contratante que saiu em março cujo login ainda funciona. Registrado somente a partir da resposta do humano: de uma sessão você pode provar que uma chave funciona, nunca ver quem mais possui uma. Plano Team.

list_accessread-only

Leia isso de volta, para uma conta ou em todo o ledger. Sem registros significa que nada foi registrado — nunca que ninguém mais tem acesso. Plano Team.

Divulgação completa

Exatamente o que o servidor diz ao seu agente

As instruções chegam com o handshake do MCP — esse mecanismo é o produto inteiro, então aqui está o texto completo, verbatim. Se você preferir que seu agente não ofereça escritas voluntariamente, não o conecte.

Toda sessão — as instruções de manutenção

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.

Primeira conexão a um ledger vazio — a variante de onboarding: ela oferece a varredura e nunca a executa sem seu consentimento

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.
…

A varredura em si — o procedimento "organize minha bagunça", servido inteiro como um prompt MCP (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.
…

Cada variante é orçada para caber inteira no contexto de um agente — clientes truncam handshakes longos, então as instruções permanecem curtas e o procedimento de varredura viaja separadamente, como um prompt MCP que seu agente busca por completo somente quando você diz “organize minha bagunça”. Nada é executado até você dizer.

O lembrete no momento da escrita (hook opcional)

Se você instalar o hook opcional do Claude Code, no momento em que uma sessão executa uma CLI de provedor (vercel, supabase, stripe, …) ele pergunta ao MESS se o ledger já conhece aquele provedor para o repositório atual. A correspondência acontece na sua máquina — apenas o nome do provedor correspondido e o nome da pasta do repositório são enviados, nunca o comando em si. Se o ledger já tiver essa conta para aquele projeto, a resposta é silêncio; repetições são silenciadas por uma hora. Caso contrário, seu agente ouve uma linha como esta:

Exemplo — exatamente o que o agente ouve, composto pelo mesmo código que o serve

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.

O hook em si — o que roda na sua máquina, verbatim

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "m=$(head -c 20000 | grep -oiE '\\b(vercel|supabase|stripe|wrangler|flyctl|netlify|railway|neonctl|turso|upstash|doctl|heroku|resend|pscale|planetscale)\\b' | head -1); [ -n \"$m\" ] && curl -sfG --max-time 3 https://mess.fyi/api/v1/write-nudge --data-urlencode \"provider=$m\" --data-urlencode \"project=${PWD##*/}\" -H \"Authorization: Bearer mess_sk_YOUR_KEY\" || true"
          }
        ]
      }
    ]
  }
}

O que ele nunca guarda

O mapa, não o cofre

MESS armazena qual conta existe, qual e-mail a possui e onde suas credenciais estão — nunca as credenciais em si. Não há campo para um valor secreto, de propósito. Uma linha do ledger é metadados que você poderia ler em voz alta em uma reunião.

Escritas são idempotentes, limitadas por taxa por chave e escopadas ao seu workspace. Chaves são armazenadas com hash, revogáveis a qualquer momento, e o ledger inteiro exporta para markdown determinístico — sem lock-in.