Click on "Install 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., "@Repo Interrogator search for 'BM25' in the codebase"
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.
Repo Interrogator is a local-first, deterministic MCP server that helps AI tools inspect one code repository safely.
It is for repository interrogation, not code modification.
What it does:
indexes files inside one repo_root
runs deterministic BM25 search
outlines code structure via pluggable language adapters
builds context bundles with citations
writes sanitized audit logs
What it does not do:
no LLM calls in v1
no code writes or patching
no multi-repo routing
no HTTP/SSE transport in v1
Python: >=3.11
Tested in this project: Linux and WSL paths, with explicit Windows path normalization tests
Expected to run on: Linux, macOS, Windows (with Python 3.11+)
Related MCP server: mcplens
Clone this repository and enter it:
git clone https://github.com/taggedzi/Repo-Interrogator
cd repomapInstall (end-user style):
python -m pip install .This installs the console command repo-mcp.
Run against a local repository:
repo-mcp --repo-root /absolute/path/to/target/repoThe server uses STDIO. It waits for newline-delimited JSON requests and writes newline-delimited JSON responses.
Verify it responds:
printf '%s\n' \
'{"id":1,"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"0"}}}' \
'{"jsonrpc":"2.0","method":"notifications/initialized","params":{}}' \
'{"id":2,"jsonrpc":"2.0","method":"tools/call","params":{"name":"repo.status","arguments":{}}}' \
| repo-mcp --repo-root /absolute/path/to/target/repoYou should get two JSON-RPC 2.0 response lines (the notification produces no output):
Line 1: initialize result — {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05",...}}
Line 2: tool result — {"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"{\"index_status\":...}"}]}}
python -m venv .venv
source .venv/bin/activate
python -m pip install -e .
python -m pip install ruff mypy pytest buildRun checks:
python -m ruff format .
python -m ruff check .
python -m mypy src
python -m pytest -qrepo.status
repo.list_files
repo.open_file
repo.outline
repo.search
repo.references
repo.find_definition
repo.build_context_bundle
repo.refresh_index
repo.audit_log
Install the semantic extra (pip install repo-interrogator[semantic]) to
enable mode="semantic"/"hybrid" on repo.search and retrieval_mode on
repo.build_context_bundle. The core package has zero runtime dependencies
and is unaffected when this extra isn't installed. See ADR-0018 and
docs/USAGE.md for details.
repo.outline currently supports these adapters:
Python: python (AST-based)
TypeScript/JavaScript: ts_js_lexical (lexical)
Java: java_lexical (lexical)
Go: go_lexical (lexical)
Rust: rust_lexical (lexical)
C++: cpp_lexical (lexical)
C#: csharp_lexical (lexical)
Fallback: lexical (empty structural outline for unsupported files)
Important limits:
Non-Python adapters are lexical. They are deterministic and fast, but conservative.
Macro/generated code and advanced language features can be partially represented.
Search, references, and context bundle coverage depend on indexed extensions/excludes.
Start from examples/repo_mcp.toml for stack-aware include/exclude defaults and override guidance.
Installation: docs/INSTALL.md
Usage and request/response examples: docs/USAGE.md
Configuration and limits: docs/CONFIG.md
AI client integration (MCP over STDIO): docs/AI_INTEGRATION.md
Troubleshooting: docs/TROUBLESHOOTING.md
Issue labels and triage workflow: docs/TRIAGE.md
Security policy and vulnerability reporting: SECURITY.md
Security model and blocked behavior: docs/SECURITY.md
Release process: docs/release.md
Run these commands to validate docs examples against the current codebase:
python -m ruff format .
python -m ruff check .
python -m mypy src
python -m pytest -q
# quick server smoke
printf '%s\n' \
'{"id":1,"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"0"}}}' \
'{"id":2,"jsonrpc":"2.0","method":"tools/call","params":{"name":"repo.status","arguments":{}}}' \
| python -m repo_mcp.server --repo-root .Read sanitized audit log entries for all tool calls made in this session. Useful for diagnostics and verifying what was called and whether it succeeded.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of entries to return. | |
| since | No | ISO timestamp — return only events after this time. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It mentions 'sanitized' and 'in this session' which are behavioral traits, but does not disclose additional details like idempotency, rate limits, or effects of use. However, for a read-only diagnostic tool, these are less critical.
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: first states purpose, second states usage. No redundant words or repetitive information. Front-loaded with key 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?
Tool is simple with 2 optional parameters and no output schema. Description covers purpose, scope, and use case. Could mention ordering or that entries are chronological, but overall sufficiently complete for this context.
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?
Input schema has 100% coverage with clear descriptions for both parameters (limit, since). Description adds no new parameter meaning beyond 'sanitized audit log entries', which is already implied. 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?
Description clearly states verb 'Read' and resource 'sanitized audit log entries', and scopes to 'all tool calls made in this session'. It distinguishes itself from sibling tools which focus on repo file operations and indexing.
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?
Specifies use case: 'Useful for diagnostics and verifying what was called and whether it succeeded.' Does not explicitly state when not to use or mention alternatives, but given no overlapping siblings, this is a minor omission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a compact, ranked, cited context bundle for a coding task. Combines search, outline, and cross-file references into a budget-bounded excerpt set. Each selection includes why_selected explaining which signals drove it. Requires the index to be built first (repo.refresh_index).
| Name | Required | Description | Default |
|---|---|---|---|
| budget | Yes | Size constraints for the bundle. | |
| prompt | Yes | Natural language description of your coding task. | |
| strategy | No | Bundle strategy — only 'hybrid' is supported in v1. | |
| include_tests | No | Whether to include test files in the bundle. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the core behavior (bundle building, budget-bounded, includes why_selected) and dependency on index, but lacks details on error handling, latency, or performance characteristics.
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 with no redundancy: first states the purpose, second details content and prerequisite. Every sentence adds essential information, making it highly efficient.
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 covers purpose and dependency, but with no output schema, it omits details on the bundle's return structure (e.g., format of excerpts, file paths, scores). For a tool with nested parameters and combined capabilities, more guidance on output would improve completeness.
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 value by explaining the bundle's compact, ranked, cited nature and the presence of why_selected, giving context to the parameters. However, it doesn't elaborate on each parameter's specific usage beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a compact, ranked, cited context bundle for coding tasks, combining search, outline, and cross-file references. It distinguishes from siblings like repo.search and repo.outline by describing the integrated nature of the output.
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 notes the prerequisite of building the index first via repo.refresh_index, giving a clear usage condition. However, it doesn't explicitly state when to avoid this tool or mention alternatives like repo.search for simpler queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List readable source files under the repository root. Supports glob filtering. Use to discover what files exist before searching or opening.
| Name | Required | Description | Default |
|---|---|---|---|
| glob | No | Glob pattern to filter results (e.g. 'src/**/*.py'). | |
| max_results | No | Maximum number of files to return. | |
| include_hidden | No | Include hidden files and directories (default false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full burden. It indicates 'readable' source files (an access constraint) and supports glob filtering, but does not specify recursion behavior, limits of max_results, or handling of invalid globs. Sufficient for a simple read tool.
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 with no waste. The first sentence defines the action and resource, the second explains when to use it. Front-loaded and efficient.
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 listing tool with no output schema, the description covers the essential purpose and usage. It could mention recursion behavior or that it lists all files by default, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter (glob, max_results, include_hidden). The tool description adds no significant semantics beyond what the schema already provides, earning the baseline score.
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 verb 'List' and the resource 'readable source files under the repository root,' with explicit mention of glob filtering and a usage note that distinguishes it from sibling tools like repo.search and repo.open_file.
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 a clear use case: 'Use to discover what files exist before searching or opening.' This indirectly guides to use it for exploration before using search or file open tools, though it lacks explicit when-not-to-use or alternative naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a line range from a source file. Returns numbered lines. Specify start_line and end_line to read a focused range rather than the entire file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Repository-relative file path (e.g. 'src/server.py'). | |
| end_line | No | Last line to read, inclusive. | |
| start_line | No | First line to read, 1-indexed (default 1). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions that the tool returns numbered lines and suggests using a range, but it does not detail error handling (e.g., file not found), performance implications, or whether the file is locked. This is insufficient for a read operation with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with only two sentences that convey the essential purpose and key guidance. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema, no annotations), the description covers the basic operation. However, it leaves out return format details beyond 'numbered lines' and does not address edge cases or behavior when parameters are invalid.
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 describes all three parameters with 100% coverage. The description adds marginal value by suggesting the use of start_line and end_line for focused reading, but does not provide additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'read' and the resource 'source file', and specifies that it reads a line range. However, it does not explicitly differentiate from sibling tools like 'repo.outline' or 'repo.status', though the purpose is 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 advises to specify start_line and end_line for a focused range rather than the entire file, providing some usage context. However, it lacks when-not-to-use guidance or references to alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the declaration structure of a file using AST (Python) or lexical analysis. Shows classes, functions, and other symbols with line ranges and parent context.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Repository-relative file path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions using AST (Python) or lexical analysis, which gives insight into method. However, it does not disclose limitations (e.g., only Python for AST?) or performance implications. Lacks full disclosure for a tool with no 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?
Two sentences, 20 words, front-loaded. Every sentence adds value. No redundancy or 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?
Given no output schema and no annotations, the description provides some context (return types, line ranges, parent context) but lacks format specification and usage guidance. It is adequate but not fully complete for a tool with these signals.
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 has 100% coverage for the single parameter 'path' with description 'Repository-relative file path.' The description adds minimal extra meaning beyond the schema, just implying the file is the target. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns declaration structure of a file, listing classes, functions, symbols with line ranges and parent context. It is specific and distinguishes from siblings like repo.open_file (content) and repo.references (references).
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 does not provide explicit guidance on when to use this tool versus alternatives like repo.open_file or repo.references. Usage is implied by the purpose, but no when-not-to-use or alternative comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all cross-file references to a named symbol using AST (Python) or lexical analysis. Returns file paths, line numbers, strategy, and confidence level per reference.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Optional file path to scope the reference search to one file. | |
| top_k | No | Maximum number of references to return. | |
| symbol | Yes | Symbol name to find references for (e.g. 'MyClass.my_method'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden; it reveals the analysis strategy (AST/lexical) and return fields (file paths, line numbers, etc.), enough for an agent to understand the tool's read-only nature, though it doesn't explicitly state idempotency or lack of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a two-sentence summary that front-loads the core purpose and then details the return output, with no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explicitly states what is returned (file paths, line numbers, strategy, confidence), covering key aspects for a reference-finding tool; it could mention behavior when symbol is not found but is otherwise adequate.
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%, and the tool description does not add significant meaning beyond the parameter descriptions already provided in the schema (e.g., 'Optional file path to scope', 'Maximum number', 'Symbol name').
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 finds cross-file references to a named symbol, uses AST or lexical analysis, and returns specific information, effectively distinguishing it from sibling tools like repo.search.
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 finding references but does not explicitly contrast with similar tools like repo.search or repo.outline, nor provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build or incrementally refresh the BM25 search index. Run this before searching or bundling if the index is stale or not yet built. Use force=true to rebuild from scratch.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Force a full rebuild even if the index appears current. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavior (incremental refresh vs. full rebuild with force=true) but does not elaborate on potential side effects like resource usage or locking. Given no annotations, it covers the essential aspects for a simple index refresh tool.
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 short sentences. The first sentence states the purpose, the second provides usage conditions and parameter guidance. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description fully covers what an agent needs to know: purpose, when to use, how to force a rebuild. It is complete for its complexity.
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 single parameter force has a schema description, and the tool description adds further context by explaining when to use force=true. With 100% schema coverage, the description provides meaningful additional guidance 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 verb 'Build or incrementally refresh' and the resource 'BM25 search index'. It differentiates from siblings by noting that this tool should be used before searching or bundling, implying it is a prerequisite for repo.search and repo.build_context_bundle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool: 'if the index is stale or not yet built'. It also provides guidance on the force parameter for full rebuilds. While it does not explicitly list when not to use it, the conditions are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run BM25 full-text search over indexed repository chunks. Returns ranked hits with file path, line range, snippet, and matched terms. Run repo.refresh_index first if the index is not yet built.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Search mode — only 'bm25' is supported in v1. | |
| query | Yes | Search terms (BM25 keyword matching). | |
| top_k | No | Maximum number of results to return. | |
| file_glob | No | Glob pattern to restrict search to matching files (e.g. 'src/**/*.py'). | |
| path_prefix | No | Path prefix to restrict search scope (e.g. 'src/repo_mcp/'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the search algorithm (BM25), result structure, and index requirement. Does not explicitly state side effects, but hints at read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loading purpose and output, then providing usage guidance. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains output format (ranked hits with specific fields) and index prerequisite. No output schema, so the description compensates well. Could mention read-only nature, but still adequate.
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%. The description adds only general context (BM25, index requirement) without per-parameter details 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 verb 'Run BM25 full-text search', specifies the resource 'indexed repository chunks', and describes the output components. It differentiates from siblings like repo.refresh_index.
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?
Provides explicit prerequisite: 'Run repo.refresh_index first if the index is not yet built.' No when-not-to-use or alternatives, but 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.
Return index state, active limits, enabled adapters, and effective config. Call this first to verify the server is connected and the index is ready.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies read-only behavior by stating 'return' but does not explicitly confirm safety, auth requirements, or side effects. Adequate for a 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?
Two concise sentences: first lists returned data, second gives usage instruction. No wasted words, 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?
Description covers what is returned (categories) and usage context (call first). Lacks detailed output fields but no output schema exists; sufficient for a health-check tool with no parameters.
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?
No parameters exist (0 params, 100% schema coverage). Baseline for 0 params is 4; description does not need to add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns specific data (index state, active limits, enabled adapters, effective config) and its primary use (server connection verification). Differentiates from sibling tools which are file operations or search.
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 advises to call this tool first to verify server and index readiness. Provides clear context but does not mention when to avoid using it, though alternatives are not obvious from sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0repo.audit_logrepo.build_context_bundlerepo.list_filesrepo.open_filerepo.outlinerepo.referencesrepo.refresh_indexrepo.searchrepo.statusEach tool has a clearly distinct purpose: from indexing and search to file operations, references, outline, and audit. No overlap exists between tools.
All tools follow the 'repo.verb_noun' pattern using snake_case, providing a predictable and consistent naming scheme throughout.
With 9 tools, the set is well-scoped for repository interrogation. Each tool serves a specific function without redundancy or excess.
The tool surface covers the full workflow: indexing, searching, listing, opening, outlining, referencing, and building context bundles. No obvious gaps for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that gives your AI access to the source code and docs of all public github repos
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/taggedzi/Repo-Interrogator'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
