ContextCut
ContextCut is an MCP server that prunes code to its essential interfaces to reduce token usage and cost for LLM coding agents.
Prune source code with
prune_code_context: Accepts a file path, directory path, or rawcode_contentstring and returns AST-stripped stubs preserving signatures, types, interfaces, and docstrings.Support Python, TypeScript, and JavaScript with optional language hints and glob filtering for directory scans.
Choose pruning depth:
interfaces_onlykeeps docstrings;minimalstrips them for maximum compression.Validate licensing with
check_license: Check Free vs Pro tier status; TypeScript/JavaScript pruning requires a Pro license key.Generate ROI reports with
get_savings_report: Aggregate token and cost savings over daily, weekly, monthly, or all-time intervals in Markdown or JSON.Track persistent local analytics: Savings are recorded to a private append-only ledger at
~/.contextcut/history.jsonl.Provide MCP resources: Expose on-demand pruned stubs via
contextcut://pruned/{filepath}.Offer an architecture-analysis prompt:
analyze_architectureguides agents to inspect high-level code structure without implementation noise.Include CLI utilities: Install agent integration (
contextcut-mcp install), clipboard quick-trimming (clip), project initialization/autopilot rules (init), savings reports (report), and an interactive dashboard (dashboard).
Allows pruning JavaScript source files by removing function and method bodies in favor of stubs while keeping signatures and docstrings intact.
Allows pruning Python source files by stripping function and method bodies into stubs while preserving signatures, type hints, dataclasses, and docstrings for reduced context usage.
Allows pruning TypeScript source files by reducing implementation bodies to stubs while retaining interfaces, signatures, type annotations, and docstrings.
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., "@ContextCutPrune the src folder to stubs and show token savings"
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.
ContextCut MCP Server (v1.3.0 - Polyglot & ROI Analytics)
ContextCut is a local-first, AST-based code context pruner for LLMs and AI coding agents (Claude Desktop, Cursor, Antigravity, Roo Code) via the Model Context Protocol (MCP).
It parses Python and TypeScript/JavaScript files and directories, stripping out internal function and method bodies down to stubs while retaining 100% of signatures, interfaces, type hints, dataclasses, and docstrings.
๐ธ Verified Live in Claude Desktop
TypeScript AST Pruning (48.1% Token Reduction) | Python Architecture Analysis (55.2% Token Reduction) |
Related MCP server: mcp-agent-opt
โก What it Does
# Before ContextCut (~350 tokens of internal loops, regex, and logging):
def process_data(uri: str) -> dict:
"""Loads and normalizes schema."""
if not uri:
raise ValueError("Invalid")
# ... 40 lines of heavy implementation logic ...
return result
# After ContextCut (~35 tokens, 90% reduction):
def process_data(uri: str) -> dict:
"""Loads and normalizes schema."""
passReal-Time Telemetry Header
Every pruned output automatically injects an instant token and cost savings summary:
"""
[ContextCut Telemetry]
----------------------------------------
Files Pruned: 3
Original Size: 14,250 chars (~3,562 tokens)
Pruned Size: 3,810 chars (~952 tokens)
Token Savings: 73.3% reduction (~2,610 tokens saved)
Est. Cost Saved: $0.0078 per prompt (@ $3.00/1M tokens)
----------------------------------------
"""๐ Persistent ROI Analytics & Reporting (New in v1.3.0)
ContextCut automatically records cumulative token and dollar savings to a private, local append-only ledger at ~/.contextcut/history.jsonl.
100% Local & Private: Only anonymous token counts and timestamps are logged. No source code or prompts ever leave your machine.
Quantifiable ROI: Generate aggregated cost-benefit reports on any interval (daily, weekly, monthly, or all-time).
Terminal CLI Report:
# View all-time savings report
node build/index.js report
# View weekly report
node build/index.js report --interval=weekly
# Raw JSON output for custom dashboards
node build/index.js report --interval=monthly --json๐ Visual Interactive Dashboard (Web UI & CLI):
Launch an interactive visual dashboard in your browser to visualize savings over time, track top pruned files, and export executive PDF reports:
# Launch offline visual dashboard in your default browser:
node build/index.js dashboard
# Or when installed via npm:
npx contextcut-mcp dashboardLive Dynamic Sync: Automatically refreshes live as your AI coding agents prune files in real-time.
Executive PDF Export: One-click print-ready formatted report for leadership and CFO reviews.
100% Client-Side Web Viewer: Drag-and-drop your
~/.contextcut/history.jsonlanytime at ๐ 5tra83rstudios.com/viewer (zero telemetry leaves your machine).
๐ Quick Start
โก 1. 1-Click Automated Machine Setup (Zero JSON Editing)
Connect ContextCut to all your installed AI desktop apps in 2 seconds:
# Automatically finds Claude Desktop, Cursor, Antigravity, and Windsurf:
npx contextcut-mcp installโ๏ธ 2. Clipboard Quick-Trimmer (For Web ChatGPT & Gemini)
Using ChatGPT or Gemini in your web browser? Prevent the dreaded 5-hour usage limit lockout:
# 1. Copy bloated code or functions to clipboard (Cmd+C)
# 2. Run the quick-trimmer:
npx contextcut-mcp clip
# 3. Paste trimmed interfaces directly into ChatGPT / Gemini (Cmd+V)!Or trim code 100% online directly in your browser: ๐ 5tra83rstudios.com/viewer/#trimmer
3. Enable Agent Autopilot Mode (Recommended)
Never forget to use ContextCut again. Run this 1-click command inside any project directory:
node /ABSOLUTE/PATH/TO/contextcut-mcp/build/index.js init
# Or when installed via npm:
npx contextcut-mcp initThis automatically writes the Autopilot rule to your .cursorrules and CLAUDE.md:
# ContextCut Agent Autopilot Rule
# -----------------------------------------------------------------------------
# When exploring, surveying, or analyzing code architecture, class definitions,
# or public API interfaces, ALWAYS invoke the `prune_code_context` MCP tool first
# to eliminate token bloat. Only inspect raw, unpruned function bodies if you are
# explicitly modifying the internal implementation of that specific function.
# -----------------------------------------------------------------------------Your agents in Cursor, Claude Desktop, and Antigravity will now automatically route code through ContextCut before analyzing architecture, slashing token consumption on autopilot!
๐ Available Tools, Prompts & Resources
Tool: prune_code_context
target_path: Path to a source file or directory (Python, TypeScript, or JavaScript).code_content: Optional raw code string to prune directly in-memory.language: Optional language hint ("python","typescript", or"javascript").glob_pattern: Optional filter for directory scans (default:*.pyor*.ts).depth:"interfaces_only"(default): Preserves docstrings, signatures, and types."minimal": Strips docstrings for maximum token compression.
Tool: get_savings_report
Generates an aggregated cost-benefit ROI report over a specified interval.
interval:"daily","weekly","monthly", or"all_time"(default:"all_time").format:"markdown"(default) or"json".
Tool: check_license
Validates license tier status (Free Core vs Pro Polyglot).
Prompt: analyze_architecture
Guides your AI agent to inspect a repository's high-level architecture using pruned interface stubs without getting lost in implementation noise.
Resource: contextcut://pruned/{filepath}
Exposes on-demand pruned stubs as native MCP readable resources.
๐งช Testing
Run the automated test suite:
npm test
# Or: python3 -m unittest discover -s tests๐ผ Business & Monetization
See MONETIZATION.md for the complete Go-To-Market roadmap, Lemon Squeezy payment integration, and community registry launch guide.
๐ License
ยฉ 2026 5tra83r Studios. All rights reserved.
Available Tools
3 toolscheck_licenseA
Checks ContextCut license tier status (Free vs Pro).
| Name | Required | Description | Default |
|---|---|---|---|
| license_key | No | Optional explicit license key to validate |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. The verb 'Checks' conveys a read-only operation, which signals non-destructive behavior. It does not detail side effects, auth, or rate limits, which are likely not relevant for this simple status check.
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, front-loaded sentence that states purpose and expected output with 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?
For a tool with one optional parameter and no output schema, the description is sufficient: it specifies the input (via schema) and the semantic output (Free vs Pro). No critical information is missing.
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 fully documents license_key (optional, with description), so the schema provides 100% coverage. The description adds no additional parameter meaning, but 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?
The description states a specific verb ('Checks') and resource ('ContextCut license tier status') and specifies the output categories (Free vs Pro), clearly distinguishing it from sibling tools like prune_code_context and get_savings_report.
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 leaves no ambiguity about when to use this tool โ it is for checking license tier. It doesn't explicitly name alternatives or exclusions, but the purpose is self-evident and siblings are unrelated, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_savings_reportA
Generates an aggregated cost-benefit and token savings ROI report over a specified interval (daily, weekly, monthly, or all_time) based on persistent local history.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format: 'markdown' (default human-readable report) or 'json' (raw structured analytics). | |
| interval | No | Reporting interval: 'daily' (past 24h), 'weekly' (past 7 days), 'monthly' (past 30 days), or 'all_time' (cumulative). Default: 'all_time'. |
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. It says the tool 'Generates' a report based on 'persistent local history', which implies a non-destructive read operation. It does not disclose details like whether the history is automatically updated, whether there are rate limits, or whether the data is cached. The term 'persistent local history' is somewhat ambiguous but provides some transparency that it is a read-only operation.
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 front-loads the core purpose and includes the interval options. It is reasonably concise, though it repeats enum values that are already in the schema. The phrase 'aggregated cost-benefit and token savings ROI' is a bit dense but not verbose.
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 2 parameters, no output schema, and no annotations, so the description must carry the context. It adequately explains what the tool does, the interval choices, and that it relies on local history. It does not explicitly describe the return value, but the format parameter in schema covers that. For a simple reporting tool, this 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 description coverage is 100%, so the baseline is 3. The description mentions the interval parameter and its allowed values, but does not add meaning beyond what the schema already provides (e.g., enum values and their descriptions). It does not mention the format parameter, though that is also fully covered in 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 states a specific verb ('Generates') and resource ('aggregated cost-benefit and token savings ROI report'), and includes the key scoping dimension (interval). It clearly distinguishes this from siblings like prune_code_context and check_license, which are unrelated support 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?
The description implies the tool is for producing savings analytics reports over time, but it does not explicitly state when to use it over alternatives or provide any exclusions. The context is clear enough, but no explicit guidance about when not to use it exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prune_code_contextA
Reads a source file or directory (or raw string) and returns an AST-pruned version containing only signatures, types, interfaces, and docstrings. Replaces function/method bodies with stubs to drastically cut token consumption and latency. Python pruning is free; TypeScript/JavaScript pruning is a Pro feature.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Pruning depth: 'interfaces_only' (preserves docstrings) or 'minimal' (strips docstrings) | |
| language | No | Optional language hint ('python', 'typescript', or 'javascript'). Auto-detected if target_path has an extension. | |
| license_key | No | Optional ContextCut Pro license key (can also be set via CONTEXTCUT_LICENSE_KEY environment variable) | |
| target_path | No | Path to the source file or directory to prune (absolute or relative to current workspace) | |
| code_content | No | Optional raw code string to prune directly in-memory instead of reading from disk | |
| glob_pattern | No | Glob filter for directory scans (default: '*.py' for Python, '*.ts' for TypeScript) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses input modes, the transformation (replacing bodies with stubs), output contents, and the free/Pro licensing boundary. It could mention non-mutation of files or what happens with Pro languages without a license, but it is already substantive.
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?
Three compact sentences: purpose and output, mechanism and benefit, and licensing constraint. Each earns its place and the most important information 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?
Covers the essential context: input modes, output contents, use case, and language-specific licensing. The main remaining gap is what happens when a Pro language is requested without a license key, but overall the description is sufficient 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%, so parameters are already well documented. The description adds minimal extra parameter meaning beyond mapping 'source file or directory (or raw string)' to target_path and code_content. 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?
States a specific verb and result: reads source and returns an AST-pruned version containing signatures, types, interfaces, and docstrings with bodies stubbed. This clearly distinguishes it from sibling tools like check_license and get_savings_report.
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?
Gives clear context for when to use the tool: to reduce token consumption and latency by pruning code. It also adds a conditional constraint (Python free, TypeScript/JavaScript Pro), but it does not explicitly name alternatives or state when not to use it.
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
v1.3.0- First observed
check_license - First observed
get_savings_report - First observed
prune_code_context
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: pruning code, checking license status, and generating savings reports. There is no overlap or ambiguity between them.
Tool names follow a consistent verb_noun pattern (prune_code_context, check_license, get_savings_report). Minor deviation: 'prune_code_context' uses a compound noun while the others use simpler nouns, but the pattern is still predictable.
Three tools is a reasonable, focused set for a utility server with a narrow purpose. It is slightly minimal but each tool serves a distinct function and the scope is appropriately narrow.
The core pruning workflow is covered, and license checking plus reporting support the main use case. However, there is no tool for managing history, configuring pruning options, or handling Pro feature access beyond checking license status, which leaves some minor gaps.
Maintenance
Related MCP Connectors
Codebase graphs, caller impact analysis, and recorded project context for AI coding agents.
Codebase intelligence for AI agents โ dead code, blast radius, ownership.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Related MCP Servers
- FlicenseAqualityDmaintenanceReduces Claude's context window costs by automatically summarizing inactive files to their public interfaces using AST parsing, keeping only the full contents of the currently active file.6-
- AlicenseAqualityCmaintenanceProvides code-aware context compression by stripping comments, docstrings, and whitespace while maintaining full logic fidelity for AI agents. It features tools for architectural mapping, symbol searching, and token-budgeted multi-file reading.94 npm4MIT
- AlicenseBqualityBmaintenanceEnables LLMs to efficiently read, write, and refactor code using precise AST-based operations, reducing token usage and context window waste.2519 npm3MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI coding agents to efficiently analyze codebases by extracting AST skeletons, reducing token usage while preserving type contracts and interfaces.5 npm1MIT