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., "@Codex Context Engine find definitions for the function 'parseConfig'"
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.
Codex Context Engine is a local MCP server that indexes a workspace and exposes code-navigation tools to Codex.
It parses JavaScript and TypeScript files with Babel, uses simple regex-based indexing for Python, Go, and Rust, writes an index to .codex-context.json, and generates a CODEBASE_MAP.md report.
The project is useful for quick local navigation, reference lookup, dependency checks, and lightweight audits. It is not a replacement for a compiler, language server, type checker, or dedicated security scanner.
Indexes source files with these extensions: .js, .jsx, .ts, .tsx, .mjs, .cjs, .py, .go, .rs.
Ignores common generated or heavy paths such as node_modules, .git, dist, build, package lockfiles, and its own index file.
Extracts symbols, imports, exports, and call expressions into a JSON index.
Watches the workspace for changes and updates indexed files incrementally. If recursive fs.watch is not available, it falls back to polling.
Provides MCP tools over stdio for local Codex integrations.
Runs locally and does not call external APIs during indexing.
Related MCP server: MCP Indexer
JavaScript and TypeScript support is AST-based, but it is still a static heuristic indexer. It does not type-check code or resolve every dynamic pattern.
Python, Go, and Rust support is regex-based and intentionally shallow.
Reference and call-graph results are best-effort. Dynamic dispatch, aliasing, reflection, generated code, and complex module resolution may be missed.
semantic_query is keyword scoring over names, paths, and comments. It is not embeddings or AI semantic search.
audit_security detects common secret patterns and source map files. It can miss secrets and can produce false positives.
estimate_semver_impact requires a Git repository and compares exported JavaScript/TypeScript signatures heuristically.
graph TD
A[Codex Agent] <-->|JSON-RPC over stdio| B[MCP Server]
B <--> C[Query Engine]
B <--> D[Codebase Indexer]
D -->|JS/TS AST parsing| E[Babel Parser]
D -->|Python/Go/Rust regex parsing| H[Regex Fallbacks]
D -->|Watches files| F[fs.watch or polling]
D -->|Writes JSON| G[.codex-context.json]
D -->|Generates report| I[CODEBASE_MAP.md]Tool | Parameters | What it returns |
| None | Rebuilds the workspace index. |
|
| Definition locations, line ranges, docs when available, and code snippets. |
|
| Import and call-expression references found in the indexed files. |
|
| Best-effort caller/callee data from indexed call expressions. |
|
| Weighted keyword matches over symbol names, docs, and file paths. |
| None | Cycles found in resolved internal imports. |
| None | Exports that are not imported elsewhere in the indexed workspace. |
|
| Heuristic SemVer suggestion based on Git diff against a ref. |
| None | Common credential-pattern warnings, source map files, and sensitive config filenames. |
|
| Symbols, import count, and export count for one indexed file. |
Requires Node.js 18 or newer.
npm installnpm startThe server communicates over stdio, so normal diagnostic output is written to stderr to avoid corrupting MCP JSON-RPC messages on stdout.
Project-scoped example:
[mcpServers.codex-context-engine]
command = "node"
args = ["/absolute/path/to/codex-context-engine/src/server.js"]Global config locations commonly used by Codex:
Windows: %USERPROFILE%\.codex\config.toml
macOS/Linux: ~/.codex/config.toml
This repository also includes .mcp.json for plugin-style configuration:
{
"mcpServers": {
"codex-context-engine": {
"command": "node",
"args": ["./src/server.js"]
}
}
}.codex-context.json: local index cache. It is ignored by Git.
CODEBASE_MAP.md: generated workspace report. This repository currently tracks it as a sample/report artifact.
npm testThe test suite covers:
JS/TS symbol indexing and doc extraction.
CommonJS imports and exports.
Destructured bindings.
Basic Python, Go, and Rust regex indexing.
Circular dependency and unused export detection.
Git-based SemVer impact estimation.
Security-audit masking for common patterns.
Polling watcher fallback.
MCP stdio safety for indexer diagnostics.
Scans the workspace to identify sensitive credentials (API keys, private keys, database connection strings) and build source map files (.map) that might leak source structure.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes what it identifies but lacks disclosure on side effects, permissions needed, or whether it is read-only. Without annotations, more detail is expected.
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?
Single sentence with no waste; clearly communicates two key actions efficiently.
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?
Adequate for a parameterless tool but lacks information about return values or side effects, which is needed since no output schema or annotations exist.
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, and schema coverage is 100%, so baseline is 4. Description adds nothing 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 tool scans for specific sensitive credentials and source map files, with a precise verb and resource. It is distinct from siblings like code analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyzes module imports to locate dependency cycles (e.g. A imports B, B imports A) which lead to runtime errors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool analyzes imports and finds cycles, but does not disclose whether it is read-only, requires permissions, how it handles large modules, or any limitations. The description is too minimal 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?
The description is a single sentence that conveys the core functionality without any wasted words. It is appropriately sized and 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?
The description is adequate for a parameterless tool, but it lacks details about the output format, scope (entire workspace or selected files), performance implications, or any side effects. Given no output schema, more context on the return value 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?
The input schema has no parameters, and schema description coverage is 100% (vacuously). With 0 parameters, the description does not need to add meaning beyond what the schema provides. Baseline is 4.
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 analyzes module imports to detect dependency cycles, provides an example (A imports B, B imports A), and explains the consequence (runtime errors). This is a specific verb-resource pair that distinguishes it from sibling tools like get_call_graph or audit_security.
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 when needing to find circular dependencies causing runtime errors, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. The guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimates the semantic versioning impact (Major/Minor/Patch) of current changes by comparing code signatures with a reference commit or branch.
| Name | Required | Description | Default |
|---|---|---|---|
| refBranch | No | Reference branch or commit tag to compare signatures against (defaults to "main"). | main |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions the method (comparing code signatures) but does not state read-only nature, side effects, or limitations. For a read-only estimation tool, safety is not explicitly conveyed.
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, clear sentence that efficiently conveys the tool's purpose and method without any wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should compensate by explaining return values or behavior. It does not, leaving the agent uninformed about what the tool outputs, which is critical for a tool that provides an estimate.
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% with a clear description for the single parameter 'refBranch'. The description adds no additional detail beyond the schema, so 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 verb 'estimates' and the resource 'semantic versioning impact (Major/Minor/Patch)', and specifies that it compares code signatures with a reference commit or branch. It is distinct from sibling tools which focus on other code analyses.
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 when needing to determine semver impact but provides no explicit guidance on when to use versus alternatives, nor any exclusions or prerequisites. It only states the core functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns definition details, lines, and exact code snippet for a given function, class, or method name.
| Name | Required | Description | Default |
|---|---|---|---|
| symbolName | Yes | The name of the class, function, variable, or method (e.g. "getUser" or "UserService.register"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description must disclose behavior. It states returns include 'definition details, lines, and exact code snippet', implying read-only. However, no details on scope, prerequisites (e.g., indexing), error conditions, or limitations. Adequate but not thorough.
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?
Single, concise sentence with no redundancy. Every word is necessary to convey the tool's action and result.
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 a simple tool with one parameter and no output schema, the description adequately covers what it does and returns. Could mention error cases or indexing requirements, but overall sufficient for the 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?
Schema coverage is 100% for one parameter. The description adds minimal value beyond the schema's 'description' field—both mention symbol types and examples. Baseline 3 as schema does the heavy lifting.
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 ('Returns') and the specific resource ('definition details, lines, and exact code snippet') for a given symbol. It explicitly lists symbol types (function, class, method) and distinguishes from siblings like find_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?
No explicit when-to-use or when-not-to-use guidance. The intended use is implied by the description (find definition of a symbol). Sibling tools like find_references provide implicit contrast, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the workspace for references to a given symbol name. Returns file paths, line numbers, caller names, and matching code snippets.
| Name | Required | Description | Default |
|---|---|---|---|
| symbolName | Yes | The name of the symbol to find usages of. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the return values (file paths, line numbers, caller names, code snippets) but does not mention performance, limitations, or whether it modifies state. It describes a read operation adequately but not richly.
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 two sentences, fully front-loaded with the purpose, and contains no extraneous words. Every sentence provides essential 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 no output schema, the description covers return values adequately. It explains what is returned (file paths, line numbers, caller names, code snippets). However, it could mention that results are from the entire workspace, which is implied by 'workspace'. Overall complete for a simple search 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 coverage is 100%, and the parameter 'symbolName' is described in the schema as 'The name of the symbol to find usages of.' The tool description adds no additional semantics beyond this, so baseline 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 searches for references to a symbol and distinguishes it from siblings like 'find_definitions' (definitions) and 'get_call_graph' (call graph). The verb 'searches' and resource 'workspace for references' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies use when you need references, but does not contrast with siblings like 'find_definitions' or 'semantic_query'. Users must infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scans the project to identify exported classes, functions, or variables that are never imported anywhere in the codebase.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behaviors. It does not mention whether scanning requires a pre-indexed workspace, how dynamic imports are handled, or if the search is limited to certain file types. Side effects or performance impact are not addressed.
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 conveys the core action and result. No extraneous words, front-loaded with the scanning intent.
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 (no params, no output schema), the description is minimally adequate. However, it lacks usage context and behavioral details that would enhance completeness beyond the bare minimum.
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?
With zero parameters and 100% schema coverage, the baseline is 4. The description could explicitly note that no input is needed, but the absence of parameters makes the tool self-explanatory.
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's verb ('scans to identify') and specific resource ('unused exports'), distinguishing it from sibling tools like 'find_definitions' which find all definitions, not just unused ones.
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 guidance is provided on when to use this tool vs alternatives, such as using 'find_references' to check usage or 'detect_circular_dependencies' for circular imports. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates caller-callee trees to trace program execution pathways for a given function or method.
| Name | Required | Description | Default |
|---|---|---|---|
| direction | No | Direction of trace. "incoming" to find who calls this function, "outgoing" to find who this function calls. | incoming |
| functionName | Yes | The name of the function to trace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the behavioral burden. It only states the high-level function without disclosing traits like destructive potential, authentication needs, rate limits, or output format. For a tool that likely performs read analysis, more context on computational cost or side effects would be beneficial.
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, complete sentence with no wasted words. It front-loads the core purpose and is appropriately concise.
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 moderate complexity (2 parameters, no output schema), the description omits details about the output format (tree structure) and does not explain return values or usage context. It is adequate but not comprehensive.
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%, and parameter descriptions in the schema are sufficient. The tool description adds no additional meaning beyond 'generates caller-callee trees,' which is already implied by the tool name and schema. 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 action ('generates caller-callee trees') and the resource ('program execution pathways for a given function or method'). It distinguishes itself from sibling tools like find_references and find_definitions by focusing on tracing call hierarchies.
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 tracing execution pathways but doesn't explicitly state when to use this tool versus alternatives. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a structured outline of all symbols (classes, functions, methods, variables) declared inside a specific file from the index.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | The workspace-relative path of the target file (e.g. "src/indexer.js"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions 'from the index' but does not clarify dependencies (e.g., prior indexing), error behavior (e.g., file not indexed), or whether it is read-only. Lack of behavioral details reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, 19 words, no fluff. Front-loaded with verb and key outcome. Each word is meaningful.
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, so description could hint at output structure (e.g., hierarchical list). It adequately describes input but lacks return format details. Given low complexity (1 param), it is somewhat complete but could be improved.
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% for the single 'filePath' parameter. The description adds minimal value beyond the schema (e.g., 'from the index'), so baseline 3 applies. No additional parameter nuances are provided.
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 ('Returns'), resource ('structured outline of all symbols'), and scope ('from the index'). It distinguishes from siblings like 'find_definitions' and 'get_call_graph' by focusing on a single file's declarations.
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 guidance on when to use this tool versus siblings (e.g., 'find_definitions' or 'semantic_query'). The description implies a specific use case but does not explicitly state contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Triggers a re-scan of the workspace, parsing all JavaScript/TypeScript files to rebuild the symbol and call graph index.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Basic behavior is described: triggers re-scan and rebuilds index. However, no details on whether the operation is synchronous/asynchronous, performance impact, or what happens to existing data. With no annotations, more disclosure would be helpful.
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?
Single sentence, 17 words, front-loads the verb 'Triggers' and clearly states the action and outcome. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter administrative tool, the description covers the purpose and effect. Could mention that re-indexing is needed for accurate results from sibling tools, but it is sufficient as is.
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?
Tool has zero parameters, so baseline is 4. Description does not need to add parameter info, and it correctly describes the action without parameter details.
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 triggers a re-scan of the workspace to rebuild the symbol and call graph index. It distinguishes itself from siblings like find_definitions or get_call_graph by focusing on index rebuilding.
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 on when to use this tool versus alternatives. The description does not mention prerequisites, scenarios that require re-indexing, or when other tools like find_definitions might be sufficient without re-indexing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs a weighted search over symbols and comments using query keywords to locate code by intent (e.g., "jwt parsing").
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default 10). | |
| queryText | Yes | The query text representing the functional intent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions 'weighted search' and 'over symbols and comments' but does not define the weighting, ordering, or output format. It implies a read operation but doesn't confirm non-destructiveness or other behavioral traits.
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, well-structured sentence that efficiently communicates the core purpose. No unnecessary words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description covers the basic functionality. However, it lacks details on result format, pagination behavior, or what happens with no matches. It is adequate but not fully comprehensive.
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% with clear descriptions for both parameters. The description adds no additional meaning beyond the schema, aside from illustrating the queryText with an example. 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 the tool performs a weighted search over symbols and comments using query keywords to locate code by intent, with a concrete example ('jwt parsing'). This distinguishes it from siblings like find_definitions or find_references, which are structural rather than intent-based.
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 intent-based code search but does not explicitly state when to use this tool versus alternatives like find_references or get_call_graph. No 'when not to use' or exclusions are provided.
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.0audit_securitydetect_circular_dependenciesestimate_semver_impactfind_definitionsfind_referencesfind_unused_exportsget_call_graphget_file_outlineindex_workspacesemantic_queryEach tool has a clear and distinct purpose: security auditing, circular dependency detection, semver estimation, symbol definition/reference lookup, unused export detection, call graph generation, file outlining, workspace indexing, and semantic querying. No overlap is apparent.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., audit_security, find_definitions, get_file_outline), making them predictable and easy to distinguish.
With 10 tools, the server covers a comprehensive range of code analysis tasks without being overwhelming. Each tool serves a distinct analytical purpose, justifying its inclusion.
The tool set covers essential code analysis operations like indexing, symbol lookup, call graph, security scan, etc. Minor gaps exist (e.g., no tool for refactoring or package-level dependency listing), but the surface is largely complete for a context engine.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Ground-truth code graph for your codebase: exact callers, callees, symbols & dependencies.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Elioz404/PanchiCodex'
If you have feedback or need assistance with the MCP directory API, please join our Discord server