Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@RLM-MCP Load project docs and search for 'recursive language model'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Status: ✅ v0.2.2 - Production-Ready for Team Environments
A Model Context Protocol (MCP) server implementing the Recursive Language Model pattern from Zhang et al. (2025), enabling LLMs to process arbitrarily long contexts by treating prompts as external environment objects.
What's New in v0.2.x:
v0.2.2: Exact BM25 doc_ids filtering • Highlight bounds clamping • Server config defaults • Budget exemption for session.close
v0.2.1: Atomic budget enforcement • chunk_index persistence • Truncation warnings • Error message improvements
v0.2.0: Persistent indexes • Concurrent session safety • Structured logging • Batch document loading (2-3x faster)
Long prompts should not be fed into the neural network directly but should instead be treated as part of the environment that the LLM can symbolically interact with.
Related MCP server: MCP-RLM
Session-based document management — Load files, directories, or inline content with batch processing
On-demand chunking — Fixed, line-based, or delimiter-based strategies with intelligent caching
BM25 search — Lazy-built, persistently cached, survives server restarts
Artifact storage — Store derived results with complete span provenance
Persistent indexes — BM25 indexes saved to disk with atomic writes and corruption recovery
Concurrent session safety — Per-session locks prevent race conditions in multi-user environments
Structured logging — JSON output with correlation IDs for production observability
Batch document loading — Concurrent file loading with memory-bounded semaphores (2-3x faster)
v0.2.2 production-ready validation:
✅ 103/103 tests passing (100% functionality + production features)
✅ All 13 core tools implemented with canonical naming
✅ MCP protocol integration confirmed with real clients
✅ Large corpus tested — 1M+ chars loaded and indexed
✅ Performance validated — Sub-second searches, <100ms index loads from disk
✅ Concurrency tested — 50 concurrent operations, no race conditions
✅ Memory safety — Bounded semaphores prevent OOM on large batches
✅ Production logging — JSON structured logs with correlation tracking
Error handling: 13 tests
Concurrency safety: 9 tests
Index persistence: 10 tests
Integration workflows: 14 tests
Large corpus performance: 5 tests
Structured logging: 13 tests
Batch loading: 7 tests
Provenance tracking: 8 tests
Storage layer: 11 tests
v0.2.2 bug fixes: 13 tests
See MIGRATION_v0.1_to_v0.2.md for upgrade guide.
pip install rlm-mcpOr with development dependencies:
pip install rlm-mcp[dev]from rlm_mcp import run_server
# Start the MCP server
run_server()All tools use canonical naming: rlm.<category>.<action>
Category | Tools |
|
|
|
|
|
|
|
|
|
|
|
|
Initialize: rlm.session.create with config
Load: rlm.docs.load documents
Probe: rlm.docs.peek at structure
Search: rlm.search.query to find relevant sections
Chunk: rlm.chunk.create with appropriate strategy
Process: rlm.span.get + client subcalls
Store: rlm.artifact.store results with provenance
Close: rlm.session.close
Configuration file: ~/.rlm-mcp/config.yaml
# Data storage
data_dir: ~/.rlm-mcp
# Session limits (per-session overridable)
default_max_tool_calls: 500
default_max_chars_per_response: 50000
default_max_chars_per_peek: 10000
# Batch loading (v0.2.0)
max_concurrent_loads: 20 # Max concurrent file loads (memory safety)
max_file_size_mb: 100 # Reject files larger than this
# Logging (v0.2.0)
log_level: "INFO" # DEBUG, INFO, WARNING, ERROR
structured_logging: true # JSON format (true) vs human-readable (false)
log_file: null # Optional: "/var/log/rlm-mcp.log"
# Tool naming: strict by default (fails if SDK doesn't support canonical names)
# Only set to true for experimentation with older MCP SDKs
allow_noncanonical_tool_names: falseBy default, RLM-MCP requires an MCP SDK that supports explicit tool naming (e.g., FastMCP). This ensures tools are discoverable as rlm.session.create, not rlm_session_create.
Strict mode (default): Server fails to start if SDK doesn't support tool(name=...)
Compat mode: Falls back to function names with a warning. Use only for experimentation.
# ~/.rlm-mcp/config.yaml
allow_noncanonical_tool_names: true # Enable compat mode (not recommended)RLM-MCP produces structured JSON logs for production observability. Each operation gets a unique correlation ID for tracing related events.
{
"timestamp": "2026-01-15T10:30:45.123456Z",
"level": "INFO",
"logger": "rlm_mcp.server",
"message": "Completed rlm.session.create",
"correlation_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"session_id": "session-123",
"operation": "rlm.session.create",
"duration_ms": 42,
"success": true
}# Filter by session
cat /var/log/rlm-mcp.log | jq 'select(.session_id == "session-123")'
# Filter by operation
cat /var/log/rlm-mcp.log | jq 'select(.operation == "rlm.search.query")'
# Track operation with correlation ID
cat /var/log/rlm-mcp.log | jq 'select(.correlation_id == "a1b2c3d4...")'
# Only errors
cat /var/log/rlm-mcp.log | jq 'select(.level == "ERROR")'See docs/LOGGING.md for detailed logging guide.
{
"max_tool_calls": 500, # Budget enforcement
"max_chars_per_response": 50000, # DOS protection
"max_chars_per_peek": 10000, # DOS protection
"chunk_cache_enabled": True,
"model_hints": { # Advisory for client
"root_model": "claude-opus-4-5-20251101",
"subcall_model": "claude-sonnet-4-5-20250929",
"bulk_model": "claude-haiku-4-5-20251001"
}
}┌─────────────────────────────────────────┐
│ Claude Skills (policy layer) │
├─────────────────────────────────────────┤
│ MCP Server (RLM Runtime) │
│ • Session management + concurrency │
│ • Document/span operations │
│ • BM25 search (lazy, persisted) │
│ • Batch loading with semaphores │
│ • Response size caps │
├─────────────────────────────────────────┤
│ Local Persistence (v0.2.0) │
│ • SQLite: sessions, docs, spans │
│ • Blob store: content-addressed │
│ • Index cache: persistent BM25 │
│ • Structured logs: JSON + correlation │
└─────────────────────────────────────────┘Local-first — All reads/writes hit local storage
Client-managed subcalls — MCP is the "world", client makes LLM calls
Immutable documents — Content-addressed, never modified
On-demand chunking — Chunk at query time, cache results
DOS protection — Hard caps on response sizes
# Clone and install with uv (recommended)
git clone https://github.com/yourorg/rlm-mcp.git
cd rlm-mcp
uv sync --extra dev
# Run tests
uv run pytest
# Or with pip (editable install required for tests)
pip install -e ".[dev]"
pytest
# Type checking
uv run mypy src/
# Linting
uv run ruff check src/To validate tool discovery and schemas from a real client:
# Start server
uv run rlm-mcp
# In another terminal, use MCP Inspector
npx @anthropic/mcp-inspectorVerify:
Tool names appear as rlm.session.create, not rlm_session_create
Schemas match expected input/output structures
truncated and index_built fields appear in responses
MIT
Zhang, A. L., Kraska, T., & Khattab, O. (2025). Recursive Language Models. arXiv:2512.24601
Retrieve artifact content.
Args: session_id: Session containing artifact artifact_id: Artifact ID to retrieve
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| artifact_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is read-only, any required permissions, or potential errors. 'Retrieve' implies a read operation but lacks explicit confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with only two sentences: one for the purpose and one structured list for parameters. Every sentence serves a clear function without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema being present, the description is incomplete as it omits usage guidelines, behavioral transparency, and any notes on error handling or prerequisites. For a simple get operation, it is minimally adequate but lacks sufficient context for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description briefly explains each parameter ('session_id: Session containing artifact' and 'artifact_id: Artifact ID to retrieve'), adding meaning beyond the schema titles. However, it lacks details on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' and resource 'artifact content', clearly indicating the tool's function. It is easily distinguishable from sibling tools like 'rlm.artifact.list' or 'rlm.artifact.store'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 rlm.artifact.list or rlm.artifact.store. It only states what the tool does, without any conditional or exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List artifacts for a session or span.
Args: session_id: Session to query span_id: Optional span ID filter type: Optional type filter
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| span_id | No | ||
| type | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies read-only behavior by the verb 'list', but no further behavioral traits (e.g., permissions, side effects) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence for purpose, then parameter list. Front-loaded and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so return values are covered. However, for a list tool, missing details like ordering or pagination. With no annotations, more context on expected behavior would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description adds basic semantics: 'Session to query', 'Optional span ID filter', 'Optional type filter'. This clarifies the parameters but is minimal and does not provide additional format constraints or usage details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists artifacts for a session or span, with specific verb 'list' and resource 'artifacts'. It implicitly distinguishes from siblings like 'get' (single artifact) and 'store'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like rlm.artifact.get or rlm.artifact.store. Does not mention any prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a derived artifact with provenance.
Args: session_id: Session to store artifact in type: Artifact type (summary, extraction, classification, custom) content: Artifact content span_id: Optional span ID for provenance span: Optional span reference (doc_id, start, end) - creates span if needed provenance: Optional provenance metadata (model, prompt_hash)
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| type | Yes | ||
| content | Yes | ||
| span_id | No | ||
| span | No | ||
| provenance | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers some behavioral aspects, such as proving optional parameters like span_id and span, and noting that span 'creates span if needed.' However, it does not disclose whether storing overwrites existing artifacts, auth requirements, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a front-loaded purpose and clear parameter list. Every sentence adds value, and there is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, 3 required) and presence of an output schema, the description is mostly complete. It covers all parameters and mentions provenance. It lacks details on idempotency or return value, but the output schema likely fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining each parameter. It lists required ones and describes optional ones, e.g., 'Optional span ID for provenance' and 'Optional span reference (doc_id, start, end).' However, it does not specify valid values for type beyond examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Store a derived artifact with provenance.' It clearly distinguishes this tool from sibling tools like rlm.artifact.get and rlm.artifact.list, which are for retrieval and listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While the purpose is clear, there is no guidance on when not to use it or mention of sibling tools for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Chunk a document using a specified strategy.
Args: session_id: Session containing document doc_id: Document ID to chunk strategy: Chunking strategy (type, chunk_size, line_count, delimiter, overlap)
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| doc_id | Yes | ||
| strategy | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states the action and arguments, with no insight into side effects (e.g., whether the document is modified, if the session state changes, or what the output contains).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and front-loaded: a single sentence followed by a compact argument list. No fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, nested object, output schema exists), the description is incomplete. It lacks context on output, error conditions, and whether chunking affects the source document. The output schema existing does not fully compensate for missing description of behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description compensates by listing argument names and, for the 'strategy' object, its constituent fields ('type, chunk_size, line_count, delimiter, overlap'). However, it does not specify types, constraints, or which fields are required, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Chunk a document using a specified strategy.' It uses a specific verb ('Chunk') and resource ('document'), and the tool name distinctively sets it apart from sibling tools like rlm.docs.list or rlm.search.query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor does it mention preconditions or exclusions. It merely states what the tool does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List documents in session.
Args: session_id: Session to query limit: Max documents to return offset: Pagination offset
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'List documents in session.' It does not mention what happens if the session_id is invalid, whether documents are ordered, or if pagination defaults to first page. The agent lacks critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the purpose stated first followed by a bulleted parameter list. It is efficient and easy to scan, though the parameter descriptions could be more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and an output schema, but the description omits details like ordering, filtering, and error handling. It does not address common usage scenarios (e.g., empty session, pagination behavior). For a list tool, this lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter descriptions are minimal: 'Session to query' for session_id (redundant with schema), 'Max documents to return' for limit, and 'Pagination offset' for offset. These add some context beyond the schema types and defaults, but are very brief. Given 0% schema description coverage, the description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List documents in session', which is a specific verb and resource. It distinguishes from sibling tools like rlm.docs.load and rlm.docs.peek by focusing on listing multiple documents. However, it does not specify the scope (e.g., all documents or filtered) beyond the session context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings like rlm.search.query or rlm.artifact.list. No when-to-use or when-not-to-use instructions are given, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load documents into the session context.
Args: session_id: Session to load into sources: List of source specs (type, path, content, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| sources | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description fails to disclose behavioral traits such as mutation of session state, side effects, error conditions, or required permissions. The phrase 'load documents' is ambiguous regarding consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short (one sentence plus a bulleted list). It is efficient and front-loaded, but the brevity compromises completeness. Every sentence provides relevant information, though more detail is needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (array of arbitrary objects as sources, output schema exists but not described), the description is severely lacking. It does not specify source format, behavior on duplicates, session existence requirements, or return value structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%: parameter descriptions are absent. The description adds brief explanations for session_id ('Session to load into') and sources ('List of source specs (type, path, content, etc.)'), but does not elaborate on the structure of source specs or valid values, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Load documents into the session context', specifying the action and target. It distinguishes from siblings like rlm.docs.list (listing) and rlm.artifact.store (storing artifacts), though lacks specificity about what 'load' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites, typical workflows, or when not to use. Siblings like rlm.search.query or rlm.docs.peek are not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View a portion of a document. Enforces max_chars_per_peek.
Args: session_id: Session containing document doc_id: Document ID to peek start: Start offset (inclusive) end: End offset (exclusive), -1 for end of doc
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| doc_id | Yes | ||
| start | No | ||
| end | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses 'Enforces max_chars_per_peek' and explains parameter semantics (start inclusive, end exclusive, -1 for end). With no annotations, description does a good job. Minor gap: behavior if max_chars exceeded is not specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short, front-loaded purpose sentence. Argument list clear. Could use bullet points or more structure, but overall concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains all parameters and behavioral constraint. Output schema exists so return format need not be described. Minor omission: the actual max_chars value not provided (may be assumed or retrieved elsewhere). Still complete for usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully explains all 4 parameters: session_id, doc_id, start default 0, end default -1 with explicit interpretation. Fully compensates for lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'View a portion of a document' with a specific verb and resource. Distinguishes from siblings like load (whole doc) and list (list docs). The constraint 'Enforces max_chars_per_peek' adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage from description: for partial document viewing. But no explicit when-to-use or when-not-to-use compared to alternatives like rlm.docs.load. No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search documents. BM25 index is lazy-built on first use.
Args: session_id: Session to search query: Search query string method: Search method (bm25, regex, literal) doc_ids: Optional list of doc IDs to limit search limit: Max matches to return context_chars: Characters of context around each match
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| query | Yes | ||
| method | No | bm25 | |
| doc_ids | No | ||
| limit | No | ||
| context_chars | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the BM25 index is lazy-built on first use, which is a useful behavioral note. However, it does not mention side effects, authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with a clear first sentence. The Args list provides structure but includes redundant information already present in the schema, slightly reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and an output schema, the description is adequate but incomplete. It covers the purpose and basic parameters but lacks guidance on method selection and behavior for edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameter names but adds little semantic value beyond the schema (e.g., 'session_id: Session to search' is a rephrase). Default values and types are already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search documents' clearly states the tool's purpose with a specific verb and resource. However, it does not differentiate from sibling tools like rlm.artifact.get or rlm.docs.list, which also involve document retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description mentions search methods (bm25, regex, literal) but does not explain when to choose one over another, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark session complete and persist index metadata.
Args: session_id: Session ID to close
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It mentions 'persist index metadata' implying writes, but does not disclose if the operation is destructive, reversible, or any side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with no wasted words. However, the Args section repeats schema info, slightly reducing efficiency. It is front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple close operation with one parameter and an existing output schema, the description is adequate but gaps remain: no mention of idempotency, error conditions, or session state expectations. It meets minimum viability but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes 'Args: session_id: Session ID to close', but the schema already has a title 'Session Id'. This adds little meaning beyond the schema. Schema description coverage is 0%, indicating no additional parameter info in the description proper, though the Args block provides marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Mark session complete and persist index metadata.' The verb 'mark' and resource 'session' are specific. This distinguishes it from siblings like rlm.session.create and rlm.session.info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites, conditions, or exclusions are mentioned. The description only states what it does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new RLM session for processing large contexts.
Args: name: Human-readable session name config: Session configuration (max_tool_calls, max_chars_per_response, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| config | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions creation but omits side effects (e.g., session resources consumption, authentication needs, rate limits) or any potential destructive actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loaded with the core purpose, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and low schema coverage, the description does not fully compensate. It lacks details on return values (though output schema exists), session lifecycle, or error conditions, making it incomplete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It provides basic descriptions for 'name' and 'config', but 'config' details are incomplete ('max_tool_calls, max_chars_per_response, etc.') without enumerating all possible fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'RLM session', specifying its purpose 'for processing large contexts'. This distinguishes it from sibling tools like rlm.session.close and rlm.session.info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for large contexts but provides no explicit guidance on when to use this tool instead of alternatives, nor 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.
Get session statistics and configuration.
Args: session_id: Session ID to query
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose side effects, auth requirements, or behavior on invalid input. 'Get' implies read-only but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise with no wasted words. However, it could be slightly more structured with optional usage hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema to cover return values. Description covers basic function and parameter. Missing usage context and error scenarios; adequate for simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description only adds 'Session ID to query' which is nearly tautological. No format, constraints, or examples provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets session statistics and configuration. Distinguishes from siblings like rlm.session.create (create), rlm.session.close (close), and others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not mention when it is appropriate relative to other session tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the content of one or more spans. Enforces max_chars_per_response.
Args: session_id: Session containing spans span_ids: List of span IDs to retrieve
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| span_ids | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions max_chars_per_response but omits other behavioral details like idempotency, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and front-loaded purpose. The args section is integrated, no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool. Output schema exists, so return value not required. But could elaborate on max_chars_per_response behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds brief meaning for each parameter beyond schema titles, compensating for 0% schema coverage. However, it does not elaborate on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves span content, with a constraint on max characters. Distinguishable from siblings like rlm.artifact.get, though 'spans' assumed understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The sibling list exists but description does not differentiate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.2rlm.artifact.getrlm.artifact.listrlm.artifact.storerlm.chunk.createrlm.docs.listrlm.docs.loadrlm.docs.peekrlm.search.queryrlm.session.closerlm.session.createrlm.session.inforlm.span.getScored across 12 tools
Each tool targets a distinct resource (artifact, chunk, doc, session, span) and action, with clear descriptions. No ambiguity between tools.
All tools follow a consistent `rlm.<resource>.<action>` dot-separated pattern, improving predictability for agents.
12 tools cover the necessary operations for a document processing server without being excessive or insufficient.
The tool set covers core lifecycle operations (session creation/close, document loading/peeking, artifact storage/retrieval, search), but lacks delete or update operations for several resources, which may be intentional but limits completeness.
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
Ingest, manage, and retrieve documents for RAG-powered AI applications
Universal persistent memory and knowledge retrieval layer for AI agents and LLMs.
Intelligent context infrastructure for AI teams: knowledge graph, sessions, tasks, documents.
