How do I use Open-E JovianDSS REST API Documentation MCP Server?

1. Click on "Install 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., "@Open-E JovianDSS REST API Documentation MCP Server search for volume management in the latest 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.

Open-E JovianDSS REST API Documentation MCP Server

by miroslawfranek

Overview Schema Related Servers Score Discussions

Remote

Open-E JovianDSS REST API Documentation MCP Server

A Model Context Protocol (MCP) server that provides Claude Code with access to Open-E JovianDSS REST API documentation, enabling intelligent assistance with JovianDSS development and integration.

🚀 Features

📚 Documentation Access: Retrieve latest or trunk versions of JDSS REST API documentation
🔍 Smart Search: Search within documentation for specific terms, endpoints, and concepts
🔗 API Analysis: Extract and analyze API endpoints, HTTP methods, and schemas
📥 ZIP Downloads: Access complete documentation packages for offline use
🆚 Version Comparison: Compare different versions of documentation
🎯 Global Installation: Install once, use everywhere across all your projects

Related MCP server: Apidog MCP Server

📦 Installation

Quick Install (Recommended)

# Install globally from GitHub
npm install -g https://github.com/miroslawfranek/JDSS-REST-Documentation-MCP.git

# Verify installation
jdss-rest-doc --help

Manual Installation

# Clone repository
git clone https://github.com/miroslawfranek/JDSS-REST-Documentation-MCP.git
cd JDSS-REST-Documentation-MCP

# Install dependencies
npm install

# Make globally available
npm install -g .

Using Installation Script

# Run the comprehensive installation script
./install.sh

🔧 Configuration

Claude Code Integration

Add to your Claude Code MCP configuration:

{
  "mcpServers": {
    "jdss-rest-documentation": {
      "command": "jdss-rest-doc-mcp",
      "env": {
        "NODE_ENV": "production"
      }
    }
  }
}

Claude Desktop Integration

Add to Claude Desktop settings:

{
  "mcpServers": {
    "jdss-rest-documentation": {
      "command": "node",
      "args": ["path/to/jdss-rest-doc-mcp/index.js"]
    }
  }
}

🎯 Usage

Command Line Interface

# Start MCP server
jdss-rest-doc start

# Test documentation access
jdss-rest-doc test

# Explore and download documentation
jdss-rest-doc explore

# Show configuration information
jdss-rest-doc config

# View usage examples
jdss-rest-doc demo

Claude Integration

Once configured, you can ask Claude:

"Get the latest JovianDSS REST API documentation"
"Search for 'volume' in the JDSS documentation"
"Analyze the API endpoints in the JovianDSS documentation"
"Compare latest and trunk versions of JDSS docs"
"Download the complete JDSS documentation as ZIP"

🛠️ Available MCP Tools

1. `get_edss_documentation`

Retrieve JDSS REST API documentation content.

Parameters:

version: "latest" or "trunk" (default: "latest")
section: Optional specific section to extract

Example:

{
  "name": "get_edss_documentation",
  "arguments": {
    "version": "latest",
    "section": "authentication"
  }
}

2. `search_edss_documentation`

Search within the documentation for specific terms.

Parameters:

query: Search term (required)
version: "latest", "trunk", or "both" (default: "latest")

Example:

{
  "name": "search_edss_documentation", 
  "arguments": {
    "query": "volume management",
    "version": "both"
  }
}

3. `analyze_edss_api_endpoints`

Extract and analyze API endpoints from documentation.

Parameters:

version: "latest" or "trunk" (default: "latest")
detailed: Include detailed analysis (default: false)

4. `download_edss_documentation`

Get information about downloading documentation as ZIP.

Parameters:

download: Return download information (default: true)

5. `compare_documentation_versions`

Compare different versions of the documentation.

Parameters:

focus: "endpoints", "changes", "summary", or "all" (default: "summary")

📋 Documentation URLs

The MCP server accesses these Open-E JovianDSS documentation sources:

Latest: http://dh.lan:777/docs/EDSS/JEFFERSONVILLE/documentation/v4/
Trunk: http://dh.lan:777/docs/EDSS/trunk/documentation/v4/
ZIP Download: http://dh.lan:777/docs/EDSS/JEFFERSONVILLE/documentation/v4/get_doc.php?t=zip

🏗️ Development

Project Structure

jdss-rest-mcp/
├── package.json              # NPM package configuration
├── README.md                  # This documentation
├── index.js                   # Main MCP server
├── cli.js                     # Command-line interface
├── install.sh                 # Installation script
├── edss-doc-explorer.js       # Documentation analysis tool
└── examples/
    ├── claude-queries.md      # Example Claude interactions
    └── mcp-config.json        # MCP configuration examples

