mcp-rtfm

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.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.
Average 2.9/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 issues responded to in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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 'Find related documentation files' but doesn't explain what 'related' entails, whether this is a read-only operation, how results are returned, or any constraints like rate limits or permissions. For a tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core function without unnecessary words. It's front-loaded with the main action ('Find related documentation files'), but it could be slightly more structured by clarifying the scope or output. Overall, it's concise and earns its place, though not perfectly optimized.
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 (finding related files based on metadata), lack of annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain what 'related' means, how metadata is used, or what the return format is, leaving critical gaps for an agent to use it correctly in context.
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 what the schema provides, such as explaining how these parameters interact or what 'metadata' refers to. Baseline 3 is appropriate 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose ('Find related documentation files') and mentions the mechanism ('based on metadata'), which is more specific than just restating the name. However, it doesn't clearly distinguish this from sibling tools like 'search_docs' or 'get_doc_content'—it's vague about what 'related' means or how metadata is used, leaving ambiguity about its unique role.
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 'search_docs' and 'analyze_existing_docs', there's no indication of context, prerequisites, or exclusions. This leaves the agent to guess based on the name alone, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-rtfm MCP server](https://glama.ai/mcp/servers/ryanjoachim/mcp-rtfm/badges/card.svg)](https://glama.ai/mcp/servers/ryanjoachim/mcp-rtfm)

Score Badge

Copy to your README.md:

[![mcp-rtfm MCP server](https://glama.ai/mcp/servers/ryanjoachim/mcp-rtfm/badges/score.svg)](https://glama.ai/mcp/servers/ryanjoachim/mcp-rtfm)

Latest Blog Posts

Lightport: Open-Sourcing Glama's AI Gateway
By punkpeye on April 27, 2026.
open source
OpenAI
Tool Definition Quality Score (TDQS)
By punkpeye on April 3, 2026.
mcp
The Hackers Who Tracked My Sleep Cycle
By punkpeye on March 26, 2026.
security

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