Which integrations are available for this server?

Fetches official CrewAI documentation for multi-agent orchestration and workflows. Fetches official Django documentation for models, views, templates, and the ORM. Fetches official Express.js documentation for middleware, routing, and HTTP utilities. Fetches official FastAPI documentation for building APIs with automatic OpenAPI generation. Fetches official documentation for LangChain, enabling retrieval of chain and agent tutorials and examples. Fetches official documentation for LangGraph from the web, providing access to agent creation guides and API references. Fetches official Next.js documentation for server-side rendering, routing, and API routes. Fetches official NumPy documentation for array operations, linear algebra, and mathematical functions. Fetches official Pandas documentation for data manipulation, DataFrames, and I/O. Fetches official PyTorch documentation, including tensor operations and neural network modules. Fetches official React documentation, including hooks, components, and state management. Fetches official TensorFlow documentation for model building, training, and deployment.

How do I use CHECK-MODULE MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CHECK-MODULE MCP Server Fetch official React hooks documentation" 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.

CHECK-MODULE MCP Server

by muhammedehab35

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

CHECK-MODULE MCP Server

A powerful Model Context Protocol (MCP) server for managing internal documentation and fetching official library documentation from the web.

License: MIT TypeScript Node MCP

🎥 Demo

https://github.com/user-attachments/assets/aec8d362-4ac3-477f-84db-fc304cd7e927

Watch CHECK-MODULE in action: fetching documentation, searching internal docs, and managing custom documentation with Claude Desktop.

Related MCP server: MCP Framework Documentation Server

🎯 Features