Prerequisites

Node.js: Version 18.0.0 or higher
npm: Latest stable version
Network Access: To Open-E documentation servers

Local Development

# Clone repository
git clone https://github.com/miroslawfranek/JDSS-REST-Documentation-MCP.git
cd JDSS-REST-Documentation-MCP

# Install dependencies
npm install

# Run in development mode
npm run dev

# Test CLI functionality  
npm run test

🧪 Testing

Test Documentation Access

# Test all documentation endpoints
jdss-rest-doc test

# Test with Node.js directly
node cli.js test

Test MCP Server

# Start server and test with Claude
npm start

# Run exploration and analysis
npm run explore

📖 Documentation Structure

The JovianDSS REST API documentation typically includes:

Authentication: API key management and login procedures
Volume Management: Create, modify, and delete storage volumes
Pool Operations: ZFS pool management and monitoring
System Information: Hardware status and system configuration
User Management: User accounts and permissions
Monitoring: Performance metrics and health status
Backup & Replication: Data protection features
Network Configuration: iSCSI, NFS, and CIFS settings

🔍 Search Capabilities

The MCP server can find information about:

API Endpoints: /api/v4/volumes, /api/v4/pools, etc.
HTTP Methods: GET, POST, PUT, DELETE operations
Parameters: Request/response schemas and data types
Authentication: Token-based access and session management
Error Codes: HTTP status codes and error handling
Medical/Clinical Terms: Patient, assessment, score, examination
Storage Terms: Volume, pool, dataset, snapshot, replication

🤝 Contributing

Fork the repository
Create a feature branch: git checkout -b feature-name
Make your changes and test thoroughly
Commit with clear messages: git commit -m "Add feature description"
Push to your fork: git push origin feature-name
Submit a pull request

📄 License

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

🙏 Acknowledgments

Open-E, Inc. - For JovianDSS and comprehensive REST API documentation
Anthropic - For Claude and the Model Context Protocol framework
Professional Wiki - For MCP server architecture inspiration

📞 Support

Issues: GitHub Issues
Documentation: Project Wiki
Open-E Support: Open-E Knowledge Base

🎯 Ready to enhance your JovianDSS development experience with intelligent documentation assistance!

Available Tools

7 tools

analyze_edss_api_endpointsC

Extract and analyze API endpoints from EDSS documentation

ParametersJSON Schema

Name	Required	Description	Default
`version`	No	Documentation version to analyze	latest
`detailed`	No	Include detailed analysis of endpoints, parameters, and schemas

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as whether the tool is read-only, what it outputs, or side effects. The minimal 'extract and analyze' leaves much to inference.

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, concise sentence that is easy to parse. However, it could benefit from slightly more structure or bullet points for clarity.

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 multiple siblings and no output schema, the description is insufficient. It does not explain what 'analyze' entails, the output format, or how it differs from similar tools like 'get_edss_documentation_enhanced'.

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 schema already explains the 'version' and 'detailed' parameters. The tool description adds no additional meaning beyond what is in 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 action ('extract and analyze') and the resource ('API endpoints from EDSS documentation'). It is distinguishable from siblings like 'get_edss_documentation', but does not explicitly contrast with them.

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 like 'search_edss_documentation' or 'get_edss_documentation_enhanced'. The description lacks any contextual usage hints.

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

compare_documentation_versionsA

Compare latest and trunk versions of EDSS documentation

ParametersJSON Schema

Name	Required	Description	Default
`focus`	No	What to focus the comparison on	summary

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, and the description only says 'compare' without detailing behavioral traits like output format, side effects, or authentication needs. Minimal transparency beyond the basic action.

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 directly states the tool's purpose without any waste, achieving maximum efficiency.

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 tool with one parameter and no output schema, the description is minimal but sufficient to convey core purpose. Lacks details on comparison output or behavior, which could aid agent understanding, especially given sibling tools.

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 the 'focus' parameter described, but the tool description adds no extra meaning to how the parameter affects behavior. Baseline of 3 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 uses specific verb 'compare' and resource 'latest and trunk versions of EDSS documentation', clearly distinguishing it from sibling tools like analyze, discover, or search.

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 comparing versions but does not explicitly state when to use this tool over alternatives or provide exclusions, such as when to use analyze_edss_api_endpoints instead.

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

discover_documentation_linksB

Discover all available EDSS documentation by parsing dh.lan homepage

ParametersJSON Schema

