The Vesalius code graph MCP server is an on-device tool that maps your repository into a graph an AI agent can query. It ships as an MCP server with a CLI, a Mac app and a VS Code extension. Instead of grepping files, your agent asks the graph what calls what, and works from a real map of your codebase.
your repo
|
v
Vesalius (on-device)
| builds a code graph: files, symbols, edges
v
MCP server <-- your AI agent (Claude Code, Cursor, ...)
| |
| +-- asks: "who calls publishPost?"
+-- answers with symbols + relationships
|
v
agent edits files, runs creatoros CLI, ships the toolWhat Is the Vesalius Code Graph MCP Server?
Vesalius turns a repository into structured, queryable context and exposes it through an MCP server, so an agent reads relationships instead of raw file dumps.
The source is the haplollc/Vesalius repository. Per that project, Vesalius is a map of your codebase for Claude Code: an on-device code graph with an MCP server, a CLI, a Mac app and a VS Code extension. That is the whole claim. It builds the graph locally and serves it. Details like exact graph schema, language coverage and query syntax live in that repo, not in this post.
The useful framing for a creator is this. You do not need a code graph to write a caption. You need one the moment you are building your own posting, analytics or scheduling tool and an agent has to change code it did not write.
Why Your AI Agent Needs a Code Graph, Not Just File Search
A code graph answers relationship questions that file search cannot: what calls this function, what breaks if I rename it, which module already owns this logic.
Plain file context has a predictable failure mode. Your agent opens five files, each partially relevant, and burns context on text that does not matter. Ask “where is the retry logic for failed posts” and it greps for “retry”, finds four hits, guesses, and edits the wrong one.
Here is the difference in practice. Say you are building a small tool that queues posts through the Creator OS API and retries failures. With plain file context, a prompt looks like this:
Read src/queue.ts, src/api.ts and src/retry.ts.
Add a retry with backoff for 429 responses.
The agent reads three files and still may not know whether the queue or the API client owns the retry, or whether a helper already exists. With a code graph in the loop, the question changes:
Which function handles failed API calls, what calls it,
and is there an existing backoff helper I should reuse?
That is a structural question, and a graph is built to answer it. The agent gets a symbol and its callers instead of a folder tour. Fewer wrong edits, less context spent, faster loops.
How Vesalius Maps Your Repo On-Device (CLI, Mac App, VS Code)
Vesalius runs locally, so your source never leaves your machine to build the map, and the same graph is reachable from a terminal, a Mac window or your editor.
The repo lists four surfaces: an MCP server, a CLI, a Mac app and a VS Code extension. For an agent-driven workflow the MCP server is the one that matters, because that is what Claude Code and other MCP-capable agents connect to. The CLI and the VS Code extension cover the cases where you want to query or inspect the graph yourself, and the Mac app gives you a visual pass over it.
Treat the on-device part as a real benefit, not a slogan. Private repos, client work and half-finished side projects are normal for a creator. A tool that builds its index locally keeps that material where it already lives.
How to Connect Vesalius MCP to Claude Code and Other Agents
The pattern is the standard MCP one: point your agent at a server URL or local server, and it discovers the tools the server exposes.
Vesalius publishes exact setup steps in its repository. Follow those, since the transport and command differ from a hosted server. Here is the shape to expect, using Creator OS as the working example of a hosted MCP server so you can see how both kinds sit side by side in one config.
For a hosted server, Claude Code takes the URL and an auth header:
claude mcp add --transport http creatoros https://mcp.creatoros.ca/mcp \
--header "Authorization: Bearer cos_live_..."
For Cursor, Windsurf or VS Code, the same server goes in as an mcpServers entry with type http, the URL and the Authorization header. A local server like Vesalius follows the same mcpServers pattern with its own command. Once connected, your agent lists the tools and calls them.
Two things to check after any MCP connection:
- Does the agent see the tools? Ask it to list what it has. No tools, no benefit.
- Which tools write or delete? Read tools are free to use. Write and destructive tools deserve a confirmation step.
That second point is not theoretical. Creator OS marks destructive MCP tools (delete post, delete comment, delete automation, delete webhook, disconnect account, delete Skool post, deny Skool member, delete ad, delete blog article) so the AI app asks before acting. The Claude Code plugin goes further and adds a publish guard that asks Proceed or Cancel before anything is published, spent or deleted. You want that layer when an agent can touch live accounts. The setup is walked through in the Claude Code plus Creator OS MCP setup post, and there are walkthroughs on the KevBuildsApps YouTube channel.
Vesalius vs Plain File Context: What Changes in Real Output
The measurable change is in how many wrong turns the agent takes before it edits the right file, and a code graph cuts that number by answering structure directly.
Take a concrete build: a script that pulls per-post analytics from Creator OS and writes a weekly summary. With plain file context the agent has to reconstruct your project’s shape from whatever it happened to open. With a code graph it can start from the question that actually matters.
| Question | Plain file context | Code graph context |
|---|---|---|
| Where does the app call the analytics endpoint? | Grep, open candidates, guess | Ask which function calls it |
| What breaks if I change a function’s return type? | Find out at runtime | List callers before editing |
| Is there already a helper for this? | Depends on what got read | Look up the symbol |
| Context spent on irrelevant files | Often high | Lower, questions are targeted |
None of this replaces tests. It replaces the part where the agent builds a mental model by reading code it may never need. For a creator coding between shoots, that matters more than raw speed, because a wrong edit costs an afternoon of debugging.
Using a Code Graph to Build Your Own Posting and Analytics Tools
Pair a code graph with an API that already does the platform work, and you spend your agent’s effort on your product instead of platform quirks.
Here is a real shape. Say you want a small internal tool that posts a weekly update to Instagram and X, then pulls engagement and posts a summary to Slack. Creator OS covers the platform side: a REST API, the @creatoros/cli, a hosted MCP server and about 160 MCP tools. A minimal posting call through the API looks like this:
POST /v1/posts
{
"content": "This week in the build log...",
"platforms": ["instagram", "x"],
"media": ["med_abc123"],
"schedule_at": "2026-03-02T14:00:00Z",
"timezone": "America/Toronto"
}
Or the same thing from the terminal after uploading media once:
creatoros media:upload ./clip.mp4
creatoros posts:create --text "This week in the build log..." \
--platforms instagram,x --media med_abc123 \
--scheduledAt 2026-03-02T14:00:00Z --timezone America/Toronto
Analytics come back with one call, and posting rules are applied for you. A TikTok post needs its consent flags, Instagram needs a Business or Creator account, and a post naming a platform you have not connected comes back with missing_platforms while the rest still go out. You read the response shape once at the posts API docs.
Now the split. Your tool’s own code, the scheduling logic, the summary formatting, the retry wrapper, is exactly what Vesalius maps. The platform plumbing is a service call. Your agent stops reinventing OAuth flows and starts working on the part that is yours. That combination, a code graph for your repo plus an API for the platforms, is the fastest path from “I want my own tool” to a tool that runs.
If you would rather not hand an agent a codebase at all, Creator OS ships 14 Claude Code skills installed with npx @creatoros/cli@latest init, covering posting, scheduling, comments, DMs, automations, analytics, ads and Skool. Skills handle the routine work; a code graph handles the custom work. Most people end up with both.
Can a Code Graph MCP Server Scale to a Creator’s Whole Content Stack?
It scales as far as your own code goes, which for most creators is one or two small apps, not a platform.
Be honest about the boundary. A code graph knows your repository. It does not know your post history, your comment inbox, your Skool members or your ad spend. Those live behind the Creator OS API and MCP tools: list_posts, get_post_analytics, list_comments, skool_revenue, ads_best_posts. If your agent needs to answer “which post got the most comments this month,” that is an API question, not a code question.
The stack that works has three layers:
- Platform layer. Creator OS holds the 11 platforms plus Skool, plus a WordPress blog, Shopify, and paid ads as an add-on. Your tool calls it.
- Code layer. Your own repo, mapped by a code graph so your agent edits it correctly.
- Agent layer. Whatever AI app you use. Creator OS works with any MCP-capable agent, and the MCP docs cover the connection options.
One warning about scale. Every MCP server you connect adds tools to the agent’s list, and every server adds context. Connect two or three you actually use, not ten you might. The goal is less noise, not more endpoints.
There is also a governance angle worth planning for. API keys are pinned to one workspace, so an agent building your tool cannot reach a client’s accounts. Creator OS pins each cos_live_ key to one workspace, and read-only keys are created in Settings > API keys. Pair that with an on-device code graph and your private material stays put at both ends. The post on giving an AI agent safe access to your social accounts covers the account side in detail.
FAQ
What is the Vesalius code graph MCP server?
Per its repository, Vesalius is a map of your codebase for Claude Code: an on-device code graph with an MCP server, a CLI, a Mac app and a VS Code extension. It builds a structural graph of your repository and serves it to an AI agent over MCP, so the agent can query relationships between symbols instead of reading files blind.
How do I connect an MCP server to Claude Code?
For a hosted server, run claude mcp add with the HTTP transport, the server URL and an Authorization header, as in the Creator OS example above. For a local server like Vesalius, follow the exact command in its repository, then ask the agent to list its tools to confirm the connection. Creator OS also installs as a Claude Code plugin if you prefer that route.
Is Vesalius safe for private repos since it runs on-device?
Running on-device means the graph is built locally rather than by shipping your source to a remote indexing service, which is the right default for private work. Check the repository for what it does with your code and any telemetry, since this post makes no claims beyond the project’s own description. For the account side, keep agent access scoped: Creator OS API keys are pinned to one workspace and you can create read-only keys in Settings > API keys.
Can an AI agent build me a social media scheduling app?
An agent can write the app’s code, but it should not rewrite the platform layer. Creator OS exposes posting, scheduling, media upload, analytics, comments, DMs, automations and webhooks through its REST API, CLI and MCP server, so your tool calls those instead of handling eleven networks itself. An agent that can read a code graph for your repo and an API for the platforms spends its effort on your product.
What is the difference between an MCP server and an API for AI agents?
An API is a set of HTTP endpoints you call from code. An MCP server packages those capabilities as tools an AI agent discovers and calls in a conversation, with descriptions that tell the model when to use each one. Creator OS ships both: the REST API for your programs, and a hosted MCP server at https://mcp.creatoros.ca/mcp with about 160 tools for Claude, ChatGPT, Claude Code, Cursor, Codex, Windsurf and VS Code.
Get Started With Creator OS and Vesalius MCP
Start with the platform layer, because it is the part you should not be building alone. Sign up at https://www.creatoros.ca/sign-up. Creator OS plans start at $14.99/month for 11 platforms plus Skool, with the API, the MCP server and the CLI included. New subscribers start at $0 with a free trial and can cancel anytime.
Then wire the agents. Add Creator OS as an MCP connector, create a workspace-scoped key in Settings > API keys, and connect Vesalius to the same agent so it can read your own code. The agents docs cover permissions and setup.
If you want to see the open-source side of this stack in motion, watch the walkthroughs on the KevBuildsApps YouTube channel. Social Agents is an open-source agent harness that runs your socials on Creator OS from a local dashboard, and OPEN VIDEO EDIT is an open-source set of Claude Code skills that turns a raw talking-head clip into an animated short. Both live in their own GitHub repositories, and the channel is where the builds get shown end to end. The launch video is a good first stop.
Get started for $0
Free trial for new subscribers. Cancel anytime.