Skip to main content
Glama
enesjakozh
ryanjoachim

mcp-rtfm

by ryanjoachim
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

MCP-RTFM

TypeScript MCP License: MIT

"RTFM!" they say, but what if there's no FM to R? 🤔 Enter MCP-RTFM: an MCP server that helps you create the F*ing Manual everyone keeps telling people to read! Using advanced content analysis, metadata generation, and intelligent search capabilities, it transforms your non-existent or unreadable docs into an interconnected knowledge base that actually answers those "basic questions" before they're asked.

Plot twist: Instead of just telling people to RTFM, now you can actually give them an FM worth R-ing! Because the best response to "read the f*ing manual" is having a manual that's actually worth reading. 📚✨

📚 Table of Contents

Related MCP server: GitMCP

🚀 Quick Start

# Install dependencies
npm install

# Build the server
npm run build

# Add to your MCP settings and start using
await use_mcp_tool({
  server: "mcp-rtfm",
  tool: "analyze_project_with_metadata", // Enhanced initialization
  args: { projectPath: "/path/to/project" }
});

// This will:
// 1. Create documentation structure
// 2. Analyze content with unified/remark
// 3. Generate intelligent metadata
// 4. Build search index with minisearch
// 5. Add structured front matter
// 6. Make your docs actually readable!

✨ Features

Documentation Management Tools

  • analyze_existing_docs - Analyze and enhance existing documentation with content analysis and metadata

  • analyze_project_with_metadata - Initialize documentation structure with enhanced content analysis and metadata generation

  • analyze_project - Basic initialization of documentation structure

  • read_doc - Read a documentation file (required before updating)

  • update_doc - Update documentation using diff-based changes

  • get_doc_content - Get current content of a documentation file

  • get_project_info - Get project structure and documentation status

  • search_docs - Search across documentation files with highlighted results

  • update_metadata - Update documentation metadata

  • get_related_docs - Find related documentation based on metadata and content links

  • customize_template - Create or update documentation templates

Default Documentation Files

The server automatically creates and manages these core documentation files:

  • techStack.md - Detailed inventory of tools, libraries, and configurations

  • codebaseDetails.md - Low-level explanations of code structure and logic

  • workflowDetails.md - Step-by-step workflows for key processes

  • integrationGuides.md - Instructions for external system connections

  • errorHandling.md - Troubleshooting strategies and practices

  • handoff_notes.md - Summary of key themes and next steps

Documentation Templates

Built-in templates for different documentation types:

  • Standard Documentation Template

  • API Documentation Template

  • Workflow Documentation Template

Custom templates can be created using the customize_template tool.

📝 Example Workflows

1. Analyzing Existing Documentation

// Enhance existing documentation with advanced analysis
await use_mcp_tool({
  server: "mcp-rtfm",
  tool: "analyze_existing_docs",
  args: { projectPath: "/path/to/project" }
});

// This will:
// - Find all markdown files in .handoff_docs
// - Analyze content structure with unified/remark
// - Generate intelligent metadata
// - Build search index
// - Add front matter if not present
// - Establish document relationships
// - Preserve existing content

// The results include:
// - Enhanced metadata for all docs
// - Search index population
// - Content relationship mapping
// - Git context if available

2. Enhanced Project Documentation Setup

// Initialize documentation with advanced content analysis
await use_mcp_tool({
  server: "mcp-rtfm",
  tool: "analyze_project_with_metadata",
  args: { projectPath: "/path/to/project" }
});

// Results include:
// - Initialized documentation files
// - Generated metadata from content analysis
// - Established document relationships
// - Populated search index
// - Added structured front matter
// - Git repository context

// Get enhanced project information
const projectInfo = await use_mcp_tool({
  server: "mcp-rtfm",
  tool: "get_project_info",
  args: { projectPath: "/path/to/project" }
});

// Search across documentation with intelligent results
const searchResults = await use_mcp_tool({
  server: "mcp-rtfm",
  tool: "search_docs",
  args: {
    projectPath: "/path/to/project",
    query: "authentication"
  }
});

// Results include:
// - Weighted matches (title matches prioritized)
// - Fuzzy search results
// - Full content context
// - Related document suggestions

3. Updating Documentation with Content Links

// First read the document
await use_mcp_tool({
  server: "mcp-rtfm",
  tool: "read_doc",
  args: {
    projectPath: "/path/to/project",
    docFile: "techStack.md"
  }
});

// Update with content that links to other docs
await use_mcp_tool({
  server: "mcp-rtfm",
  tool: "update_doc",
  args: {
    projectPath: "/path/to/project",
    docFile: "techStack.md",
    searchContent: "[Why this domain is critical to the project]",
    replaceContent: "The tech stack documentation provides essential context for development. See [[workflowDetails]] for implementation steps.",
    continueToNext: true // Automatically move to next document
  }
});

