Skip to main content
Glama
AshutoshBuilds

Aindreyway MCP Codex Keeper

by AshutoshBuilds
OverviewSchemaRelated ServersScoreDiscussions
Remote

Aindreyway MCP Codex Keeper

MCP Server Version License

An intelligent MCP server that serves as a guardian of development knowledge, providing AI assistants with curated access to latest documentation and best practices.

🚀 Quick Start

Prerequisites

  1. Make sure you have Node.js installed (version 18 or higher):

    node --version

  2. Install or update npm (comes with Node.js):

    npm install -g npm@latest

  3. Verify npx is available:

    npx --version

    If not found, install it:

    npm install -g npx

Configuration

Add this to your Cline/Sonnet configuration:

"aindreyway-codex-keeper": {
  "command": "npx",
  "args": ["-y", "@aindreyway/mcp-codex-keeper@latest"],
  "disabled": false,
  "env": {
    "npm_config_cache_max": "1024000000",
    "NODE_OPTIONS": "--max-old-space-size=256"
  }
}

That's it! The assistant will handle everything automatically.

Note: This server uses npx for direct npm package execution, which is optimal for Node.js/TypeScript MCP servers, providing seamless integration with the npm ecosystem and TypeScript tooling.

Related MCP server: Dedalus MCP Documentation Server

🎯 What Your Assistant Can Do

Ask your assistant to:

  • "Show me the latest React documentation"

  • "Find best practices for TypeScript development"

  • "Update documentation for Node.js"

  • "Search for information about async/await"

🛠 Available Tools

list_documentation

Lists all available documentation sources with optional category filtering.

add_documentation

Add new documentation sources to the knowledge base.

update_documentation

Update existing documentation to get the latest content.

search_documentation

Search through documentation with category filtering.

📚 Documentation Categories

  • Frontend

  • Backend

  • Language

  • MCP

  • MCP-Guide

  • Database

  • DevOps

  • Security

  • Testing

  • Architecture

  • Mobile

  • AI

  • Cloud

🔧 Features

The server automatically:

  • Manages documentation from various sources

  • Keeps track of latest development best practices

  • Provides intelligent search capabilities

  • Updates documentation automatically

  • Supports tagging and categorization

  • Optimizes memory usage:

    • Uses streaming for large files

    • Automatic cache cleanup

    • Memory-efficient search

    • Size and age limits for cached files

    • Limited heap size (256MB)

📝 License

MIT License - feel free to use this in your projects!

👤 Author

aindreyway

⭐️ Support

Give a ⭐️ if this project helped you!

Available Tools

4 tools
add_documentationC

Add a new documentation source

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL of the documentation
nameYesName of the documentation
tagsNoTags for additional categorization
versionNoVersion information
categoryYesCategory of the documentation
descriptionNoDescription of the documentation

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are absent, so the description is the only source of behavioral information. It does not disclose any side effects, permissions, idempotency, or response format, leaving the agent to infer the operation's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the action. It is concise but sacrifices necessary detail for brevity.

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 the lack of annotations and output schema, the description is too minimal to be complete. It does not mention return values, error conditions, or any constraints beyond the parameter schema.

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?

All six parameters have descriptions in the schema, providing full coverage. The tool description does not add any additional semantic meaning beyond what the schema already states, so it meets the baseline.

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 verb 'Add' with the resource 'documentation source', clearly indicating a creation operation. It distinguishes from sibling tools like list, update, and search by its action verb, though it does not elaborate on specifics.

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 information about when to use this tool versus alternatives such as update_documentation. It lacks any context about prerequisites, typical scenarios, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_documentationC

List all available documentation sources

ParametersJSON Schema
NameRequiredDescriptionDefault
tagNoFilter documentation by tag
categoryNoFilter documentation by category

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden for behavioral disclosure. It implies a read-only operation ('list') but does not explicitly state safety or output behavior. The claim of 'all' conflicts with the schema's filter parameters, creating ambiguity about whether results are unfiltered or filterable.

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, short sentence with no redundant words. It is appropriately concise for a simple listing operation, though it sacrifices detail.

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?

