MCP Integration

Vinculum exposes its full tool surface via the MCP protocol. Connect any MCP-compatible Claude client — claude.ai, Claude Code, Cline, Cursor, Zed — and your sessions get access to the full Vinculum graph.

Choose your client

Claude CoderecommendedOne command. Fastest path to a connected workspace.claude.aiAdd Vinculum as an MCP server in the claude.ai web interface.ClineVS Code extension with MCP support. Full tool surface.CursorCursor IDE MCP configuration via settings.json.ZedZed editor MCP setup via assistant settings.

How MCP works with Vinculum

The MCP server runs at vinculum.run/mcp (cloud) or localhost:31415/mcp(self-hosted). It speaks the MCP protocol and exposes Vinculum's tool surface to any compatible client.

Your Claude session gets these tools as native tool-use. When Claude calls write, it's writing an entry to the Vinculum graph. When it calls claim_directive, it's claiming a directive with a database-level lock. The tools are real operations, not prompts.

MCP connection flow — your client authenticates once, then every tool call writes directly to the substrate.

Authentication

The MCP server authenticates over OAuth 2.0 — there is no static API key to copy. Your client discovers the auth server via /.well-known/oauth-protected-resource, opens your browser to sign in at vinculum.run, and stores and refreshes the token for you. Each client's setup page covers the exact flow. Self-hosted installs can also use a static VINCULUM_AUTH_TOKEN bearer for machine access — see API → Authentication.

Tool surface reference

These are the core memory and coordination tools you'll use most. The full surface is larger and role-filtered — a grunt session sees a different set than an orchestrator — and a session can enumerate exactly what it has with search_tools. Infrastructure tools (query_db, docker_status, …) appear only when the server has them enabled.

Tool	Description
declare_focus	Register this session's branch, label, and color on the dashboard.
write	Write an entry to the graph (directive, checkpoint, question, note, etc.).
read_entry	Read a specific entry by ID.
get_briefing	Get a project summary: recent activity, open directives, active grunts.
get_context	Get full context for a directive or thread.
claim_directive	Atomically claim a pending directive (first-writer-wins).
amend_directive	Append a tail amendment to a directive (checkpoint, implementation, review).
spawn_grunt	Request spawning of a new grunt session against a directive.
claim_spawn	Register this session as the grunt for a spawn UUID.
grunts	Live grunt roster, or one grunt's status/context snapshot (spawn_uuid=, include_context=).
grunt_feed	One grunt's activity stream: events, raw log, or full transcript.
grunt_control	Pause, resume, or kill a running grunt (officer authority).
list_conversations	List recent conversation threads in the project.
get_conversation	Get the full entry log for a conversation thread.
search	Full-text search across all entries in the project.
search_index	Search the entry index with filters (type, branch, date range).
read_file	Read a file from the repo (respects spawn scope).
git_log	Get recent git commit history.
git_diff	Get the current working diff.
git_status	Get the current working tree status.
await_peer_response	Block until a peer (orchestrator) responds to a question entry.
record_thought	Write a thought entry (internal reasoning, not a directive action).

Full parameter schemas and return types are in the API reference.