Gemini Researcher is a lightweight, stateless MCP server that offloads deep codebase analysis to Gemini CLI, reducing agent context usage while providing structured JSON insights into local projects.
Key Capabilities:
Quick code queries (quick_query) - Fast analysis of specific files or code sections using Gemini's flash model with adjustable verbosity (concise/normal/detailed)
Deep research (deep_research) - Comprehensive multi-file analysis for architectural reviews, security audits, and cross-file investigations using Gemini's pro model
Directory structure mapping (analyze_directory) - Enumerate and understand project organization, file purposes, and module relationships with configurable depth and file limits
Path validation (validate_paths) - Pre-verify file accessibility within the project root before running expensive queries
Health diagnostics (health_check) - Check server status, Gemini CLI installation, authentication, and configuration to troubleshoot issues
Large response handling (fetch_chunk) - Automatically chunks responses over ~10KB with 1-hour caching for continuation retrieval
Context-aware analysis - All queries support focus areas (security, architecture, performance, general) to guide targeted insights
Token efficiency - Analyzes files directly from disk using @path references instead of consuming the agent's context window
Read-only safety - Stateless server that only reads files, never modifies them
Cross-client compatibility - Works with Claude Code, Cursor, VS Code (GitHub Copilot), and other MCP clients
Docker deployment - Run as a containerized service with project mounting and environment configuration
Delegates deep repository analysis and codebase research to Google's Gemini models via the Gemini CLI, enabling architectural reviews and multi-file analysis using large context windows.
A lightweight, stateless MCP (Model Context Protocol) server that lets developer agents (Claude Code, GitHub Copilot) hand off deep repository analysis to the Gemini CLI. The server is read-only, returns structured JSON (as text content), and is designed to reduce the calling agent's context and model usage.
Status: v1 complete. Core features are stable, but still early days. Feedback welcome!
If this saved you tokens, ⭐ please consider giving it a star! :)
The primary goals:
Reduce agent context usage by letting Gemini CLI read large codebases locally and do its own research
Reduce calling-agent model usage by offloading heavy analysis to Gemini
Keep the server stateless and read-only for safety
Why use this?
Instead of copying entire files into your agent's context (burning tokens and cluttering the conversation), this server lets Gemini CLI read files directly from your project. Your agent sends a research query, Gemini reads and synthesizes using its large context window, and returns structured results. You save tokens, your agent stays focused, and complex codebase analysis becomes practical.
Verified clients: Claude Code, Cursor, VS Code (GitHub Copilot)
It definitely works with other clients, but I haven't personally tested them yet. Please open an issue if you try it elsewhere!
Table of contents
Gemini Researcher accepts queries from your AI agent and uses Gemini CLI to analyze your local code files. Results are returned as formatted JSON for your agent to use.
The server runs Gemini CLI with safety restrictions enabled. See docs/runtime-contract.md for full technical details.
Default invocation pattern:
gemini [ -m <model> ] --output-format json --approval-mode default [--admin-policy <path>] -p "<prompt>"Key safety points:
Uses --approval-mode default (not yolo mode) for controlled execution
Enforces read-only policy by default to prevent file changes
Policy blocks mutating tools like write_file, replace, run_shell_command
Strict enforcement can be disabled with GEMINI_RESEARCHER_ENFORCE_ADMIN_POLICY=0 (not recommended)
Run health_check with includeDiagnostics: true to see auth status and server health.
authStatus | What it means | Impact |
| Gemini CLI is authenticated | Server ready to use |
| No valid authentication found | Server marked as degraded |
| Could not verify auth status | Server marked as degraded |
health_check.status values:
ok: Gemini CLI is available, auth is working, and safety policy is enforced
degraded: Setup incomplete, auth unclear, or safety policy disabled
Related MCP server: Codex MCP Server
Node.js 18+ installed
Gemini CLI installed: npm install -g @google/gemini-cli
Gemini CLI authenticated (recommended: gemini → Login with Google) or set GEMINI_API_KEY
Quick checks:
node --version
gemini --versionRun the setup wizard to verify Gemini CLI is installed and authenticated:
npx gemini-researcher initStandard config works in most of the tools:
{
"mcpServers": {
"gemini-researcher": {
"command": "npx",
"args": [
"gemini-researcher"
]
}
}
}On native Windows, some MCP hosts use shell-less process spawning and may not resolve npm command shims reliably (npx, gemini).
If startup fails with launch errors (spawn ... ENOENT / GEMINI_CLI_LAUNCH_FAILED despite working in PowerShell), prefer Docker or WSL for immediate reliability.
See the full remediation tree in docs/platforms/windows.md.
Add to your VS Code MCP settings (create .vscode/mcp.json if needed):
{
"servers": {
"gemini-researcher": {
"command": "npx",
"args": [
"gemini-researcher"
]
}
}
}Option 1: Command line (recommended)
Local (user-wide) scope
# Add the MCP server via CLI
claude mcp add --transport stdio gemini-researcher -- npx gemini-researcher
# Verify it was added
claude mcp listProject scope
Navigate to your project directory, then run:
# Add the MCP server via CLI
claude mcp add --scope project --transport stdio gemini-researcher -- npx gemini-researcher
# Verify it was added
claude mcp listOption 2: Manual configuration
Add to .mcp.json in your project root (project scope):
{
"mcpServers": {
"gemini-researcher": {
"command": "npx",
"args": [
"gemini-researcher"
]
}
}
}Or add to ~/.claude/settings.json for local scope.
After adding the server, restart Claude Code and use /mcp to verify the connection.
Go to Cursor Settings -> Tools & MCP -> Add a Custom MCP Server. Add the following configuration:
{
"mcpServers": {
"gemini-researcher": {
"type": "stdio",
"command": "npx",
"args": [
"gemini-researcher"
]
}
}
}The server automatically uses the directory where the IDE opened your workspace as the project root or where your terminal is. To analyze a different directory, optionally setPROJECT_ROOT:
Example
{
"mcpServers": {
"gemini-researcher": {
"command": "npx",
"args": [
"gemini-researcher"
],
"env": {
"PROJECT_ROOT": "/path/to/your/project"
}
}
}
}Ask your agent: "Use gemini-researcher to analyze the project."
All tools return structured JSON (as MCP text content). Large responses are chunked (~10KB per chunk) and cached for 1 hour.
Tool | Purpose | When to use |
| Fast analysis with flash model | Quick questions about specific files or small code sections |
| In-depth analysis with pro model | Complex multi-file analysis, architecture reviews, security audits |
| Map directory structure | Understanding unfamiliar codebases, generating project overviews |
| Pre-check file paths | Verify files exist before running expensive queries |
| Diagnostics | Troubleshooting server/Gemini CLI issues |
| Get chunked responses | Retrieve remaining parts of large responses |
Query tool fallback chains are family-aware:
quick_query: flash -> flash_lite -> auto
deep_research: pro -> flash -> flash_lite -> auto
analyze_directory: flash -> flash_lite -> auto
When using API-key auth, fallback also handles model-unavailable/unsupported errors (not only quota/capacity errors).
Understanding a security vulnerability:
Agent: Use deep_research to analyze authentication flow across @src/auth and @src/middleware, focusing on securityQuick code explanation:
Agent: Use quick_query to explain the login flow in @src/auth.ts, be conciseMapping an unfamiliar codebase:
Agent: Use analyze_directory on src/ with depth 3 to understand the project structurequick_query
{
"prompt": "Explain @src/auth.ts login flow",
"focus": "security",
"responseStyle": "concise"
}deep_research
{
"prompt": "Analyze authentication across @src/auth and @src/middleware",
"focus": "architecture",
"citationMode": "paths_only"
}analyze_directory
{
"path": "src",
"depth": 3,
"maxFiles": 200
}validate_paths
{
"paths": ["src/auth.ts", "README.md"]
}health_check
{
"includeDiagnostics": true
}fetch_chunk
{
"cacheKey": "cache_abc123",
"chunkIndex": 2
}A pre-built multi-platform Docker image is available on Docker Hub:
# Pull the image (works on Intel/AMD and Apple Silicon)
docker pull capybearista/gemini-researcher:latest
# Run the server (mount your project and provide API key)
docker run -i --rm \
-e GEMINI_API_KEY="your-api-key" \
-v /path/to/your/project:/workspace \
capybearista/gemini-researcher:latestFor MCP client configuration with Docker:
{
"mcpServers": {
"gemini-researcher": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "GEMINI_API_KEY",
"-v", "/path/to/your/project:/workspace",
"capybearista/gemini-researcher:latest"
],
"env": {
"GEMINI_API_KEY": "your-api-key-here"
}
}
}
}The -i flag is required for stdio transport
The container mounts your project to /workspace (the project root)
Replace /path/to/your/project with your actual project path
Replace your-api-key with your actual Gemini API key (this is required for Docker usage)
Native Windows launch model and remediation: docs/platforms/windows.md
Remediation decision tree:
Error / signal | Run this check first | Change this configuration next |
|
| Prefer Docker or WSL config. If staying native, point host command to a stable shim/binary path and restart host. |
| Run | Update host config to launch the reported |
MCP host cannot launch server via |
| Change host server command from |
|
| Upgrade Gemini CLI to v0.36.0+ |
|
| Authenticate Gemini CLI or set |
GEMINI_CLI_NOT_FOUND: Install Gemini CLI: npm install -g @google/gemini-cli
GEMINI_CLI_LAUNCH_FAILED: This is a launch-path issue, not an auth/capability issue. On Windows, command shims can fail in shell-less spawn contexts. Validate gemini --help and npx --version interactively, then prefer Docker or WSL if host launch mode is strict.
GEMINI_RESEARCHER_GEMINI_COMMAND: Override the Gemini command name/path used by the server (for wrappers or pinned binary locations).
GEMINI_RESEARCHER_GEMINI_ARGS_PREFIX: Prefix extra Gemini args for every invocation (for example --config <file>).
health_check diagnostics redact sensitive token-like values in configured args prefix output.
AUTH_MISSING: Run gemini, and authenticate or set GEMINI_API_KEY
AUTH_UNKNOWN: Auth could not be confirmed (often network/CLI probe failure). If launch errors are present, fix launch-path first; otherwise verify gemini works interactively, then retry.
ADMIN_POLICY_MISSING: Reinstall package or verify policies/read-only-enforcement.toml exists in installed package.
ADMIN_POLICY_UNSUPPORTED: Upgrade Gemini CLI to v0.36.0+ (gemini --help should include --admin-policy).
Capability errors (ADMIN_POLICY_UNSUPPORTED, output format unsupported) should be interpreted only after a successful gemini --help probe. If probe launch fails, treat it as launch-path failure first.
GEMINI_RESEARCHER_ENFORCE_ADMIN_POLICY=0: Disables strict startup policy checks. This reduces safety guarantees.
.gitignore blocking files: Gemini respects .gitignore by default; toggle fileFiltering.respectGitIgnore in gemini /settings if you intentionally want ignored files included (note: this changes Gemini behavior globally)
PATH_NOT_ALLOWED: All @path references must resolve inside the configured project root (process.cwd() by default). Use validate_paths to pre-check paths.
QUOTA_EXCEEDED: Server retries with fallback models; if all options are exhausted, reduce scope (use quick_query) or wait for quota reset.
Read the Contributing Guide to get started.
Quick links:
Map repository structure and understand what each file/module does. Preferred when questions ask about project organization or 'what's in this directory'. Example: {path: './src', depth: 3, maxFiles: 100}
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Relative or absolute path to directory | |
| depth | No | Maximum traversal depth (default: unlimited) | |
| maxFiles | No | Maximum files to enumerate (default: 500) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It only states purpose and parameters, not side effects, performance implications, or whether it reads file contents. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a relevant example. No fluff, front-loaded with purpose.
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?
No output schema, and description does not specify return format (e.g., list of files with summaries). The phrase 'understand what each file/module does' is vague. Missing critical detail for agent to interpret results.
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 covers all parameters (100% coverage). Description adds an example with typical values, providing practical context beyond the schema definitions.
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 maps repository structure and understands files/modules. It distinguishes from siblings like deep_research or quick_query by focusing on project organization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Preferred when questions ask about project organization or what's in this directory' and provides an example. No explicit alternative guidance, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform comprehensive codebase analysis across multiple files with deep reasoning. Preferred for complex architectural questions or multi-file investigation. Example: {prompt: 'Trace authentication flow from @src/routes to @src/middleware', focus: 'architecture', citationMode: 'paths_only'}
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Complex research question or analysis request | |
| focus | No | Optional focus area to guide analysis | |
| citationMode | No | Include file citations in response | none |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It explains the tool performs deep reasoning across multiple files but does not mention side effects, auth needs, or performance implications. The example gives some insight into usage but lacks comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences and an example. The purpose is front-loaded, and every element serves a clear function 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?
Given the tool's complexity and the fact that there is no output schema, the description covers the main aspects: what it does, when to use it, and how to use it via the example. It could be improved by mentioning any limitations or typical use cases, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds value by providing a concrete example that demonstrates how to use the parameters, especially the prompt and focus/citationMode options, which goes beyond the schema definitions.
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 comprehensive codebase analysis with deep reasoning, and it distinguishes itself from siblings by specifying it is preferred for complex architectural questions or multi-file investigation. The example further solidifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('complex architectural questions or multi-file investigation'), providing clear context. However, it does not mention when not to use it or suggest alternatives, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve continuation of a large response. Use when a previous tool response included 'chunks' metadata indicating more content available. Example: {cacheKey: 'cache_abc123', chunkIndex: 2}
| Name | Required | Description | Default |
|---|---|---|---|
| cacheKey | Yes | Cache key returned in initial chunked response | |
| chunkIndex | Yes | 1-based index of chunk to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation ('retrieve') and provides an example, but does not explicitly state that it is non-destructive, any side effects, rate limits, or error conditions. The example helps but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences and an example, front-loaded with purpose, followed by usage guidance. Every element is relevant and concise without 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?
For a simple retrieval tool with two params and no output schema, the description explains what it does and when to use it, but does not describe the response format or error handling. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds an example showing how cacheKey and chunkIndex relate, but the schema descriptions already cover their meaning. The example adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('retrieve'), the resource ('continuation of a large response'), and the context (when 'chunks' metadata is present). It distinguishes from siblings like analyze_directory and deep_research by focusing on paginated retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: 'Use when a previous tool response included 'chunks' metadata indicating more content available.' It does not mention when not to use it or alternatives, but the guidance is clear and context-specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify server status and Gemini CLI configuration. Use for troubleshooting connection issues or confirming setup. Example: {includeDiagnostics: true}
| Name | Required | Description | Default |
|---|---|---|---|
| includeDiagnostics | No | Include detailed diagnostics (Gemini CLI version, auth status, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries burden. It notes diagnostics inclusion but lacks info on error behavior or expected output format. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences plus an example, no fluff. Front-loaded with the main action.
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 one-param tool with no output schema, the description covers the main use case. Could mention return format but not necessary for basic functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds an example JSON with includeDiagnostics: true, which provides practical guidance beyond the schema's field description.
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 verifies server status and Gemini CLI configuration, using strong verbs 'Verify' and 'troubleshooting'. It distinguishes from siblings like analyze_directory and deep_research which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for troubleshooting connection issues or confirming setup. While no when-not is given, the context is clear and the tool name reinforces usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze code/files quickly using Gemini's large context window. Preferred when questions mention specific files or require reading repository code. Example: {prompt: 'Explain @src/auth.ts security approach', focus: 'security', responseStyle: 'concise'}
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Research question or analysis request | |
| focus | No | Optional focus area to guide analysis | |
| responseStyle | No | Desired verbosity of response | normal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks detailed behavioral traits such as rate limits, side effects, or limitations of the large context window.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus an example, no redundant information, and the key 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?
Adequately covers purpose, usage guidance, and parameter semantics given the absence of an output schema; could include more behavioral details but sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters; the description adds an example showing parameter usage, enhancing semantic understanding 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?
Clearly states the tool analyzes code/files quickly using Gemini's large context window, and distinguishes itself by specifying it's preferred for specific file or repository code questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to prefer this tool (questions mentioning specific files or requiring repository code), providing useful context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify file paths exist and are accessible before analysis. Use when uncertain about path correctness or troubleshooting 'PATH_NOT_ALLOWED' errors. Example: {paths: ['src/auth.ts', 'config/database.js', '../README.md']}
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | Array of paths to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states 'Verify file paths exist and are accessible' but does not describe what the tool returns (e.g., boolean, list of invalid paths), error handling, or whether it is read-only. This leaves significant behavioral ambiguity for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a relevant example. It front-loads the core purpose and usage, with no unnecessary words. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and lack of annotations, the description covers purpose and usage adequately but omits critical behavioral details like return value or side effects. It is minimally viable but incomplete for an agent to confidently invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (parameter 'paths' described as 'Array of paths to validate'). The description adds value by clarifying that validation checks existence and accessibility, and provides an example input. This goes beyond the schema's minimal description, meriting a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Verify file paths exist and are accessible before analysis.' It uses a specific verb ('Verify') and resource ('file paths'), and distinguishes itself from siblings like 'analyze_directory' by focusing on validation rather than analysis.
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 clear when-to-use guidance: 'Use when uncertain about path correctness or troubleshooting PATH_NOT_ALLOWED errors.' It lacks explicit when-not-to-use or alternative comparisons, but the stated scenarios are sufficiently specific for an agent to decide.
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.
analyze_directorydeep_researchfetch_chunkhealth_checkquick_queryvalidate_pathsScored across 6 tools
Each tool has a clearly distinct purpose: directory mapping, deep multi-file research, pagination, server health, quick file analysis, and path validation. No overlapping functionality.
All tools use snake_case with verb_noun or verb_verb patterns (e.g., analyze_directory, deep_research). Consistent style throughout.
6 tools is well-suited for a code analysis server, covering essential operations without being excessive or minimal.
Covers directory analysis, deep research, quick queries, path validation, health checks, and pagination. Minor gap: no explicit code search tool, but deep_research can handle it.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
