Tokenectomy-Razor
This MCP server provides tools to sanitize error logs, search Stack Overflow, and apply code patches, all with automatic secret redaction and framework noise filtering.
get_error_context: Extracts detailed source code context and git diff from an error log (requires
log, optionalcontext_lines).search_stack_overflow: Searches Stack Overflow for a specific error query (requires
query).apply_code_patch: Applies a code patch to a file by replacing
original_codewithnew_code(requiresfile_path,original_code,new_code).Automatically redacts secrets (JWTs, API keys, connection strings) and filters framework internals from logs.
Integrates with AI agents via the Model Context Protocol (MCP) for local, privacy-preserving processing.
Supports Ollama as a local/offline AI model provider for the server.
Supports OpenAI as one of the AI model providers for the server.
Queries Stack Exchange APIs to search for and inject relevant Stack Overflow solutions into the AI context.
Tokenectomy Razor
Fast, deterministic log surgery and secret redaction for AI coding agents β purge 90%+ framework noise, redact credentials with O(N) ReDoS immunity, sub-millisecond latency. Written in safe Rust.
Tokenectomy (noun): token + -ectomy (surgical removal) β the precise excision of wasteful tokens from LLM context windows.
High-Performance Log Surgery & Secret Redaction Engine for AI Coding Agents
Official MCP Registry:
mcp-name: io.github.Tokenectomy-Labs/razor
π Table of Contents
Related MCP server: uacos
What It Does
Tokenectomy Razor is an autonomous, machine-to-machine (M2M) Model Context Protocol (MCP) server and stream processing engine written in safe Rust. It intercepts error logs from AI agents, strips 90%+ of framework noise, automatically redacts secrets (JWTs, API keys, database credentials), and caches sanitized contexts with a 24-hour TTLβall without sending raw data to external services.
In 30 Seconds
The Problem:
AI agents waste tokens on framework noise (
node_modules,site-packages,.cargo/registry)Sensitive credentials accidentally leak into LLM logs (AWS keys, database URLs, API tokens)
Repeated identical errors cost money for every retry
The Solution:
Raw Error Log (38K tokens + secrets)
β
[Redact secrets locally] β [Filter framework frames] β [Extract user code]
β
Sanitized Context (2K tokens, no secrets) β Safe to send to LLMReal Example
Before:
$ cat error.log | head -20
Error in /home/user/.cargo/registry/src-xxx/tokio-1.35/src/runtime/mod.rs:12345
at /home/user/.cargo/registry/src-yyy/serde/src/lib.rs:456
Database connection failed: postgresql://admin:secretpass@db.example.com:5432/mydb
JWT Auth token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0...
[... 500+ more framework frames ...]After:
$ cat error.log | razor --scrub
Error in /home/user/src/main.rs:42
at /home/user/src/utils.rs:18
Database connection failed: [CONNECTION_STRING_REDACTED]
JWT Auth token: [JWT_REDACTED]Benefits:
β 95% smaller context (2K vs 38K tokens) β Save money on LLM API calls
β Zero secrets in logs β Sleep better at night
β Identical errors cached β Second retry costs $0
Technical Highlights
ββββββββββββββββββββββββββββββββββββββββββββββββ
Agent Error β TOKENECTOMY RAZOR β Sanitized Context
Dump (38K toks) β - Polyglot Stack Frame Filter β βββΊ (2K toks) βββΊ LLM
βββββββββββββββββΊβ - Deterministic Secret Redactor (O(N)) β
β - SHA-256 Idempotency Cache (24h TTL) β
ββββββββββββββββββββββββββββββββββββββββββββββββDeep Polyglot Trace Surgery: In-memory parsing across Rust, Python, TypeScript/JavaScript, Go, Java/Kotlin (Spring Boot 3, Tomcat, Hibernate, Netty, Undertow, HikariCP), C/C++ (AddressSanitizer, GDB, glibc), and PHP. Surgically filters noisy framework internals and runtime boilerplate while isolating genuine user application code frames.
Static AST Code Analysis Engine (
analyze_code): High-throughput static AST analysis detecting unclosed handles, resource leaks, and security vulnerabilities with bounded execution limits (50K AST nodes, 10 MB file limit) and precise LSP UTF-16 coordinates.Glama Grade A TDQS Compliance: 100% Tool Definition Quality Score with explicit schema boundaries, runtime preconditions, and full disclosure across all MCP tools.
AI Gateway Reverse Proxy (
--proxy): Transparently intercepts prompt streams on127.0.0.1:8080, performing real-time token excision and credential sanitization before upstream forwarding to OpenAI, Anthropic, or Ollama.Zero-Knowledge Secret Redaction: Linear-time deterministic regex engine strips JWTs, API tokens, cloud access keys, connection strings, and private keys prior to network transmission. All processing happens locally.
SHA-256 Idempotency Cache: Stores deterministic responses with a 24-hour TTL. Repeated CI/CD or agent loop failures incur zero upstream API cost.
Path Traversal Containment: All MCP filesystem access is canonicalized and locked to the workspace root boundary (
CWD). No../escapes or symlink breakouts.M2M Protocol Compliance: Native JSON-RPC 2.0 stdio server compliant with the official Model Context Protocol specification.
Verifiable Benchmarks
Performance metrics are hardware-grounded and reproducible via standalone benchmark suites:
Benchmark Target | Workload Under Test | Verified Measurement | Result |
High-Volume Log Redaction | 250,000 lines (24.44 MB) enterprise dump containing API keys and connection URIs | 333.49 ms (73.3 MB/sec, 749,652 lines/sec) | Pass |
ReDoS Resistance | 50,000-character pathological backtracking string | 1.44 ms (Linear $O(N)$ evaluation) | Pass |
Thread Concurrency | 100 concurrent OS threads executing simultaneous redaction and extraction | 100/100 completed in 27.35 ms (7,312 ops/sec) | Pass |
Kernel Memory Footprint | Peak Resident Memory during 250,000-line continuous stress test | 76.24 MB VmRSS via | Pass |
Understanding the Benchmarks
Metric | Why It Matters | What To Expect |
73.3 MB/sec redaction throughput | Most logs are <5MB; you'll redact them in milliseconds | <10ms for typical CI logs |
1.44ms ReDoS immunity | Prevents malicious log payloads from DoS'ing your system | Safe to use in production with untrusted input |
76.24 MB peak memory | Suitable for constrained CI/CD runners (GitHub Actions, GitLab) | Fits within 256MB limits comfortably |
7,312 ops/sec concurrent | Multiple AI agents querying simultaneously | 100 concurrent requests handled safely |
Reproduce locally:
cargo test --release --test stress_benchmark -- --nocapture
Installation
Method 1: Instant via npx (Recommended for MCP Clients)
No Rust toolchain, native compilation, or manual path setup required:
npx -y tokenectomy-razor --mcpOr install globally via npm:
npm install -g tokenectomy-razorMethod 2: Cargo (crates.io)
cargo install tokenectomyMethod 3: Precompiled Native Binaries (GitHub Releases)
Download zero-dependency, precompiled standalone binaries directly from GitHub Releases:
Linux:
tokenectomy-linux-x86_64(glibc),tokenectomy-linux-x86_64-musl,tokenectomy-linux-aarch64macOS:
tokenectomy-darwin-arm64(Apple Silicon M1/M2/M3/M4),tokenectomy-darwin-x86_64(Intel)Windows:
tokenectomy-windows-x86_64.exe
Method 4: Build from Source
git clone https://github.com/Tokenectomy-Labs/Tokenectomy.git
cd Tokenectomy
cargo build --release
sudo cp target/release/razor /usr/local/bin/razorMethod 5: Multi-Arch Container (GHCR)
docker pull ghcr.io/tokenectomy-labs/razor:latest
docker run -it ghcr.io/tokenectomy-labs/razor:latest --helpModel Context Protocol (MCP) Integration
Configure Tokenectomy Razor as an autonomous background server across major AI agent environments:
Claude Desktop
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"tokenectomy": {
"command": "npx",
"args": ["-y", "tokenectomy-razor", "--mcp"]
}
}
}Cursor
Add to .cursor/mcp.json in your project root:
{
"mcpServers": {
"tokenectomy": {
"command": "npx",
"args": ["-y", "tokenectomy-razor", "--mcp"]
}
}
}VS Code (Native MCP / GitHub Copilot Agent / Continue)
For VS Code with native MCP support, create or edit .vscode/mcp.json in your workspace:
{
"mcpServers": {
"tokenectomy": {
"command": "npx",
"args": ["-y", "tokenectomy-razor", "--mcp"]
}
}
}Or use the ultra-low latency native binary (if installed via cargo install tokenectomy):
{
"mcpServers": {
"tokenectomy": {
"command": "razor",
"args": ["--mcp"]
}
}
}VS Code + Cline
Open Cline Settings in VS Code (or edit cline_mcp_settings.json):
macOS:
~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.jsonLinux:
~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.jsonWindows:
%APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json
{
"mcpServers": {
"tokenectomy": {
"command": "npx",
"args": ["-y", "tokenectomy-razor", "--mcp"],
"disabled": false,
"autoApprove": [
"get_error_context",
"search_stack_overflow",
"analyze_code"
]
}
}
}VS Code + Roo Code
In Roo Code Settings (or edit cline_mcp_settings.json in Roo storage):
Linux:
~/.config/Code/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.jsonmacOS:
~/Library/Application Support/Code/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json
{
"mcpServers": {
"tokenectomy": {
"command": "npx",
"args": ["-y", "tokenectomy-razor", "--mcp"],
"disabled": false,
"autoApprove": ["get_error_context", "analyze_code"]
}
}
}Windsurf (Codeium)
Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"tokenectomy": {
"command": "npx",
"args": ["-y", "tokenectomy-razor", "--mcp"]
}
}
}Google Antigravity CLI
agy mcp add tokenectomy-razor -- npx -y tokenectomy-razor --mcpExposed MCP Tools
Tool Name | Capability Description |
| Performs trace surgery on error dumps, removes framework noise, redacts credentials, and extracts relevant local source context bounded to the workspace. |
| Queries Stack Exchange API for relevant error signatures using sanitized search terms. |
| Applies atomic file modifications with post-write language syntax verification ( |
| Performs static AST code analysis to detect resource leaks, security vulnerabilities, and code defects with bounded execution limits and precise LSP UTF-16 coordinates. |
Quick Start
I use Claude Desktop
# 1. Add to claude_desktop_config.json (see MCP Integration section above)
# 2. When Claude encounters errors, it automatically uses "get_error_context" tool
# 3. Errors stay sanitized without any additional setupI use GitHub Actions
# Add to your workflow (.github/workflows/build.yml)
- name: Sanitize Build Failure Log
if: failure()
uses: daffa2555/tokenectomy-action@v1
with:
log-file: 'build.log'
output-file: 'sanitized.log'
# Now you can safely share sanitized.log without leak concernsParameters:
Parameter | Type | Default | Description |
| String |
| Path to raw error log file to process |
| String |
| Direct string content if file is not specified |
| String |
| Path for scrubbed output file |
| String |
| Binary release target version |
I want max privacy (air-gapped environment)
# All redaction happens locallyβno network calls except to your LLM
cargo install tokenectomy
# Process logs without any cloud services
echo $ERROR_LOG | razor --scrub --local-only
# Or from a file:
razor --scrub --file /var/log/app/error.log > sanitized.logAdvanced Usage
Standalone CLI
In addition to M2M agent mode, Razor provides CLI commands for terminal piping and local shell scripting:
# Scrub framework frames and output clean log
npm test 2>&1 | razor --scrub > sanitized.log
# Sanitize a specific log file
razor --scrub --file /var/log/app/error.log > sanitized.log
# CLI diagnosis with specific AI provider
razor --file error.log --provider openai
razor --file error.log --provider anthropic
razor --file error.log --local-onlyAI Gateway Reverse Proxy Mode
Tokenectomy Razor can operate as a transparent local HTTP reverse proxy. It sits between client applications and upstream LLM providers (OpenAI, Anthropic, Ollama, OpenRouter), performing real-time token excision and credential sanitization before upstream forwarding.
Local Development (Default Loopback):
# Forward to OpenAI
razor --proxy --proxy-bind 127.0.0.1:8080 --upstream-url https://api.openai.com/v1
# Forward to local Ollama instance
razor --proxy --proxy-bind 127.0.0.1:8080 --upstream-url http://127.0.0.1:11434/v1Point any standard SDK or IDE client to the local proxy:
export OPENAI_BASE_URL="http://127.0.0.1:8080/v1"
# Now all API calls are automatically sanitizedProduction Proxy Hardening
Binding to external interfaces (0.0.0.0) requires explicit token authorization:
razor --proxy --proxy-bind 0.0.0.0:8080 --upstream-url https://api.openai.com/v1 --allow-remote --proxy-token "YOUR_SECURE_TOKEN"Resource limits enforced: MAX_HEADER_SIZE (64 KB), MAX_BODY_SIZE (10 MB), client/upstream timeouts (30s / 60s), and a 128-connection concurrency cap.
Real-Time FinOps Economics Dashboard & Metrics
Tokenectomy Razor features an embedded zero-dependency real-time FinOps dashboard and metrics exporter:
Interactive UI: Open
http://127.0.0.1:8080/dashboardin any browser to inspect live token savings, dollars saved (blended LLM pricing), total requests, and active security redactions.Prometheus / JSON Metrics: Poll
GET http://127.0.0.1:8080/v1/metricsfor programmatic FinOps telemetry integration.Health Check:
GET http://127.0.0.1:8080/healthreturns gateway operational status.
Configuration
Configuration values can be set via ~/.tokenectomy.toml:
default_provider = "openai" # openai | anthropic | ollama | mock
openai_api_key = "sk-..."
anthropic_api_key = "sk-ant-..."
ollama_base_url = "http://localhost:11434"
context_lines = 10
max_context_chars = 10000Supported Ecosystems
Language | Primary Frameworks | Excluded Framework Paths |
Rust | Tokio, Actix-web, Axum |
|
Python | Django, FastAPI, Flask, PyTorch |
|
TypeScript / JavaScript | Next.js, Express, NestJS, Vite |
|
Golang | Gin, Fiber, Stdlib panics |
|
Java / Kotlin | Spring Boot, Quarkus, Gradle |
|
C / C++ | GDB Backtraces, AddressSanitizer |
|
PHP | Laravel, Symfony |
|
Note: Currently shipped with robust extractors for Rust, Python, TypeScript/JavaScript, and Go. Java/Kotlin, C/C++, and PHP support is coming in v1.2. See #1 for progress tracking.
How Tokenectomy Compares
Feature | Tokenectomy | Splunk Log Obfuscation | Datadog Logs | git-secrets |
Instant setup (no agent install) | β | β | β | β |
Works with AI agents (MCP) | β | β | β | β |
Local-only processing | β | β | β | β |
Polyglot stack traces | β | β | β | β |
Redaction caching (cost savings) | β | β | β | β |
Open source (MIT) | β | β | β | β |
Price | Free OSS | $$$ /mo | $$$ /mo | Free |
When to Use Tokenectomy:
β You use AI coding agents (Claude, Cursor, Cline, etc.)
β You care about privacy & local-first processing
β You want to reduce LLM token costs
β You're worried about secret leakage in logs
When to Use Something Else:
β You only need static secret scanning β use
truffleHog,detect-secretsβ You need real-time monitoring dashboards β use
Datadog,New Relic,Splunkβ Your error logs are naturally <100 tokens β overhead not worth it
β You're fully air-gapped β Actually Tokenectomy is perfect! (100% local processing)
Frequently Asked Questions
Q: Does Tokenectomy send my logs to external servers?
A: No. All redaction, parsing, and filtering happens locally on your machine. The only network call is to your chosen LLM (OpenAI, Anthropic, Ollama) after sanitization is complete. See SECURITY.md for the zero-knowledge guarantee.
Q: What secrets does Tokenectomy redact?
A: GitHub PATs, AWS keys, OpenAI/Anthropic API keys, JWTs, database connection strings (PostgreSQL, MySQL, MongoDB, Redis), private SSH keys, Slack/Discord webhooks, and more. Full list in src/redact.rs.
Q: What if my secret doesn't match the redaction patterns?
A: File an issue with an example (sanitized). We'll add the pattern. For now, you can add custom patterns in ~/.tokenectomy.toml (feature coming in v1.3).
Q: Is Tokenectomy safe for production?
A: Yes. Written in safe Rust (zero unsafe code in security paths), ReDoS-immune, and audited via RustSec. See SECURITY.md for full details.
Q: Can I use Tokenectomy offline?
A: Yesβexcept Stack Overflow search. Use --local-only flag to disable all network access (except your LLM).
Q: How do I remove Tokenectomy?
A: Simply uninstall:
npm uninstall -g tokenectomy-razor
# OR
cargo uninstall tokenectomyZero config cleanup neededβno files left behind.
Q: Can I use Tokenectomy in my CI/CD pipeline?
A: Yes! Use the GitHub Marketplace action (see Quick Start section) or the Docker container. Works with GitHub Actions, GitLab CI, Jenkins, etc.
Q: What's the difference between Razor (OSS) and Sentinel (Commercial)?
A: Razor is the free, community version with all essential features. Sentinel adds advanced capabilities like tree-sitter AST healing, anti-hallucination guards, and time-machine undo. See Edition Comparison below.
Edition Comparison
Capability | Razor (Community OSS) | Sentinel (Commercial Tier) |
Framework Log Filtering | Yes | Yes |
Polyglot Trace Extraction (4 Languages) | Yes | Yes (7 Languages) |
AI Reverse Proxy Gateway ( | Yes | Yes |
Stack Overflow Integration | Yes | Yes |
SHA-256 Idempotency Cache | Yes | Yes |
ReDoS-Safe Secret Redaction | Yes | Yes |
MCP Protocol Server (JSON-RPC) | Yes | Yes |
Bundled Agent Skills | 2 Skills (Spec TDD & Fuzzer) | Full 4 Skills Suite |
Tree-sitter AST Syntax Healing | No | Yes |
Anti-Hallucination Scope Guard | No | Yes |
Automated Test Rollback Loop | No | Yes |
Multi-File Atomic Transactions | No | Yes |
Time Machine Undo Engine ( | No | Yes |
True Ectomy Deep Surgery Engine | No | Yes |
Live DB Port & Docker Diagnostics | No | Yes |
Interested in Sentinel? View pricing & features
Roadmap
Milestone / Capability | Status | Target Version |
Core Polyglot Log Surgery & $O(N)$ ReDoS-Immune Secret Redaction | β Complete | v1.0.0 |
AI Gateway Reverse Proxy ( | β Complete | v1.1.0 |
Multi-arch Docker (GHCR) & GitHub Actions Marketplace Action | β Complete | v1.1.3 |
Static AST Code Analysis Engine ( | β Complete | v1.1.5 |
Glama.ai Tool Definition Quality Score (TDQS Grade A) | β Complete | v1.1.5 |
Standalone Multi-Arch Precompiled Binaries (Linux, macOS, Windows) | β Complete | v1.1.6 |
Official Anthropic MCP Registry Listing ( | β Complete | v1.1.7 |
| β Complete | v1.1.7 |
Java / Kotlin (Spring Boot 3, Gradle) framework stack trace extractors | β Complete | v1.2.0 |
C / C++ (AddressSanitizer & GDB/LLDB) backtrace cleaner | β Complete | v1.2.0 |
Go goroutine panic & dump compression heuristics | β Complete | v1.2.0 |
| π In Progress | v1.2.0 |
User-defined custom redaction patterns via | π Planned | v1.3.0 |
Configurable noise thresholds & custom exclude patterns | π Planned | v1.3.0 |
Local agent token savings & cost reduction metrics dashboard | π Planned | v1.3.0 |
Native VS Code & JetBrains companion extensions | π Planned | v1.4.0 |
Server-Sent Events (SSE) remote MCP transport | π Planned | v1.4.0 |
Tree-sitter AST syntax healing & repair | β Sentinel (Paid) | Available Now |
Multi-file atomic transactions & Time-machine rollback ( | β Sentinel (Paid) | Available Now |
Security & Reliability Invariants
Zero-Knowledge Processing: All scanning and redaction occurs on local hardware before data leaves the system boundary.
ReDoS Immunity: All pattern matchers utilize finite automaton evaluation with linear time guarantees. Verified in benchmarks.
Path Traversal Isolation: File operations are strictly locked within workspace boundaries via
WorkspaceBoundarysecurity module.Memory Safety: Implemented in safe Rust with bounded stream readers (
.take()) preventing resource exhaustion attacks.Audit Verification: Continuous dependency auditing maintained via RustSec advisory databases.
Vulnerability Disclosure: See SECURITY.md for responsible disclosure procedures.
Contributing
Found a bug? Have a feature request? Want to add support for a new language?
Pull Requests: Fork, create a feature branch, and submit a PR with tests
Security: See SECURITY.md for private vulnerability disclosure
See CONTRIBUTING.md for detailed contribution guidelines.
Resources
π Documentation β Full guides, API reference, and integration tutorials
π Changelog β Release history and notable changes
π€ Contributing β How to contribute, development workflow, and testing
π Security Policy β Vulnerability disclosure and audit details
ποΈ Architecture β Internal design and system architecture
License
MIT License. See LICENSE for full terms.
Made with β€οΈ by @daffa2555
Questions? Open an issue or start a discussion on GitHub.
Available Tools
3 toolsapply_code_patchA
Applies a code patch to a specific file by replacing original_code with new_code.
| Name | Required | Description | Default |
|---|---|---|---|
| new_code | Yes | The new code block | |
| file_path | Yes | Absolute path to the file | |
| original_code | Yes | The exact code block to be replaced |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core mutation behavior: replacing an exact code block with new code. However, with no annotations and no mention of failure modes (e.g., if original_code is not found), side effects, or success/failure signaling, transparency is incomplete.
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?
One focused sentence with the key action front-loaded. No filler or redundant information.
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 is simple and the parameter schema covers all inputs, but the description omits what happens on failure, whether replacement is global or first occurrence, and what the tool returns. For a mutation tool with no annotations or output schema, this leaves 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?
All three parameters have schema descriptions, so the description adds modest semantic value by clarifying the relationship between original_code and new_code. It does not significantly deepen the meaning 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?
Description uses a specific verb ('applies') and clearly identifies the action and resource: replacing original_code with new_code in a file. This clearly distinguishes it from the read-oriented sibling tools.
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 explicit when-to-use, prerequisites, or exclusions are provided. The intended context is only mildly implied by 'applies a code patch'; the sibling alternatives are named in the environment but not differentiated here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_error_contextC
Extracts detailed source code context and git diff from an error log
| Name | Required | Description | Default |
|---|---|---|---|
| log | Yes | ||
| context_lines | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It hints at a read-only, git-adjacent operation (extract context and git diff) but does not disclose side effects (or their absence), permissions, failure modes when the log references unknown code, or the shape of what is returned.
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?
A single concise sentence, front-loaded with the core extraction behavior and no filler. The trade-off is that the minimalism leaves required details out, but as far as it goes the content is all signal.
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 annotations and no output schema, this 2-parameter tool had the burden of explaining the full behavior, but it provides no return-format info, no failure semantics, and no explanation of how context_lines influences output. The description is adequate for discovering the purpose but not sufficient to invoke it 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 description coverage is 0%, so the description must compensate for parameters, but it only loosely maps 'log' to an error log and never addresses 'context_lines' at all. The description adds minimal meaning beyond the raw property names.
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 uses a specific verb-resource pair ('Extracts detailed source code context and git diff from an error log') that makes the core function clear. An agent can differentiate it from siblings search_stack_overflow and apply_code_patch based on this statement, though the description does not name them explicitly to reinforce the distinction.
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?
There is no guidance on when to choose this tool over its siblings or when not to use it. The only implied usage is 'when an error log needs code context,' but no prerequisites (e.g., a local git repo), exclusions, or alternative selection rules are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_stack_overflowB
Search Stack Overflow for a specific error query
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description has full responsibility for behavior disclosure. It only implies a read-only search operation and gives no information about return format, network requirements, rate limits, failure modes, or side effects. This is a thin behavioral disclosure for a tool that likely makes an external API call.
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 seven words long and front-loads the action and resource. There is no filler or redundant content, so it earns a strong score on conciseness and structure.
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 single-parameter search tool with no output schema, the description is barely enough for basic invocation. It falls short on contextual completeness because it does not mention usage boundaries relative to the sibling tools or explain what should be done after the error query is given.
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 no description semantics for the one string parameter, and the schema description coverage is 0%. The description partially compensates by indicating that the query should be 'a specific error query,' but it does not explain the expected form, language, or example values.
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 uses a specific verb ('Search'), resource ('Stack Overflow'), and purpose ('for a specific error query'), which makes the function clear. It is distinguishable from the sibling tools get_error_context and apply_code_patch by its stated behavior, though it does not explicitly differentiate from them.
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 provides no guidance on when to use this tool versus alternatives like get_error_context or apply_code_patch. There are no prerequisites, favorites, exclusions, or next-step hints, leaving the usage context entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.0- First observed
apply_code_patch - First observed
get_error_context - First observed
search_stack_overflow
TDQS
Scored across 3 tools
Each tool has a clearly distinct role: extracting error context, searching for solutions, and applying a patch. There is no overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case: get_error_context, search_stack_overflow, apply_code_patch. No naming deviations.
Three tools form a tight, well-scoped workflow for handling and fixing errors. Neither too thin nor excessive for the stated purpose.
The core loop of retrieve context β search for solution β apply fix is covered. A minor gap is lack of a post-patch verification step, but the surface is functional.
Maintenance
Related MCP Connectors
Nifty's MCP server β exposes tasks, projects, messages, and files as tools for AI agents.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA lightning-fast, language-agnostic code analysis MCP (Model Context Protocol) server built in Rust9-
- AlicenseNot gradedqualityBmaintenanceLocal-first code intelligence and safety layer for AI coding agents. MCP server exposes dependency graph, impact analysis, and AST-compressed repo context, backed by typed local memory, patch-scope safety gates, and git-independent transaction rollback.1MIT
- FlicenseNot gradedqualityAmaintenanceLocal MCP server that lets your AI coding agent query its own cross-tool project history - file/command freshness, past test failures, cost & token spend, cache status, and session handoff - over stdio, 100% local, no telemetry.45-
- AlicenseNot gradedqualityAmaintenanceLocal-first MCP server that provides project context, verification gates, and structured tools for coding agents to discover knowledge, run diagnostics, and execute allowlisted commands within a repository.35MIT