Skip to content

For AI agents

Put your agents to work on real data.

Coding agents, chat assistants and the agents in your product read and write the same structured data as your team. Each works with a key scoped to its job, every change it makes carries its name and its reason, and any of them can be reverted.

Start building freeRead the agents guide

Works with the agents you use. Any shell, any MCP client.

If an agent can run a command or send an Authorization header, it can work on your data: with a key of its own and the same guardrails as every other client.

  • CLIMCP

    Claude Code

    One command adds the MCP server, and it runs the CLI in your terminal.

  • CLIMCP

    Codex

    Follows your AGENTS.md and calls the CLI or the MCP server.

  • CLIMCP

    Gemini CLI

    Runs the CLI as it works, or connects to the MCP server with your key.

  • CLIMCP

    Cursor

    Add the server and key to its mcp.json, or let its agent run the CLI.

  • CLIMCP

    GitHub Copilot

    In VS Code's agent mode, add the server to mcp.json with your key.

  • CLIMCP

    Windsurf

    Its agent connects to the MCP server, or runs the CLI in the terminal.

  • MCP

    n8n

    Workflows' AI agents use the server through the MCP Client tool.

  • APISDKs

    Your own agents

    The REST API or the TypeScript, Python and Ruby SDKs, with webhooks to react.

Chat apps you sign in to, such as Claude.ai and ChatGPT, come next: connecting them with your account instead of a key is on the way.

Every kind of agent. One API underneath.

Whether it lives in a terminal, a chat app or your own product, an agent reaches the same records through the same API, with the same permissions, validation and history as everyone else.

Coding agents

Claude Code, Codex, Cursor and the like use the CLI: one JSON document per command, stable exit codes and dry runs. /llms.txt maps the API, and a few lines in AGENTS.md teach them your conventions.
Coding agents guide

Chat apps and agent frameworks

Agents without a shell connect to the MCP server at mcp.nohead.io with a key: tools for collections, search, records, drafts, publishing, schedules, history and assets, limited to what the key may do.
MCP guide

Agents in your product

Your own agents use the REST API or the TypeScript, Python and Ruby SDKs, and webhooks tell them when something changes, so they react instead of polling.
For developers

Real work, not demos. Done in the open.

Agents do their best work on data with a shape: typed fields, relations and rules they can read before they write. Here is what that looks like.

  • Build the site and its content model. A coding agent writes the schema file, you review the diff in a pull request, CI applies it, and the agent seeds the first records.

  • Keep content in sync. Agents and sync jobs create and update records from your other systems, upserting on a unique field so a rerun never duplicates anything.

  • Enrich and tidy. Summaries, tags, alt text and fixes across a whole collection, each change with a note saying why, so it can be reviewed and reverted.

  • Answer from your knowledge base. Support and docs assistants search with a published-only key, so they quote the current, live version, never a draft.

  • Leave the last word to people. Records an agent creates stay unpublished until someone publishes them, so its work can be reviewed in the editor before it goes live.

  • Clean up after a bad run. Every change is a revision under the agent's key: diff it, revert it, or restore what it deleted within 30 days.

Guardrails, not good intentions. Built into every request.

An agent is as safe as what it's allowed to do and how easily you can undo what it did. Both are part of the platform, not a prompt.

A key of its own

Each agent gets a key for one project, with only the scopes its job needs and never more than the role of the person who made it. Keys can expire, and revoking one stops the agent at once.

No silent overwrites

A change carries the revision the agent read. If someone saved in the meantime, it is refused, and the agent reads again before retrying.

Undo built in

Revert any change in one click or call. Deleted records, fields, collections and assets come back for 30 days, unless a key that may write assets purges a deleted file for good.

Every change explained

MCP tools require a note on every change to your content, and the CLI takes one with --note. History shows it next to the key's name and the client it came through.

  • Only what is live, if you like. A published-only key reads live records and nothing else: no drafts, no history, no schema changes.

  • Tools follow the key. Over MCP, an agent sees only the tools its key's scopes allow. Changing the schema isn't a tool at all: it goes through a reviewed file.

  • No double writes. Every write takes an idempotency key, so a retried call returns the first result instead of applying the change twice.

  • A preview first. Reverts, schema changes and field migrations dry-run, showing exactly what would change before anything does.

An MCP server. 28 tools, one key.

Point any MCP client that can send a header at mcp.nohead.io with the agent's key. Each tool call is one API request, so scopes, rate limits and history apply exactly as they do everywhere else.

Read the MCP guide
# Give the agent a key of its own, then add the server
$ claude mcp add --transport http nohead https://mcp.nohead.io/mcp \
    --header "Authorization: Bearer $NOHEAD_API_KEY"

Read

  • list_collections
  • get_schema
  • list_records
  • get_record
  • list_drafts
  • get_draft
  • get_schedule
  • search
  • search_collection

Write

  • create_record
  • update_record
  • create_draft
  • update_draft
  • discard_draft
  • publish_record
  • unpublish_record
  • schedule_record
  • unschedule_record

History

  • list_revisions
  • diff_record
  • revert_record
  • restore_record

Assets

  • list_assets
  • get_asset
  • update_asset
  • delete_asset
  • start_upload
  • complete_upload

Every change to a record takes a note and the revision the agent read, every write an optional idempotency key; revert_record takes a dry run. Signing in to chat apps as yourself, instead of with a key, comes later.

Coding agents feel at home. Scriptable on purpose.

The CLI was designed for scripts and agents first: output they can parse, errors they can act on, and conventions you can write down once in AGENTS.md.

## Nohead

- Schema lives in `nohead.schema.yaml`. Change it there, run
  `nohead schema diff`, and let CI run `nohead schema push --yes`.
  Never push field migrations (`--allow-migrations`) without showing the
  diff's migration preview to a person first.
- Use `--json` and check exit codes. Pass `--note "<why>"` on every write and
  `--if-revision <n>` when updating a record you read earlier.
- Deletions are soft and restorable; prefer `records bulk` over loops.
- API reference: `https://api.nohead.io/llms.txt`.
  • --json prints exactly one document; errors go to stderr in the API's envelope, and exit codes are stable.
  • --note says why, and --if-revision refuses to overwrite newer edits.
  • --dry-run for reverts; schema push never deletes, and migrations need an explicit flag.
  • /llms.txt is generated from the published contract on request, so it is never stale.

Questions, answered.

About connecting agents, what they can do, and keeping them in check.

Ask us directly

Give your agent a key.

Create a project, make a key with the scopes the job needs, and connect your agent. Everything it does is on the record from its first request.

Start building freeRead the docs