Standards

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

Conecta Claude Code, Codex o Cursor a tu espacio de trabajo y deja que lean y escriban registros a través de las herramientas que tu clave ya permite.

---

Standards es un servidor del Model Context Protocol. Apunta un cliente MCP a https://api.standards.new/v1/mcp, inicia sesión o pega una clave de API, y el cliente obtiene hasta 24 herramientas, limitadas a lo que tu clave puede hacer. Los mismos roles que dan forma a la API REST dan forma a la lista de herramientas.

Standards también es un cliente MCP: los agentes de tu propio espacio de trabajo pueden llamar a servidores de terceros. Esa dirección se cubre en Servidores salientes. Configurar una dirección no tiene efecto sobre la otra.

Conectar un cliente

Dos formas de entrar. OAuth te inicia sesión a través de Standards y vincula el cliente a un espacio de trabajo. Una clave de API omite el inicio de sesión y lleva los roles de la clave. Cursor solo acepta una clave.

Con OAuth, añade el servidor e inicia sesión en el primer uso:

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

Con una clave de API, crea una y pásala como encabezado:

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"

Con OAuth:

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

Con una clave de API, Codex lee el token de una variable de entorno:

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"

Cursor se conecta con una clave de API en ~/.cursor/mcp.json:

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

La ruta de OAuth se describe en OAuth: alcances, consentimiento, duración de los tokens y las reglas que un cliente debe cumplir. La ruta de la clave se describe en Espacios de trabajo y claves de API.

Lo que recibe el cliente

El servidor no tiene un prompt de sistema propio, por lo que presenta el espacio de trabajo en el campo instructions del handshake. El texto enumera cada objeto que la clave puede leer, una línea por objeto con su nombre, etiqueta y descripción, luego cuatro reglas de uso fijas, y luego dónde vive la documentación 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

Los dos enlaces de Referencia son los mismos en cada instancia: una instancia dedicada mueve su URL base de API, no la documentación. https://docs.standards.new/llms-full.txt es toda esta documentación como un solo archivo de texto plano, y https://docs.standards.new/llms.txt es su índice.

La última regla de uso está presente siempre que las herramientas de memoria estén en la lista del cliente, es decir, para cualquier clave que lea. El handshake no lleva memoria en sí: el cliente lee sus perfiles bajo demanda y sugiere qué recordar en lugar de escribirlo. Ver Memoria.

Una clave que no lee nada obtiene (no objects are readable with this key) en lugar del índice. El detalle de los atributos no está en el payload; el cliente llama a get_schema para obtenerlo. La lista completa de herramientas y las dos formas de rechazo están en Herramientas.

Memoria

Un cliente MCP comparte la memoria del espacio de trabajo con sus agentes: las mismas páginas, leídas bajo la misma visibilidad. Tres herramientas la sirven, visibles para cualquier clave que lea:

• get_memory sin argumento devuelve los perfiles del llamante tal como están ahora: el perfil del espacio de trabajo y el perfil de la persona detrás de la clave. Con name, devuelve esa página.
• search_memories busca en las páginas: perfiles, páginas de registros y temas.
• propose_memory toma learning (una oración) y un evidenceExcerpt opcional (las palabras del usuario). No escribe nada: el pase de memoria en segundo plano del espacio de trabajo decide si el aprendizaje pertenece y dónde, unos minutos después. Como máximo 30 propuestas por persona por hora.

get_record también devuelve la página de memoria del registro, como memory, cuando hay una que puedas ver. Los registros de memoria en sí no se pueden escribir a través de MCP: create_record, update_record y delete_record en memory responden a SCHEMA_SYSTEM_ENTITY_IMMUTABLE. Cómo se escriben las páginas y quién puede dar forma a una compartida se describe en Habilidades y memorias.

El endpoint

Propiedad	Valor
URL	POST https://api.standards.new/v1/mcp
Transporte	HTTP transmisible. GET y DELETE responden a 405: no hay stream independiente ni sesión que terminar.
Revisión del protocolo	2026-07-28. Un cliente en una revisión de la era 2025 aún abre con initialize y obtiene las mismas herramientas.
Estado	Ninguno. Cada solicitud construye un servidor nuevo y lo descarta. Sin Mcp-Session-Id, sin afinidad de réplica.
Alcance de caché	private. La lista de herramientas se resuelve por clave, por lo que nunca se anuncia como públicamente cacheable.

Autenticación

Envía una de dos credenciales en el encabezado Authorization:

• una clave de API: Authorization: Bearer stndrds_…;
• un token de acceso OAuth emitido para este espacio de trabajo, ver OAuth.

Las sesiones de inicio de sesión del navegador y los tokens de ID no son credenciales MCP. Lo que sale mal:

Estado	Cuándo
401 con WWW-Authenticate: Bearer resource_metadata="…"	Sin credencial de portador. El desafío apunta a los metadatos del recurso protegido que un cliente OAuth necesita para comenzar.
401 con error="invalid_token"	El token OAuth está expirado, revocado, vinculado a otro recurso o ya no coincide con una concesión activa.
403 con error="insufficient_scope"	El token no lleva ninguno de mcp:read, mcp:write, mcp:delete, mcp:people:read.
403	La solicitud nombra un espacio de trabajo en su encabezado de tenant que no es aquel al que está vinculado el token.
503	El backend de autorización no pudo validar el token. Reintenta más tarde.

Próximos pasos

• OAuth — alcances, consentimiento, duración de los tokens y reglas de admisión de clientes.
• Herramientas — las herramientas que un cliente puede ver, sus límites y cómo se ve un rechazo.
• Servidores salientes — permite que tus agentes llamen a servidores MCP de terceros.
• Flujo de trabajo del agente — una sesión completa desde get_schema hasta update_record.

[

Servidores MCP

Conecta, renombra, actualiza, confía y desconecta los servidores MCP salientes que se pueden otorgar a los agentes de tu espacio de trabajo, desde una terminal.

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

OAuth

Firma un cliente MCP en un espacio de trabajo con OAuth, comprende los cuatro alcances que puede solicitar y sabe cuánto dura cada token.

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