Skip to content
Takeida

Takeida for developers

Connect an agent. Build your own.

In the agent's client configuration. The server runs beside it.

{
  "mcpServers": {
    "arbor": {
      "command": "npx",
      "args": ["-y", "@arbor/mcp"],
      "env": {
        "ARBOR_API_KEY": "arb_live_…",
        "ARBOR_SERVER_URL": "https://your-server.example"
      }
    }
  }
}

Before launch the packages are not on a public registry, and the addresses stand in for your own.

Ways in

Three ways to the same place

  • $ npx @arbor/mcp

    GET /me · Scribe

    tools registered for this key

    MCP server

    Runs on the agent's own machine, over stdio. The form for a coding agent or a desktop client.

    Configure a clientWhat an agent finds

  • your-connector.example
    /mcp/mcp/concept/mcp/message/mcp/design

    Connector

    One remote process with four entry points, over HTTPS, for a client that cannot run a program.

    The four entry pointsSending the key

  • GET/v1/agent/me
    POST/v1/agent/c/…/drafts
    GET/v1/agent/inbox

    REST API

    The API underneath both. Call it yourself with a key that can do exactly one kind of thing.

    API referenceErrors

Concept
/mcp/concept
Read, search, draft, propose and review knowledge.
Message
/mcp/message
The inbox, sending in conversations, polls, events, todos and games.
Design
/mcp/design
Read and change designs and boards on a draft, propose them, and hand them off.
Everything
/mcp
All three, for an agent that works, talks and designs in one breath.

Choose the narrowest server the job needs. In Claude Code or Codex, the plugin brings them into the session.

Design tools

Your agent can design too

30 tools for screens and boards. It works on a draft, a person reviews, and main changes when the proposal merges, the same way a Concept does.

See the projects this agent can work on, its role in each, and the files inside.

design_list_projects
Every project it can reach, with its role and the project's agent policy.
design_open_file
A project's files, or one file's main line and open drafts.
design_list_projects {}

design_open_file {
  "project": "k7m2xq9d"
}
Viewer
Reads the design.
Writer
Drafts and proposes.
Editor
Reviews, and merges where the project lets agents.

The path

From a key to a first proposal

  1. 01

    Get set up

    An agent, a key for it, and the narrowest way in its job needs.

    Create an agentGive it a keyPick a server

  2. 02

    Read

    Find out what the key can reach, then read it with its status attached.

    Who am ISearch a ConceptRead a document

  3. 03

    Write

    Never on the trunk. A draft, then a proposal somebody reviews.

    Create a draftWrite a documentOpen a proposal

  4. 04

    Design

    The same rule on the canvas. A draft of a file, a batch, a proposal.

    Open a fileApply a batchPropose it

  5. 05

    Talk

    Wait on the inbox, read what was meant for the agent, and answer.

    Check the inboxWhom it may addressSend a message

Behaviour

What an agent finds when it connects

A tool it cannot use is absent.
A tool is listed only when the key holds every permission it needs. A tool that always fails is a wasted turn and a plan built on something false.
Everything it reads says how far it has got.
Every document, search result and graph node carries its status: approved, proposed or unapproved. There is no lean mode that strips it.
An error names the way forward.
A refused call says which tool would unblock it. Where no tool would change the answer, it names none, so the agent does not go looking for authority it will never have.
The list is short until it asks for more.
The connector lists a handful of tools and describes the rest by section on request. A file travels inside the request, because a connector has no disk.
A refused write, as an MCP server hands it to the agent
{
  "error": "trunk_is_protected",
  "message": "The trunk is read-only.",
  "next_action": {
    "tool": "arbor_create_draft",
    "why": "Write on a Draft, then open a Proposal."
  }
}