Agent harness

Pi Agent

Pi Agent reaches Korely's memory through the community pi-mcp-adapter, which speaks Streamable HTTP and lets you set a static Authorization header, so you point it straight at the remote server, no bridge.

Pi Agent ships with no native MCP support of its own. MCP, both remote servers and local stdio ones, is provided entirely by a third-party community extension, pi-mcp-adapter (MIT-licensed, authored by nicobailon, not an official Pi / pi.dev product). The good news: that adapter supports a static Bearer header over Streamable HTTP, so you can connect to Korely's remote MCP endpoint directly, the intelligence (entity and typed-fact extraction, contradiction resolution, bi-temporal validity) runs server-side, and Pi just calls the tools.

Prerequisites

• A Korely API key (kor_live_...). The hobby tier is free.
• Pi Agent installed.
• The community adapter (one time):

  pi install npm:pi-mcp-adapter

Connect Korely (recommended, native remote header)

The adapter reads its MCP config from one of these files (precedence high to low): ~/.config/mcp/mcp.json (user-global), ~/.pi/agent/mcp.json (Pi global override), .mcp.json (project-local), .pi/mcp.json (Pi project override). Use ~/.config/mcp/mcp.json or ~/.pi/agent/mcp.json for a machine-wide connection, or .mcp.json in a repo for project scope.

Korely's agent memory is a remote MCP server at https://api.korely.ai/agent/mcp (Streamable HTTP), authenticated with your key in a static header, no browser login. Point the adapter straight at it:

{
  "mcpServers": {
    "korely": {
      "url": "https://api.korely.ai/agent/mcp",
      "headers": {
        "Authorization": "Bearer ${KORELY_API_KEY}"
      },
      "auth": "bearer",
      "bearerToken": "${KORELY_API_KEY}"
    }
  }
}

Set KORELY_API_KEY=kor_live_... in your environment, the adapter interpolates ${KORELY_API_KEY}. You can also inline the literal key, e.g. "Authorization": "Bearer kor_live_...". The "headers" object alone is enough for Korely's static-key auth; the "auth" / "bearerToken" fields are the adapter's explicit Bearer form and are optional.

Fallback, mcp-remote stdio bridge

Only if the native remote path misbehaves, you can route through the standard mcp-remote proxy instead. It runs as a local stdio MCP server and forwards every call to Korely over HTTP with your header attached, useful because the adapter also accepts command-based (stdio) servers. Requires Node.js / npx on the machine.

{
  "mcpServers": {
    "korely": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://api.korely.ai/agent/mcp",
        "--header",
        "Authorization: Bearer ${KORELY_API_KEY}"
      ]
    }
  }
}

By default the adapter routes all MCP tools through a single proxy tool to save context. To expose korely_get_context, korely_add, korely_search and korely_get_facts as first-class tools, use the adapter's directTools config or its /mcp interactive panel to promote them.

What Pi Agent can do

Once connected, Pi Agent has four memory tools:

Use it

Now Pi Agent reaches for memory on its own. Tell it something durable and it calls korely_add; ask it something personal and it calls korely_get_context first:

You › Remember that this repo deploys to Hetzner, not Render.
      → korely_add("This repo deploys to Hetzner, not Render")

# next session, days later
You › How do we deploy this?
      → korely_get_context("deploy") → "This repo deploys to Hetzner..."
Pi › This repo deploys to Hetzner (you told me earlier), not Render. ...

Scoping

Every tool accepts an optional user_id so one key can serve many end users, a memory written for "user-a" never surfaces for "user-b". Omit it and everything is scoped to the key's default.

Related

• Korely MCP, the full MCP surface and other clients.
• Get context, the call behind korely_get_context.
• Memory as a tool, the same pattern when you build the agent loop yourself.