Standards

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

Connect Claude Code, Codex or Cursor to your workspace and let them read and write records through the tools your key already allows.

---

Standards is a Model Context Protocol server. Point an MCP client at https://api.standards.new/v1/mcp, sign in or paste an API key, and the client gets up to 24 tools, narrowed to what your key may do. The same roles that shape the REST API shape the tool list.

Standards is also an MCP client: your workspace's own agents can call third-party servers. That direction is covered in Outbound servers. Configuring one direction has no effect on the other.

Connect a client

Two ways in. OAuth signs you in through Standards and binds the client to one workspace. An API key skips the sign-in and carries the key's roles. Cursor takes a key only.

With OAuth, add the server and sign in on first use:

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

With an API key, create one and pass it as a header:

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"

With OAuth:

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

With an API key, Codex reads the token from an environment variable:

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 connects with an API key in ~/.cursor/mcp.json:

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

The OAuth path is described in OAuth: scopes, consent, token lifetimes and the rules a client must meet. The key path is described in Workspaces and API keys.

What the client receives

The server has no system prompt of its own, so it introduces the workspace in the instructions field of the handshake. The text lists every object the key can read, one line per object with its name, label and description, then four fixed usage rules, then where the full documentation lives:

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

The two Reference links are the same on every instance: a dedicated instance moves its API base URL, not the documentation. https://docs.standards.new/llms-full.txt is this whole documentation as one plain-text file, and https://docs.standards.new/llms.txt is its index.

The last usage rule is there whenever the memory tools are in the client's list, that is, for any key that reads. The handshake carries no memory itself: the client reads its profiles on demand, and suggests what to remember instead of writing it. See Memory.

A key that reads nothing gets (no objects are readable with this key) in place of the index. Attribute detail is not in the payload; the client calls get_schema for it. The full tool list and the two refusal shapes are on Tools.

Memory

An MCP client shares the workspace's memory with its agents: the same pages, read under the same visibility. Three tools serve it, visible to any key that reads:

• get_memory with no argument returns the profiles of the caller as they are now: the workspace profile and the profile of the person behind the key. With name, it returns that page.
• search_memories searches the pages: profiles, record pages and themes.
• propose_memory takes learning (one sentence) and an optional evidenceExcerpt (the user's words). It writes nothing: the workspace's background memory pass decides whether and where the learning belongs, a few minutes later. At most 30 proposals per person per hour.

get_record also returns the record's memory page, as memory, when there is one you can see. Memory records themselves cannot be written over MCP: create_record, update_record and delete_record on memory answer SCHEMA_SYSTEM_ENTITY_IMMUTABLE. How pages are written and who may shape a shared one is described in Skills and memories.

The endpoint

Property	Value
URL	POST https://api.standards.new/v1/mcp
Transport	Streamable HTTP. GET and DELETE answer 405: there is no standalone stream and no session to terminate.
Protocol revision	2026-07-28. A client on a 2025-era revision still opens with initialize and gets the same tools.
State	None. Every request builds a fresh server and drops it. No Mcp-Session-Id, no replica affinity.
Cache scope	private. The tool list is resolved per key, so it is never advertised as publicly cacheable.

Authentication

Send one of two credentials in the Authorization header:

• an API key: Authorization: Bearer stndrds_…;
• an OAuth access token issued to this workspace, see OAuth.

Browser login sessions and ID tokens are not MCP credentials. What goes wrong:

Status	When
401 with WWW-Authenticate: Bearer resource_metadata="…"	No bearer credential. The challenge points at the protected-resource metadata an OAuth client needs to start.
401 with error="invalid_token"	The OAuth token is expired, revoked, bound to another resource or no longer matches an active grant.
403 with error="insufficient_scope"	The token carries none of mcp:read, mcp:write, mcp:delete, mcp:people:read.
403	The request names a workspace in its tenant header that is not the one the token is bound to.
503	The authorization backend could not validate the token. Retry later.

Next steps

• OAuth — scopes, consent, token lifetimes and client admission rules.
• Tools — the tools a client can see, their limits, and how a refusal looks.
• Outbound servers — let your agents call third-party MCP servers.
• Agent workflow — a full session from get_schema to update_record.

[

MCP servers

Connect, rename, refresh, trust and disconnect the outbound MCP servers your workspace's agents can be granted, from a terminal.

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

OAuth

Sign an MCP client into one workspace with OAuth, understand the four scopes it can ask for, and know how long each token lives.

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