Name	Required	Description	Default
`refresh`	No	Force refresh discovery cache

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral transparency. It mentions parsing a homepage to discover links, implying a read operation, but does not confirm that it is non-destructive, disclose caching behavior (though hinted by the 'refresh' parameter in schema), or address any side effects.

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

Conciseness5/5

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

The description is a single sentence that immediately conveys the tool's purpose. It is front-loaded, efficient, and contains no unnecessary words.

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 explains the action and resource, but it lacks details about the output format or structure (no output schema provided). Given the simplicity of the tool (one optional parameter), the description is minimally complete but could benefit from specifying what the discovered links look like.

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% for the single boolean parameter 'refresh', so the description does not need to add meaning. It provides no additional context about the parameter beyond what the schema already offers, which is acceptable.

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 purpose: discovering all available EDSS documentation by parsing the dh.lan homepage. It uses a specific verb ('discover') and resource ('EDSS documentation links'), and distinguishes itself from sibling tools like search_edss_documentation or download_edss_documentation.

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 its siblings, such as search_edss_documentation or get_edss_documentation. There are no explicit conditions, exclusions, or alternative recommendations.

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

download_edss_documentationB

Get download link for EDSS documentation as ZIP file

ParametersJSON Schema

Name	Required	Description	Default
`download`	No	Return download information for ZIP file

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are present, and the description only states the function without disclosing behavioral traits like whether the download link expires, requires authentication, or has side effects.

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

Conciseness5/5

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

One concise sentence with no extraneous words, efficiently conveying the tool's purpose.

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 tool with one parameter, the description is adequate but could mention the nature of the download link (e.g., direct URL) and any prerequisites.

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 description coverage is 100% for the single boolean parameter 'download', and the tool description adds no additional 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 'Get download link for EDSS documentation as ZIP file' clearly states the action (Get) and the resource (download link for ZIP), distinguishing it from siblings like get_edss_documentation which likely returns content directly.

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 discover_documentation_links or get_edss_documentation. The description lacks context for selection.

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

get_edss_documentationA

Get EDSS REST API documentation (latest or trunk version)

ParametersJSON Schema

Name	Required	Description	Default
`version`	No	Documentation version to retrieve	latest
`section`	No	Optional: specific section or page to retrieve (if available)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided; description lacks details on response format, authentication needs, or side effects. Minimal behavioral disclosure.

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?

Single sentence with no superfluous words; front-loaded with key information.

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?

No output schema; description does not explain return format or prerequisites. Adequate for a simple retrieval but incomplete for a complex tool.

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 parameters; description adds no significant meaning beyond existing 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?

Clearly states verb 'Get' and resource 'EDSS REST API documentation' with specific version options, distinguishing it from sibling tools like search_edss_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?

Implies use for retrieving specific versions but does not explicitly guide when to use this tool over alternatives like get_edss_documentation_enhanced.

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

get_edss_documentation_enhancedC

Get EDSS documentation with automatic version discovery and jQuery processing

ParametersJSON Schema

Name	Required	Description	Default
`version`	No	Version: 'latest', 'trunk', or specific release name	latest
`apiVersion`	No		v4
`useJavaScript`	No	Process with jQuery to reveal hidden content

TDQS

C2.9/5.0

Behavior2/5

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

No annotations exist, so the description must disclose behaviors. It mentions jQuery processing to reveal hidden content, implying a non-destructive transformation, but fails to clarify side effects, auth needs, or error handling, leaving significant gaps.

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, concise sentence. While it is efficiently brief, it could include a bit more detail without becoming verbose, such as the purpose of the tool relative to siblings.

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 lacks critical context: no mention of return format, error conditions, or what 'automatic version discovery' entails. Given no output schema and 3 parameters, the description should provide more to ensure the agent can use the tool correctly.

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 67% (descriptions for 'version' and 'useJavaScript'), and the description adds context by linking 'automatic version discovery' to version defaults and 'jQuery processing' to the boolean parameter. However, it does not address the 'apiVersion' parameter, and the added value is moderate.

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 states 'Get EDSS documentation with automatic version discovery and jQuery processing', clearly indicating the action and unique features compared to siblings like 'get_edss_documentation'. However, 'automatic version discovery' is somewhat vague.

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 specify when to use this tool versus its siblings (e.g., 'get_edss_documentation', 'analyze_edss_api_endpoints'), leaving the agent without context for selection.

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

search_edss_documentationC

Search for specific terms or endpoints in EDSS documentation

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search term (e.g., 'patient', 'assessment', 'POST', '/api/patients')
`version`	No	Which version to search	latest

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided, so the description must convey behavior. It only states 'search' without detailing return format, pagination, or any side effects. Minimal behavioral insight.

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?

