The mcp-injector server is a local daemon that pre-indexes, compresses, and serves your codebase context to AI tools like Claude, significantly reducing token costs (41–89% reduction) while maintaining privacy.
get_project_map: Returns a compressed structural overview of your workspace with function bodies folded to save tokens. Supports configurable compression tier and unfolded_files to serve specific files or glob patterns at full resolution.
injector_retrieve: Fetches the full uncompressed source of a file from the local SQLite cache, optionally by line range (start_line/end_line), using a SHA-256 retrieval key from a prior compressed payload.
injector_search: BM25-ranked full-text search over indexed symbols using SQLite FTS5 query syntax (bare terms, quoted phrases, prefix wildcards). Returns symbol types, line ranges, and context snippets.
injector_stats: Reports current index status, compression ratio, total files indexed, and cache hit rate.
injector_sync: Waits for all pending file index updates to complete, ensuring the index reflects the latest changes before querying. Returns a list of reindexed files.
Additional highlights:
Runs fully locally with no telemetry or cloud integration.
Automatically redacts sensitive data (AWS keys, JWTs, high-entropy strings) before context leaves your machine.
Incrementally monitors files for changes and auto-reindexes on git branch switches.
Produces deterministic, byte-identical compressed outputs to maximize LLM KV cache hits.
Auto-configures with Claude Desktop, Cursor IDE, and VS Code.
AI coding assistants often fail because they retrieve the wrong context. On a large codebase, blindly dumping raw files into the prompt leads to hallucinations, slow responses, and high API costs.
Foldwork fixes this. It is a deterministic repository understanding engine that pre-indexes your entire codebase into a local SQLite catalog. It acts as the Context Layer for your IDE, serving exactly the functions the AI needs—no more, no less—maximizing the first-try success rate and reducing token usage by 41-89%.
By combining AST body folding (which strips out function bodies while preserving signatures) with canonical determinism (which guarantees byte-identical outputs to maximize Anthropic's KV cache hits), Foldwork transforms massive enterprise monorepos into lightweight, cache-friendly payloads. This drastically reduces token consumption, cuts API costs by up to 90%, and eliminates context window overflow.
No cloud. No telemetry. Runs entirely on your machine.--
Estimate the impact of AST code compression on large open-source repositories (calculated at $2.00 / million input tokens for Claude Sonnet 5):
Repository | Total Files | Raw Context Tokens | Compressed Context Tokens | Token Reduction | Cost Saved / Run |
Django | 2,359 | 5,554,607 | 596,752 | 89.3% | $10.99 |
Tokio | 789 | 1,597,813 | 444,164 | 72.2% | $3.11 |
Gin | 99 | 197,300 | 47,718 | 75.8% | $0.39 |
Numbers are reproducible. Run the open-source benchmark tool on any public repository:
mcp-benchmark repository
Related MCP server: Headless Codebase Indexer
Run mcp-benchmark on your own project to see your exact savings before installing anything:
mcp-benchmark ./your-project
════════════════════════════════════════════════════════════════════════════════
mcp-injector Benchmark — context
Tier 3 compression | $2.00/1M tokens | 2026-07-15T12:00:00Z
════════════════════════════════════════════════════════════════════════════════
FILE RAW TOKENS COMPRESSED SAVED COST SAVED*
──────────────────────────────────────────────────────────────────────────────────────────
cmd/license-gen/main.go 3,633 214 94% $0.0072
main.go 17,555 1,917 89% $0.0347
website/api/webhook.go 2,682 295 89% $0.0053
main_test.go 1,576 353 78% $0.0031
──────────────────────────────────────────────────────────────────────────────────────────
TOTAL (4 files) 25,446 2,779 89.1% $0.0503
* Based on $2.00 / 1M input tokens
💡 Running this codebase through Claude 10×/day costs $0.51/day raw.
With mcp-injector: $0.01/day. You save $0.50/day ($15/month).get_project_mapReturns a compressed structural overview of the workspace. Function bodies are folded and replaced with placeholders to reduce token usage.
tier (integer, optional): Compression tier to apply (default: 2).
unfolded_files (array of strings, optional): Workspace-relative paths or glob patterns for files to serve at full resolution (uncompressed).
path_prefixes (array of strings, optional): Scope the project map to specific microservices or packages, drastically reducing payload bloat.
git_context: always includes current branch, changed files, and recent commits in the response.
secrets_redacted: count of credentials automatically redacted before sending to Claude.
Example call:
{
"tool": "get_project_map",
"arguments": {
"tier": 3,
"unfolded_files": ["src/auth/handler.go", "**/*_test.go"],
"path_prefixes": ["src/auth/"]
}
}injector_retrieveRetrieves the full uncompressed source of a file from the local cache.
path (string, required): The workspace-relative path of the file to retrieve.
retrievalKey (string, optional): The SHA-256 retrieval key returned in a prior compressed payload.
start_line (integer, optional): 1-indexed start line for range retrieval.
end_line (integer, optional): 1-indexed end line for range retrieval.
expand_graph (boolean, optional): Resolves and appends cross-file dependencies (limited to 50 1st-degree dependencies).
injector_searchBM25-ranked full-text symbol search over the local SQLite catalog. Supports FTS5 boolean logic (e.g., user AND (auth OR login)).
query (string, required): FTS5 query string (bare terms, "phrase", prefix*).
limit (integer, optional): Maximum results (default: 20).
search_paths (array of strings, optional): Scope search to specific isolated directories.
injector_diagramGenerates a Mermaid sequence diagram for a given symbol by traversing its outbound dependencies (halts after 500 nodes).
symbol (string, required): The exact symbol name.
max_depth (integer, optional): Maximum traversal depth (default: 3).
include_primitives (boolean, optional): Include basic types (String, boolean) and framework boundaries.
injector_regex_searchFallback for exact literal or regex searches against file contents. Bypasses FTS5 tokenization.
query (string, required): The string or regex pattern to search for.
is_regex (boolean, optional): Treats query as extended regex (-E).
injector_write_fileWrite a full file to disk. CRITICAL: Prevents data loss by intercepting and rejecting payloads containing compressed fold markers.
injector_blast_radiusAnalyzes the architectural impact of changing a symbol by traversing the dependency graph. Supports inbound and outbound directional traversal.
injector_git_contextIntegrates with local Git history to surface commit context, authorship, and code evolution directly into the LLM context.
injector_inspect_tableEnables direct database introspection capabilities. Currently supports PostgreSQL and MySQL.
CRITICAL: You must start the daemon with the FOLDWORK_DB_DSN environment variable set to your database connection string (e.g. postgres://user:pass@localhost:5432/dbname) to activate this tool.
injector_clear_cacheWipes the SQLite index cache and triggers a clean cold-start full re-index.
injector_statsReturns index status, current compression ratio, total files indexed, and cache hit rate.
injector_sync (Deprecated)Read tools automatically wait for pending indexing implicitly. You never need to manually call this tool.
Install the daemon locally and configure your IDEs:
curl -fsSL https://foldwork.dev/install | shAutomatically configures Claude Desktop, Cursor IDE, VS Code, Devin Desktop, and Antigravity.
Run the benchmark CLI on your project to see your token savings and line count:
mcp-benchmark ./your-projectIf your project is under 50,000 lines, mcp-injector is completely free. The benchmark output shows your exact line count.
curl -fsSL https://foldwork.dev/install | shThe installer auto-detects Claude Desktop, Cursor, VS Code, Devin Desktop, and Antigravity and writes the MCP config automatically. You should see output like:
* mcp-injector v0.2.0 installed to /usr/local/bin/mcp-injector
* Claude Desktop configured
* Cursor configured
Restart your IDE and mcp-injector will be active.The MCP server starts automatically when your IDE launches. No separate daemon process to manage.
In Claude Code or Cursor, ask Claude:
"Use get_project_map to show me the structure of this project"
Claude will call the mcp-injector tool and return a compressed map of your entire codebase. If you see module names, entry points, and dependency information - it is working.
When Claude needs to see the complete implementation of a compressed function, it automatically calls injector_retrieve. You can also trigger this explicitly:
"Show me the full implementation of UserService.java"
Claude will fetch the uncompressed source from the local cache.
Editing Code: You MUST use the injector_write_file tool to edit code. If Claude tries to write back folded placeholders into your source code, the daemon will hard-reject the payload to protect you from data loss.
injector_statsOr ask Claude directly: "Call injector_stats and tell me my current token savings."
Now that your AI has deterministic tools to search, traverse, and retrieve code, you can ask it high-level architectural questions that usually fail on raw codebases:
Trace authentication flow — Ask the agent to map out your login sequence; it will use injector_retrieve with expand_graph=true to traverse through middleware, validation, and database layers.
Find dead code — The agent can leverage injector_blast_radius (inbound traversal) to identify unused functions and isolated structs.
Generate architecture diagrams — Tell your AI to "Generate a Mermaid diagram for this workflow"; it uses injector_diagram to instantly draw the entire outbound execution sequence.
Understand dependency graphs — Use injector_blast_radius to see exactly what services or packages rely on a specific core module.
Locate implementations — The agent uses injector_search (BM25 full-text indexing) to find exact function definitions across millions of lines of code.
Refactor safely — Before making a breaking change, the agent checks injector_blast_radius to see every caller that will be impacted.
Review pull requests — Instruct the agent to analyze your uncommitted changes or branch diff. It uses injector_git_context to understand recent commits and author intent alongside the code.
Navigate large monorepos — get_project_map gives the AI a compressed, birds-eye view of your entire architecture, allowing it to drill down into specific microservices using path_prefixes.
Sometimes you need Claude to see the exact implementation of a file while keeping the rest compressed. Use the unfolded_files parameter:
In your MCP call or by asking Claude:
"Get the project map but show me src/auth/handler.go at full resolution"
This passes "unfolded_files": ["src/auth/handler.go"] to get_project_map. That file is served raw; everything else stays compressed.
Glob patterns work too:
"**/*_test.go" - all test files uncompressed
"src/auth/*.go" - all files in a directory uncompressed
mcp-injector installs a post-checkout git hook when it first runs. Branch switching automatically triggers a full re-index. You will see this in the daemon logs:
[mcp-injector] Branch switched to feature/auth-refactor, re-indexing...
[mcp-injector] Re-index complete in 4.2s (47,293 lines indexed)Enterprise security teams often block AI coding tools because developers accidentally leak sensitive credentials in their context window.
mcp-injector solves this locally. The daemon includes a built-in Shannon entropy filter that analyzes all AST strings and comments in real-time. If it detects high-entropy strings (like AWS Access Keys, SSH private keys, or database passwords), it dynamically redacts them as [REDACTED: high entropy] before they ever leave your machine. Your API credentials are never sent to Anthropic.
If your codebase has a hardcoded API key or AWS credential, the get_project_map response will include:
"secrets_redacted": 2,
"files_with_redactions": ["config/db.go", "scripts/deploy.sh"]The actual values are replaced with [REDACTED: high entropy]. Variable names are preserved so Claude still understands the code structure.
If the auto-installer does not detect your IDE, add this to your MCP config manually:
{
"mcpServers": {
"mcp-injector": {
"command": "/usr/local/bin/mcp-injector",
"env": {
"MCP_WORKSPACE": "/absolute/path/to/your/project",
"FOLDWORK_DB_DSN": "postgres://user:pass@localhost:5432/dbname"
}
}
}
}Note: VS Code supports
"${workspaceFolder}", but Claude Desktop, Cursor, and Devin Desktop require a hardcoded absolute path to your project.
Config file locations:
Claude Desktop (Mac): ~/Library/Application Support/Claude/claude_desktop_config.json
Claude Desktop (Windows): %APPDATA%\Claude\claude_desktop_config.json
Claude Desktop (Linux): ~/.config/Claude/claude_desktop_config.json
Cursor: ~/.cursor/mcp.json
VS Code: .vscode/mcp.json
Devin Desktop: ~/.codeium/windsurf/mcp_config.json
Antigravity: ~/.gemini/antigravity/mcp_config.json
Incremental Parsing: Foldwork scans your repository instantly using a single-pass AST parser, identifying all interfaces, classes, and function signatures without blocking.
Graph Generation: It deterministically builds two structures: a Symbol Graph for precise definitions, and a Dependency Graph tracking outbound caller/callee relationships.
Local Catalog: The graphs are durably stored in a local SQLite FTS5 catalog. Indexing happens exactly once per file change, meaning zero overhead during AI prompts.
MCP Serving: Your AI agent securely communicates with Foldwork via the Model Context Protocol, fetching sub-graphs in milliseconds without the code ever leaving your machine.
Branch-Aware & Deterministic: Switching branches triggers automatic incremental re-indexing via git hooks. By guaranteeing byte-identical outputs across runs, Foldwork maximizes Claude's KV prompt caching hits.
Supports: Go, Python, TypeScript, JavaScript, Java, C++, C, C#, Rust.
Free Tier: Workspaces under 50,000 total source lines (all tools and features fully active).
Pro Tier ($12/month or $99/year): Unlocks unlimited workspace sizes and high-speed incremental diff indexing.
Activate Pro at foldwork.dev
You can run mcp-injector status in your terminal at any time. This CLI dashboard visually proves your exact token savings and estimated dollars saved by comparing your raw codebase tokens against the AST-compressed tokens in real-time.
mcp-injector automatically redacts secrets and credentials before they reach Claude's context window:
AWS access keys, GitHub PATs, Stripe secret keys
JWT tokens and bearer tokens
High-entropy strings detected via Shannon entropy analysis
Private key headers (-----BEGIN RSA PRIVATE KEY-----)
Air-Gapped Ready: Pro license validation uses strictly offline Ed25519 cryptography. The daemon never makes an outbound network request, even to verify your subscription.
Redacted content is replaced with [REDACTED BY MCP-INJECTOR]. A count of redactions is included in the get_project_map response so you always know what was protected.
Your code never leaves your machine. Redaction happens locally before compression, and is always-on - it cannot be disabled.
To remove mcp-injector completely:
# Remove binary
sudo rm /usr/local/bin/mcp-injector
# Remove index cache and logs
rm -rf ~/.mcp-injector/
# Remove from IDE MCP config (edit manually):
# Claude Desktop (Linux): ~/.config/Claude/claude_desktop_config.json
# Claude Desktop (macOS): ~/Library/Application Support/Claude/claude_desktop_config.json
# Cursor: ~/.cursor/mcp.json
# VS Code: .vscode/mcp.json
# Devin Desktop: ~/.codeium/windsurf/mcp_config.json
# Antigravity: ~/.gemini/antigravity/mcp_config.json
# (Remove the "mcp-injector" entry from mcpServers)mcp-injector automatically redacts the following before your code reaches Claude:
Pattern | Example Match |
AWS access key IDs |
|
GitHub PATs (ghp_, ghs_) |
|
Stripe secret keys |
|
JWT tokens |
|
PEM private key headers |
|
Generic high-entropy strings >20 chars | Detected via Shannon entropy |
Password / secret / token assignments |
|
Redacted values are replaced with [REDACTED BY MCP-INJECTOR]. File paths and variable names are never redacted - only the values.
Commercial. Free tier available. Source code not public.
Support Contact: foldwork@proton.me
Returns a compressed structural overview of the workspace. Function bodies are folded and replaced with placeholders. Compression tiers: Tier 1 removes comments; Tier 2 removes comments and folds function bodies; Tier 3 folds all block structures. IMPORTANT: This output is read-only reference material. Never edit files using the folded output. Always call injector_retrieve to get the full uncompressed source before making any edits. Feel free to use this tool proactively to understand architecture or locate unfamiliar code before searching.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Compression tier to apply (default: 2). | |
| path_prefixes | No | Optional list of path prefixes to restrict the project map to specific directories. | |
| unfolded_files | No | Workspace-relative paths or glob patterns for files to serve at full resolution (uncompressed). Supports exact paths, globs (src/auth/*.go), and ** prefix patterns (**/*_test.go). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: output is compressed, read-only, and function bodies are folded. It also explains three compression tiers and the importance of not editing based on this output, which is transparent.
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 well-structured, starting with the main purpose, then detailing tiers, and ending with usage guidance. It is concise but includes necessary warnings and advice, earning a high score.
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 3 parameters, no output schema, and no annotations, the description covers all essential aspects: what it does, how to use it, what the output looks like, and how it relates to other tools. It is complete for an agent to use correctly.
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 the baseline is 3. The description adds value by explaining the effect of compression tiers (e.g., 'removes comments', 'folds function bodies') and reiterating the purpose of path prefixes and unfolded files, improving clarity 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 clearly states 'Returns a compressed structural overview of the workspace' and details the compression tiers and intended use. It distinguishes from sibling tools by focusing on structural overview rather than other search or write operations.
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 explicitly advises when to use ('proactively to understand architecture'), warns against editing folded output, and recommends the alternative 'injector_retrieve' for full source before edits. This provides strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds dependencies of a specific symbol to analyze the impact of a refactor. Can traverse inbound (callers), outbound (what it calls), or both.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | The exact symbol name to analyze. | |
| direction | No | Traversal direction: 'inbound', 'outbound', or 'both' (default: 'inbound'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. States it finds dependencies and can traverse directions, but does not mention what 'dependencies' includes (e.g., direct/transitive), performance, or 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?
Two sentences, no fluff, front-loaded with purpose. Every sentence adds value.
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?
Adequate for two parameters with no output schema. Covers basic behavior and direction options, but could specify return format or error handling.
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 provides 100% coverage with descriptions for both parameters. Description adds context on traversal directions but does not significantly enhance semantics beyond 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?
Description uses specific verb 'finds dependencies' and resource 'specific symbol', clearly stating purpose for refactoring impact analysis. Distinguishes from siblings by specifying traversal directions.
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?
Explicitly states when to use (analyzing refactor impact) and traversal options. Lacks guidance on when not to use or alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a Mermaid sequence diagram for a given symbol by traversing its outbound dependencies (Product B). Useful for visualizing architectural workflows.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | The exact symbol name to generate a sequence diagram for (e.g., 'handleProjectMap'). | |
| max_depth | No | Maximum traversal depth (default: 3). | |
| include_primitives | No | If true, includes basic types (String, boolean) and framework boundaries in the diagram. Defaults to false for crisp business logic visualization. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present; description mentions traversing outbound dependencies but does not disclose whether the tool is read-only, has rate limits, 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?
Two sentences, front-loaded with the core action, no unnecessary words.
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?
Adequate for a diagram generation tool with three parameters, but no mention of output format or return value.
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 the description adds no extra meaning beyond what the schema already captures.
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?
Title 'injector_diagram' and description clearly state it generates a Mermaid sequence diagram for a symbol, distinct from siblings like 'get_project_map' or 'injector_blast_radius'.
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 says 'useful for visualizing architectural workflows' but lacks explicit when-to-use vs. alternatives or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspects the live database schema of a specific table. Connects using the FOLDWORK_DB_DSN environment variable (format: postgres://user:pass@host/db or mysql://user:pass@tcp(host)/db).
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | The exact name of the database table to inspect. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Behavioral transparency is moderate: the description discloses the connection method and environment variable, but does not state that the operation is read-only, nor what happens on errors (e.g., table not found, connection failure). No annotations are present to supplement this.
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 with two sentences, front-loading the main purpose and then providing necessary connection detail. No wasted words.
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's simplicity (one required parameter, no output schema), the description adequately covers the core functionality and connection requirements. It could mention what the inspection output contains, but the lack of output schema means this is not strictly necessary for basic understanding.
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%, with table_name well-described in the schema. The description adds no extra meaning beyond the schema for the parameter, only providing context about the connection method (not a parameter). Thus baseline score of 3.
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?
Description clearly states it 'Inspects the live database schema of a specific table', providing a specific verb and resource. This distinguishes it from sibling tools like injector_blast_radius or injector_diagram.
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?
Description mentions the required environment variable and connection format, giving usage context. However, it does not explicitly state when to use this tool versus alternatives, nor provide exclusions or prerequisites beyond the DSN.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fallback for exact literal or regex searches against file contents. Bypasses FTS5 tokenization to find punctuation-heavy strings or regex patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The literal string or regex pattern to search for. | |
| is_regex | No | If true, treats the query as an extended regex (-E). If false, treats as a fixed literal string (-F). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions bypassing FTS5 tokenization, which is a useful behavioral trait. However, it does not disclose potential performance impacts, scope of search (e.g., all files or specific directories), or whether it is read-only (inferred but not stated).
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?
Two concise sentences with no fluff. The purpose is stated first, followed by behavioral detail. Every word adds value.
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?
For a simple search tool with two parameters and no output schema, the description covers purpose, use case, and key behavioral trait. It could mention the scope of files searched (e.g., entire project) to be fully self-contained, but overall it is sufficient.
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% with clear parameter descriptions. The tool description adds minimal extra (e.g., 'punctuation-heavy strings'), but does not significantly enhance understanding beyond the schema. Baseline 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 clearly states it is a fallback for literal or regex searches on file contents, bypassing FTS5 tokenization for punctuation-heavy strings or regex patterns. This distinguishes it from siblings, which are not search tools, and provides a specific verb-resource-modifier structure.
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 explicitly frames it as a 'fallback' and mentions when to use (for punctuation-heavy strings or regex patterns). It implies a primary FTS5 search exists but does not name alternatives, limiting explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a full file to disk. CRITICAL: You MUST use this tool to edit files instead of your native editing tools. It prevents data loss by rejecting fold markers.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Workspace-relative path to the file to write. | |
| content | Yes | The full, uncompressed source code to write. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It mentions that the tool rejects fold markers to prevent data loss, but does not disclose overwrite behavior, permissions, or error handling. Adequate but not comprehensive.
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?
Two concise sentences with no extraneous information. The critical usage directive is front-loaded.
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?
For a simple write tool with two parameters and no output schema, the description provides core functionality but lacks details like overwrite behavior and error scenarios. Adequate but not fully complete.
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%, and the description adds no new meaning for parameters beyond the schema's own descriptions (e.g., 'full, uncompressed source code' is already in the schema). Baseline 3 applies.
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?
Clearly states the verb 'write' and resource 'file to disk'. The description also distinguishes this tool from sibling tools (e.g., injector_diagram) by emphasizing file editing and data loss prevention.
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?
Explicitly instructs the agent to use this tool for file editing instead of native tools, citing data loss prevention. However, it does not mention when not to use or provide alternatives.
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. Dates show when Glama detected each change.
v0.3.2get_project_map1 field changedInput schema / properties / path_prefixesAdded value: +{
+ "description": "Optional list of path prefixes to restrict the project map to specific directories.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}injector_blast_radiusinjector_diagraminjector_inspect_tableinjector_regex_searchinjector_retrieveinjector_searchinjector_statsinjector_syncinjector_write_filev0.1.0get_project_mapinjector_retrieveinjector_searchinjector_statsinjector_syncEach tool has a clear, distinct purpose: get_project_map provides structural overview, injector_blast_radius analyzes dependencies, injector_diagram generates sequence diagrams, injector_inspect_table inspects database schemas, injector_regex_search performs fallback searches, and injector_write_file writes files. No overlap or ambiguity.
Naming is inconsistent: get_project_map lacks the 'injector_' prefix used by the other five tools. The patterns after the prefix also vary: 'blast_radius' (noun phrase), 'diagram' (simple noun), 'inspect_table' (verb_noun), 'regex_search' (noun_noun), 'write_file' (verb_noun). No single convention is followed.
With 6 tools, the server covers essential operations for a code injection and analysis tool: overview, dependency analysis, visualization, database inspection, search, and file writing. The count is well-scoped and appropriate for the domain.
The tool set covers reading (get_project_map), analysis (blast_radius, diagram), search (regex_search), and writing (write_file), but lacks partial file editing or incremental updates. The description emphasizes using injector_write_file for all edits, yet it only supports full file writes, leaving a notable gap for typical editing tasks.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/foldwork-dev/mcp-injector'
If you have feedback or need assistance with the MCP directory API, please join our Discord server