Skip to main content
Glama
batosai

Adonis MCP Documentation Server

by batosai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Adonis MCP Documentation Server

MCP (Model Context Protocol) server to access adonis-mcp documentation.

๐Ÿ“‹ Resources

file:///{name}.md - Documentation Markdown File

Resource template to retrieve markdown documentation files from the GitHub repository.

Available files:

  • inspector - MCP Inspector tool documentation

  • installation - Installation guide

  • introduction - Introduction to MCP

  • prompts - Prompts documentation

  • resources - Resources documentation

  • sessions - Session management

  • tools - Tools documentation

  • unit-tests - Unit testing

Usage example:

file:///resources.md
file:///tools.md

Related MCP server: GitHub MCP Server

๐Ÿ› ๏ธ Tools

1. list_documentation

Lists all available documentation files with their descriptions.

Parameters: None

Returns: Structured list of all available documentation files

Annotations:

  • @isReadOnly() - Read-only

  • @isIdempotent() - Can be called multiple times without side effects

2. search_in_docs

Search for a keyword or phrase across all documentation files.

Parameters:

  • query (string, required) - The keyword or phrase to search for

  • caseSensitive (boolean, optional) - Case-sensitive search (default: false)

Returns: List of matches with context (2 lines before/after)

Annotations:

  • @isReadOnly() - Read-only

  • @isOpenWorld() - Accesses external resources (GitHub)

  • @isIdempotent() - Can be called multiple times without side effects

Example:

{
  "query": "Resource templates",
  "caseSensitive": false
}

3. extract_code_examples

Extracts all code blocks from a documentation file with their languages and line numbers.

Parameters:

  • filename (string, required) - File name (without .md extension)

Returns: Structured list of all code blocks with their language, content, and line number

Annotations:

  • @isReadOnly() - Read-only

  • @isOpenWorld() - Accesses external resources (GitHub)

  • @isIdempotent() - Can be called multiple times without side effects

Example:

{
  "filename": "resources"
}

๐ŸŽฏ Prompts

explain_feature

Guide to get a detailed explanation of an adonis-mcp feature with code examples.

Parameters:

  • feature (string, required) - The feature to explain

  • level (string, optional) - Audience level: "beginner", "intermediate", "advanced" (default: "intermediate")

Suggested features:

  • resources

  • tools

  • prompts

  • resource templates

  • tool annotations

  • completions

  • authentication

  • authorization

  • sessions

  • unit testing

  • inspector

  • middleware

Example:

{
  "feature": "resource templates",
  "level": "intermediate"
}

๐Ÿš€ Usage

Installation

Install globally via npm:

npm install -g adonis-mcp-docs

Or use with npx (no installation required):

npx adonis-mcp-docs

Testing locally before publishing

  1. Build the project:

npm run build

  1. Test with npx locally:

cd build
node bin/mcp.js

Start the MCP server

adonis-mcp-docs

Or with npx:

npx adonis-mcp-docs

Configuration for MCP Clients

Add to your Claude Desktop or Cursor MCP configuration:

{
  "mcpServers": {
    "adonis-mcp-docs": {
      "command": "npx",
      "args": ["adonis-mcp-docs"]
    }
  }
}

๐Ÿ“ฆ Services

DocumentationService

Manages retrieval of remote markdown files from GitHub.

Methods:

  • fetchMarkdownFile(name: string) - Fetches a markdown file

  • fileExists(name: string) - Checks if a file exists

  • getFileSize(name: string) - Gets the size of a file

ResourceCompletionService

Provides completion suggestions for documentation file names.

Methods:

  • getCompletions(prefix?: string) - Returns files matching the prefix

  • getAllNames() - Returns all available file names

๐Ÿ” Combined Usage Examples

Search then read

  1. Use search_in_docs to find where a concept is documented

  2. Use the file:///{name}.md resource to read the complete content

Extract and analyze

  1. Use extract_code_examples to get all examples

  2. Analyze the code with a custom prompt

Explore then explain

  1. Use list_documentation to see what's available

  2. Use the explain_feature prompt to get a detailed explanation

๐Ÿ“ Technical Notes

  • Base URL: https://raw.githubusercontent.com/batosai/adonis-mcp/main/docs

  • Format: Markdown (.md)

  • Search: Case-insensitive by default with 2 lines of context

  • Parsing: Code block extraction with automatic language detection

๐ŸŽจ Advanced Features

  • โœ… Completions enabled for all templates

  • โœ… Tool annotations to guide AI

  • โœ… Robust error handling

  • โœ… Search with context

  • โœ… Automatic extraction of all code blocks with language detection

Available Tools

3 tools
extract_code_examplesExtract Code ExamplesA
Read-onlyIdempotent

