chatgpt-codex-local-mcp

by dpaula

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource/action. The general exploration tools (list, read, search, git) are clearly separated, and each memory tool reads a specific, uniquely named file with no overlap.
Naming Consistency5/5
Tool names follow a consistent verb-first pattern: list_*, read_*, search_*, get_*. The memory tools all use read_<topic>_memory, with read_memory_index as a minor but still predictable deviation. Overall naming is highly uniform.
Tool Count3/5
At 17 tools, the server is slightly above the ideal 3-15 range. The 9 memory read tools are nearly identical operations on different files, inflating the count and adding unnecessary redundancy. A generic read_memory_file would reduce this.
Completeness4/5
For a read-only project exploration and memory reading server, the tool surface covers the core workflows: listing files, reading content, searching, and git status/diff. Minor gaps include no git log or branch listing, and memory files not in the predefined set require using read_file.
Average 3.7/5 across 17 of 17 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, but the description adds no additional context beyond that. It does not disclose what markers are scanned for, whether detection is recursive, or what the return format is. With no output schema, the description carries more burden but fails to provide behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded, and contains no filler. It is appropriately concise for a simple detection tool, with every word serving a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description should clarify what 'detect' returns (e.g., a list of detected stacks, a boolean, or details about markers). It also omits context about 'allowed root' and any session setup. The simple schema and strong annotations help, but the description is too thin to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter projectPath with a clear description ('Absolute path to a project directory inside an allowed root'). The description adds no extra parameter semantics, but since schema coverage is high, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Detect' with the resource 'common stack markers' for a 'project directory', clearly distinguishing it from sibling tools like read_file or list_project_files. However, 'stack markers' is somewhat ambiguous and could be more specific about what is detected (e.g., languages, frameworks, package manifests).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites (e.g., using list_allowed_repositories first) or exclusion cases. The bare description leaves the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds the specific file path and content, which is useful context, but it does not disclose return format, size limits, or behavior when the file is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the resource and purpose, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and several sibling memory tools, the description is under-specified. It does not explain what the tool returns (file contents), nor does it help the agent choose this over related read_memory tools. Annotations cover safety, but the minimal description leaves important usage context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% because maxBytes lacks a description. The tool description adds some context for projectPath (the file is read relative to it) but says nothing about maxBytes or its semantics, so it does not compensate for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a specific file (docs/memory/arquivos-importantes.md) and mentions its content (key project files). It uses a specific verb and resource, and it is easily distinguished from sibling tools by the unique file path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus the many sibling memory-reading tools. It does not mention alternatives or exclusion criteria, leaving the agent to infer usage solely from the file name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context: 'literal text' (non-regex) and 'text files' (excludes binaries), but it does not disclose recursion depth, hidden file handling, or match limits beyond what schema defaults hint at.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. Every word contributes to the core purpose, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description does not explain what the result looks like (e.g., list of file paths, match snippets). It also omits behavioral details like recursion depth, hidden files, or case sensitivity, which are left to schema defaults. The tool is moderately complex (6 parameters), and the description is too thin to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, covering query and projectPath. The description adds no meaning for maxDepth, maxMatches, caseSensitive, or includeHidden, leaving their semantics to defaults and names. The term 'literal text' reinforces the query description but does not compensate for the other four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'search', identifies the resource as 'text files under a project directory', and clearly distinguishes from sibling tools like read_file and list_project_files. The use of 'literal text' further clarifies that regex is not supported.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives such as read_file or list_project_files. The description does not mention when not to use it, nor does it reference any exclusion criteria like binary files or symlinks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the specific file path and content type (architecture context), but does not disclose behaviors like handling missing files or response format, which would be helpful but are not required given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that directly states the tool's function without any filler. Very concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately conveys the core purpose, but with no output schema, it omits what the return value looks like (e.g., file content) and does not explain the maxBytes parameter. Given the simplicity of a read operation and the annotations, it is minimally complete but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; only projectPath has a description while maxBytes is undocumented. The tool description does not mention either parameter, so it fails to compensate for the missing maxBytes semantics and adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (Read), the resource (docs/memory/arquitetura.md), and the context (technical architecture), making it easy to distinguish from sibling memory-reading tools such as read_project_memory or read_decisions_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like read_file or other memory-specific tools. The phrase 'with technical architecture context' implies usage but does not state exclusions or alternative tool choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotations; it merely states the file path and content type. It does not disclose behaviors such as maximum byte limits (maxBytes) or return format, making the description rely on annotations for safety only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no wasted words, front-loading the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is brief but sufficient for a simple read operation; however, it lacks any mention of the return value or the maxBytes behavior, and does not differentiate from sibling memory tools. Given the absence of an output schema, the description should provide more context about what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents projectPath but not maxBytes, and the description mentions neither parameter. With 50% schema coverage, the description fails to compensate by explaining the byte limit or path requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 specific resource 'docs/memory/projeto.md', and adds the purpose 'functional project knowledge'. This distinguishes it from sibling memory tools by naming the exact file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly specify when to use this tool vs alternatives. It implies usage by naming the file, but there is no mention of exclusions or alternative tools, such as read_architecture_memory or read_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds the 'allowed root' constraint, which is useful, but it does not disclose other behaviors such as recursion depth limits (maxDepth), result truncation (maxFiles), or hidden file handling (includeHidden). Given the annotations, this is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and object. There is no unnecessary verbosity, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and an 'allowed root' constraint, the description is too brief to be complete. It does not specify the output format, explain parameter semantics, or mention limit behaviors. The strong annotations cover safety but not functional completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only projectPath has a description). The tool description does not explain maxDepth, maxFiles, or includeHidden, and it does not compensate for the low coverage. While parameter names hint at their purpose, the description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'List files under a project directory inside an allowed root.' It distinguishes itself from sibling tools like read_file (which reads content) and search_in_project (which searches), and the 'allowed root' qualifier adds important scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for listing files in a project, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. There is no mention of when to prefer this over search_in_project or read_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnly, idempotent, and non-destructive behavior. The description adds that sensitive files are blocked and that reads are restricted to an allowed root, which is useful context. However, it does not specify what counts as sensitive or what error occurs when a sensitive file is accessed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and object, and no redundant information. Every word contributes to understanding the tool's primary function and key constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining behavior. It covers the core function and the allowed-root constraint but omits details about return format, maxBytes handling, and how sensitive files are blocked. For a read-only tool with clear annotations, this is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers filePath with 'Absolute file path inside an allowed root', but maxBytes has no description in the schema. The tool description does not mention maxBytes at all, so with only 50% schema coverage, the semantics of maxBytes are left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read a text file inside an allowed root' – a specific verb, resource, and scope. This distinguishes it from sibling tools like search_in_project and list_project_files, which search or list rather than read file content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading text files but provides no explicit when-to-use guidance or alternatives. It mentions the 'allowed root' constraint, giving some context, but does not reference sibling tools like list_allowed_repositories or memory read tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the file path and content context but does not disclose additional behavioral traits such as error handling, permission requirements, or how the file content is returned. It provides some context beyond annotations but not a significant amount.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and clearly states the resource and content. Every word earns its place; there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (read a specific file), and the description identifies the file and its purpose. Annotations cover safety, and the schema documents parameters. Missing details like output format and error handling, but these are not critical for such a straightforward read operation, making the description sufficiently complete for an agent to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention parameters at all. Schema description coverage is 50% (only projectPath is described); maxBytes lacks a schema description. The tool description fails to compensate for this gap, adding no meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Read'), the specific resource ('docs/memory/referencias.md'), and the content ('important links and references'). This distinguishes it from sibling memory tools by naming the exact file, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the specific file name and content, suggesting it should be used when references or links are needed. However, it provides no explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the specific file path and content type, but does not disclose return format or error behaviors, which is acceptable given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the essential information without waste. It earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with strong annotations, the description provides the exact file path and content type. It does not describe the return value, but that is intuitive for a read tool. The sibling context and schema cover the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents projectPath as 'Absolute project directory path' and includes maxBytes with defaults. The description's mention of 'docs/memory/decisoes.md' implies the file is relative to projectPath, adding context. However, it does not clarify maxBytes, but the parameter is self-explanatory with a default. Overall, the description adds some meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and identifies the exact resource ('docs/memory/decisoes.md with simplified ADR records'). This clearly distinguishes it from sibling memory readers like read_architecture_memory or read_project_memory, which read different files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading decision memory by naming the specific file path, but it does not explicitly state when to prefer this over generic read_file or other memory readers. No alternatives 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the file is for navigation and current status, but it does not disclose the truncation behavior implied by maxBytes or what happens if the file is missing. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the resource and purpose. There is no redundant wording or filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-file tool, the description is adequate but not fully complete. It does not describe the return format (the raw content of index.md) or the effect of maxBytes, and it assumes the agent knows where projectPath points. Given the tool's simplicity and annotation coverage, a 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (projectPath has a description, maxBytes does not). The description adds no information about maxBytes, which limits the output size, nor does it explain the role of projectPath beyond the schema. The description's mention of the file path partially compensates but leaves the maxBytes parameter semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a specific file (docs/memory/index.md) for navigation and current status. This distinguishes it from sibling memory readers that target different files (e.g., read_onboarding_memory, read_project_memory) and from generic file reading via read_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for navigation and current status' implies when to use this tool: to get an overview of the memory structure and current state. It does not explicitly exclude alternatives or name sibling tools, but the context is clear enough for an agent to select it over other memory readers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the specific file path and content type, but does not disclose any additional behavior such as return format, error conditions, or that it reads the entire file (or up to maxBytes). With annotations handling the safe-read aspect, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence of nine words. It is front-loaded with the verb and resource, contains no filler, and every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two parameters and no output schema, the description gives the essential purpose but leaves out details about return content or how it fits into the memory system. It also doesn't clarify what 'pendencias' means to non-Spanish speakers, which could be ambiguous. Given the many sibling memory tools, a bit more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: projectPath has a description, but maxBytes has none. The description does not mention maxBytes or add any parameter semantics. While the parameter name is somewhat self-explanatory, the description fails to compensate for the missing schema description, providing no additional guidance on parameter behavior or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' with the exact resource 'docs/memory/pendencias.md', and adds the content scope 'with open issues and risks'. This clearly distinguishes it from sibling memory-reading tools by naming the unique file and its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to access open issues and risks stored in the pending-memory file. It provides clear context but does not explicitly name alternatives or state when not to use it, though the sibling list makes the memory-tool family apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive. The description adds meaningful context that it lists 'configured allowed roots' and 'likely project directories', which hints at a configuration source and a heuristic ('likely'). It does not contradict the annotations and enriches beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that fully conveys the tool's purpose without any redundancy or filler. It is front-loaded with the action and resource, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one optional parameter, and strong annotations, the description is sufficient for an agent to know what the tool does. However, it does not specify the output format (e.g., absolute paths, relative paths) or clarify what 'likely project directories' means, which could be useful but is not essential for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter `maxDepth` is fully described in the schema (100% coverage), so the description does not need to add parameter-level detail. The baseline of 3 applies because the schema carries the semantic load, and the description does not enhance understanding of that parameter beyond the default/min/max values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action ('List') and resource ('configured allowed roots and likely project directories'). It distinguishes from siblings like list_project_files, which lists files within projects, by focusing on the allowed roots themselves. The wording is specific and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used to enumerate allowed root directories, but it does not explicitly state when to prefer it over alternatives like list_project_files or read_memory_index. It lacks explicit when-not-to-use guidance or a named alternative, but the context is clear enough for basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds specific operational context by naming the exact file path and its structure (TODO/DOING/DONE), which is useful beyond what annotations state. It does not cover edge cases like missing files or encoding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and free of filler. It clearly states what the tool does and the target resource without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with good annotations, the description provides essential context (file path and content sections). It does not explicitly state the return format or maxBytes significance, but these are minor gaps given the tool's simplicity and the sibling tool set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema explains projectPath as an absolute directory path. The description adds meaning by indicating that the file path is relative to projectPath, but maxBytes is left without any description, and the overall schema coverage is only 50%. The description does not fully compensate for the undocumented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' with an exact resource 'docs/memory/backlog.md', and clarifies the file contains TODO, DOING, and DONE items. This makes it distinct from sibling memory tools like read_onboarding_memory or read_project_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It is implied that this tool is for reading the backlog memory file, but there is no explicit guidance on when to use it over alternative memory readers. The sibling list includes many similar read_memory_* tools, yet the description does not distinguish usage cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds the specific file path and purpose but does not disclose error handling or return format, which is acceptable given the simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly conveying the action and purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with strong annotations, the description covers the purpose, file location, and usage context. Some information like return value behavior is implied rather than stated, but it's sufficient for this tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with only projectPath described. The description implies projectPath is the base directory containing the onboarding file, adding context for that parameter. However, maxBytes is not mentioned in the description, though its schema includes default and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' with an exact file path 'docs/memory/onboarding.md', clearly distinguishing it from sibling memory-read tools. The stated purpose 'to bootstrap a new project session' clarifies its intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context ('to bootstrap a new project session') indicating when to use it. It does not explicitly mention alternatives or when not to use it, but the use case is evident from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds transparency by specifying the exact file path and its contents, which is useful beyond the annotations. It does not disclose error handling or return format, but this is less critical given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the primary action and resource. It is concise while including the file's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with good annotations and a straightforward schema, the description is complete enough: it names the exact file and the context it contains. It does not cover edge cases like missing files or truncation, but these are implied by the schema and tool type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain parameters directly. The schema provides a description for projectPath and constraints for maxBytes, but the description does not explicitly tie projectPath to the file path. This is adequate but not additive beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') with a precise resource ('docs/memory/contexto-chat.md') and clarifies content ('current operational session context'). This clearly distinguishes it from sibling memory-read tools like read_onboarding_memory or read_project_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys a clear use case: when you need the current operational session context. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of full usage-guidance coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the 'allowed root' constraint, which is meaningful behavioral context beyond the annotations. It also confirms the read-only behavior consistent with readOnlyHint, and does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core function ('Run a read-only git diff') and includes the key scope constraint without unnecessary detail. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage and annotations, the description is sufficient. It clearly states the operation and scope, and the git diff output format is implied by the tool name, so no further explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters having clear descriptions. The tool description itself adds no additional parameter semantics, so the baseline of 3 is appropriate given the schema handles the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a git diff, specifies that it is read-only, and scopes it to a project directory within an allowed root. This distinguishes it from sibling tools like get_git_status, which show status rather than diffs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is for viewing diffs, and the read-only nature implies safe inspection. However, it does not explicitly state when to use this over alternatives like get_git_status or mention exclusions, so it stops short of the strongest guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description reinforces 'read-only' and adds the valuable behavioral constraint that the path must be inside an allowed root, providing context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that precisely conveys the operation and constraints with no wasted words. It earns every word and is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only tool with comprehensive annotations and no output schema, the description adequately covers the operation, scope, and safety. It does not detail the return format, but 'git status' is a well-known command, so the description is sufficient for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes projectPath as an absolute project directory path (100% coverage). The description adds the extra semantic requirement that the path must reside within an allowed root, which is not present in the schema description, thus providing additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('run a read-only git status'), the target resource ('project directory'), and the scope constraint ('inside an allowed root'). This distinguishes it from sibling tools like get_git_diff, which compares changes rather than showing status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is a read-only operation and is restricted to allowed roots, implying it should be used for checking repository status within permitted paths. However, it does not explicitly name alternatives or state when not to use it, such as comparing against get_git_diff.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![chatgpt-codex-local-mcp MCP server](https://glama.ai/mcp/servers/dpaula/chatgpt-codex-local-mcp/badges/card.svg)](https://glama.ai/mcp/servers/dpaula/chatgpt-codex-local-mcp)

Score Badge

Copy to your README.md:

[![chatgpt-codex-local-mcp MCP server](https://glama.ai/mcp/servers/dpaula/chatgpt-codex-local-mcp/badges/score.svg)](https://glama.ai/mcp/servers/dpaula/chatgpt-codex-local-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dpaula/chatgpt-codex-local-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server