SJ RedM MCP Server

by iamvillain

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as browsing namespaces, getting documentation, or searching discoveries. However, some tools like redm-get-smart-context and redm-search-framework-docs could overlap in retrieving documentation, potentially causing minor confusion for agents.
Naming Consistency5/5
All tool names follow a consistent pattern with the prefix 'redm-' and use snake_case throughout. The naming is uniform, making it easy to predict and understand the tool functions without ambiguity.
Tool Count5/5
With 13 tools, the server is well-scoped for its purpose of providing RedM game development resources. Each tool serves a specific function, such as accessing documentation, searching, or listing resources, without feeling excessive or insufficient.
Completeness4/5
The tool set covers key areas like native functions, framework documentation, and discovery repositories, supporting common workflows. A minor gap is the lack of tools for modifying or updating resources, but this is reasonable given the server's focus on retrieval and search.
Average 3/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues 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 full burden for behavioral disclosure. It mentions 'Browse' but doesn't clarify what browsing entails—whether it returns a list, details, or summaries; if it's paginated (implied by the page parameter but not stated); or any performance/rate considerations. This leaves significant gaps for a tool with 2 parameters.
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, 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 no annotations, no output schema, and a tool that likely returns complex data (native functions), the description is insufficient. It doesn't explain what 'browse' returns (e.g., list of function names, details, summaries) or any behavioral traits like pagination or performance, leaving the agent with significant uncertainty.
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 fully documents both parameters (namespace and page). The description adds no additional meaning beyond what's in the schema—it doesn't explain namespace examples beyond the schema's enum-like hint or clarify pagination behavior. Baseline 3 is appropriate as 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 action ('Browse') and target resource ('native functions within a specific namespace'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'redm-list-native-namespaces' or 'redm-search-natives', which appear related to similar native function discovery.
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 multiple sibling tools related to native functions and documentation (e.g., redm-list-native-namespaces, redm-search-natives, redm-get-native-details), there's no indication of when this browsing tool is preferred over listing, searching, or getting details.
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 states the tool 'automatically loads relevant documentation,' implying a read-only operation, but doesn't cover critical aspects like what 'intelligent context' entails, potential rate limits, error handling, or output format. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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 front-loads the core functionality: 'Get intelligent context based on query - automatically loads relevant documentation.' Every word contributes to understanding the tool's purpose without redundancy or unnecessary elaboration, 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?
Given the complexity implied by 'intelligent context' and the lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what 'context' includes, how relevance is determined, or what the return values look like. For a tool that likely involves nuanced behavior, more detail is needed to fully guide 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 input schema has 100% description coverage, with the 'query' parameter documented as 'Your development query or task description.' The description adds no additional semantic details beyond this, such as query format or examples. According to the rules, with high schema coverage (>80%), the baseline is 3, which is appropriate here as 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: 'Get intelligent context based on query - automatically loads relevant documentation.' It specifies the verb ('Get'), resource ('intelligent context'), and mechanism ('based on query'), distinguishing it from siblings that focus on specific documentation types (e.g., redm-get-lua-examples). However, it doesn't explicitly contrast with all siblings like redm-search-discoveries, keeping it at 4 rather than 5.
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. It mentions 'automatically loads relevant documentation' but doesn't specify what makes it different from siblings like redm-search-framework-docs or redm-search-discoveries, nor does it outline any prerequisites or exclusions. This lack of comparative context results in a minimal score.
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 states the tool reads file contents but doesn't disclose critical traits like whether it's read-only, safe, requires authentication, handles errors, or has rate limits. For a file-reading tool, this lack of behavioral context is a significant gap.
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, 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 the complexity of file operations and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the return values look like (e.g., file content format), error conditions, or behavioral traits, leaving the agent with insufficient context for reliable invocation.
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 the 'path' parameter clearly documented. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and resource ('contents of a specific file from the RDR3 discoveries repository'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'redm-list-discovery-dirs' or 'redm-search-discoveries', which handle directory listing and searching rather than direct file reading.
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. It doesn't mention prerequisites, exclusions, or compare it to siblings such as 'redm-list-discovery-dirs' for browsing or 'redm-search-discoveries' for searching, leaving the agent without context for 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches a GitHub repository but doesn't mention any behavioral traits like rate limits, authentication needs, pagination, or what the search results look like (e.g., file paths, snippets). For a search 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 front-loads the core purpose without unnecessary words. Every part of the sentence earns its place by specifying the action, target, and scope, 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 lack of annotations and output schema, the description is incomplete for a search tool. It doesn't explain what the search returns (e.g., file listings, content snippets), any limitations (e.g., search depth, repository structure), or how it differs from sibling search tools. This leaves the agent with insufficient context to use the tool 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?
Schema description coverage is 100%, with clear descriptions for both parameters ('query' and 'limit'), including a default value for 'limit'. The description adds no additional parameter semantics beyond what the schema provides, such as query syntax examples or result formatting. 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 action ('Search') and target resource ('RDR3 discoveries GitHub repository for game assets, scripts, and documentation'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'redm-search-natives' or 'redm-search-framework-docs', which appear to be similar search operations for different 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 multiple search-related siblings (e.g., 'redm-search-natives', 'redm-search-framework-docs'), there's no indication of what makes this tool distinct—such as searching a specific repository versus other documentation sources—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 only states the tool's purpose without mentioning any behavioral traits such as whether it's read-only, if it has rate limits, what the output format might be, or any authentication requirements. For a search 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of a single, clear sentence: 'Search RedM framework documentation (VORP and RSGCore)'. Every word earns its place by specifying the action, resource, and scope without any unnecessary details or redundancy.
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 (a search function with 2 parameters) and the absence of both annotations and an output schema, the description is incomplete. It doesn't explain what the search returns, how results are formatted, or any behavioral aspects like pagination or error handling. This leaves critical gaps for an agent to understand the tool's full 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 description adds no parameter-specific information beyond what the input schema provides. Since schema description coverage is 100%, the schema already documents both parameters ('query' and 'framework') with descriptions and an enum for 'framework'. The description doesn't elaborate on parameter usage or semantics, so it meets the baseline score of 3 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 tool's purpose: 'Search RedM framework documentation (VORP and RSGCore)'. It specifies the verb ('search'), resource ('RedM framework documentation'), and scope ('VORP and RSGCore'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'redm-search-natives' or 'redm-search-discoveries', 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. It doesn't mention sibling tools like 'redm-get-vorp-docs' or 'redm-get-rsgcore-docs', nor does it specify contexts or exclusions for its use. This lack of comparative or contextual information leaves the agent without clear usage direction.
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 the tool is for searching, implying a read-only operation, but doesn't cover aspects like response format, pagination, error handling, or rate limits. For a search 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 front-loads the core purpose without unnecessary details. It uses clear language and avoids redundancy, making it easy for an AI 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 the complexity of searching native functions and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the search returns (e.g., list of functions, metadata), how results are structured, or any limitations. This leaves gaps for an AI agent to understand the tool's full behavior.
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 ('query' and 'namespace'). The description adds no additional parameter semantics beyond what the schema provides, such as examples of search terms or namespace usage. Baseline score of 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 tool's purpose: 'Search for RDR3 native functions by name or partial match.' It specifies the verb ('Search'), resource ('RDR3 native functions'), and method ('by name or partial match'). However, it doesn't explicitly differentiate from sibling tools like 'redm-search-discoveries' or 'redm-search-framework-docs,' which might also involve searching but for different resources, keeping it from 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. It doesn't mention sibling tools like 'redm-list-native-namespaces' for browsing or 'redm-get-native-details' for detailed information, nor does it specify prerequisites or exclusions. This lack of contextual usage information limits its effectiveness for an AI agent.
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 the tool 'finds' examples, implying a read-only search operation, but doesn't specify behavioral traits like whether it returns structured data, handles errors, has rate limits, or requires authentication. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Find Lua code examples in the RDR3 discoveries repository.' It's front-loaded with the core action and resource, with zero wasted words. Every part of the sentence contributes directly to understanding the tool's purpose, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose but lacks details on behavioral traits, usage guidelines, and output format. Without annotations or an output schema, users don't know what the tool returns (e.g., code snippets, file paths, or structured data). This makes it minimally viable but with clear gaps for 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 the 'topic' parameter clearly documented as 'Topic to search for (e.g., "ped", "vehicle", "weapon").' The description doesn't add any additional meaning beyond this, such as examples of valid topics or search behavior. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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: 'Find Lua code examples in the RDR3 discoveries repository.' It specifies the verb ('Find'), resource ('Lua code examples'), and context ('RDR3 discoveries repository'), which is clear and specific. However, it doesn't explicitly distinguish this tool from its siblings like 'redm-search-discoveries' or 'redm-read-discovery-file', which might also involve searching or retrieving content from the same repository.
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. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools such as 'redm-search-discoveries' or 'redm-read-discovery-file', which could be relevant for similar tasks. Without this context, users must infer usage based on the tool name and description 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 full burden for behavioral disclosure. While 'Get detailed information' implies a read-only operation, it doesn't specify what constitutes 'detailed information' (return format, depth), whether there are rate limits, authentication requirements, or error conditions for invalid native names. 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.
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 fluff or redundant information. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup tool with full schema coverage but no output schema, the description is minimally adequate. It identifies the resource type but doesn't describe the return format or what 'detailed information' includes. Given the lack of annotations and output schema, more context about the response structure would be beneficial.
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?
With 100% schema description coverage, the input schema already fully documents both parameters (nativeName and namespace). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline but doesn't provide extra value like explaining namespace relationships or native name formats.
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 a specific verb ('Get detailed information') and resource ('about a specific native function'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'redm-search-natives' or 'redm-list-native-namespaces', 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. With multiple sibling tools related to natives (search-natives, list-native-namespaces, browse-namespace), there's no indication of when this detailed lookup is preferred over broader search or listing operations.
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 what the tool does but doesn't describe how it behaves: e.g., whether it returns formatted documentation, raw text, links; if it's cached or real-time; any rate limits; or error conditions. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational characteristics.
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 with no wasted words. It's front-loaded with the core action ('Get oxmysql documentation') and specifies the domain ('for database operations'). Every word earns its place, 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 the lack of annotations and output schema, the description is incomplete for a documentation retrieval tool. It doesn't specify what format the documentation is returned in (e.g., markdown, HTML, structured JSON), how comprehensive it is, or if there are any scoping limitations. With no structured fields to rely on, the description should provide more context about the output and behavior to be fully helpful.
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 tool has zero parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, but it could mention if there are implicit inputs (e.g., version filtering). Since there are no parameters, the baseline is 4, as the description adequately covers the lack of inputs without misleading the agent.
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 ('oxmysql documentation for database operations'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from its sibling 'redm-get-rsgcore-docs' or 'redm-get-vorp-docs', which appear to be similar documentation retrieval tools for different frameworks. A perfect score would require clarifying what makes oxmysql documentation distinct from other framework docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'redm-get-rsgcore-docs' or 'redm-search-framework-docs'. It doesn't mention prerequisites, context for when oxmysql documentation is needed, or what scenarios warrant this specific retrieval. The agent must infer usage from the tool name 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 full burden for behavioral disclosure. It states 'Get all' but doesn't clarify what 'all' means (e.g., complete set, paginated results, format of return). It also doesn't mention authentication needs, rate limits, or potential side effects. The description is too vague to adequately inform agent behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
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 and resource, making it easy to parse. There's no wasted text, and every word contributes to understanding the tool's function.
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 for a tool that retrieves documentation. It doesn't explain what 'RSGCore' is, what format the documentation is returned in (e.g., raw text, structured data), or any limitations (e.g., size of response). For a tool with no structured context, 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't discuss parameters, which aligns with the schema. A baseline of 4 is given since no parameter information is needed or missing.
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 ('Get') and the resource ('all RSGCore framework documentation'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'redm-search-framework-docs' or 'redm-get-oxmysql-docs', which appear to serve similar documentation retrieval functions for different frameworks.
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 'redm-search-framework-docs' (which might allow filtering) and 'redm-get-oxmysql-docs' (for different framework docs), there's no indication of when this specific tool is appropriate or what distinguishes it from other documentation 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. It states what the tool does but lacks critical details: it doesn't specify if this is a read-only operation, how the documentation is returned (e.g., format, structure), potential rate limits, or authentication needs. For a 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, clear sentence with zero waste. It is front-loaded with the core purpose ('Get all VORP framework documentation'), making it immediately understandable without unnecessary elaboration. Every word earns its place, and there is no redundant or verbose content.
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 of retrieving documentation (which could involve large datasets or specific formats), the description is incomplete. With no annotations and no output schema, it fails to explain return values, behavioral traits, or usage context. For a tool that likely returns structured data, this leaves the agent guessing about the output and operational details.
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 tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids mentioning any. This meets the baseline for tools with no parameters, as it doesn't mislead or omit necessary information.
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 ('Get') and resource ('all VORP framework documentation'), making the purpose immediately understandable. It distinguishes itself from siblings like 'redm-search-framework-docs' by implying retrieval of all documentation rather than searching. However, it doesn't specify the exact scope or format of what 'all' entails, keeping it from 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?
No explicit guidance is provided on when to use this tool versus alternatives. Siblings like 'redm-search-framework-docs' suggest a search function, but the description doesn't clarify if this tool is for bulk retrieval, initial exploration, or other contexts. The lack of when-to-use or when-not-to-use statements leaves the agent without direction.
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's a list operation but doesn't clarify whether it's read-only, paginated, returns structured data, or has any rate limits or authentication requirements. For a tool with zero annotation coverage, 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, clear sentence that efficiently conveys the tool's purpose without unnecessary 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. However, it lacks details on return format (e.g., list of files/directories) and behavioral aspects, which would help the agent use it correctly despite the simple 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 the 'path' parameter well-documented in the schema itself. The description doesn't add any additional meaning beyond what the schema provides, such as examples of valid paths or error handling, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List contents') and target ('a directory in the RDR3 discoveries repository'), providing specific verb+resource. However, it doesn't explicitly differentiate from sibling tools like 'redm-browse-namespace' or 'redm-search-discoveries', which might have overlapping 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. The description doesn't mention siblings like 'redm-search-discoveries' for searching or 'redm-read-discovery-file' for reading files, leaving the agent without context for 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('List') but does not describe behavioral traits such as whether the list is paginated, sorted, or cached; what format the output takes; or any potential limitations like rate limits. This leaves significant gaps in understanding how the tool behaves.
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, clear sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and efficiently communicates the essential information, 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?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns a list of namespaces. It does not explain the return format, potential errors, or behavioral aspects like ordering or limits. For a list operation with no structured output documentation, more context is needed to be fully helpful.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate here. A baseline of 4 is applied as it adequately handles the lack of parameters without introducing confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all available native function namespaces,' making the purpose specific and unambiguous. It effectively distinguishes this tool from siblings like 'redm-browse-namespace' or 'redm-search-natives' by focusing on listing rather than browsing or searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a list of namespaces, but it does not explicitly state when to use this tool versus alternatives like 'redm-browse-namespace' or 'redm-search-natives.' No exclusions or prerequisites are mentioned, leaving usage context somewhat implied rather than clearly defined.
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:

[![sj-redm-mcp MCP server](https://glama.ai/mcp/servers/iamvillain/sj-redm-mcp/badges/card.svg)](https://glama.ai/mcp/servers/iamvillain/sj-redm-mcp)

Score Badge

Copy to your README.md:

[![sj-redm-mcp MCP server](https://glama.ai/mcp/servers/iamvillain/sj-redm-mcp/badges/score.svg)](https://glama.ai/mcp/servers/iamvillain/sj-redm-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/iamvillain/sj-redm-mcp'

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