Extracts all code blocks from a documentation file with their language and line numbers

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYesName of the documentation file (without .md extension, e.g., "resources", "tools")

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds behavioral context beyond annotations by specifying that it extracts all code blocks and includes language and line numbers, clarifying the output scope and nature of the 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 that front-loads the action and resource, then adds the output detail. It contains no redundant phrasing, filler, or unrelated context, making it highly concise and efficiently scannable.

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, read-only extraction tool with one well-documented parameter and safety annotations, the description covers the essential behavior and return characteristics. It mentions 'all code blocks' and the inclusion of language and line numbers, mitigating the absence of an output schema. The schema handles the filename format, so nothing critical is missing for an agent to invoke 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?

The only parameter, filename, is fully described in the schema, including the no-.md-extension convention and concrete examples ('resources', 'tools'). With 100% schema coverage, the description does not need to add parameter semantics; the baseline of 3 applies because the description merely reinforces the 'documentation file' concept already present in 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 the specific verb 'Extracts' with a clear resource ('all code blocks from a documentation file') and specifies the output characteristics (language and line numbers). This clearly distinguishes it from sibling tools like list_documentation and search_in_docs, which serve different purposes.

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 clearly indicates the operation and context: use this when you need to extract code blocks from a documentation file. It does not explicitly contrast with siblings, but the distinct purpose makes the usage evident. No exclusions or prerequisites are stated, but none are needed for this straightforward read operation.

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

list_documentationList Documentation FilesA
Read-onlyIdempotent

Lists all available documentation markdown files with their names and descriptions

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior4/5

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

With readOnlyHint and idempotentHint already present, the annotations cover safety and side-effect behavior. The description adds the useful behavioral context that the result contains file names and descriptions, which is more than the annotations alone provide and compensates for the lack of an output schema.

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 with no filler. The verb, scope, and output detail are all included with high efficiency, and the description is front-loaded with the key action 'Lists'.

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 zero-parameter, read-only, idempotent list tool, the description is complete: it identifies the resource type, the scope ('all available'), and the return content ('names and descriptions'). No output schema exists, so this succinct description supplies the necessary contract.

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 input schema has zero parameters, so there is nothing for the description to clarify. The baseline for a parameterless tool is 4, and the description appropriately avoids inventing unnecessary parameter guidance.

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 'Lists', identifies the resource as 'all available documentation markdown files', and states the output includes 'names and descriptions'. It is clear and actionable, though it does not explicitly distinguish itself from the sibling tools.

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 use when the agent needs an overview or inventory of documentation files. However, it does not explicitly state when to use this tool instead of search_in_docs or extract_code_examples, leaving the routing decision to inference.

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

search_in_docsSearch in DocumentationA
Read-onlyIdempotent

Search for a keyword or phrase across all documentation files and return matching sections

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe search query (keyword or phrase to find in documentation)
caseSensitiveNoWhether the search should be case-sensitive (default: false)

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds useful scope ('across all documentation files') and result behavior ('return matching sections'), but does not detail edge cases, matching semantics, or result formatting.

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 front-loads the action and outcome with no wasted words. Every element 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, two-parameter search tool, the description is functionally complete. The absence of an output schema is partially mitigated by 'return matching sections', though an explicit result format would make it 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?

Schema description coverage is 100%, so both query and caseSensitive are already documented in the schema. The description only restates the general notion of 'keyword or phrase' without adding extra meaning beyond the structured definition.

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') and resource ('all documentation files'), and clearly states the outcome: 'return matching sections'. This distinguishes it naturally from siblings like list_documentation and extract_code_examples.

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 conveys when to use the tool: when you need to find a keyword or phrase in documentation. However, it does not explicitly mention alternatives or when not to use it, leaving the comparison to sibling tools implicit.

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.

  1. 3 tool updatesv0.2.0
    • First observedextract_code_examples
    • First observedlist_documentation
    • First observedsearch_in_docs
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a distinct operation: discovering files, searching content, and extracting code examples. There is no meaningful overlap or ambiguity between them.

Naming Consistency5/5

All tool names use a consistent lowercase snake_case verb-first pattern: list_documentation, search_in_docs, extract_code_examples. The naming style is predictable and easy to follow.

Tool Count4/5

Three tools is a reasonable, focused count for a documentation helper, and each tool serves a clear purpose. It is slightly on the low side because a direct full-document retrieval tool would round out the set.

Completeness2/5

The set supports listing, searching, and extracting code blocks, but lacks a direct 'read/get documentation file' tool. Agents cannot retrieve full document content, which is a significant gap for a documentation server and will cause failures when complete text is needed.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers