Standards

npx add-mcp 'https://api.standards.new/v1/mcp'

Conecte o Claude Code, Codex ou Cursor ao seu workspace e deixe-os ler e escrever registros por meio das ferramentas que sua chave já permite.

---

Standards é um servidor Model Context Protocol. Aponte um cliente MCP para https://api.standards.new/v1/mcp, faça login ou cole uma chave de API, e o cliente recebe até 24 ferramentas, limitadas ao que sua chave pode fazer. Os mesmos papéis que moldam a API REST moldam a lista de ferramentas.

Standards também é um cliente MCP: os agentes do seu próprio workspace podem chamar servidores de terceiros. Essa direção é abordada em Servidores de saída. Configurar uma direção não tem efeito sobre a outra.

Conecte um cliente

Duas formas de entrada. O OAuth faz login por meio do Standards e vincula o cliente a um workspace. Uma chave de API pula o login e carrega os papéis da chave. O Cursor aceita apenas chave.

Com OAuth, adicione o servidor e faça login no primeiro uso:

claude mcp add --transport http standards https://api.standards.new/v1/mcp

Com uma chave de API, crie uma e passe-a como cabeçalho:

standards keys create --name "claude-code" --yes

claude mcp add --transport http standards \
  https://api.standards.new/v1/mcp \
  --header "Authorization: Bearer stndrds_your_api_key"

Com OAuth:

codex mcp add standards --url https://api.standards.new/v1/mcp
codex mcp login standards

Com uma chave de API, o Codex lê o token de uma variável de ambiente:

export STANDARDS_API_KEY="stndrds_your_api_key"

# ~/.codex/config.toml
[mcp_servers.standards]
url = "https://api.standards.new/v1/mcp"
bearer_token_env_var = "STANDARDS_API_KEY"

O Cursor conecta com uma chave de API em ~/.cursor/mcp.json:

{
  "mcpServers": {
    "standards": {
      "url": "https://api.standards.new/v1/mcp",
      "headers": { "Authorization": "Bearer stndrds_your_api_key" }
    }
  }
}

O caminho OAuth é descrito em OAuth: escopos, consentimento, tempos de vida do token e as regras que um cliente deve cumprir. O caminho da chave é descrito em Workspaces e chaves de API.

O que o cliente recebe

O servidor não tem prompt de sistema próprio, então ele apresenta o workspace no campo instructions do handshake. O texto lista cada objeto que a chave pode ler, uma linha por objeto com nome, rótulo e descrição, depois quatro regras de uso fixas e, em seguida, onde está a documentação completa:

You are connected to a Standards workspace through its MCP tool surface.

Readable objects:
- contacts (Contact): People you work with.
- invoices (Invoice)

Usage rules:
- Object names are kebab-case and usually plural (e.g. "contacts", "invoices").
- Call get_schema for an object's attributes before writing to it.
- Deletes are reversible but must be confirmed with the user before you call a delete tool.
- Prefer get_record over search_records when the record id is already known.
- get_file_url returns a short-lived download URL for one file of a document (file ids come from read_document).
- Memory: call get_memory with no argument to read your profile and the workspace profile before acting; use propose_memory to suggest something worth remembering.

Reference:
- Full documentation, one file for agents: https://docs.standards.new/llms-full.txt
- Documentation index: https://docs.standards.new/llms.txt

Os dois links de Referência são os mesmos em todas as instâncias: uma instância dedicada move sua URL base de API, não a documentação. https://docs.standards.new/llms-full.txt é toda esta documentação como um único arquivo de texto simples, e https://docs.standards.new/llms.txt é seu índice.

A última regra de uso está presente sempre que as ferramentas de memória estão na lista do cliente, ou seja, para qualquer chave que leia. O handshake não carrega memória em si: o cliente lê seus perfis sob demanda e sugere o que lembrar em vez de escrever. Veja Memória.

Uma chave que não lê nada recebe (no objects are readable with this key) no lugar do índice. O detalhe de atributos não está no payload; o cliente chama get_schema para obtê-lo. A lista completa de ferramentas e as duas formas de recusa estão em Ferramentas.

Memória

Um cliente MCP compartilha a memória do workspace com seus agentes: as mesmas páginas, lidas sob a mesma visibilidade. Três ferramentas a servem, visíveis para qualquer chave que leia:

• get_memory sem argumento retorna os perfis do chamador como estão agora: o perfil do workspace e o perfil da pessoa por trás da chave. Com name, retorna essa página.
• search_memories pesquisa as páginas: perfis, páginas de registro e temas.
• propose_memory recebe learning (uma frase) e um evidenceExcerpt opcional (as palavras do usuário). Não escreve nada: a passagem de memória em segundo plano do workspace decide se e onde o aprendizado pertence, alguns minutos depois. No máximo 30 propostas por pessoa por hora.

get_record também retorna a página de memória do registro, como memory, quando há uma que você possa ver. Registros de memória em si não podem ser gravados via MCP: create_record, update_record e delete_record em memory respondem SCHEMA_SYSTEM_ENTITY_IMMUTABLE. Como as páginas são escritas e quem pode moldar uma compartilhada é descrito em Habilidades e memórias.

O endpoint

Propriedade	Valor
URL	POST https://api.standards.new/v1/mcp
Transporte	HTTP Streamable. GET e DELETE respondem 405: não há stream independente nem sessão a encerrar.
Revisão do protocolo	2026-07-28. Um cliente em uma revisão da era 2025 ainda abre com initialize e recebe as mesmas ferramentas.
Estado	Nenhum. Cada requisição constrói um servidor novo e o descarta. Sem Mcp-Session-Id, sem afinidade de réplica.
Escopo de cache	private. A lista de ferramentas é resolvida por chave, então nunca é anunciada como publicamente cacheável.

Autenticação

Envie uma de duas credenciais no cabeçalho Authorization:

• uma chave de API: Authorization: Bearer stndrds_…;
• um token de acesso OAuth emitido para este workspace, veja OAuth.

Sessões de login no navegador e tokens de ID não são credenciais MCP. O que dá errado:

Status	Quando
401 com WWW-Authenticate: Bearer resource_metadata="…"	Sem credencial bearer. O desafio aponta para os metadados de recurso protegido que um cliente OAuth precisa para iniciar.
401 com error="invalid_token"	O token OAuth está expirado, revogado, vinculado a outro recurso ou não corresponde mais a uma concessão ativa.
403 com error="insufficient_scope"	O token não carrega nenhum de mcp:read, mcp:write, mcp:delete, mcp:people:read.
403	A requisição nomeia um workspace em seu cabeçalho de tenant que não é aquele ao qual o token está vinculado.
503	O backend de autorização não conseguiu validar o token. Tente novamente mais tarde.

Próximos passos

• OAuth — escopos, consentimento, tempos de vida do token e regras de admissão de clientes.
• Ferramentas — as ferramentas que um cliente pode ver, seus limites e como uma recusa se parece.
• Servidores de saída — deixe seus agentes chamarem servidores MCP de terceiros.
• Fluxo de trabalho do agente — uma sessão completa de get_schema a update_record.

[

Servidores MCP

Conecte, renomeie, atualize, confie e desconecte os servidores MCP de saída que podem ser concedidos aos agentes do seu workspace, a partir de um terminal.

](https://docs.standards.new/docs/cli/mcp-servers)[

OAuth

Registre um cliente MCP em um workspace com OAuth, entenda os quatro escopos que ele pode solicitar e saiba quanto tempo cada token vive.

](https://docs.standards.new/docs/mcp/oauth)