4. Managing Documentation Metadata

// Update metadata for better organization
await use_mcp_tool({
  server: "mcp-rtfm",
  tool: "update_metadata",
  args: {
    projectPath: "/path/to/project",
    docFile: "techStack.md",
    metadata: {
      title: "Technology Stack Overview",
      category: "architecture",
      tags: ["infrastructure", "dependencies", "configuration"]
    }
  }
});

// Find related documentation
const related = await use_mcp_tool({
  server: "mcp-rtfm",
  tool: "get_related_docs",
  args: {
    projectPath: "/path/to/project",
    docFile: "techStack.md"
  }
});

5. Searching Documentation with Context

// Search with highlighted results
const results = await use_mcp_tool({
  server: "mcp-rtfm",
  tool: "search_docs",
  args: {
    projectPath: "/path/to/project",
    query: "authentication"
  }
});

// Results include:
// - File name
// - Line numbers
// - Highlighted matches
// - Context around matches

6. Creating Custom Templates

// Create a custom template for architecture decisions
await use_mcp_tool({
  server: "mcp-rtfm",
  tool: "customize_template",
  args: {
    templateName: "architecture-decision",
    content: `# {title}

## Context
[Background and context for the decision]

## Decision
[The architecture decision made]

## Consequences
[Impact and trade-offs of the decision]

## Related Decisions
[Links to related architecture decisions]`,
    metadata: {
      category: "architecture",
      tags: ["decision-record", "design"]
    }
  }
});

🔧 Installation

VSCode (Roo Cline)

Add to settings file at: Add to settings file at:

  • Windows: %APPDATA%\Code\User\globalStorage\rooveterinaryinc.roo-cline\settings\cline_mcp_settings.json

  • MacOS: ~/Library/Application Support/Code/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json

  • Linux: ~/.config/Code/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json

{
  "mcpServers": {
    "mcp-rtfm": {
      "command": "node",
      "args": ["<path-to-mcp-rtfm>/build/index.js"],
      "disabled": false,
      "alwaysAllow": []
    }
  }
}

Claude Desktop

Add to config file at:

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "mcp-rtfm": {
      "command": "node",
      "args": ["<path-to-mcp-rtfm>/build/index.js"],
      "disabled": false,
      "alwaysAllow": []
    }
  }
}

🎯 Advanced Features

Content Linking

Use [[document-name]] syntax to create links between documents. The server automatically tracks these relationships and includes them when finding related documentation.

Metadata-Driven Organization

Documents are organized using:

  • Categories (e.g., "architecture", "api", "workflow")

  • Tags for flexible grouping

  • Automatic relationship discovery based on shared metadata

  • Content link analysis

Enhanced Content Analysis

The server uses advanced libraries for better documentation management:

  • unified/remark for Markdown processing:

    • AST-based content analysis

    • Accurate heading structure detection

    • Code block and link extraction

    • Proper Markdown parsing and manipulation

  • minisearch for powerful search capabilities:

    • Fast fuzzy searching across all documentation

    • Field-weighted search (titles given higher priority)

    • Full content and metadata indexing

    • Efficient caching with TTL management

    • Real-time search index updates

Intelligent Metadata Generation

  • Automatic content analysis for categorization

  • Smart tag generation based on content patterns

  • Structured front matter in documents

  • AST-based title and section detection

  • Code snippet identification and tagging

  • Context-aware result presentation

Template System

  • Built-in templates for common documentation types

  • Custom template support with metadata defaults

  • Template inheritance and override capabilities

  • Placeholder system for consistent formatting

🛠️ Development

# Install dependencies
npm install

# Build the server
npm run build

# Development with auto-rebuild
npm run watch

🐛 Debugging

Since MCP servers communicate over stdio, debugging can be challenging. Use the MCP Inspector:

npm run inspector

The Inspector will provide a URL to access debugging tools in your browser.

📄 License

MIT © Model Context Protocol

Available Tools

11 tools
analyze_existing_docsC

Analyze existing documentation files with enhanced content analysis and metadata generation

