DevProjex turns any folder or codebase into clean, ready-to-use context for AI chats, code reviews, and documentation. Use it as a GUI, a TUI, a CLI, or an MCP server for AI agents — whatever fits your workflow.
Choose what you need in an interactive file tree, check the result in a live preview, then export it as ASCII, Markdown, JSON, or XML. Need more than text? Export a real copy of your project — a clean folder or ZIP file — with the same filters applied.
🔒 Read-only and telemetry-free by design. DevProjex does not upload your project contents or collect telemetry.
Related MCP server: code2prompt
Download from Microsoft Store: 👉 DevProjex
Latest GitHub release: 👉 https://github.com/Avazbek22/DevProjex/releases/latest
Install via WinGet (Windows): winget install OlimoffDev.DevProjex
All install options per OS are covered in Docs/Installation.md.
Copying files into a chat window one by one doesn't scale. CLI tools pack a whole project fast, but you can't see what you're sending before it's sent.
DevProjex works differently — visual, precise, and local-first:
You see what leaves your project — file tree, live preview, token estimate
You control what leaves it — Smart Ignore, Git modes, secret and private-data redaction, name filters, saved profiles
You get more than text — a real project copy as a folder or ZIP
AI assistants — clean input for ChatGPT, Claude, DeepSeek, Qwen, Kimi
AI agents — Claude Code, Cursor, or any MCP client inspects your project through a read-only, always-redacted server
CI pipelines — fail a build when secrets would leak into packed context, without ever printing the values
Restricted environments where AI agents, remote indexing, or IDE plugins aren't allowed
Code reviews — share structure and only the files that matter
Large codebases — pull out one module instead of the whole repo
Teaching — explain a project's architecture to a teammate or student
Open or drop a project folder.
Choose folders, files, filters, ignore rules, and output mode.
Preview, then copy, export, or run the same workflow from the terminal.
Works with any language, repository, or project structure.
Choose and control
Smart Ignore — hides build output, dependency folders, and caches, and checks for evidence before hiding anything. How it works ↓
Hide Secrets — masks detected credential values in everything you export. How it works ↓
Hide private data — optionally masks emails, IPs, MACs, phones, and user paths. How it works ↓
Code compression — keeps declarations and signatures, empties implementation bodies; pure code gets ~3× smaller. How it works ↓
Strip comments and strip blank lines — syntax-aware cleanup across 20 language packs, without modifying source files
File tree with checkboxes, search, and name filters
Git-aware scopes for .gitignore, tracked files, staged files, all current changes, or a ref-to-ref diff
Preview and export
Live preview (tree / content / both) before you copy or export
Scrollbar markers show search matches and redaction findings at a glance
Export as ASCII, Markdown, JSON, or XML
Save to file or clipboard — tree only, content only, or both
Export a clean copy of your project to a folder or ZIP archive
Workflow
GUI, TUI, CLI, and MCP server — the same engine, four ways to work
Git tools built in: clone by URL, switch branches, update cached copies
Local profiles remember your settings per project
Live counters for lines, characters, and estimated tokens
Progress bar with safe cancellation
Interface
Light, dark, and system themes, with transparency and blur where supported
Platform-native keyboard shortcuts — ⌘-based on macOS, Ctrl-based on Windows and Linux
Tree context menu — reveal in the file manager, copy paths or transformed contents, select one item, expand or collapse a branch
Localization in 20 languages
Stays smooth even on very large folders
Feature | DevProjex | Repomix | gitingest | code2prompt | GPTree | files-to-prompt |
GUI + TUI + CLI + MCP — all in one app | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
Built-in MCP server for AI agents | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
Live preview that updates while you select | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
Tracked-files-only Git mode | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
Scope-aware, evidence-based Smart Ignore (monorepo-safe) | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
Value-level secret masking that keeps the file in output | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
Private-data masking (emails, IPs, MAC, phones, user paths) | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
Signature-level code compression | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
CI secret pre-flight gate (fail build on findings) | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
Export a clean project copy as folder/ZIP | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
GUI-managed Git workflow (clone, branch switch, cache updates) | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
Run with no install (npx / uvx / browser) | ❌ | ✅ | ✅ | ❌ | ❌ | ✅ |
Based on publicly documented features, last verified September 2026.
Use File → Export Project → To Folder… or To ZIP Archive… to create a separate copy of your current selection.
Project copies respect your chosen root folders, file types, ignore rules, and checked items. If nothing is checked, the whole current tree is exported. Directory structure, binary files, and included empty folders are preserved.
When Hide Secrets or Hide private data is enabled, detected values in text files are replaced. Binary files remain unchanged. This result is intentionally not a byte-for-byte copy and may not build or run.
The source project is never modified, and the result can't be written inside it. The same workflow is available through devprojex export project.
DevProjex isn't only a desktop context builder. The same app runs from the terminal too, for repeatable, script-friendly project analysis and AI-context export.
devprojex
devprojex open . --preview
devprojex tree .
devprojex tree https://github.com/owner/repo --branch main
devprojex analyze . --format json
devprojex analyze . --hide-secrets --hide-private-data --findings --fail-on-findings
devprojex export context . --format markdown -o ../devprojex-context.md
devprojex export context https://github.com/owner/repo -o -
git diff --name-only | devprojex export context . --select-from - -o -
devprojex export project . --as zip --hide-secrets -o ../devprojex-submission.zip
$ devprojex export project . --as zip -o - > devprojex-submission.zip
devprojex analyze . --git-mode tracked --exclude smart-ignore
devprojex profile save . --hide-secrets on
devprojex cache update https://github.com/owner/repoScriptable exports for CI pipelines — JSON reports, stdout output, deterministic files
Git repository URLs as project sources — analyze, export, open, or start the TUI on a repository straight from its URL through a managed clone cache (devprojex cache, devprojex recent)
A redaction pre-flight for CI — --findings lists rule, category, file, and source line (never the values), and --fail-on-findings fails the pipeline when findings exist
Composable selection — pipe a file list from git diff or any tool into --select-from -
Documented aliases and short flags (export ctx, export proj, -f, -n, -q) plus devprojex help <command> and shell completion for bash, zsh, fish, and PowerShell
A keyboard-first Terminal Workspace for interactive work, no desktop app needed
A searchable Action Palette to find any workflow fast
The same Git filtering, exclusions, and profiles as the desktop app
See Docs/CommandLine.md for the full command reference, and Docs/TerminalWorkspace.md for the interactive terminal interface.
DevProjex ships a built-in secure Model Context Protocol server (on the official C# MCP SDK) that turns any local folder or Git repository into safe, token-efficient codebase context for AI agents — Claude Code, Claude Desktop, Cursor, Windsurf, VS Code, or any MCP client — through the same engine as the GUI, TUI, and CLI:
devprojex mcp --root /path/to/projectFor Claude Code it's one command: claude mcp add devprojex -- devprojex mcp --root .
Seven read-only tools cover the whole workflow: list_projects, get_tree, analyze, search_project, get_file, pack_context, and read_pack. Only pack_context stores oversized context as a session pack; read_pack reads it back in line ranges instead of flooding the agent's context. Long operations report standard MCP progress notifications.
The server enforces hard security boundaries on top of DevProjex's read-only design:
Read-only by design — tools cannot modify project files or run project code; network access is disabled unless --allow-remote is explicitly enabled for Git URL projects
Secret redaction is always on in MCP mode and has no off switch — not in the server flags, not in the tool schemas, so neither a config mistake nor the agent itself can turn it off
Optional private-data masking via devprojex mcp --hide-private-data, mirroring the CLI flag
Root jail — local access is pinned to startup roots; opt-in remote Git URL checkouts are pinned on first use; symlink and junction escapes are rejected
Smart Ignore and the selected Git baseline or scope stay active; agent paths and globs can only narrow the selection
Returned file contents are wrapped in untrusted-data markers to resist prompt injection
The missing off switch is a control guarantee, not a detection guarantee. DevProjex detects common secret formats, but detection is heuristic; review each pack before publishing it outside your environment.
Built for agent efficiency. Trees default to compact markdown, content declares the root once and uses relative paths — no tokens wasted on scaffolding. A max_tokens budget packs the largest files that fit and reports what was included, top_files shows where the tokens go, git_scope narrows get_tree, analyze, pack_context, or search_project to staged files, current changes, or a ref-to-ref diff, and profile switches between built-in defaults, your saved Desktop selections, or a portable profile file.
Want to audit what the agent gets? Open the same project in the GUI: the engine and redaction pipeline are shared, and filters match when the same profile and parameters are used.
Capability | DevProjex | Repomix | Repo Prompt | code2prompt | gitingest |
Cross-platform: Windows + Linux + macOS | ✅ | ✅ | ❌ macOS only | ✅ | ✅ |
MCP server ships built into the app | ✅ | ✅ | ✅ | ⚠️ separate server | ❌ community only |
Secret masking that cannot be disabled | ✅ | ⚠️ optional, drops whole files | ❌ | ❌ | ❌ |
Agent can only narrow the human's selection | ✅ | ❌ | ❌ | ❌ | ❌ |
Root jail with symlink-escape rejection | ✅ | ❌ | ❌ | ❌ | ❌ |
Prompt-injection hardening (untrusted-data wrapping) | ✅ | ❌ | ❌ | ❌ | ❌ |
Git-scoped packing: tracked, staged, changes, ref diff | ✅ | ❌ | ⚠️ diffs in context | ❌ | ❌ |
Token budget for packing | ✅ | ❌ | ✅ | ❌ | ❌ |
Oversized results stored, read back in ranges | ✅ | ✅ | ❌ | ❌ | ❌ |
Remote Git repositories by URL | ✅ opt-in | ✅ | ❌ | ❌ | ✅ |
Based on publicly documented features, last verified September 2026.
See Docs/McpServer.md for client setup, the full tool reference, and the security model.
DevProjex keeps your source projects read-only, with clear limits on what it does:
Does not edit, rename, move, or delete files in the opened source project
Does not commit, merge, push, or switch branches in the source repository opened from the user's filesystem. Branch operations are limited to application-owned cached clones.
Does not include binary file contents in text or AI-context output; redaction rules do not scan binary data
Writes generated files and project copies only to destinations you choose, outside the source project
Smart Ignore is a local, deterministic filter — not an AI model, and not one big blacklist for the whole folder. It knows where each project starts and ends, and applies the right rules only inside that project.
It knows project boundaries. DevProjex finds project markers like .csproj, package.json, pyproject.toml, go.mod, or Cargo.toml. Rules for that stack (node_modules, bin/obj, virtual environments, build caches) apply only inside the project that owns them. A .NET service won't hide bin in an unrelated folder next to it, and a frontend app won't hide node_modules somewhere it doesn't belong.
It checks before it hides anything. Folder names like build, dist, or vendor can mean generated files — or real source code. Smart Ignore looks for real signs first: package files, compiler output, known build layouts. If there's no clear sign, the folder stays visible.
It keeps monorepos separate. Each nested project — frontend, backend, tools, docs — is filtered on its own, based on its own markers. Nothing crosses over between unrelated parts of your workspace.
Git modes — a separate setting, not part of Smart Ignore:
Mode | What it shows |
| Tracked files, plus untracked files not excluded by |
Tracked-files-only | Only files currently recorded in the Git index |
Staged | Files with staged changes |
Changes | Staged, unstaged, and non-ignored untracked files |
Diff | Files changed between two Git references |
You stay in control. Smart Ignore, the Git mode, and basic filters (hidden files, dot-files, empty folders) all work together and can be turned on or off one by one. "Ignored" means excluded from the current view, copy, or export — it never deletes anything from your project.
📖 Full technical details — signature matching, worktree handling, edge cases — are in Docs/SmartIgnore.md.
An AI rarely needs every implementation line — it needs the shape of your code. Compression keeps declarations, signatures, fields, and class structure, and empties named implementation bodies:
// Before — what's in your file (unchanged on disk)
private Command BuildMcpCommand()
{
var command = new Command("mcp", L("Terminal.Command.Mcp"));
// … ~40 more lines of implementation
}
// After — what goes into the packed context
private Command BuildMcpCommand()
{ }Measured on DevProjex's own C# sources (619 files), the packed context shrinks from 5.4 MB to 1.7 MB — a 69% cut, roughly 3× smaller. On a mixed repository the saving is lower, because compression only touches code, never test fixtures, JSON assets, or documentation.
It covers 14 languages, parsing with Tree-sitter grammars and applying DevProjex's own per-language rules about what must survive (properties in Kotlin, val/var in Scala, free lambdas everywhere), and it is deliberately conservative: a file it can't process safely stays complete. Comment and blank-line stripping extend the same syntax engine to 20 packs in total — the 14 plus six comments-only packs such as HTML, CSS, YAML, and XML project files. The same transformed content feeds token metrics, context documents, and folder/ZIP exports, in the GUI and via --compress-code in the CLI.
📖 Per-language rules and edge cases are in Docs/CodeCompression.md.
Two independent layers. Both replace values inside the output — they never delete a file and never modify your project.
Hide Secrets finds credential values — API keys, tokens, connection strings — and masks each one where it stands, keeping the file and all surrounding code:
var botToken = "110201543:AAHdqTcvE…"; // in your file
var botToken = "DEVPROJEX_REDACTED[telegram-bot-api-token#1]"; // in the exportDetection runs a pinned, reviewed Gitleaks rule set on DevProjex's own engine, and one secret never costs you the whole file. Findings are marked on the Preview scrollbar, and a false positive can be excluded per match right in Preview. You enable it with one switch in the GUI or --hide-secrets in the CLI; in MCP mode it is forced on with no off switch. For pipelines, --findings prints rule, file, and line — never the value — and --fail-on-findings fails the build.
Hide private data is the second, optional layer for personal traces: emails, global IPs, local-user paths, MAC addresses, and international phone numbers become DEVPROJEX_REDACTED[email#1], [ipv4#1], [local-user#1], and so on — the same placeholder for the same finding on every surface, so exported code stays consistent. It is off by default: real projects are full of version strings that look like IPs and sample emails that are not personal. Turn it on per profile in the GUI, or with --hide-private-data in the CLI and MCP.
📖 Detection rules and edge cases: Docs/HideSecrets.md · Docs/HidePrivateData.md
Installation · Smart Ignore · Hide Secrets · Hide private data · Code Compression · Command Line · Terminal Workspace · MCP Server · Contributing · Code of Conduct
.NET 10
Avalonia UI (cross-platform)
Tree-sitter parsing · Gitleaks rule source · official MCP C# SDK — attributions in THIRD-PARTY-NOTICES.md
Clean Architecture layers (Kernel / Application / Infrastructure / Terminal / Avalonia)
JSON-based resources (localization, icon mappings, presets)
17,000+ automated tests (unit + integration + terminal + UI), run on Windows, Linux, and macOS
Build from source
git clone https://github.com/Avazbek22/DevProjex.git
cd DevProjex
dotnet build -c Release
dotnet testIssues and pull requests are welcome. Good places to start: UX, performance tuning, tests, localization, documentation & screenshots. Not sure where? Check issues labeled good first issue.
See CONTRIBUTING.md for details.
DevProjex is licensed under the Apache License 2.0 — free to use, modify, and distribute, with an explicit patent grant. Copyright (c) 2025–present Avazbek Olimov. See LICENSE for details.
Measure a redacted project selection and list its largest text files by estimated tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | No | Existing project-relative files or directories that narrow the selection. | |
| branch | No | Optional Git branch for a remote project URL; invalid for local project paths. | |
| detail | No | Collapse code to signatures or strip comments/blank lines to fit large projects into a budget; unsupported languages are returned unchanged. | full |
| profile | No | Selection profile: 'standard', 'local', or a portable profile JSON path inside the project root. | |
| project | No | Absolute root path returned by list_projects, or a Git URL when the server allows remote sources. Optional only when one local root is configured. | |
| git_scope | No | Further restrict results to staged files, all current changes, or files changed between two Git refs. | |
| top_files | No | Number of largest text files to return by estimated tokens; default 10; integer or numeric string. | |
| tracked_only | No | Restrict results to files tracked by Git; accepts a boolean or the string 'true' or 'false'. | |
| max_file_bytes | No | Exclude otherwise selected files strictly larger than this byte count; integer or numeric string. | |
| exclude_patterns | No | Project-relative glob patterns using '/' to exclude additional paths. | |
| include_patterns | No | Project-relative glob patterns using '/'. They only narrow built-in and gitignore filtering. |
| Name | Required | Description |
|---|---|---|
| files | Yes | |
| detail | Yes | |
| tokens | Yes | |
| topFiles | Yes | |
| characters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the behavioral detail that it 'measures' a 'redacted project selection' and lists largest text files by estimated tokens, which is useful beyond the annotations. However, it does not disclose details like whether results are returned as a list or a package, how 'redacted' affects results, or whether remote URLs are allowed despite the parameter description mentioning them.
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 one tight sentence that states the core outcome without padding or repetition. It earns its place by adding the 'redacted project selection' constraint and 'largest text files by estimated tokens' outcome, which are not fully visible in the schema.
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 11 optional parameters and rich annotations, the description could still explain how analyze relates to pack_context or list_projects, and what 'redacted' means in practice. An output schema exists, so return values are partly covered, but the meaning of selection scoping and the use of the project parameter are not sufficiently clarified. Still, with all parameters documented and safety annotations present, the definition is mostly complete for a capable agent.
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 itself adds almost no parameter-level meaning beyond what the schema already provides, and it doesn't clarify how the complex fields like git_scope, include_patterns, or exclude_patterns interact. The description is not misleading, but it does not compensate for the interpretive burden of 11 optional parameters.
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 says 'Measure a redacted project selection and list its largest text files by estimated tokens,' which states a specific action and result, but it doesn't fully distinguish how this differs from sibling tools like search_project or get_tree. 'Redacted project selection' is an unusual term and the intended scope isn't immediately obvious without looking at parameters.
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 for measuring and listing large files, but it does not explicitly state when to choose analyze over siblings like pack_context or search_project. The mention of 'redacted project selection' suggests a scoping behavior, but no exclusions or alternatives are named. This is still clearer than nothing but leaves the tool-selection decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read redacted text from one effective project file using an optional 1-based line range.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Existing file path inside the effective project selection. | |
| branch | No | Optional Git branch for a remote project URL; invalid for local project paths. | |
| project | No | Absolute root path returned by list_projects, or a Git URL when the server allows remote sources. Optional only when one local root is configured. | |
| end_line | No | Last 1-based line, inclusive; integer or numeric string. | |
| start_line | No | First 1-based line; integer or numeric string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint). The description adds meaningful context: output is 'redacted text' and the file must be in the 'effective project selection', plus line-range scoping. This goes beyond annotated facts and helps set expectations.
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, tightly packed sentence that front-loads the verb and resource. Every phrase adds value: 'redacted text', 'effective project file', and 'optional 1-based line range'. No filler or repetition.
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 annotations cover safety and the schema covers all parameter semantics, the description completes the picture with the redaction behavior and scope. It does not explain error cases or 'effective project' meaning, but for a simple read tool this is a minor gap. Overall it is sufficiently complete 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 all five parameters are already documented with types and constraints. The description only summarizes the optional line-range parameters (start_line/end_line) and does not add any new semantic detail beyond what the schema provides. 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 uses a specific verb ('Read'), a clear resource ('one effective project file'), and a scoping detail (optional 1-based line range). It distinguishes itself from sibling tools like get_tree (directory structure) and search_project (search), making it clear this is the tool to read file contents.
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 guidance is given for when to use get_file versus alternatives. The description does not mention any sibling tools or conditions that would favor get_file over get_tree, search_project, or pack_context. Usage is only implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the effective project tree after built-in, gitignore, profile, and optional agent glob filters.
| Name | Required | Description | Default |
|---|---|---|---|
| branch | No | Optional Git branch for a remote project URL; invalid for local project paths. | |
| format | No | Tree representation. Markdown is the compact default; text uses drawing characters, while JSON and XML are structured. | markdown |
| project | No | Absolute root path returned by list_projects, or a Git URL when the server allows remote sources. Optional only when one local root is configured. | |
| git_scope | No | Further restrict results to staged files, all current changes, or files changed between two Git refs. | |
| max_depth | No | Maximum tree depth from 0 to 1000; accepts an integer or numeric string. | |
| tracked_only | No | Restrict results to files tracked by Git; accepts a boolean or the string 'true' or 'false'. | |
| max_file_bytes | No | Exclude otherwise selected files strictly larger than this byte count; integer or numeric string. | |
| exclude_patterns | No | Project-relative glob patterns using '/' to exclude additional paths. | |
| include_patterns | No | Project-relative glob patterns using '/'. They only narrow built-in and gitignore filtering. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds valuable context by disclosing that output is the 'effective' tree after built-in, gitignore, profile, and optional glob filters, which is not inferable from annotations alone. It is consistent with annotations.
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 sentence, front-loaded with the core action and resource, then the filter stages. No filler or repetition of schema content.
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 high-complexity tool with 9 optional parameters, the description gives enough high-level context (effective tree, filter pipeline) while leaving per-parameter details to the complete schema. It doesn't address all edge cases like project resolution or remote sources, but schema coverage and annotations cover most operational constraints; the lack of an output schema is partially mitigated by the strong parameter documentation.
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 schema documents every parameter. The description's mention of 'optional agent glob filters' adds a conceptual frame for include_patterns and exclude_patterns, but it doesn't detail individual parameters; 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 states a specific verb (Return) and resource (effective project tree), and explains the filtering pipeline. It does not explicitly distinguish get_tree from siblings such as get_file or search_project, but the object type (tree) makes the primary purpose clear.
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 retrieving a filtered project tree, which is a common exploration need, but it does not state when to prefer it over siblings like pack_context or search_project, nor any exclusions. There is no explicit alternative routing, so an agent must infer usage from the name and role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the project roots this server is allowed to read and their saved local profiles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| profiles | Yes | |
| projects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), lowering the bar. The description adds modest context by disclosing that results are restricted to project roots the server is allowed to read and that saved local profiles are included. It adds some value but not rich behavioral context; it does not contradict the annotations.
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, tightly worded sentence with zero filler — the action, the resource scope, the read restriction, and the profile payload each earn their place. The core action is front-loaded before the qualifiers.
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 zero-parameter list operation backed by a complete annotation set (read-only, idempotent, non-destructive) and an existing output schema, the description is fully adequate. Return-value details are appropriately delegated to the output schema. The only implicit element — how this feeds into sibling tools — belongs to the usage-guidelines dimension.
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 tool takes zero parameters and schema description coverage is 100% vacuously. With 0 params, the baseline is 4 and there is nothing for the description to explain about arguments. No compensation 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 uses a specific verb ('List') and names a concrete resource ('project roots... and their saved local profiles'), while adding a useful scoping qualifier ('this server is allowed to read'). This clearly differentiates it from the file/tree-level siblings (get_tree, get_file, search_project), so an agent can tell this is about enumerating projects rather than navigating their contents.
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 a discovery use case — enumerate which projects are available — but never states when to prefer it over siblings or names an alternative. An agent must infer that listing project roots is the natural precursor to project-scoped calls like get_tree, get_file, or search_project. No explicit exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build an exact redacted DevProjex context export. A stored pack id remains valid until this server process exits; after restart, call pack_context again.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | tree-content | |
| paths | No | Existing project-relative files or directories that narrow the selection. | |
| branch | No | Optional Git branch for a remote project URL; invalid for local project paths. | |
| detail | No | Collapse code to signatures or strip comments/blank lines to fit large projects into a budget; unsupported languages are returned unchanged. | full |
| format | No | markdown | |
| profile | No | Selection profile: 'standard', 'local', or a portable profile JSON path inside the project root. | |
| project | No | Absolute root path returned by list_projects, or a Git URL when the server allows remote sources. Optional only when one local root is configured. | |
| git_scope | No | Further restrict results to staged files, all current changes, or files changed between two Git refs. | |
| max_tokens | No | Maximum estimated content tokens to include; accepts an integer or numeric string. Document structure is outside this budget. | |
| tracked_only | No | Restrict results to files tracked by Git; accepts a boolean or the string 'true' or 'false'. | |
| max_file_bytes | No | Exclude otherwise selected files strictly larger than this byte count; integer or numeric string. | |
| exclude_patterns | No | Project-relative glob patterns using '/' to exclude additional paths. | |
| include_patterns | No | Project-relative glob patterns using '/'. They only narrow built-in and gitignore filtering. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag readOnlyHint=true and destructiveHint=false. The description adds the non-obvious behavior that a stored pack id is tied to the server process lifetime and becomes invalid on restart, which is valuable for an agent. It also implies a pack is stored in memory without contradicting the read-only annotation.
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?
Exactly two sentences. The first is a terse verb+object opening, and the second captures a critical lifetime constraint. Every word earns its place with no filler.
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 13 optional parameters and no output schema, an agent needs more orientation than this description provides. It never explicitly says the tool returns a pack id (only implies it), gives no example call shape, and does not explain what 'redacted' means for selection. The lifetime hint is useful, but the overall context is thin for such a complex tool.
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 85%, so the input schema already documents most parameters. The tool description adds no parameter-level meaning, such as which parameters are needed or how they interact, so it neither compensates for nor detracts from the schema's coverage.
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 opening sentence states a specific action ('Build an exact redacted DevProjex context export') with a clear resource, and the name pack_context helps distinguish it from siblings like read_pack and get_tree. However, it does not explicitly differentiate from those tools, and 'DevProjex context export' leaves some meaning implicit.
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 gives one explicit usage signal: pack ids expire at process exit, so call pack_context again after restart. It does not, however, state when to prefer pack_context over read_pack, get_tree, or search_project, so guidance beyond the lifetime rule is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a 1-based line range from a pack created by this server session.
| Name | Required | Description | Default |
|---|---|---|---|
| pack_id | Yes | Session-scoped id returned by pack_context. | |
| end_line | No | Last 1-based line, inclusive; integer or numeric string. | |
| start_line | No | First 1-based line; integer or numeric string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context: lines are 1-based and the pack is session-scoped, which prevents an agent from attempting to read arbitrary or stale packs.
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, information-dense sentence with no filler. The most important scoping facts—1-based line range and session-created pack—are 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 read operation with full schema coverage and strong annotations, the description is sufficiently complete. It could mention return format or error behavior, but these are not critical for an agent to select and invoke the tool 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 100%, so pack_id, start_line, and end_line are already well documented with types, constraints, and the integer-or-string alternatives. The description adds no parameter-specific semantics beyond this, so the baseline of 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 clear verb ('Read'), a specific resource ('a pack created by this server session'), and a precise scope ('1-based line range'). This distinguishes it from sibling tools like pack_context, which creates packs, and get_file, which reads files.
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 when to use it: after a pack has been created by the current session, and the parameter schema reinforces this by noting pack_id is 'returned by pack_context'. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search already-redacted project text with a timeout-bounded .NET regular expression.
| Name | Required | Description | Default |
|---|---|---|---|
| branch | No | Optional Git branch for a remote project URL; invalid for local project paths. | |
| pattern | Yes | A .NET regular expression evaluated against redacted text with a 2-second timeout. | |
| project | No | Absolute root path returned by list_projects, or a Git URL when the server allows remote sources. Optional only when one local root is configured. | |
| git_scope | No | Further restrict results to staged files, all current changes, or files changed between two Git refs. | |
| ignore_case | No | Case-insensitive matching; accepts a boolean or the string 'true' or 'false'. | |
| max_results | No | Maximum matches from 1 to 200; default 50; integer or numeric string. | |
| tracked_only | No | Restrict results to files tracked by Git; accepts a boolean or the string 'true' or 'false'. | |
| context_lines | No | Context lines from 0 to 20; default 2; integer or numeric string. | |
| max_file_bytes | No | Exclude otherwise selected files strictly larger than this byte count; integer or numeric string. | |
| exclude_patterns | No | Project-relative glob patterns using '/' to exclude additional paths. | |
| include_patterns | No | Project-relative glob patterns using '/'. They only narrow built-in and gitignore filtering. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context about the timeout-bounded nature of the search and that the text is already redacted, which are not covered by annotations. This extra detail about execution limits and data state earns a score above baseline.
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, compact sentence that conveys the core function (search), the input (project text), the mechanism (regex), and a key constraint (timeout). No unnecessary words or repetition.
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 description does not specify the output format or the exact nature of the results (e.g., matches with line numbers, file paths, or context snippets). Since there is no output schema, the description leaves the agent guessing about the return structure. It is adequate for basic usage but incomplete for full operational 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?
All 11 parameters have thorough schema descriptions covering types, defaults, and constraints (e.g., pattern length, range for max_results, glob patterns). Since schema coverage is 100% and the description adds no additional parameter context, the 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 clearly states the tool performs a search over project text using a .NET regular expression, and it is distinct from sibling tools like get_file or list_projects. However, it does not explicitly differentiate itself from other search-like tools or mention the scope of the search (e.g., all files vs. tracked files), so a small deduction applies.
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 gives no explicit guidance on when to prefer this tool over alternatives such as get_file, pack_context, or analyze. The use case is implied by the name and description, but the instructions for selecting this tool over a sibling are missing.
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.
v5.1.0analyzeget_fileget_treelist_projectspack_contextread_packsearch_projectScored across 7 tools
Each tool targets a distinct operation: listing projects, viewing trees, reading files, building/reading packs, regex searching, and analyzing sizes. read_pack and get_file are similar in mechanics but clearly separated by pack vs. individual file scope.
Most names follow a clear verb_noun pattern (list_projects, get_tree, pack_context, read_pack, search_project, get_file). The single outlier is 'analyze', which would be more consistent as something like analyze_project.
Seven tools is well-scoped for a project context and redaction server. Each tool has a clear role with no obvious redundancy or bloat.
The set covers the main workflow: discover projects, inspect tree/files, search, build a pack, and read pack contents. Minor gaps exist, such as no pack-specific search or profile management, but agents can work around them.
An MCP server that gives your AI access to the source code and docs of all public github repos
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Turn a GitHub repo or docs site into agent-ready context: pack it or search it, over MCP.
Read-only MCP server exposing a user ORANO library to their own AI agent.
