Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Graft map the codebase structure"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
AI coding tools are only as good as the context they receive. Most tools either have no codebase understanding, or use proprietary indexing locked to a single editor.
Graft gives any MCP-compatible AI tool deep structural understanding of your codebase:
100K lines of code represented in ~2K tokens of ranked context
Dependency-aware — knows which files import what, and what depends on what
PageRank-scored — surfaces the most structurally important files first
Tool-agnostic — works with Claude, Cursor, Windsurf, Continue, or any MCP client
Local-first — no cloud, no telemetry, no code ever leaves your machine
$ npx graftmap map
src/indexer/pipeline.ts [score: 0.0842]
function buildIndex (L19)
src/graph/pagerank.ts [score: 0.0731]
function computePageRank (L52)
function buildTeleportVector (L11)
src/parser/index.ts [score: 0.0654]
function parseFiles (L28)
src/mcp/server.ts [score: 0.0612]
function createGraftServer (L238)
function startMcpServer (L327)
[~487 tokens]Related MCP server: agentmako
# Run instantly with npx (no install needed)
npx graftmap map
# Or install globally
npm install -g graftmap
graft mapAdd Graft to your AI tool's MCP configuration. Once connected, your AI assistant automatically gets ranked codebase context.
Add to your MCP settings:
{
"mcpServers": {
"graft": {
"command": "npx",
"args": ["-y", "graftmap"],
"cwd": "/path/to/your/project"
}
}
}Add to .cursor/mcp.json in your project:
{
"mcpServers": {
"graft": {
"command": "npx",
"args": ["-y", "graftmap"],
"cwd": "/path/to/your/project"
}
}
}Graft speaks standard MCP over stdio. Point any MCP-compatible client at npx graftmap and it works.
Once connected, your AI tool gets these capabilities:
Tool | Description |
| Ranked tree map of the codebase by structural importance |
| Dependencies and definitions for a specific file |
| Find definitions by name or kind (function, class, type, etc.) |
| Files affected by changing a given file |
| Project overview with key files and tech stack |
Plus two MCP resources: graft://map and graft://file/{path}
graft map # Ranked codebase tree
graft map --focus src/api.ts # Personalized view focused on a file
graft map --budget 4096 # Custom token budget
graft stats # File count, definitions, edges, cache age
graft impact src/auth.ts # What breaks if you change this file?
graft search "handleRequest" # Find definitions by name
graft search "User" --kind class # Filter by kind
graft serve # Start MCP server (default command)Your Codebase Graft Pipeline AI Tool
───────────── ────────────── ───────
.ts .js .py ──► tree-sitter AST
extraction
│
dependency graph ──► graft_map
construction graft_context
│ graft_search
personalized ──► graft_impact
PageRank scoring graft_summary
│
token-budgeted ──► Ranked context
rendering in ~2K tokensDiscover — finds all supported files, respects .gitignore
Parse — extracts definitions (functions, classes, types) and references using tree-sitter
Graph — builds a directed dependency graph (files as nodes, imports as edges)
Rank — runs personalized PageRank to score files by structural importance
Render — produces token-budgeted output that fits in any AI context window
Cache — stores results in .graft/cache.json for instant re-indexing
Language | Definitions | References | Status |
TypeScript | Functions, classes, interfaces, types, enums, methods | Imports, usages | Stable |
JavaScript | Functions, classes, methods | Imports, usages | Stable |
TSX/JSX | Same as TS/JS | Same as TS/JS | Stable |
Python | Functions, classes, methods, decorators, dataclasses | Imports, usages | Stable |
Go | — | — | Planned |
Rust | — | — | Planned |
Graft is designed for large codebases:
Caching — parses once, re-indexes only changed files
Token-efficient — 100K LOC → ~2K tokens of meaningful context
Fast — full index of a medium codebase in under 3 seconds
Memory-efficient — in-memory graph, no external database needed
Graft is zero-config by default. It automatically:
Discovers .ts, .tsx, .js, .jsx, and .py files
Respects .gitignore patterns
Excludes node_modules, dist, .git, and common build directories
Uses sensible defaults for token budgets and PageRank parameters
No config files needed. Ever.
Contributions are welcome! See CONTRIBUTING.md for development setup and guidelines.
Especially interested in:
New language support (Go, Rust, Java, C#, Ruby)
Performance optimizations for very large monorepos
MCP tool improvements and new tool ideas
Integration guides for more AI coding tools
MIT — use it anywhere, for anything.
Dependencies and definitions for a specific file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path relative to project root |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the tool retrieves data for a file but does not mention whether it is read-only, any required permissions, the nature of the output, or potential side effects. This is insufficient for an agent to safely invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action. It is concise and to the point, but could be slightly more informative without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one required parameter and no output schema, the description is minimally sufficient. However, it lacks details about return format, pagination, or limitations, and does not help an agent decide between this and sibling tools in a meaningful way.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a full description for the 'path' parameter ('File path relative to project root'), achieving 100% coverage. The description does not add any additional meaning beyond what the schema already states, so it meets the baseline expectation without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: retrieving dependencies and definitions for a specific file. It uses a specific verb+resource pattern, but could be more precise about what 'definitions' entails. It does not explicitly distinguish from siblings like graft_impact or graft_search, but the purpose is distinct enough to infer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings (graft_impact, graft_map, graft_search, graft_summary). The description lacks any contextual cues about prerequisites or alternative scenarios, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Files affected by changing a given file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path relative to project root |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether affected files include transitive dependencies, limits, or required file existence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with key info. However, it is overly terse, potentially under-specified for a tool with no output schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and no output schema; the description should explain what 'affected' means (direct vs transitive) and any limits. It fails to provide sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'path' parameter. The description adds no additional meaning beyond the schema, thus baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns files affected by changing a given file, using a specific verb ('changing') and resource ('files affected'). It distinguishes from sibling tools like graft_search, though it lacks detail on scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not specify prerequisites or mention sibling tools for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranked tree map of the codebase by structural importance.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | File or symbol for personalization | |
| budget | No | Max tokens (default 2048) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. The description only mentions 'ranked tree map by structural importance' without explaining side effects, read-only nature, or nuances like how personalization works with the 'query' parameter. The behavior is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise, but it lacks structure and fails to provide necessary context. It is not overly verbose, but the brevity compromises completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should explain what the tool returns (e.g., a list, tree structure, or map). It does not, leaving an agent uncertain about the expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its two parameters, clearly explaining 'query' as personalization and 'budget' as max tokens. The tool description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a 'ranked tree map of the codebase by structural importance,' which conveys a general purpose but lacks specificity. It does not clearly differentiate from siblings like 'graft_search' or 'graft_impact,' as it does not explain what 'structural importance' means or how this map is generated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'graft_context' or 'graft_summary.' The description does not mention prerequisites, context, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find definitions by name or kind.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Name pattern to search for | |
| kind | No | Filter by kind: function, class, type, etc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description minimally states the tool's purpose but does not disclose behavioral traits like case sensitivity, wildcards, pagination, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no unnecessary words, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params, no output schema, no annotations), the description is adequate but minimal; it could explain the result format or provide search behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds 'Name pattern to search for' and 'Filter by kind: function, class, type, etc.', which offers slight additional context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Find definitions by name or kind.' uses a specific verb 'find' and a specific resource 'definitions', clearly distinguishing it from sibling tools like graft_context or graft_impact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via name or kind but does not provide explicit guidance on when to use this tool over alternatives, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Project overview with key files and tech stack.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, or performance characteristics. The burden of transparency is unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 6 words, but it is not a complete sentence; it is a noun phrase. Despite this, it communicates essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description provides a reasonable overview of what the tool returns (key files and tech stack). However, it lacks details on format, scope, or how 'key files' are determined, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so per guidelines the baseline is 4. The description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'project overview with key files and tech stack', which is specific and distinct from sibling tools like graft_search or graft_impact. However, it could be more explicit in differentiating from close alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context about prerequisites, limitations, or recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.0.1graft_contextgraft_impactgraft_mapgraft_searchgraft_summaryScored across 5 tools
Each tool has a clearly distinct purpose: context for a file, impact analysis, codebase map, definition search, and project summary. No overlap or ambiguity.
All tools follow the consistent pattern 'graft_<noun>' with simple, descriptive names (context, impact, map, search, summary). Perfect consistency.
5 tools is well-scoped for a focused code analysis server. Each tool earns its place covering essential exploration tasks without unnecessary bloat.
The set covers core codebase exploration: summary, search, context, impact, and structural map. Minor gaps like diff or history exist but the surface is practical for typical use.
Codebase graphs, caller impact analysis, and recorded project context for AI coding agents.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Hosted code graph over MCP: exact callers, dependencies, and cross-repo blast radius for AI agents.
shared AI-context layer for teams — persistent memory your agents search and update over MCP
