Give AI coding agents precise code context through MCP
The short answer
MCP provides a standard way for compatible AI applications to use external tools and context sources. CodeMesh can use MCP to expose repository intelligence to supported agents, allowing them to request targeted structural information rather than relying only on broad file reads.
What comes back over MCP
Three kinds of question and the tool that answers each: a value or definition, a call chain walked over real edges, and an exact string. In every case what returns is spans of code with their file and line, not whole files.
What is MCP?
The Model Context Protocol (MCP) is an open, standard way for an AI application, a coding agent, a chat client, an IDE extension, to discover and call external tools and context sources at runtime, instead of every integration needing its own bespoke API. A client connects to an MCP server, sees the tools it exposes, and calls them as part of answering a question or completing a task.
CodeMesh runs an MCP server. Remote and hosted clients, Claude.ai, ChatGPT, and other clients connecting to CodeMesh's hosted MCP endpoint, authenticate to it using standard MCP OAuth 2.1 discovery. Local coding agents like Claude Code, Cursor and Devin are instead configured by the CodeMesh extension: clicking Connect writes that agent's MCP settings for you.
What MCP does not automatically solve
MCP standardizes how an AI application discovers and calls external tools; it says nothing about what those tools return or how well they select relevant information. A server that exposes MCP tools but retrieves poorly can still hand an agent far more context than it needs.
MCP is the communication layer. Context quality still matters.
A context server that just wraps file reads
An MCP server that only wraps a text or file search still returns whatever it finds, often many more files than a question actually needs, leaving the agent to sort through a large amount of context to find the relevant part.
CodeMesh: structural retrieval over MCP
CodeMesh instead resolves a question against a structural understanding of the repository, the specific functions, classes, imports and call relationships it depends on, and returns that targeted result through MCP, rather than a pile of candidate files.
The six tools CodeMesh exposes over MCP
CodeMesh's MCP server exposes six distinct tools, not just a single file-search wrapper:
- graph-ontology: describes how the repository is structured (which node types hold which facts, which relationships connect them), so later queries target the right place instead of guessing.
- code-answer: returns a finished, cited answer to a question in one call.
- code-context: returns the raw matching lines relevant to a question.
- search-code: finds an exact string across the repository.
- fetch-code: reads a specific span of code.
- query-context: runs a direct structural query over the repository's relationships, for open-ended questions the other tools don't cover.
Having distinct, purpose-built tools, rather than one generic file-read tool, is what lets an agent ask a targeted question and get a targeted answer back.
MCP alone doesn't guarantee token efficiency
Connecting an agent to an MCP server does not by itself reduce token consumption; that depends entirely on what the server does when it's called. A poorly targeted MCP tool can consume just as many tokens as an agent reading files directly, or more.
In CodeMesh's published benchmark, this structural approach to retrieval reduced token consumption substantially compared to an agent reading files directly for the same questions.
Results are from the published CodeMesh benchmark (98 questions, one public repository, one model). Actual results vary by repository, model, coding agent, task and usage pattern. Read the methodology →
FAQ
See structural retrieval over MCP in practice
Connect a supported agent to CodeMesh and see the difference targeted context makes.