Product · SynOI MCP Server

Testing

Stop re-explaining your context
to every new AI tool.

@synoi/mcp-server speaks the Model Context Protocol, so any MCP-capable client, Claude Desktop, Cursor, or the MCP CLI, can read and edit your operator Persona, look up graduated Skills, and recall past Q+A, without that client needing to know SynOI exists. It talks to your gateway, not a separate store: the same signed, hash-chained Persona and Skills your other SynOI products already use.

Seven tools, one bridge

Once configured, your Persona simply “appears” as tools the model can call.

synoi_persona_get

Read the operator profile or project context.

synoi_persona_put

Append a new revision (signed, scanned for prompt injection before it's written).

synoi_persona_history

List recent Persona revisions, newest first.

synoi_skills_list

List graduated skills, filterable by status.

synoi_skill_get

Fetch a specific skill by id, including its markdown body.

synoi_skills_retrieve

Find skills relevant to a query: procedural memory retrieval.

synoi_recall

Hybrid keyword and semantic search over past Q+A summaries.

Install in a few minutes

One install, one client config.

  1. 01

    Install the server and its peer SDK

    The MCP SDK is a peer dependency; install it alongside the server.

    npm install -g @synoi/mcp-server @modelcontextprotocol/sdk
  2. 02

    Point your MCP client at it

    Claude Desktop reads this from its config file; Cursor takes the same command and args under Settings → Features → Model Context Protocol. The admin key and tenant are yours: one server instance serves one tenant.

    {
      "mcpServers": {
        "synoi": {
          "command": "npx",
          "args":    ["@synoi/mcp-server"],
          "env": {
            "SYNOI_GATEWAY_URL": "http://localhost:3000",
            "SYNOI_ADMIN_KEY":   "<your gateway admin key>",
            "SYNOI_TENANT":      "<your tenant id>"
          }
        }
      }
    }

Trust model

Full read and write access to one tenant. Nothing more, nothing hidden.

Admin-key scoped, one tenant per process

The server uses your gateway's admin key, so it can read and write that tenant's Persona and Skills. Tenant binding is fixed at server start; a shared desktop with separate Personas needs one process per tenant.

Writes pass the injection scanner

Every synoi_persona_put call runs through the gateway's prompt-injection scanner before it's persisted. Content the model tries to smuggle in gets quarantined, not written.

Signed, hash-chained history

Persona writes are hash-chained and hybrid-signed, same as the rest of the SynOI substrate. synoi_persona_history gives you the audit trail, not just the latest value.

Keep the admin key out of shared configs

Claude Desktop's config file is plaintext. The README is explicit: prefer OS keychain integration or env-only injection over checking the key into a config file that syncs anywhere.

For embedders

Beyond the CLI: a factory function and a typed gateway client.

The package exports createSynoiMcpServer for embedding the MCP server in your own process, and a GatewayClient if you just want the typed gateway calls without the MCP transport layer.

import { createSynoiMcpServer } from '@synoi/mcp-server'

const server = await createSynoiMcpServer({
  gateway_url: 'http://localhost:3000',
  admin_key:   process.env.SYNOI_ADMIN_KEY!,
  tenant:      'founder',
})

The agent you use is already the client. This is the bridge.

No new UI to learn. Configure once, and Claude Desktop, Cursor, or any MCP client starts calling into your governed Persona and Skills.