MCP

Connect Claude Code, Codex, or Cursor to your workspace over the Model Context Protocol.

standards exposes a Model Context Protocol server at POST /mcp, so an AI coding client can read and write your workspace's records, documents, and schema through the same permissions your API keys already have.

This endpoint is for developer clients — tools you run yourself, that connect with an API key. Claude Code, Codex, and Cursor are the three configurations below. Clients that require OAuth (Claude Desktop, ChatGPT) are out of scope. If you're after an AI assistant for business users instead of developers, that's what the agents built into the standards application are for — they run the same underlying tools with no client setup at all.

The endpoint

Transport: Streamable HTTP, one route: POST /mcp. GET and DELETE both answer 405 — the server is stateless and keeps no session to resume or terminate.
Statelessness: every request builds a fresh MCP server and tears it down afterwards. There's no session affinity, so the endpoint works the same behind any number of API replicas.
Authentication: API key only. Send your key as Authorization: Bearer stndrds_your_api_key, exactly like every other request. A request without a validated key gets 401 — including a request carrying a valid browser session token. Sessions authenticate people in the web app; this endpoint only accepts keys.

Connect a client

You need an API key first — create one from the API keys area of your workspace, or with standards keys create --name "claude-code" --yes (see Creating keys). Then point your client at https://api.standards.new/v1/mcp with that key.

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

Codex reads its token from an environment variable rather than inline, so it needs two pieces: the export, and a config entry that points to it.

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"

Add this to ~/.cursor/mcp.json:

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

The same three configurations are available from Connect your AI in the workspace settings, with your workspace's URL already filled in — you only need to paste in the key.

On connect, the server's initialize response tells the model which objects it can read (name, label, description) plus a short set of usage rules — it has no system prompt of its own, so this is what orients it.

Tools

A client only ever sees the tools its key's roles allow — a tool your key cannot use is absent from the list, not merely refused. Visibility follows the same read/create/update/delete actions as the rest of the API: any object granting read unlocks the read tools, create or update unlocks the write tools, and delete unlocks delete_record. Every call is still checked against the specific object being touched, so a key scoped to one object won't be able to use a visible tool against another.

One tool answers to a system permission instead: list_workspace_users returns every workspace member's id, name and email, so it needs read on people — the same permission GET /users requires. Object access alone never unlocks it.

There is no bulk_delete_records tool — deletes are deliberately single-record only over MCP.

Read

Tool	Does
`get_schema`	Read the attributes, types, and required fields of one or more objects.
`search_records`	Full-text search or plain listing within one object, with filters, sorts, and pagination.
`get_record`	Fetch a single record by ID.
`global_search`	Full-text search across every readable object at once.
`bulk_search`	Up to 20 parallel searches across different objects in one call.
`list_record_drive`	Inspect a record's document drive as a folder/file tree.
`read_document`	Read a document's metadata, files, and OCR content. Files that were never OCR'd are extracted on demand by the call itself, so the first read of a fresh document can take a few seconds. `contentStatus` reports whether that text is final (`ready`), still being extracted (`ocr_processing`), or will never arrive (`ocr_unavailable`) — so empty content is never mistaken for an empty document.
`list_workspace_users`	List or search workspace users, e.g. to resolve an assignee. Requires `read` on `people`.

Write

Tool	Does
`create_record`	Create a single record.
`update_record`	Update fields on an existing record.
`bulk_create_records`	Create up to 100 records in one call.
`bulk_update_records`	Apply the same field values to up to 100 records.
`create_folder`	Create a folder on a record's document drive.
`attach_file`	Attach an already-uploaded file to a record's drive or a document attribute.
`remove_file`	Remove one file from a document pack without deleting the document.
`update_document`	Rename a document and/or move it to another folder.
`delete_document`	Delete a document and its whole file pack.
`initialize_record_preset`	Instantiate a declared document folder preset onto a record's drive.

Delete

Tool	Does
`delete_record`	Delete a record. The record is soft-deleted and can be restored.

Next steps

Authentication — how API keys and their roles work.
Permissions — the full role and action model that shapes the tool list.
Records and Files and documents — the REST surface the same tools call into.