The description omits the optional filtering capability exposed in the schema and does not differentiate from search_documentation. With no output schema and no annotations, the description should clarify what is listed and how filters relate, but it does not.

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 input schema already provides 100% coverage with descriptions for both optional parameters (tag and category). The tool description adds no additional parameter semantics, so it meets the baseline without enriching the schema.

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 a specific verb 'list' with the resource 'documentation sources' and includes scope ('all available'). It is clear and unambiguous, but it does not explicitly distinguish from sibling tools like search_documentation, which likely targets specific items.

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 given on when to use this tool instead of search_documentation or the add/update tools. The description does not mention scenarios, exclusions, or alternatives, leaving the agent without context for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_documentationC

Search through documentation content

ParametersJSON Schema
NameRequiredDescriptionDefault
tagNoFilter by tag
queryYesSearch query
categoryNoFilter by category

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are absent, so the description must disclose behavior. It only says 'Search through documentation content,' which implies a read-only operation but does not explain search mechanics (e.g., full-text vs exact match, filter combination, pagination). This is minimal transparency.

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. It is maximally concise and easy to parse.

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 no output schema and no annotations, the description must cover return values, usage context, and behavior. It only provides a basic phrase, leaving users to infer what results are returned and how filters combine. This is insufficient for a search tool with optional filters.

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 100%, so the parameter descriptions in the schema already explain query, tag, and category. The tool description adds no additional parameter semantics, warranting a baseline 3.

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 verb 'Search' clearly indicates the action, and 'documentation content' identifies the resource. It distinguishes from sibling tools like list_documentation, add_documentation, and update_documentation, though it could be more specific about the scope of search.

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 guidance on when to use this tool versus list_documentation or update_documentation. No context, prerequisites, or alternatives are mentioned, leaving the agent to infer appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_documentationC

Update documentation content from source

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesName of the documentation to update
forceNoForce update even if recently updated

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits, but it only says 'Update documentation content from source', which is vague. It does not mention side effects, whether changes are destructive, what the 'force' flag controls, or any prerequisites. This leaves significant ambiguity for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that is easy to read and not verbose. While it is under-specified in content, conciseness itself is high, and every word serves the basic 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?

Given the tool's complexity (2 params, no output schema, no annotations), the description is too incomplete. It does not explain what 'source' refers to, how the update is performed, potential side effects, or return values, leaving the agent without enough context to use it safely or effectively.

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 descriptions for both 'name' and 'force', so the baseline is 3. The description adds minimal extra meaning with the phrase 'from source', but it does not clarify how 'name' relates to the source or explain the 'force' behavior beyond the schema.

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 clearly states the verb 'update' and the resource 'documentation content', indicating it modifies existing documentation. It distinguishes from 'add_documentation' by implying an existing target, though it lacks explicit sibling differentiation or elaboration on what 'source' means.

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 like 'add_documentation' or 'search_documentation'. There are no conditions, exclusions, or scenario examples, leaving the agent to infer usage 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 4 tool updatesv1.0.12
    • First observedadd_documentation
    • First observedlist_documentation
    • First observedsearch_documentation
    • First observedupdate_documentation
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool targets a distinct action on documentation sources: listing, adding, updating, and searching. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case (list_, add_, update_, search_). This makes the API predictable and easy to navigate.

Tool Count5/5

Four tools is a well-scoped set for a documentation keeper, covering the essential operations without bloat or unnecessary additions.

Completeness4/5

The set covers list, add, update, and search, but lacks a delete operation, which is a minor gap in full lifecycle management. Agents can work around this limitation, but it is not a complete CRUD surface.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/AshutoshBuilds/mcp-codex-keeper'

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