onecell

Sign in

Help/Documentation

Automations: let your tools write to onecell

GitHub Actions, n8n, Zapier, cron jobs: anything that can call MCP or send an HTTP request can keep its work in onecell, as memory your team can find.

Automations do a lot of work nobody sees: a release goes out, a nightly job reconciles payments, a workflow triages tickets. The result ends up in a log that scrolls away. Point the automation at onecell instead and its work becomes a document or a fact your team, and every agent, can search, cite and build on.

Three ways to connect

WayUse it whenExamples
A plain HTTP callThe automation knows exactly what to writecurl in GitHub Actions, n8n's HTTP Request node, Zapier webhooks
An agent with onecell's toolsA model should decide what to write, or read firstn8n's AI Agent with an MCP Client tool, any MCP client
A scheduled agent runA recurring brief or sweepClaude Code with -p from cron or CI

Give each automation its own key

  1. Create a Drafts only key

    On Settings → Agents, under Keys, one per automation, named after it (“GitHub releases”). It can read, create and edit drafts, and remember facts. It cannot publish, share, delete or invite, so a misbehaving workflow can't publish anything.

  2. Store it as a secret

    In GitHub, a repository secret; in n8n, a credential. Never in the workflow file.

  3. Pick where it writes

    Name a cell for the work, such as engineering or operations, or inbox for a private log only you see.

  4. Tag what it writes

    Add a tag like src:github so you can list everything the automation wrote, and tell it apart from people's work.

Calling onecell over HTTP

onecell's tools answer at https://onecell.io/api/mcp. One POST runs one tool; no session or client library is needed. The tool names and arguments are the same ones agents use (see the Tool reference).

curl -sS https://onecell.io/api/mcp \
  -H "Authorization: Bearer $ONECELL_API_KEY" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{
    "jsonrpc": "2.0", "id": 1, "method": "tools/call",
    "params": {
      "name": "create_document",
      "arguments": {
        "cell": "engineering",
        "slug": "deploy-2026-08-14",
        "title": "Deploy on 14 August: partial payments",
        "tags": ["deploy", "src:ci"],
        "blocks": [{ "type": "text", "html": "<p>Shipped #412 and #415.</p>" }],
        "dry_run": false
      }
    }
  }'
  • Pass dry_run: false. Every tool that changes something is a dry run by default.
  • The answer is JSON, with the tool's result as a string in result.content[0].text: applied, a reason, and the document's id.
  • Slugs make reruns safe. A slug is unique, so a retried job gets slug_taken instead of a duplicate. Build it from something stable, like the release tag.
  • One sentence worth keeping? Call remember with a fact and an entity instead of writing a document.

GitHub Actions: save every release

Add ONECELL_API_KEY as a repository secret, then this workflow. It saves each published release as a draft in your engineering cell, and a rerun does nothing.

name: Release to onecell
on:
  release:
    types: [published]
jobs:
  onecell:
    runs-on: ubuntu-latest
    steps:
      - name: Save the release in onecell
        env:
          ONECELL_API_KEY: ${{ secrets.ONECELL_API_KEY }}
          TAG: ${{ github.event.release.tag_name }}
          NAME: ${{ github.event.release.name }}
          BODY: ${{ github.event.release.body }}
          URL: ${{ github.event.release.html_url }}
        run: |
          args=$(jq -n --arg tag "$TAG" --arg name "$NAME" --arg body "$BODY" --arg url "$URL" '{
            cell: "engineering",
            slug: ("release-" + ($tag | ascii_downcase | gsub("[^a-z0-9]+"; "-"))),
            title: ("Release " + $tag + ": " + $name),
            summary: ("Release notes for " + $tag + ", saved by GitHub Actions when the release was published."),
            tags: ["release", "src:github"],
            blocks: [
              {type: "text", html: ("<p>Published on GitHub: <a href=\"" + $url + "\">" + $tag + "</a>.</p>")},
              {type: "code", lang: "markdown", code: $body}
            ],
            dry_run: false
          }')
          curl -sS https://onecell.io/api/mcp \
            -H "Authorization: Bearer $ONECELL_API_KEY" \
            -H 'Content-Type: application/json' \
            -H 'Accept: application/json, text/event-stream' \
            -d "$(jq -n --argjson args "$args" '{jsonrpc:"2.0", id:1, method:"tools/call", params:{name:"create_document", arguments:$args}}')" \
            | jq -e '.result.content[0].text | fromjson | .applied or .reason == "slug_taken"'

n8n

To write something specific, add an HTTP Request node: method POST, URL https://onecell.io/api/mcp, a header credential Authorization: Bearer ic_…, the two headers above, and the same JSON body with your workflow's values in arguments.

To let a model decide, add an AI Agent node and give it an MCP Client tool with the same URL and the Bearer header, using the HTTP Streamable transport. The agent can then search onecell before it writes, and file what it finds where it belongs.

A scheduled agent

Claude Code runs without a person when you pass -p. Give it onecell in a config file, with the key read from the environment:

{
  "mcpServers": {
    "onecell": {
      "type": "http",
      "url": "https://onecell.io/api/mcp",
      "headers": { "Authorization": "Bearer ${ONECELL_API_KEY}" }
    }
  }
}
# Every Monday at 7:00, from cron or a scheduled CI job:
claude -p "$(cat monday-brief-prompt.txt)" \
  --mcp-config onecell-mcp.json --strict-mcp-config \
  --allowedTools 'mcp__onecell__*' < /dev/null

Use any recipe's prompt as the prompt file. The Monday brief is a good first one.

Good habits

  • One key per automation, so you can see what each wrote and revoke one without breaking the rest.
  • One document per event (a release, a deploy, an incident), or one running document the automation updates: read it with get_document, then update_document with expected_version.
  • Keep secrets, tokens and customer data out of what an automation writes. onecell is memory, not a vault.
  • Remember only what lasts. A deploy is a document; “the worker needs REMINDERS_QUEUE on” is a fact.

Ready-made workflows are in the recipes, under Automations.