📚 Internal Documentation Management - Store, search, and manage your custom documentation
🌐 Web Documentation Fetching - Automatically fetch official documentation from 13+ popular libraries
🔍 Smart Search - Relevance-based search with category and tag filtering
📝 Markdown Support - Full Markdown formatting for documentation
🔧 MCP Tools - 6 powerful tools exposed via Model Context Protocol
📦 Resources - URI-based access to documentation (doc://internal/*)

📦 Installation

# Clone the repository
git clone https://github.com/muhammedehab35/CHECK-MODULE-MCP.git
cd CHECK-MODULE-MCP

# Install dependencies
npm install

# Build the project
npm run build

⚙️ Configuration

Add to your Claude Desktop config file (claude_desktop_config.json):

Windows: %APPDATA%\Claude\claude_desktop_config.json macOS/Linux: ~/.claude/claude_desktop_config.json

{
  "mcpServers": {
    "CHECK-MODULE": {
      "command": "node",
      "args": [
        "/absolute/path/to/CHECK-MODULE-MCP/dist/index.js"
      ]
    }
  }
}

Then restart Claude Desktop completely.

🚀 Usage

Internal Documentation Tools

`search-docs` - Search your internal documentation

Search for "authentication" in the documentation

`get-doc` - Get a complete document by ID

Show me the Authentication API guide

`list-categories` - List all documentation categories

What documentation categories are available?

`add-doc` - Add or update documentation

Add documentation about Redis caching with ID "redis-cache"

Web Documentation Fetching

`fetch-library-docs` - Fetch official documentation from the web

Use CHECK-MODULE to fetch LangGraph documentation about creating agents

`list-available-libraries` - Show supported libraries

What libraries can CHECK-MODULE fetch documentation for?

📚 Supported Libraries

CHECK-MODULE can automatically fetch documentation for:

AI/ML: LangGraph, LangChain, PyTorch, TensorFlow, CrewAI
Web Frameworks: React, Next.js, Vue, Express, FastAPI, Django
Data Science: Pandas, NumPy

🛠️ Available Tools

Tool	Description
`search-docs`	Search internal documentation with filters
`get-doc`	Retrieve full document by ID
`list-categories`	List all documentation categories
`add-doc`	Add or update documentation
`fetch-library-docs`	Fetch official docs from the web
`list-available-libraries`	Show supported libraries

🏗️ Project Structure

CHECK-MODULE-MCP/
├── src/
│   ├── index.ts          # Main MCP server
│   ├── docStore.ts       # Documentation storage
│   ├── webFetcher.ts     # Web documentation fetcher
│   └── types.ts          # TypeScript type definitions
├── dist/                 # Compiled JavaScript (generated)
├── package.json          # Project configuration
├── tsconfig.json         # TypeScript configuration
└── README.md             # This file

🔧 Development

# Install dependencies
npm install

# Build
npm run build

# Watch mode (auto-rebuild)
npm run watch

# Run manually (for testing)
npm start

📖 Examples

Example 1: Search Internal Docs

User: Search for "deployment" in DevOps category
Claude: [Uses search-docs tool]
Found 1 result: Deployment Guide with Docker/Kubernetes instructions

Example 2: Fetch Web Documentation

User: How do I create an agent in LangGraph?
Claude: [Uses fetch-library-docs tool]
Fetches from https://langchain-ai.github.io/langgraph/
Returns: Step-by-step guide with code examples

Example 3: Add Custom Documentation

User: Add docs about our Redis caching strategy
Claude: [Uses add-doc tool]
Documentation stored with ID "redis-cache"

🎨 Customization

Adding More Libraries

Edit src/webFetcher.ts to add custom documentation sources:

const DOC_SOURCES: Record<string, string> = {
  'your-library': 'https://docs.your-library.com/',
  // ... existing libraries
};

Then rebuild: npm run build

Pre-loading Documentation

Edit src/docStore.ts in the initializeSampleDocs() method to add your initial documentation.

🐛 Troubleshooting

Server not starting

# Test the build
npm run build

# Run directly
node dist/index.js
# Should output: "CHECK-MODULE MCP Server running on stdio"

Claude doesn't see the tools

Check that the path in claude_desktop_config.json is absolute
Restart Claude Desktop completely
Check developer console (Ctrl+Shift+I) for errors

Web fetching not working

Ensure you have internet connection
Check if the library is in the supported list
The library name must match exactly (case-insensitive)

📝 Pre-loaded Documentation

The server comes with 3 example documents:

Authentication API (api-auth) - JWT authentication guide
Database Schema (db-schema) - PostgreSQL schema reference
Deployment Guide (deploy-guide) - Docker/Kubernetes deployment

🔮 Roadmap

Add more library documentation sources
Implement persistent storage (SQLite/PostgreSQL)
Add version history tracking
Support for custom authentication
REST API for external management
Import from Markdown files
Export documentation to various formats

🤝 Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Fork the project
Create your feature branch (git checkout -b feature/AmazingFeature)
Commit your changes (git commit -m 'Add some AmazingFeature')
Push to the branch (git push origin feature/AmazingFeature)
Open a Pull Request

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

🙏 Acknowledgments

Built with @modelcontextprotocol/sdk
Inspired by Context7
Uses Zod for schema validation

📞 Support

Issues: GitHub Issues
Documentation: MCP Documentation

Made with ❤️ using TypeScript and MCP

Available Tools

6 tools

add-docC

Add or update documentation. Stores a new document or updates an existing one.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Unique document ID
`title`	Yes	Document title
`description`	Yes	Short description
`content`	Yes	Full document content (supports Markdown)
`category`	Yes	Category (e.g., API, Database, DevOps)
`tags`	Yes	Tags for categorization
`version`	No	Optional: Document version

TDQS

C2.9/5.0

Behavior2/5

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

The description only says 'Stores a new document or updates an existing one,' but lacks details on whether updates are partial or full replacements, or any side effects. With no annotations, the description fails to provide sufficient behavioral context.

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

Conciseness4/5

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

The description is concise and front-loaded, but it is too brief to convey necessary detail. No wasted words, but could be expanded.

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 7 parameters and no output schema or annotations, the description is incomplete. It does not explain behavior on duplicate IDs, confirm creation vs update, or return type. More context 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?

The input schema covers all 7 parameters with descriptions, so the description adds no additional semantic value. Baseline score 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 clearly states the tool adds or updates documentation, distinguishing it from sibling tools like get-doc which only retrieve. However, it does not explicitly differentiate between the add and update behaviors.

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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives like search-docs or list-categories.

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

fetch-library-docsC

Fetch official documentation from online sources for libraries and frameworks (LangGraph, React, FastAPI, etc.). Automatically retrieves up-to-date documentation from the web.

ParametersJSON Schema

Name	Required	Description	Default
`library`	Yes	Name of the library/framework (e.g., "LangGraph", "React", "FastAPI")
`query`	No	Optional: Specific topic to search for in the documentation (e.g., "create agent", "routing")

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided; the description only says 'automatically retrieves up-to-date documentation from the web.' It omits details on caching, network requirements, error handling, or rate limits. The agent cannot infer potential side effects or constraints.

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?

Two short sentences that state purpose and automation. No fluff, but could be more efficient by including key behavioral notes in the same length.

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?

No output schema; the description does not explain what the tool returns (e.g., raw text, markdown, error format). Given simple parameters, the agent still lacks information to anticipate the response format. Also unclear how this differs from 'search-docs' in terms of scope.

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%, so the schema fully describes both parameters. The description adds 'Optional: Specific topic to search for' for query, but this merely restates the schema's description. No additional semantic depth 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 tool fetches official documentation from online sources for libraries/frameworks, with examples. It distinguishes from siblings like 'add-doc' (likely local addition) and 'search-docs' (possibly local search), but more explicit differentiation would improve clarity.

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 on when to use this tool versus alternatives. The description does not mention prerequisites, edge cases, or scenarios where other tools like 'search-docs' might be preferred.

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

get-docA

Get full documentation by ID. Returns the complete content of a specific document.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Document ID

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It states it returns complete content, which implies a read operation, but doesn't disclose any potential side effects, authentication needs, or rate limits. Adequate for a simple read.

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, 14 words, front-loaded with action. Every word earns its place. No redundancy.

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 a single simple parameter and no output schema, the description is fairly complete. It tells what it does and what parameter is needed. Could mention error handling or return format, but adequate for a simple get-by-ID.

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% with one parameter 'id'. The description adds no additional meaning beyond the schema, which already documents 'Document ID'. Baseline score 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 clearly states 'get full documentation by ID' with a specific verb and resource. It distinguishes from siblings like search-docs and list-categories, but could be more explicit about what constitutes 'full documentation'.

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 when you have a document ID, but provides no guidance on when to use this tool vs alternatives like search-docs or fetch-library-docs. No explicit when-not or exclusions.

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

list-available-librariesA

List all libraries that have known documentation sources configured.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It clearly states the tool lists libraries with documentation sources, implying a read-only operation. However, it does not disclose whether authentication or state effects exist, though the operation is simple enough that this is minimally adequate.

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, well-structured sentence of 8 words that front-loads the action ('List all libraries'). No word is wasted, and it efficiently conveys the tool'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 tool with no parameters, no output schema, and no annotations, the description is nearly complete. It states the filtering condition and lists libraries. However, it does not describe the return format (e.g., list of names or objects), which would be helpful given the absence of an output schema.

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?

There are no parameters, and the schema coverage is trivially 100%. The description adds meaning by specifying the filtering condition ('known documentation sources configured'), which is not present in the empty schema. Per guidelines, 0 params yields a baseline of 4.

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 'list' and resource 'libraries' with a clear filter condition 'that have known documentation sources configured'. This distinguishes it from sibling tools like list-categories or search-docs.

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 siblings, nor are there any when-not-to-use or prerequisite mentions. The description only states the purpose without contextual usage advice.

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

list-categoriesA

List all available documentation categories.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so the description must carry the behavioral burden. It states the tool lists all categories, implying a read-only operation, but does not explicitly confirm safety, side effects, or prerequisites. For a simple read operation, it is minimally adequate.

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 with the verb and resource. Every word earns its place; no redundancy.

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 zero parameters, no output schema, and sibling tools that provide context, the description is complete enough for a simple listing tool. It does not elaborate on return format or what categories are, but the purpose is clear.

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?

There are no parameters, so schema description coverage is 100%. The description does not add parameter semantics beyond the schema, but with zero parameters, there is nothing to add. Baseline of 4 is appropriate.

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 'List all available documentation categories' is a specific verb+resource combination. It clearly states the tool lists categories, which is distinct from sibling tools that deal with docs or libraries.

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?

No guidance on when to use this tool versus alternatives. While the tool is simple and the context is clear from sibling names, the description does not explicitly state usage context or exclusions.

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

search-docsA

Search through internal documentation. Returns relevant documents based on query, category, and tags.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query to find relevant documentation
`category`	No	Optional: Filter by category (API, Database, DevOps, etc.)
`tags`	No	Optional: Filter by tags
`limit`	No	Maximum number of results (default: 10)

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are present, so the description carries full burden. It states the tool returns relevant documents but does not disclose behavioral traits such as pagination, sorting, rate limits, or scope. The read-only nature is implied but not explicitly confirmed.

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 concise with two sentences that front-load the core purpose. Every sentence adds value without unnecessary detail.

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 search tool with 4 parameters (1 required) and no output schema, the description adequately explains the purpose and basic parameters but lacks details about return format, pagination, error handling, or performance implications. It is complete enough for basic use but not thorough.

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%, and the description adds limited value beyond what the schema already provides. It mentions the parameters (query, category, tags) but does not elaborate on their semantics or usage beyond the existing schema descriptions.

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 searches internal documentation and returns relevant documents based on query, category, and tags. It distinguishes from siblings like add-doc and get-doc by focusing on search functionality.

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 searching documentation but provides no explicit guidance on when to use this tool versus alternatives like get-doc (single document retrieval) or list-available-libraries. No exclusions or context about when not to use it are given.

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.

6 tool updatesv1.0.0May 29, 2026
- First observedadd-doc
- First observedfetch-library-docs
- First observedget-doc
- First observedlist-available-libraries
- First observedlist-categories
- First observedsearch-docs

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored 2026-05-29 23:40 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: adding/updating docs, fetching external docs, retrieving by ID, listing libraries, listing categories, and searching. No overlap.

Naming Consistency5/5

All tool names follow a consistent lowercase-hyphenated verb-noun pattern (e.g., add-doc, fetch-library-docs, list-available-libraries).

Tool Count5/5

With 6 tools covering creation, retrieval, listing, searching, and external fetching, the set is well-scoped for a documentation server.

Completeness4/5

The tools cover core CRUD operations (add, get, search, list) and add external fetching, but lack an explicit delete or separate update tool (though add-doc covers both add and update).

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
renCosta2025-context7fork
ai.smithery
Get up-to-date, version-specific documentation and code examples from official sources directly in…
Documentation Access Developer Tools Search
2
llmref A
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
42
Knowa
com.knowalabs
Team docs served to AI agents over MCP - search, Markdown reads, version pinning, read audit.
Documentation Access Knowledge & Memory Search
2

Related MCP Servers

MCP Documentation Server
Documentation Access Developer Tools Search
glassBead-tc
A
license
B
quality
D
maintenance
Provides comprehensive access to MCP documentation through structured guides, full-text search, and interactive development workflows for building servers and clients.
Updated a year ago (2025-09-19 13:06 UTC)
3
8
MIT
MCP Framework Documentation
Documentation Access Developer Tools Search
QuantGeekDev
A
license
A
quality
D
maintenance
Provides tools for AI agents to search, browse, and retrieve the full documentation for the mcp-framework. It enables agents to access documentation sections and page content directly within MCP-compatible environments like Claude Code and Cursor.
Updated 5 months ago (2026-04-01 17:57 UTC)
3
6
MIT
docs-mcp
Documentation Access Developer Tools
base-kit
A
license
Not graded
quality
A
maintenance
Provides a local MCP server for searching and retrieving documentation from 22+ open-source projects, enabling AI coding assistants to access up-to-date docs without network dependency.
Updated 3 months ago (2026-06-21 09:55 UTC)
8
2
MIT
opencode-docs
Documentation Access Search Web Scraping
salmenkhelifi1
F
license
Not graded
quality
D
maintenance
Scrapes, stores, and searches documentation locally, enabling AI assistants to access and query documentation via MCP.
Updated 8 months ago (2026-01-14 04:55 UTC)
4
-

CHECK-MODULE MCP Server

🎥 Demo

🎯 Features

📦 Installation

⚙️ Configuration

🚀 Usage

Internal Documentation Tools

search-docs - Search your internal documentation

get-doc - Get a complete document by ID

list-categories - List all documentation categories

add-doc - Add or update documentation

Web Documentation Fetching

fetch-library-docs - Fetch official documentation from the web

list-available-libraries - Show supported libraries

📚 Supported Libraries

🛠️ Available Tools

🏗️ Project Structure

🔧 Development

📖 Examples

Example 1: Search Internal Docs

Example 2: Fetch Web Documentation

Example 3: Add Custom Documentation

🎨 Customization

Adding More Libraries

Pre-loading Documentation

🐛 Troubleshooting

Server not starting

Claude doesn't see the tools

Web fetching not working

📝 Pre-loaded Documentation

🔮 Roadmap

🤝 Contributing

📄 License

🙏 Acknowledgments

📞 Support

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`search-docs` - Search your internal documentation

`get-doc` - Get a complete document by ID

`list-categories` - List all documentation categories

`add-doc` - Add or update documentation

`fetch-library-docs` - Fetch official documentation from the web

`list-available-libraries` - Show supported libraries