ParametersJSON Schema
NameRequiredDescriptionDefault
projectPathYesPath to the project root directory

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'enhanced content analysis and metadata generation' but doesn't specify what this entails—whether it's read-only, modifies files, requires specific permissions, or has performance implications. The description is too vague about actual behavior.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'enhanced analysis' means, what metadata is generated, the format of results, or how this differs from sibling tools. Given the complexity implied by 'enhanced' and lack of structured data, 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 schema description coverage is 100%, with the single parameter 'projectPath' well-documented in the schema. The description adds no additional parameter semantics beyond implying analysis occurs within a project directory, which is already clear from the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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 ('analyze') and target ('existing documentation files'), with additional context about 'enhanced content analysis and metadata generation'. However, it doesn't explicitly differentiate from sibling tools like 'analyze_project' or 'analyze_project_with_metadata', which appear related.

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 alternatives like 'analyze_project', 'get_doc_content', or 'search_docs'. It mentions 'enhanced content analysis' but doesn't specify what makes it 'enhanced' compared to other analysis tools.

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

analyze_projectC

Analyze project structure and create initial documentation files

ParametersJSON Schema
NameRequiredDescriptionDefault
projectPathYesPath to the project root directory

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'analyze' and 'create', implying read and write operations, but doesn't specify permissions needed, whether files are overwritten, what types of documentation are created, or error handling. For a tool with mutation potential and no annotations, this leaves 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.

Conciseness5/5

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

