MCP and Agent Workflows¶

otito can run as a stdio MCP server so agent hosts can ask for repository context without scraping terminal output.

Start The Server¶

Install the published package when you want Otito available as a local command:

npm install -g @bashbop/otito
otito doctor

Or start from a local checkout:

git clone https://github.com/BASHBOP/otito.git
cd otito && npm ci
node src/cli.js doctor

node src/cli.js mcp

From a local checkout:

node src/cli.js mcp

The MCP server uses stdio. The agent host starts otito mcp as a child process and speaks JSON-RPC over standard input and output.

MCP Client Examples¶

Use the installed otito binary where available. A local checkout is equally valid when you are developing Otito itself.

Generic stdio client¶

Many MCP clients use this shape:

{
  "mcpServers": {
    "otito": {
      "command": "node",
      "args": ["/absolute/path/to/otito/src/cli.js", "mcp"],
      "env": {}
    }
  }
}

Some hosts also require an explicit "type": "stdio" field. Check the host's current MCP schema before copying a config into a shared repository.

For a local checkout instead of a global install:

{
  "mcpServers": {
    "otito": {
      "command": "node",
      "args": ["/path/to/otito/src/cli.js", "mcp"],
      "env": {}
    }
  }
}

Keep /path/to/otito as a private local path. Do not commit machine-specific absolute paths to public documentation or shared repositories.

Claude Desktop¶

Claude Desktop uses claude_desktop_config.json with a top-level mcpServers object.

{
  "mcpServers": {
    "otito": {
      "type": "stdio",
      "command": "otito",
      "args": ["mcp"],
      "env": {}
    }
  }
}

After editing the config, fully restart Claude Desktop. If the server does not appear, run otito doctor and otito mcp manually in a terminal first, then check the MCP logs for the host.

Reference: Model Context Protocol local server guide.

VS Code¶

VS Code stores MCP server configuration in mcp.json. Workspace-level configuration lives at .vscode/mcp.json; user-level configuration is also supported by VS Code.

VS Code uses a top-level servers object:

{
  "servers": {
    "otito": {
      "type": "stdio",
      "command": "otito",
      "args": ["mcp"]
    }
  }
}

Useful commands from the Command Palette:

• MCP: Add Server
• MCP: List Servers
• MCP: Reset Cached Tools
• MCP: Open Workspace Folder MCP Configuration
• MCP: Open User Configuration

Reference: VS Code MCP configuration reference.

Cursor¶

Cursor uses mcp.json with a top-level mcpServers object.

{
  "mcpServers": {
    "otito": {
      "command": "otito",
      "args": ["mcp"],
      "env": {}
    }
  }
}

Use a project config when otito should only be available for one workspace. Use a global config only when you want the server available across projects. Project .cursor/mcp.json is local editor config and is not committed in this repository.

Reference: Cursor MCP docs.

Gemini CLI¶

Gemini CLI supports stdio MCP servers. Add Otito to user-level ~/.gemini/settings.json or project-level .gemini/settings.json:

{
  "mcpServers": {
    "otito": {
      "command": "otito",
      "args": ["mcp"]
    }
  }
}

Restart Gemini CLI and run gemini mcp list (or /mcp list) to confirm the server is connected. Gemini CLI also supports Skills, so use the Otito trusted agent workflow before asking it to edit code.

Reference: Gemini CLI MCP servers.

Kimi Code CLI¶

Kimi Code CLI supports stdio MCP servers. Add Otito to the user-level ~/.kimi-code/mcp.json or project-level .kimi-code/mcp.json file:

{
  "mcpServers": {
    "otito": {
      "command": "otito",
      "args": ["mcp"]
    }
  }
}

Verify the server with kimi mcp list. Kimi Code also recognises local skills; keep the agent workflow in the repository so it remains portable across tools.

Reference: Kimi Code CLI MCP support.

Grok¶

Grok custom MCP connectors use a publicly reachable MCP endpoint. Otito's local otito mcp command is stdio-only, so it must not be exposed through a local tunnel by default. Until Otito offers a reviewed remote MCP deployment, use the structured-handoff path instead:

otito context "<task>" --path . --out .otito/context-pack.md
otito pr . --base origin/main --out .otito/pr-review.md

Share only a sanitised summary or approved artifact with Grok. A future remote connector must receive a separate security, access-control, and data-boundary review before it can be presented as direct support.

Reference: Grok custom MCP connectors.

MCP Tool Surface¶

Òtítọ́ exposes 13 MCP tools for deterministic repository context and merge evidence.

Agent Loop¶

Trusted Agent Workflow¶

This workflow works across Codex, Claude, Cursor, Gemini, Kimi, and any agent that can use local MCP or a structured handoff:

Request -> context -> scoped change -> validation -> review context -> gate -> human decision

The host does not determine whether a change is trustworthy. Otito provides local, deterministic evidence; tests, protected branches, and a human reviewer provide accountability. Do not represent a passing gate as an automatic merge approval. A workspace-level gate binds local staged evidence across repositories; it does not establish hosted CI state, GitHub approval, or mergeability.

Host Guidance¶