How to use MCP

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 eight tools (search, query, read, write, edit_content, organize, delete and propose_memory), 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 clientCopy Anchor Link

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.

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

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"

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 receivesCopy Anchor Link

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 fixed usage rules (the file and memory rules only when read serves those kinds, the upload rule only when organize does), 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").
- Read schema:<object> for an object's attributes before writing to it.
- Deletes are reversible but must be confirmed with the user before you call delete.
- When you hold a reference (record:<id>), read it; search finds one by text, query lists the records of a known object.
- read file:<id> returns a stored file's metadata and a download URL valid 5 minutes (file ids come from reading a document).
- organize attach (target record:<id>) files a document from your side: inline as file "data:<type>;name=<file name>;base64,<bytes>" up to 512 KiB; larger, announce it with upload {fileName, mimeType, size}, PUT the bytes to the URL it returns, then attach with the fileId "upload:<id>".
- Memory: read memory:* for your profile and the workspace profile before acting; use propose_memory, with the record it is about, 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 read serves memory, 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 reads schema:<object> for it. The full tool list and the two refusal shapes are on Tools.

MemoryCopy Anchor Link

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

• read with memory:* returns the profiles of the caller as they are now: the workspace profile and the profile of the person behind the key. memory:<name> returns that page.
• search with kinds: ["memory"] searches the pages: profiles and record pages.
• propose_memory takes learning (one sentence), an optional evidenceExcerpt (the user's words) and an optional record (the record:<id> it is about, which routes the learning to that record's page). 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.

read of a record also returns the record's memory page, as memory, when there is one you can see, for up to 5 records per call; a larger batch asks for it with include: ["memory"]. Memory records themselves cannot be written over MCP: write and delete 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 endpointCopy Anchor Link

AuthenticationCopy Anchor Link

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:

Next stepsCopy Anchor Link

• OAuth — scopes, consent, token lifetimes and client admission rules.
• Connected apps — see the apps connected over OAuth, change their access level, revoke them.
• 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 reading a schema to updating a record.
• Book a demo