Single, clear sentence with no redundancy. However, it may be too brief to be fully effective. Still, it is well-structured and front-loaded.

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, so description should explain what the search returns. It does not mention result format, snippets, or links. Lacks context for effective use, especially given siblings.

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 100% with inline descriptions, but the description adds no additional meaning. It does not elaborate on parameter usage or expected input formats beyond what the schema provides.

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 'Search' and the resource 'EDSS documentation', indicating a search function. It distinguishes from sibling tools like 'get_edss_documentation' by focusing on term/endpoint lookup, but does not explicitly differentiate.

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 (e.g., get_edss_documentation for full docs). No exclusion criteria or prerequisites are mentioned.

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.

7 tool updatesv1.1.0Jan 26, 2026
- First observedanalyze_edss_api_endpoints
- First observedcompare_documentation_versions
- First observeddiscover_documentation_links
- First observeddownload_edss_documentation
- First observedget_edss_documentation
- First observedget_edss_documentation_enhanced
- First observedsearch_edss_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: discovering, downloading, retrieving, searching, analyzing endpoints, and comparing versions. No two tools have overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (e.g., discover_documentation_links, download_edss_documentation). No deviations or mixed conventions.

Tool Count5/5

7 tools is well-scoped for a documentation retrieval and analysis server. Each tool serves a clear need without unnecessary duplication.

Completeness4/5

Covers core documentation lifecycle: discovery, download, retrieval, search, analysis, and comparison. A minor gap is the absence of a tool for direct endpoint viewing, but search and analysis effectively address this.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

llmref A
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
42
docs-mcp A
com.redpanda
Get authoritative answers about Redpanda documentation and search API references.
Documentation Access Search Developer Tools
521
web3ctx A
io.github.FarseenSh
Version-true web3 docs, ABIs and human-validated integration recipes over MCP.
Web3 & Decentralized Tech Blockchain Documentation Access
51
ref-tools-ref-tools-mcpOAuth
ai.smithery
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Documentation Access Developer Tools Code Analysis
21,164

Related MCP Servers

Swagger/OpenAPI MCP Server
API Testing Documentation Access
gulbaki
A
license
D
quality
D
maintenance
A Model Context Protocol server that enables LLMs to explore and interact with API specifications by providing tools for loading, browsing, and getting detailed information about API endpoints.
Updated a year ago (2025-06-16 14:03 UTC)
4
16
14
ISC
Apidog MCP Server
API Testing Documentation Access Search
samhyun
A
license
Not graded
quality
D
maintenance
Enables AI tools to search and explore API documentation from Apidog projects or OpenAPI/Swagger specifications, providing endpoint details, schemas, and project statistics through natural language queries.
Updated 8 months ago (2025-12-31 00:35 UTC)
1,236
1
ISC
API Documentation MCP Server
Documentation Access Developer Tools API Testing
JaxNext
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that fetches detailed API documentation from a local platform using a document ID. It enables language models to retrieve specific endpoint specifications to assist with tasks like code generation and API integration.
Updated a year ago (2025-07-21 13:31 UTC)
131
ISC
Godot MCP Documentation Server
Documentation Access Developer Tools
banned104
A
license
A
quality
D
maintenance
Provides AI assistants with direct access to the complete Godot Engine documentation, including classes, tutorials, and features. It enables developers to retrieve and analyze official documentation through natural language interfaces using the Model Context Protocol.
Updated 7 months ago (2026-02-06 05:16 UTC)
2
MIT

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/miroslawfranek/JDSS-REST-Documentation-MCP'

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

Open-E JovianDSS REST API Documentation MCP Server

🚀 Features

📦 Installation

Quick Install (Recommended)

Manual Installation

Using Installation Script

🔧 Configuration

Claude Code Integration

Claude Desktop Integration

🎯 Usage

Command Line Interface

Claude Integration

🛠️ Available MCP Tools

1. get_edss_documentation

2. search_edss_documentation

3. analyze_edss_api_endpoints

4. download_edss_documentation

5. compare_documentation_versions

📋 Documentation URLs

🏗️ Development

Project Structure

Prerequisites

Local Development

🧪 Testing

Test Documentation Access

Test MCP Server

📖 Documentation Structure

🔍 Search Capabilities

🤝 Contributing

📄 License

🙏 Acknowledgments

📞 Support

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `get_edss_documentation`

2. `search_edss_documentation`

3. `analyze_edss_api_endpoints`

4. `download_edss_documentation`

5. `compare_documentation_versions`