RLM MCP Server

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: loading context, retrieving metadata, reading portions, decomposing, fetching chunks, searching, executing code, managing variables, managing answers, and session management. No two tools are interchangeable, and overlapping tools like rlm_search_context and rlm_find_all are differentiated by regex vs. substring search.
Naming Consistency5/5
All tool names follow a consistent rlm_<verb>_<noun> pattern with snake_case (e.g., rlm_load_context, rlm_get_context_info, rlm_decompose_context). Verbs and nouns are clear and predictable, making the API easy to navigate.
Tool Count4/5
With 17 tools, the set is slightly above the ideal 3-15 range, but the count is justified by the comprehensive workflow: context loading, analysis, decomposition, search, code execution, variable storage, answer management, and session lifecycle management. Each tool adds meaningful functionality.
Completeness5/5
The tool surface covers the full RLM processing lifecycle: load context, inspect structure, read specific sections, decompose into chunks, retrieve chunks, search, manipulate via code, store intermediate variables, build answers incrementally, and manage sessions. There are no obvious gaps or dead ends for the stated purpose.
Average 4/5 across 17 of 17 tools scored. Lowest: 3.4/5.
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
This repository is licensed under MIT License.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds return-value details but does not disclose additional behavioral aspects such as error handling, precision of averages, or session requirements. With annotations covering safety, this is acceptable but not rich.
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 two sentences, front-loaded with the purpose and then listing the return categories. Every sentence earns its place with no redundancy or fluff, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description's enumeration of return values is valuable. It covers the main information an agent needs, though 'averages' is ambiguous and it does not mention whether a session must be specified. Given low complexity and rich annotations, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (context_id, session_id) are already described in the schema. The tool description does not add any additional meaning beyond what the schema provides, so the baseline 3 applies.
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 ('statistics about a context') and lists specific return values (length, line/word/sentence/paragraph counts, averages). However, it does not explicitly differentiate from sibling tools like rlm_get_context_info or rlm_read_context, which may serve similar purposes, so it lacks sibling differentiation.
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 does not mention any exclusions, prerequisites, or preferred scenarios. The agent is left to infer usage from the name and sibling context, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a small behavioral detail by stating it returns content and a ready/complete flag, but it does not disclose edge cases (e.g., behavior if no answer exists) or any other operational traits. No contradiction with annotations exists.
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 two sentences long, front-loaded with the core action, and contains no filler. It efficiently conveys the purpose and return value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, strong annotations), the description sufficiently explains purpose and return content. It could be slightly more complete by noting that it operates on a specific session or clarifying the 'answer state' concept, but overall it is adequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter (session_id) with a description 'Session ID', yielding 100% coverage. Baseline is 3 for high coverage, and the description does not add further meaning about session_id, such as optionality or impact on results. Thus it neither enhances nor detracts from schema semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the current answer state' and specifies what is returned (content and readiness flag). This distinguishes it from siblings like rlm_set_answer (which sets the answer) and rlm_get_variable (which retrieves a different resource).
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 explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or scenarios where another sibling would be more appropriate. The existence of siblings like rlm_get_variable and rlm_read_context implies potential overlap, but no differentiation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not repeat these. The description adds no extra behavioral context (e.g., behavior on missing variable), but it does not contradict annotations.
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 no unnecessary words. It is appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with complete parameter schema and safety annotations, the description is sufficient. It covers the core purpose without needing to explain return values (no output schema). Minor gap: no mention of error cases, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters ('Variable name' and 'Session ID'). The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
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 retrieves a variable from the session, using a specific verb and resource. It distinguishes from siblings by focusing on 'variable' rather than context or session info, but does not explicitly contrast with rlm_get_answer or rlm_get_session_info.
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 intended use is implied by the name and the existence of sibling rlm_set_variable, but no explicit guidance is given about when to use this vs other getter tools. There are no exclusions or alternatives listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. Description adds concrete context about which data types are affected (contexts, variables, history), going beyond the annotation flags without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, front-loaded with the clear verb, efficiently conveys the tool's scope. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with one param and annotations covering safety profile, the description sufficiently states what is cleared. Could benefit from a caution phrase, but given low complexity and sibling context, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema fully documents the single session_id parameter with a basic description. Tool description adds no extra meaning about the parameter's format or necessity beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Clear' with resource 'session' and details what is cleared (contexts, variables, history). Clearly distinguishes from sibling tools like get_session_info or create_session.
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 when-to-use or alternative guidance. Does not mention that this is destructive or irreversible, nor when a user should prefer clearing versus creating a new session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety and side-effect profile. The description adds that the tool returns loaded contexts and variables, but it does not disclose return format, pagination, or any other behavioral traits. With annotations handling the core safety details, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource, and contains no redundant or filler content. It is appropriately sized for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, strong annotations, no output schema), the description covers the core functionality by stating what information is returned (loaded contexts and variables). However, it omits details about the complete return structure (e.g., additional session metadata), which would be more informative. Still, it is adequate for a simple read-only getter.
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 one parameter 'session_id' with a description, giving 100% schema description coverage. The description adds no extra parameter semantics (e.g., format, defaults, or behavior). Baseline 3 applies because the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'information about a session', and explicitly mentions 'loaded contexts and variables'. This clearly distinguishes it from sibling tools like rlm_get_variable and rlm_get_context_info, which target narrower scopes.
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 the tool should be used when a session-level overview is needed, mentioning loaded contexts and variables. However, it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true, readOnlyHint=false, and destructiveHint=false, and the description adds session-scoping context ('in the session') and the notion of later reuse. However, it does not disclose behavior around overwriting existing variables, omitting the value, or whether a session must exist, so some gaps remain.
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 two short sentences with no filler. The core action is front-loaded in the first sentence, and the second sentence provides a concrete use case. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter, the description is adequate, but it lacks important invocation context: it does not mention that a session must exist, what happens if value is omitted, or how session_id relates to the 'session' mentioned. With no output schema and sibling tools, a bit more guidance would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning all parameters (name, value, session_id) have descriptions. The tool description adds little beyond restating 'variable' and 'session', so it meets the baseline 3 for high schema coverage but provides no extra semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Store') with a clear resource ('a variable in the session'), and the scope ('for later use') distinguishes it from sibling tools like rlm_get_variable, which retrieves variables, and rlm_load_context, which loads context. It directly states what the tool does and is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use the tool: 'Use this to save intermediate results during RLM processing.' This gives clear context, though it does not mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only, idempotent, or destructive, which sets a basic expected behavior. The description adds a list of available functions, but does not elaborate on side effects (e.g., modifying session state via setVar) or execution semantics. It does not contradict the annotations, but more detail would improve 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 front-loaded with the core purpose and includes a structured list of available functions. The function list is lengthy but relevant, and there is no redundant text. It could be slightly more concise but is well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should ideally explain what the execution returns. It does not. It also omits information about state mutation effects. The function list and use case are helpful, but the lack of return behavior and side-effect disclosure leaves gaps for a code execution tool.
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?
Schema coverage is 100%, so the schema documents both parameters. The description adds value by listing helper functions and emphasizing custom data manipulation, giving the agent a sense of what the 'code' parameter should contain and what is possible, beyond the schema's simple 'JavaScript code to execute'.
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 'Execute JavaScript code in the session's REPL environment' with a specific verb and resource. It also includes a use case ('custom data manipulation and aggregation') that differentiates it from sibling tools which perform more specific operations like searching or variable management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this for custom data manipulation and aggregation,' giving clear guidance on when to use this tool. It does not explicitly mention when not to use it or name alternative tools, but the use case is specific enough, earning a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about modes (chars/lines) and the purpose of reading portions, but it does not describe return format, behavior for out-of-range positions, or how session/context IDs interrelate. This is similar to the TDQS get_calls baseline where annotations cover safety and description adds some context but not full behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single opening sentence, a structured mode list, and a one-line usage guideline. Every sentence earns its place, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with full schema coverage and strong annotations, the description is mostly complete. It explains what it does and the modes. However, since there is no output schema, the description could clarify the return format (e.g., it returns the text portion). The behavior for invalid ranges or when the portion is unavailable is also not described, so it loses one point.
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 each parameter having a clear description (e.g., 'Start position (character offset or line number)', 'End position (exclusive)'). The description adds little beyond restating modes and the general purpose, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a specific portion of the context, with a specific verb and resource. It distinguishes itself from siblings like rlm_load_context by emphasizing 'specific portion' and 'without loading the entire context', and from get_context_info/get_chunks by focusing on direct reading by offsets or line numbers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: 'Use this to examine specific sections without loading the entire context.' This gives a strong usage context and implicitly contrasts with loading full context. It doesn't explicitly name alternatives or exclusions, but the guidance is clear about when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool analyzes content type and size and returns a suggestion rather than performing decomposition, which is meaningful behavioral context beyond the annotations.
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 two sentences, front-loaded with the primary action, and every sentence provides useful information. No redundant or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only suggestion tool with good annotations, the description covers purpose, behavior, and the output type (suggested strategy). It lacks explicit return format details, but with no output schema and straightforward params, this is sufficient.
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?
Both parameters (context_id, session_id) have descriptions in the schema, providing 100% coverage. The description does not add any additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('suggested decomposition strategy') and clarifies it analyzes content type and size. This distinguishes it from siblings like rlm_decompose_context, which actually performs decomposition.
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 its use for recommending a chunking approach based on context structure, but it does not explicitly state when to use this tool versus alternatives like rlm_decompose_context. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable detail about what metadata is returned (length, line count, word count, structure type) and that preview is optional. No contradiction with annotations.
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 concise and well-structured, with a one-sentence summary, a bulleted return list, and a usage note. Every sentence contributes meaning without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only metadata tool, the description fully covers purpose, return categories, and usage context. With no required parameters and full schema descriptions, the description is sufficient even without an output schema.
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 covers all four parameters with descriptions, giving baseline 3. The tool description does not add further meaning beyond mentioning a preview, so no extra credit is earned.
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 gets metadata and preview of a loaded context, with a specific verb and resource. It lists return types but does not explicitly differentiate from sibling tools like rlm_read_context, so it misses the highest bar for sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this to understand the context before deciding how to process it' provides clear context for when to invoke the tool. It does not mention exclusions or alternative tools, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already cover safety, so the description adds value by disclosing the return format ('character offsets') and the performance characteristic ('faster than regex'). This goes beyond the structured annotations and helps the agent understand the tool's 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 only two sentences, front-loaded with the primary action and followed by a specific output detail. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations and full schema coverage, the description is reasonably complete. It states the output type (character offsets) and performance context, but does not detail the exact structure of the return value (e.g., array of numbers vs objects) or clarify how context_id/session_id are used. Still, it is adequate for a simple read-only search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional parameter-level semantics beyond what the schema already provides for substring, context_id, session_id, and case_sensitive. It does not clarify how parameters affect behavior beyond the schema descriptions.
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 that the tool finds all occurrences of a substring, with a specific verb ('find') and resource ('substring'). It also provides a distinguishing performance note ('faster than regex for simple searches') and the output format (character offsets), which differentiates it from siblings like rlm_search_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use this tool — for simple substring searches where it is faster than regex. This implies the alternative (using regex via rlm_search_context) for more complex patterns, though it does not explicitly name that sibling tool or provide explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context by mentioning the 50-chunk limit and the dependency on a prior decompose step, enriching the agent's understanding beyond the annotations.
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 two sentences, with the primary action front-loaded and no wasted words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 100% schema description coverage and clear annotations, the description covers the essential usage context and the batch limit. It could have mentioned error behaviors for invalid indices, but overall it is sufficiently complete for a straightforward read-only retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional parameter semantics beyond what the schema already provides; it merely references the batch limit, which is reflected in the schema's maxItems constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves content of specific chunks by index, which is a specific action on a specific resource. It distinguishes itself from sibling tools like rlm_get_context_info and rlm_read_context by focusing on chunk-level content retrieval after decomposition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool after rlm_decompose_context to get actual chunk content for processing. It provides clear context for when to use the tool, though it does not explicitly list when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context about isolation ('isolated', 'independent processing contexts') but does not disclose whether sessions are persistent, require cleanup, or return a handle. Annotations are neutral (all false), so the description carries the burden. It gives some insight but not a full picture of session lifecycle.
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 concise: three short sentences, with the main action front-loaded. Each sentence serves a purpose: stating the action, specifying when to use, and clarifying that the default is usually sufficient. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description adequately covers what it does and when to use it. It misses explaining the return value or session identifier, but for a simple create operation, the description is nearly complete. Sibling tools imply a session model, but the description doesn't elaborate.
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 schema coverage is 100% vacuously. Per the rubric, 0 parameters yields a baseline of 4. The description correctly does not add parameter info since none exist.
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 action: 'Create a new isolated RLM session.' The verb 'create' and resource 'RLM session' are specific. The qualifier 'isolated' and reference to 'multiple independent processing contexts' distinguishes it from other session-related tools like rlm_clear_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this when you need multiple independent processing contexts.' It also includes a clear exclusion: 'Most use cases can use the default session.' This tells the agent when not to use the tool and implies an alternative (the default session).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful context by stating that the tool returns chunk metadata (indices, offsets) and optionally content which 'can be large,' and by pointing to rlm_get_chunks for content retrieval. This goes beyond the structured annotations without contradicting them.
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 concise and well-structured: a one-sentence purpose, a bulleted list of strategies, and a brief return/usage note. Every sentence earns its place with no redundancy or fluff, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and rich annotations, the description adequately covers the core aspects: strategy options, return format (metadata), and the companion tool for content retrieval. It does not explain default behaviors or parameter interactions, but the schema provides defaults. The pointer to rlm_get_chunks adds important workflow context that improves completeness.
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?
Schema has 100% description coverage, so the baseline is 3. The description adds value by providing a strategy legend that explains each enum value in plain terms (e.g., 'by_paragraphs: Split on double newlines', 'by_sections: Split on markdown headers'). This helps the agent understand the intended use of the strategy parameter beyond the schema's concise descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Split context into chunks using various strategies.' It uses a specific verb and resource, and distinguishes itself from sibling rlm_get_chunks by stating that this tool returns chunk metadata while rlm_get_chunks is used to retrieve content. This is a clear, non-generic purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful usage context by listing all strategies and explicitly pointing to rlm_get_chunks for retrieving chunk content, implying a decomposition-then-retrieval workflow. However, it does not explicitly state when not to use this tool or compare it with other siblings like rlm_read_context or rlm_search_context, so it falls short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds behavioral details about return format ('surrounding context and line numbers') and usage context, which enriches transparency without contradicting annotations.
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 concise: a one-sentence primary purpose, a two-sentence output/usage note, and three examples. It is front-loaded, contains no filler, and every line contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema, the description covers purpose, output, and usage context. It could more explicitly define what 'context' refers to, but sibling tools and examples provide enough context for an AI agent to select and invoke it correctly.
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?
Schema coverage is 100%, so baseline is 3. The description adds valuable semantics through concrete pattern examples (e.g., 'error|warning' for errors/warnings), which clarifies how to use the 'pattern' parameter beyond the schema's bare definition. This lifts it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search context using regex patterns.' The verb 'search' and resource 'context' are specific, and examples differentiate it from siblings like rlm_find_all by emphasizing surrounding context and line numbers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this to find relevant sections before reading in detail.' This implies when to use it over full reads, but it does not explicitly name alternatives or state when not to use it, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose non-read-only, idempotent, and non-destructive traits. The description adds valuable context about incremental building, the meaning of ready flags, and that the answer can be retrieved later, which goes beyond annotations. No contradiction with annotations.
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 compact and front-loaded: a clear one-line purpose, followed by a concise bullet list for the ready flag and a helpful pointer to rlm_get_answer. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with full schema coverage and no output schema, the description is complete enough. It covers incremental update semantics and retrieval, which are the key contextual facts. It does not need to explain return values or session_id since the schema covers those.
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?
Schema coverage is 100% with parameter descriptions, but the description adds semantics for 'ready' (partial vs final) and clarifies that 'content' can be partial or complete. This goes beyond the schema's generic descriptions and helps the agent understand parameter usage.
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 'Set or update the answer for the current RLM task' with a specific verb and resource (answer, RLM task). It distinguishes itself from the sibling rlm_get_answer by explaining the get/set relationship and describing incremental answer building, which is unique to this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs 'Call this to build up your answer incrementally' and explains the ready=false vs ready=true distinction, giving clear when-to-use guidance. It also mentions rlm_get_answer as the retrieval counterpart, but does not explicitly contrast with rlm_set_variable or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose idempotency and non-destructiveness. The description adds valuable behavioral context on top: the context is stored in the session and can be referenced by its ID, which is not apparent from the annotations. It also implies session-scoped state, which is useful for the agent.
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 well-structured and front-loaded with the core purpose. The example workflow is concise and each step adds strategic context, helping the agent understand sequencing without being verbose or redundant. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the rich annotations/schema, the description is complete. It explains the tool's role, session storage, and integration with other tools. No output schema is needed, and the description covers all essential operational 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?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds little beyond the schema, only mentioning that context can be referenced by its ID (which maps to context_id). No additional parameter semantics are provided, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb+resource: 'Load text content into the RLM session for processing.' It also distinguishes itself from sibling tools by positioning it as the typical first step in RLM processing, which is a 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'This is typically the first step in RLM processing.' It also gives a concrete numbered workflow showing how rlm_load_context fits with other tools, making it clear when to use this tool versus alternatives.
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:

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

Score Badge

Copy to your README.md:

[![RLM-MCP MCP server](https://glama.ai/mcp/servers/win10ogod/RLM-MCP/badges/score.svg)](https://glama.ai/mcp/servers/win10ogod/RLM-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/win10ogod/RLM-MCP'

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