The description is a single, efficient sentence: 'Analyze project structure and create initial documentation files'. It's front-loaded with the core action, has no redundant words, and every part contributes to understanding the tool's purpose. This is appropriately concise for the complexity.

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 (involving analysis and file creation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'analyze' entails, what documentation files are created, or the return values. For a mutation tool with no structured behavioral data, more detail is needed to guide effective use.

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 has 100% description coverage, with 'projectPath' clearly documented as 'Path to the project root directory'. The description doesn't add any additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter documentation adequately.

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's purpose: 'Analyze project structure and create initial documentation files'. It specifies the verb ('analyze' and 'create') and resource ('project structure', 'documentation files'), making the action clear. However, it doesn't explicitly differentiate from siblings like 'analyze_existing_docs' or 'get_project_info', which might have overlapping scopes.

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 alternatives. With siblings such as 'analyze_existing_docs', 'analyze_project_with_metadata', and 'get_project_info', it's unclear if this tool is for new projects, existing ones, or specific contexts. No exclusions 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.

analyze_project_with_metadataC

Analyze project structure, create initial documentation files, and enhance with metadata/context

ParametersJSON Schema
NameRequiredDescriptionDefault
projectPathYesPath to the project root directory

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions actions ('analyze', 'create', 'enhance') but doesn't specify permissions needed, whether files are overwritten, error handling, or output format. For a tool with multiple implied operations, this is insufficient.

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, efficient sentence that front-loads key actions. It uses parallel structure ('analyze...create...enhance') with zero wasted words, making it easy to parse quickly.

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 complexity implied by multiple operations (analysis, file creation, metadata enhancement), no annotations, and no output schema, the description is incomplete. It lacks details on what 'enhance with metadata/context' entails, file types created, or success/failure indicators.

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%, with the single parameter 'projectPath' well-documented in the schema. The description adds no additional parameter details beyond implying analysis scope, so it meets the baseline for high schema coverage without compensating value.

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's purpose with specific verbs ('analyze', 'create', 'enhance') and resources ('project structure', 'documentation files', 'metadata/context'). It distinguishes from siblings like 'analyze_project' by mentioning documentation creation and metadata enhancement, though it could be more explicit about the differences.

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 alternatives like 'analyze_project' or 'analyze_existing_docs'. It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage from the purpose alone.

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

customize_templateC

Create or update a custom documentation template

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYesTemplate content with {title} placeholder
metadataNoDefault metadata for the template
templateNameYesName of the template

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'create or update', implying a mutation operation, but doesn't specify permissions required, whether changes are reversible, rate limits, or what happens on conflicts (e.g., if a template with the same name exists). For a mutation tool with zero annotation coverage, this is a significant gap in 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('create or update'), making it easy to parse quickly, and every part of the sentence contributes essential information.

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 (mutation with 3 parameters including nested objects) and lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, return values, or how 'create or update' is determined (e.g., based on 'templateName' existence), leaving critical gaps for an agent to use it 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 description coverage is 100%, with clear descriptions for all parameters (e.g., 'Template content with {title} placeholder' for 'content'). The description doesn't add any meaning beyond what the schema provides, such as explaining the purpose of the 'metadata' object or how 'templateName' is used in updates. Baseline 3 is appropriate when the schema does the heavy lifting.

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 'create or update' and the resource 'custom documentation template', making the purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'update_doc' or 'update_metadata', which also involve modifications to documentation-related resources, leaving some ambiguity about when to choose this specific template-focused tool.

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 alternatives. With sibling tools like 'update_doc' and 'update_metadata' that might overlap in functionality, there's no indication of prerequisites, specific contexts (e.g., for template management vs. direct document editing), or exclusions, leaving the agent to guess based on tool names alone.

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

get_doc_contentC

Get the current content of a documentation file

ParametersJSON Schema
NameRequiredDescriptionDefault
docFileYesName of the documentation file to read
projectPathYesPath to the project root directory

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'Get[s] the current content,' implying a read-only operation, but doesn't cover aspects like permissions, error handling, rate limits, or what 'current' entails (e.g., cached vs. live data). This leaves significant gaps for a tool with no annotation support.

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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.

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 incomplete. It doesn't explain what 'content' means (e.g., text, metadata, format) or the return values, which is crucial for a read operation. With no structured data to rely on, the description should provide more context but fails to do so.

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 has 100% description coverage, with clear documentation for both parameters ('docFile' and 'projectPath'). The description adds no additional meaning beyond the schema, such as examples or constraints, but the schema adequately covers the basics, meeting the baseline for high coverage.

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 ('Get') and resource ('content of a documentation file'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'read_doc' or 'get_related_docs', which likely have overlapping functionality, so it doesn't reach the highest score.

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 alternatives. With siblings like 'read_doc' and 'search_docs' available, there's no indication of context, exclusions, or prerequisites for selecting this specific tool.

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

get_project_infoC

Get information about the project structure and files

ParametersJSON Schema
NameRequiredDescriptionDefault
projectPathYesPath to the project root directory

TDQS

C2.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't clarify permissions needed, rate limits, error conditions, or what format the information is returned in (e.g., structured data vs. raw files).

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, efficient sentence with no wasted words. It's appropriately sized for a simple tool, though it could be more front-loaded with key details if expanded for better 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?

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'information' is returned (e.g., file list, metadata, structure details), making it hard for an agent to use effectively without trial and error.

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 the single parameter 'projectPath' documented as 'Path to the project root directory'. The description adds no additional meaning beyond this, such as path format examples or constraints, so it meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get information about the project structure and files' clearly states the verb 'Get' and resource 'project structure and files', but it's vague about what specific information is retrieved. It doesn't distinguish from siblings like 'analyze_project' or 'get_doc_content' which might overlap in functionality.

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. With siblings like 'analyze_project' and 'get_doc_content' that might retrieve similar information, the description offers no context on use cases, prerequisites, or exclusions.

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

read_docB

Read a documentation file (required before updating)

ParametersJSON Schema
NameRequiredDescriptionDefault
docFileYesName of the documentation file to read
projectPathYesPath to the project root directory

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool reads a file and is a prerequisite for updating, but doesn't describe what 'read' entails (e.g., returns content, metadata, or structure), any permissions needed, error handling, or side effects. For a tool with no annotations, this leaves significant behavioral 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, efficient sentence that front-loads the core purpose ('Read a documentation file') and adds a useful constraint ('required before updating'). There's no wasted text, and it's appropriately sized for the tool's complexity. It could be slightly more structured but is highly concise.

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?

Given the tool has no annotations, no output schema, and moderate complexity (2 parameters), the description is minimally adequate. It covers the purpose and a usage hint but lacks details on behavior, return values, or error conditions. It's complete enough for basic understanding but leaves gaps that could hinder effective use by an AI agent.

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%, with both parameters ('docFile' and 'projectPath') clearly documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as file formats or path conventions. This meets the baseline of 3 since the schema does the heavy lifting.

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's purpose as 'Read a documentation file' with a specific verb and resource. It distinguishes itself from siblings like 'get_doc_content' by implying a prerequisite action ('required before updating'), though it doesn't explicitly differentiate from all similar tools. The purpose is specific but could be more distinct.

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 provides implied usage guidance by stating 'required before updating', suggesting this tool should be used as a prerequisite for 'update_doc'. However, it doesn't explicitly state when to use this versus alternatives like 'get_doc_content' or 'search_docs', and offers no exclusions or broader context. The guidance is useful but incomplete.

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

search_docsC

Search across documentation files with highlighted results

ParametersJSON Schema
NameRequiredDescriptionDefault
projectPathYesPath to the project root directory
queryYesSearch query to find in documentation

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'highlighted results' which hints at output formatting, but doesn't cover critical aspects like whether this is a read-only operation, performance characteristics, error handling, or authentication needs. For a search tool with zero annotation coverage, this leaves 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.

Conciseness5/5

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

The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a straightforward search tool and front-loads the essential information.

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 should do more to compensate. While the purpose is clear, it doesn't explain what the search returns (beyond 'highlighted results'), how results are structured, or any limitations. For a tool with 2 parameters and no structured output documentation, this is incomplete.

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 fully documents both parameters (projectPath and query). The description adds no additional parameter information beyond what's in the schema. This meets the baseline of 3 when the schema does the heavy lifting, but doesn't provide extra value like explaining search syntax or path requirements.

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 ('Search') and target resource ('documentation files'), and mentions 'highlighted results' which adds specificity. However, it doesn't explicitly differentiate from sibling tools like 'get_related_docs' or 'analyze_existing_docs', which might also involve documentation searching or analysis.

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 alternatives. With siblings like 'get_related_docs' and 'analyze_existing_docs' that might overlap in functionality, there's no indication of when this search tool is preferred or what distinguishes it from other documentation-related tools.

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

update_docC

Update a specific documentation file using diff-based changes

ParametersJSON Schema
NameRequiredDescriptionDefault
continueToNextNoWhether to continue to the next file after this update
docFileYesName of the documentation file to update
projectPathYesPath to the project root directory
replaceContentYesContent to replace the search content with
searchContentYesContent to search for in the file

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Update' implies mutation, it doesn't specify whether this operation is destructive, requires specific permissions, or has side effects (e.g., file locking). The mention of 'diff-based changes' hints at a non-overwrite approach but lacks detail on error handling or rollback capabilities.

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, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('Update', 'specific documentation file', 'diff-based changes') contributes directly to understanding the tool's function, making it highly concise and well-structured.

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 mutation tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'diff-based changes' entail operationally, what happens on success/failure, or how it interacts with sibling tools. The agent lacks critical context for safe and effective use.

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 all parameters are documented in the schema itself. The description adds minimal value by implying 'diff-based' behavior, which loosely relates to 'searchContent' and 'replaceContent', but doesn't provide additional syntax, format, or usage details beyond what the schema already specifies.

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 ('Update') and resource ('a specific documentation file') with the method ('using diff-based changes'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like 'update_metadata' or 'customize_template', which prevents a perfect score.

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 alternatives like 'update_metadata' or 'customize_template'. It also lacks information about prerequisites (e.g., file must exist) or constraints (e.g., only works with certain file types), leaving the agent with minimal context for decision-making.

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

update_metadataC

Update metadata for a documentation file

ParametersJSON Schema
NameRequiredDescriptionDefault
docFileYesName of the documentation file
metadataYesMetadata to update
projectPathYesPath to the project root directory

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Update' implies a mutation operation, it doesn't specify whether this requires specific permissions, if changes are reversible, what happens to existing metadata not mentioned, or any rate limits or side effects. This is inadequate for a mutation tool with zero annotation coverage.

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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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 that this is a mutation tool with no annotations and no output schema, the description is insufficiently complete. It lacks critical behavioral details (e.g., permissions, reversibility) and doesn't explain what the tool returns, leaving significant gaps for an agent to operate safely and 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?

The schema description coverage is 100%, so the schema already documents all three parameters (projectPath, docFile, metadata) and their nested structure. The description adds no additional semantic context beyond what's in the schema, such as examples or constraints, meeting the baseline for high schema coverage.

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 ('Update') and resource ('metadata for a documentation file'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'update_doc', leaving some ambiguity about when to use one versus the other.

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 alternatives like 'update_doc' or other sibling tools. There's no mention of prerequisites, context, or exclusions, leaving the agent to guess based on tool names alone.

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

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

TDQS

B3.2/5.0
Disambiguation3/5

The tool set has clear distinctions for most operations like reading, updating, and searching docs, but there is significant overlap between analyze_project and analyze_project_with_metadata, which could confuse agents about which to use for basic analysis. Additionally, analyze_existing_docs and analyze_project serve similar purposes with unclear boundaries, leading to potential misselection.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (e.g., analyze_existing_docs, customize_template, get_doc_content), making them predictable and readable. However, there are minor deviations like read_doc (verb_noun) vs. update_doc (verb_noun), which are still consistent in structure, and no chaotic mixing of conventions, so the naming is largely uniform.

Tool Count5/5

With 11 tools, the count is well-scoped for a documentation management server, covering analysis, retrieval, updating, and metadata handling. Each tool appears to earn its place by addressing specific aspects of the domain, such as project analysis, content management, and search, without feeling overly heavy or thin.

Completeness4/5

The tool surface provides comprehensive coverage for documentation workflows, including analysis, reading, updating, searching, and metadata management. Minor gaps exist, such as no explicit tool for deleting documentation files or handling versioning, but agents can likely work around these with existing update and metadata tools for most tasks.

Maintenance

ActivityInactive
ResponsivenessSyncing

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

Appeared in Searches

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/ryanjoachim/mcp-rtfm'

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