Facilitates the processing of massive documentation by providing specialized chunking and analysis strategies tailored for Markdown content.
Enables free local inference for performing recursive sub-queries and semantic analysis on massive contexts using models like gemma3 and llama3.
Allows for deterministic data extraction and pattern matching against loaded contexts by executing Python code in a sandboxed subprocess.
Enables filtering and analysis of structured XML data within large-scale contexts using both LLM reasoning and deterministic tools.
Click on "Install 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., "@Massive Context MCP summarize this massive log file and find the main error patterns"
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.
Handle massive contexts (10M+ tokens) with chunking, sub-queries, and free local inference via Ollama.
flowchart TD
A[Claude Code] --> B[RLM MCP Server]
B --> C{rlm_ollama_status}
C -->|cached 60s| D{provider = auto}
D -->|Ollama running| E[🦙 Ollama<br/>gemma3:12b]
D -->|Ollama unavailable| F[☁️ Claude SDK<br/>claude-haiku-4-5]
E --> G[["💰 $0<br/>Free local inference"]]
F --> H[["💰 ~$0.80/1M<br/>Cloud inference"]]
style A fill:#ff922b,color:#fff
style B fill:#339af0,color:#fff
style E fill:#51cf66,color:#fff
style F fill:#748ffc,color:#fff
style G fill:#51cf66,color:#fff
style H fill:#748ffc,color:#fffBased on the Recursive Language Model pattern. Inspired by richardwhiteii/rlm.
Instead of feeding massive contexts directly into the LLM:
Load context as external variable (stays out of prompt)
Inspect structure programmatically
Chunk strategically (lines, chars, or paragraphs)
Sub-query recursively on chunks
Aggregate results for final synthesis
Related MCP server: log-mcp
Option 1: PyPI (Recommended)
uvx massive-context-mcp
# or
pip install massive-context-mcpWith Optional Extras:
# With Code Firewall integration (security filter for rlm_exec)
pip install massive-context-mcp[firewall]
# With Claude Agent SDK (for programmatic Claude API access)
pip install massive-context-mcp[claude]
# With all extras
pip install massive-context-mcp[firewall,claude]Option 2: Claude Desktop One-Click
Download the .mcpb from Releases and double-click to install.
Option 3: From Source
git clone https://github.com/egoughnour/massive-context-mcp.git
cd massive-context-mcp
uv syncAdd to ~/.claude/.mcp.json (Claude Code) or claude_desktop_config.json (Claude Desktop):
{
"mcpServers": {
"massive-context": {
"command": "uvx",
"args": ["massive-context-mcp"],
"env": {
"RLM_DATA_DIR": "~/.rlm-data",
"OLLAMA_URL": "http://localhost:11434"
}
}
}
}Tool | Purpose |
| Check system requirements — verify macOS, Apple Silicon, 16GB+ RAM, Homebrew |
| Install via Homebrew — managed service, auto-updates, requires Homebrew |
| Install via direct download — no sudo, fully headless, works on locked-down machines |
| Check Ollama availability — detect if free local inference is available |
Tool | Purpose |
| One-step analysis — auto-detects type, chunks, and queries |
| Load context as external variable |
| Get structure info without loading into prompt |
| Chunk by lines/chars/paragraphs |
| Retrieve specific chunk |
| Filter with regex (keep/remove matching lines) |
| Execute Python code against loaded context (sandboxed) |
| Make sub-LLM call on chunk |
| Process multiple chunks in parallel |
| Store sub-call result for aggregation |
| Retrieve stored results |
| List all loaded contexts |
rlm_auto_analyzeFor most use cases, just use rlm_auto_analyze — it handles everything automatically:
rlm_auto_analyze(
name="my_file",
content=file_content,
goal="find_bugs" # or: summarize, extract_structure, security_audit, answer:<question>
)What it does automatically:
Detects content type (Python, JSON, Markdown, logs, prose, code)
Selects optimal chunking strategy
Adapts the query for the content type
Runs parallel sub-queries
Returns aggregated results
Supported goals:
Goal | Description |
| Summarize content purpose and key points |
| Identify errors, issues, potential problems |
| List functions, classes, schema, headings |
| Find vulnerabilities and security issues |
| Answer a custom question about the content |
rlm_execFor deterministic pattern matching and data extraction, use rlm_exec to run Python code directly against a loaded context. This is closer to the paper's REPL approach and provides full control over analysis logic.
Tool: rlm_exec
Purpose: Execute arbitrary Python code against a loaded context in a sandboxed subprocess.
Parameters:
code (required): Python code to execute. Set the result variable to capture output.
context_name (required): Name of a previously loaded context.
timeout (optional, default 30): Maximum execution time in seconds.
Features:
Context available as read-only context variable
Pre-imported modules: re, json, collections
Subprocess isolation (won't crash the server)
Timeout enforcement
Works on any system with Python (no Docker needed)
Example — Finding patterns in a loaded context:
# After loading a context
rlm_exec(
code="""
import re
amounts = re.findall(r'\$[\d,]+', context)
result = {'count': len(amounts), 'sample': amounts[:5]}
""",
context_name="bill"
)Example Response:
{
"result": {
"count": 1247,
"sample": ["$500", "$1,000", "$250,000", "$100,000", "$50"]
},
"stdout": "",
"stderr": "",
"return_code": 0,
"timed_out": false
}Example — Extracting structured data:
rlm_exec(
code="""
import re
import json
# Find all email addresses
emails = re.findall(r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b', context)
# Count by domain
from collections import Counter
domains = [e.split('@')[1] for e in emails]
domain_counts = Counter(domains)
result = {
'total_emails': len(emails),
'unique_domains': len(domain_counts),
'top_domains': domain_counts.most_common(5)
}
""",
context_name="dataset",
timeout=60
)When to use rlm_exec vs rlm_sub_query:
Use Case | Tool | Why |
Extract all dates, IDs, amounts |
| Regex is deterministic and fast |
Find security vulnerabilities |
| Requires reasoning and context |
Parse JSON/XML structure |
| Standard libraries work perfectly |
Summarize themes or tone |
| Natural language understanding needed |
Count word frequencies |
| Simple computation, no AI needed |
Answer "Why did X happen?" |
| Requires inference and reasoning |
Tip: For large contexts, combine both — use rlm_exec to filter/extract, then rlm_sub_query for semantic analysis of filtered results.
For enhanced security, integrate code-firewall-mcp to filter dangerous code patterns before execution:
pip install massive-context-mcp[firewall]When installed, rlm_exec can automatically check code against a blacklist of known dangerous patterns (e.g., os.system(), eval(), subprocess with shell=True). The firewall uses structural similarity matching — normalizing code to its skeleton and comparing against blacklisted patterns via embeddings.
How it works:
Code is parsed to a syntax tree and normalized (identifiers → _, strings → "S")
Normalized structure is embedded via Ollama
Similarity is checked against blacklisted patterns in ChromaDB
Code is blocked if similarity exceeds threshold (default: 0.85)
Configuration (environment variables):
RLM_FIREWALL_ENABLED=true — Enable firewall checks (auto-enabled when package installed)
RLM_FIREWALL_MODE=warn|block — Warn or block on matches (default: warn)
Example blocked patterns:
os.system(user_input) — Command injection
eval(untrusted_data) — Code injection
subprocess.Popen(..., shell=True) — Shell injection
Use rlm_firewall_status to check firewall availability and configuration.
RLM automatically detects and uses the best available provider:
Provider | Default Model | Cost | Use Case |
| (best available) | $0 or ~$0.80/1M | Default — prefers Ollama if available |
| gemma3:12b | $0 | Local inference, requires Ollama |
| claude-haiku-4-5 | ~$0.80/1M input | Cloud inference, always available |
When you use provider="auto" (the default), RLM:
Checks if Ollama is running at OLLAMA_URL (default: http://localhost:11434)
Checks if gemma3:12b is available (or any gemma3 variant)
Uses Ollama if available, otherwise falls back to Claude SDK
The status is cached for 60 seconds to avoid repeated network checks.
Use rlm_ollama_status to see what's available:
rlm_ollama_status()Response when Ollama is ready:
{
"running": true,
"models": ["gemma3:12b", "llama3:8b"],
"default_model_available": true,
"best_provider": "ollama",
"recommendation": "Ollama is ready! Sub-queries will use free local inference by default."
}Response when Ollama is not available:
{
"running": false,
"error": "connection_refused",
"best_provider": "claude-sdk",
"recommendation": "Ollama not available. Sub-queries will use Claude API. To enable free local inference, install Ollama and run: ollama serve"
}All sub-query responses include which provider was actually used:
{
"provider": "ollama",
"model": "gemma3:12b",
"requested_provider": "auto",
"response": "..."
}Enable Claude to use RLM tools automatically without manual invocation:
1. CLAUDE.md Integration
Copy CLAUDE.md.example content to your project's CLAUDE.md (or ~/.claude/CLAUDE.md for global) to teach Claude when to reach for RLM tools automatically.
2. Hook Installation
Copy the .claude/hooks/ directory to your project to auto-suggest RLM when reading files >10KB:
cp -r .claude/hooks/ /Users/your_username/your-project/.claude/hooks/The hook provides guidance but doesn't block reads.
3. Skill Reference
Copy the .claude/skills/ directory for comprehensive RLM guidance:
cp -r .claude/skills/ /Users/your_username/your-project/.claude/skills/With these in place, Claude will autonomously detect when to use RLM instead of reading large files directly into context.
RLM can automatically install and configure Ollama on macOS with Apple Silicon. There are two installation methods with different trade-offs:
Aspect |
|
|
Sudo required | Only if Homebrew not installed | ❌ Never |
Homebrew required | ✅ Yes | ❌ No |
Auto-updates | ✅ Yes ( | ❌ Manual |
Service management | ✅ | ⚠️ |
Install location |
|
|
Locked-down machines | ⚠️ May fail | ✅ Works |
Fully headless | ⚠️ May prompt for sudo | ✅ Yes |
Recommendation:
Use Homebrew method if you have Homebrew and want managed updates
Use Direct Download for automation, locked-down machines, or when you don't have admin access
# 1. Check if your system meets requirements
rlm_system_check()
# 2. Install via Homebrew
rlm_setup_ollama(install=True, start_service=True, pull_model=True)What this does:
Installs Ollama via Homebrew (brew install ollama)
Starts Ollama as a managed background service (brew services start ollama)
Pulls gemma3:12b model (~8GB download)
Requirements:
macOS with Apple Silicon (M1/M2/M3/M4)
16GB+ RAM (gemma3:12b needs ~8GB to run)
Homebrew installed
# 1. Check system (Homebrew NOT required for this method)
rlm_system_check()
# 2. Install via direct download - no sudo, no Homebrew
rlm_setup_ollama_direct(install=True, start_service=True, pull_model=True)What this does:
Downloads Ollama from https://ollama.com/download/Ollama-darwin.zip
Extracts to ~/Applications/Ollama.app (user directory, no admin needed)
Starts Ollama via ollama serve (background process)
Pulls gemma3:12b model
Requirements:
macOS with Apple Silicon (M1/M2/M3/M4)
16GB+ RAM
No special permissions needed!
Note on PATH: After direct installation, the CLI is at:
~/Applications/Ollama.app/Contents/Resources/ollamaAdd to your shell config if needed:
export PATH="$HOME/Applications/Ollama.app/Contents/Resources:$PATH"Use a smaller model on either installation method:
rlm_setup_ollama(install=True, start_service=True, pull_model=True, model="gemma3:4b")
# or
rlm_setup_ollama_direct(install=True, start_service=True, pull_model=True, model="gemma3:4b")If you prefer manual installation or are on a different platform:
Install Ollama from https://ollama.ai or via Homebrew:
brew install ollamaStart the service:
brew services start ollama
# or: ollama servePull the model:
ollama pull gemma3:12bVerify it's working:
rlm_ollama_status()RLM automatically uses Ollama when available. You can also force a specific provider:
# Auto-detection (default) - uses Ollama if available
rlm_sub_query(query="Summarize", context_name="doc")
# Explicitly use Ollama
rlm_sub_query(query="Summarize", context_name="doc", provider="ollama")
# Explicitly use Claude SDK
rlm_sub_query(query="Summarize", context_name="doc", provider="claude-sdk")# 0. (Optional) First-time setup on macOS - choose ONE method:
# Option A: Homebrew (if you have it)
rlm_system_check()
rlm_setup_ollama(install=True, start_service=True, pull_model=True)
# Option B: Direct download (no sudo, fully headless)
rlm_system_check()
rlm_setup_ollama_direct(install=True, start_service=True, pull_model=True)
# 0b. (Optional) Check if Ollama is available for free inference
rlm_ollama_status()
# 1. Load a large document
rlm_load_context(name="report", content=<large document>)
# 2. Inspect structure
rlm_inspect_context(name="report", preview_chars=500)
# 3. Chunk into manageable pieces
rlm_chunk_context(name="report", strategy="paragraphs", size=1)
# 4. Sub-query chunks in parallel (auto-uses Ollama if available)
rlm_sub_query_batch(
query="What is the main topic? Reply in one sentence.",
context_name="report",
chunk_indices=[0, 1, 2, 3],
concurrency=4
)
# 5. Store results for aggregation
rlm_store_result(name="topics", result=<response>)
# 6. Retrieve all results
rlm_get_results(name="topics")Tested with H.R.1 Bill (2MB):
# Load
rlm_load_context(name="bill", content=<2MB XML>)
# Chunk into 40 pieces (50K chars each)
rlm_chunk_context(name="bill", strategy="chars", size=50000)
# Sample 8 chunks (20%) with parallel queries
# (auto-uses Ollama if running, otherwise Claude SDK)
rlm_sub_query_batch(
query="What topics does this section cover?",
context_name="bill",
chunk_indices=[0, 5, 10, 15, 20, 25, 30, 35],
concurrency=4
)Result: Comprehensive topic extraction at $0 cost (with Ollama) or ~$0.02 (with Claude).
Literary analysis of Tolstoy's epic novel from Project Gutenberg:
# Download the text
curl -o war_and_peace.txt https://www.gutenberg.org/files/2600/2600-0.txt# Load into RLM (3.3MB, 66K lines)
rlm_load_context(name="war_and_peace", content=open("war_and_peace.txt").read())
# Chunk by lines (1000 lines per chunk = 67 chunks)
rlm_chunk_context(name="war_and_peace", strategy="lines", size=1000)
# Sample 10 chunks evenly across the book (15% coverage)
sample_indices = [0, 7, 14, 21, 28, 35, 42, 49, 56, 63]
# Extract characters from each sampled section
rlm_sub_query_batch(
query="List major characters in this section with brief descriptions.",
context_name="war_and_peace",
chunk_indices=sample_indices,
provider="claude-sdk", # Haiku 4.5
concurrency=8
)Result: Complete character arc across the novel — Pierre's journey from idealist to prisoner to husband, Natásha's growth, Nikolái Rostóv's journey from soldier to landowner — all for ~$0.03.
Metric | Value |
File size | 3.35 MB |
Lines | 66,033 |
Chunks | 67 |
Sampled | 10 (15%) |
Cost | ~$0.03 |
graph TD
A[("$RLM_DATA_DIR")] --> B["📁 contexts/"]
A --> C["📁 chunks/"]
A --> D["📁 results/"]
B --> B1[".txt files"]
B --> B2[".meta.json"]
C --> C1["by context name"]
D --> D1[".jsonl files"]
style A fill:#339af0,color:#fff
style B fill:#51cf66,color:#fff
style C fill:#51cf66,color:#fff
style D fill:#51cf66,color:#fffContexts persist across sessions. Chunked contexts are cached for reuse.
Use these prompts with Claude Code to explore the codebase and learn RLM patterns. The code is the single source of truth.
Read src/rlm_mcp_server.py and list all RLM tools with their parameters and purpose.Explain the chunking strategies available in rlm_chunk_context.
When would I use each one?What's the difference between rlm_sub_query and rlm_sub_query_batch?
Show me the implementation.Read src/rlm_mcp_server.py and explain how contexts are stored and persisted.
Where does the data live?How does the claude-sdk provider extract text from responses?
Walk me through _call_claude_sdk.What happens when I call rlm_load_context? Trace the full flow.Load the README as a context, chunk it by paragraphs,
and run a sub-query on the first chunk to summarize it.Show me how to process a large file in parallel using rlm_sub_query_batch.
Use a real example.I have a 1MB log file. Walk me through the RLM pattern to extract all errors.Read the test file and explain what scenarios are covered.
What edge cases should I be aware of?How would I add a new chunking strategy (e.g., by regex delimiter)?
Show me where to modify the code.How would I add a new provider (e.g., OpenAI)?
What functions need to change?MIT
Automatically detect content type and analyze with optimal chunking strategy.
One-step analysis for common tasks.
Args: name: Context identifier content: The content to analyze goal: Analysis goal: 'summarize', 'find_bugs', 'extract_structure', 'security_audit', or 'answer:' provider: LLM provider - 'auto' prefers Ollama if available concurrency: Max parallel requests (default 4, max 8)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| content | Yes | ||
| goal | Yes | ||
| provider | No | auto | |
| concurrency | 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; it mentions automatic content detection and chunking but does not clarify whether the tool mutates state, requires specific permissions, or has side effects. The 'optimal chunking strategy' is vague, and no mention of output behavior or error handling is provided.
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, leading with the core purpose and using a clear list for parameters. Every sentence adds information, though the parameter list could be more structured (e.g., docstring format) but is still effective.
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?
While the output schema exists (not shown), the description fails to connect the tool's results to sibling tools like rlm_store_result or rlm_get_results, leaving the workflow unclear. For a complex analytical tool, the description should explain how to handle outputs or integrate with other steps.
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 explains all five parameters beyond the schema: name as context identifier, content as the material, goal with enumerated options, provider with default and preference, and concurrency with default and max. This adds significant value given 0% schema coverage.
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 automatically detects content type and analyzes with an optimal chunking strategy, specifying common tasks via the goal parameter. This distinguishes it from sibling tools like rlm_chunk_context or rlm_sub_query, which have different purposes.
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 a list of possible goals and hints at one-step analysis, but it does not explicitly explain when to use this tool instead of siblings like rlm_filter_context or rlm_exec. Usage context is implied but not definitive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Chunk a loaded context by strategy. Returns chunk metadata, not full content.
Args: name: Context identifier strategy: Chunking strategy - 'lines', 'chars', or 'paragraphs' size: Chunk size (lines/chars depending on strategy)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| strategy | No | lines | |
| size | 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 convey behavioral traits. It notes that only metadata is returned, not full content, and lists the strategies. However, it does not disclose whether chunking modifies the original context, side effects, or required permissions.
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 three sentences with no filler. It front-loads the purpose and follows with parameter details. Every sentence adds value; no redundancy.
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 an output schema, so return value details are not needed. The description covers parameters and output type. However, it lacks explicit preconditions (e.g., context must be loaded) and does not differentiate from sibling chunk-related tools. Still, it is adequately complete for a straightforward 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 is essential. It explains 'name' as context identifier, 'strategy' with valid options (lines, chars, paragraphs), and 'size' with context-dependent meaning. This adds significant value beyond the schema's type/default info.
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 ('chunk'), the resource ('a loaded context'), and the output ('chunk metadata, not full content'). It distinguishes from siblings like rlm_load_context and rlm_get_chunk which have different purposes.
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 that the context must be loaded before chunking, but does not explicitly state when to use this tool versus alternatives like rlm_filter_context. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute Python code against a loaded context in a sandboxed subprocess.
Set result variable for output.
Args: code: Python code to execute. User sets result variable for output. context_name: Name of previously loaded context timeout: Max execution time in seconds (default 30)
Security: When RLM_FIREWALL_ENABLED=1, code is checked against known dangerous patterns before execution. Blocked code returns an error instead of executing.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| context_name | Yes | ||
| timeout | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses sandboxed subprocess, security firewall check (RLM_FIREWALL_ENABLED=1) and timeout behavior. Does not mention persistence or idempotency, but covers key safety aspects.
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?
Well-structured with Args and Security sections. Purpose sentence is front-loaded. Could be slightly more concise, but no redundant content.
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?
Output schema exists, so return values are not needed in description. However, description lacks detail on error types, success behavior, and handling of large code blocks. Security and timeout are covered, but more context on execution results would improve 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?
Input schema has 0% description coverage. Description compensates by explaining 'code' requires a result variable, 'context_name' is a previously loaded context, and 'timeout' has default 30. Adds meaning beyond type information.
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 'Execute Python code against a loaded context in a sandboxed subprocess', specifying verb, resource, and environment. Distinguishes from sibling tools like rlm_load_context and rlm_store_result by focusing on code execution.
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?
Description implies use when needing to execute custom Python code, but lacks explicit guidance on when to use this tool versus alternatives (e.g., rlm_sub_query, rlm_filter_context). No when-not or comparison provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filter context using regex/string operations. Creates a new filtered context.
Args: name: Source context identifier output_name: Name for filtered context pattern: Regex pattern to match mode: 'keep' or 'remove' matching lines
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| output_name | Yes | ||
| pattern | Yes | ||
| mode | No | keep |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It mentions 'creates a new filtered context', implying the original is unchanged, but does not specify error handling for invalid regex, input size limits, or whether the operation is reversible. Minimal beyond basic purpose.
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 at two sentences plus a bullet-style Args list. It front-loads the purpose and then details parameters efficiently with no 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?
Given the tool has an output schema (though not shown), return values need not be explained. The description covers the core purpose and parameters. However, it lacks details on how to use the result (e.g., accessing the new context) and error scenarios, but overall is sufficient for a filter 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 coverage is 0%, so the description must compensate. It provides brief explanations for all four parameters (name, output_name, pattern, mode) in the Args section, adding meaning beyond the raw schema. This is adequate but could be more detailed (e.g., pattern format).
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 filters context using regex/string operations and creates a new filtered context. The verb 'filter' combined with resource 'context' is specific, and the tool is distinct from siblings like rlm_chunk_context or rlm_inspect_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?
No guidance is provided on when to use this tool versus alternatives (e.g., rlm_chunk_context for splitting, rlm_inspect_context for viewing). The description only states what it does, not when or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of the code execution firewall.
Returns information about whether the firewall is enabled, the Ollama endpoint being used, and whether dangerous code patterns will be blocked.
The firewall is auto-enabled when code-firewall-mcp is installed: pip install massive-context-mcp[firewall]
Returns: { "enabled": bool, "package_installed": bool, "ollama_url": str, "embedding_model": str, "similarity_threshold": float, "ollama_reachable": bool, }
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 full burden. It discloses that the firewall is auto-enabled upon installation and describes the return fields. It does not mention side effects (likely none) and is consistent with a read operation.
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 brief, front-loaded with the purpose, and every sentence is informative. It includes a clear return format without unnecessary verbiage.
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 zero parameters and a well-described output schema in the description, the tool definition is completely self-sufficient. It covers what the tool does, what it returns, and how the firewall is enabled.
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 parameters and 100% coverage. The description adds significant value by specifying the exact return structure (enabled, package_installed, ollama_url, etc.) beyond what the schema provides. Baseline for 0 params is 4, and the rich return type warrants a 5.
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 checks the status of the code execution firewall and lists the specific information returned (enabled, package_installed, ollama_url, etc.). This is a specific verb+resource that distinguishes it from siblings like rlm_ollama_status or rlm_system_check.
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?
It implies usage for checking firewall status but does not explicitly state when to use this versus alternatives like rlm_system_check. No guidance on prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific chunk by index. Use after chunking to retrieve individual pieces.
Args: name: Context identifier chunk_index: Index of chunk to retrieve
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| chunk_index | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The description implies it is a read operation ('Get'), but does not explicitly state lack of side effects, permissions, or other behaviors. It is adequate but could be more 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?
The description is extremely concise: one sentence plus a two-line args list. It is front-loaded with the purpose and contains no filler.
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 retrieval tool with two parameters and an output schema (not shown), the description is complete. It explains the tool's purpose and parameter meanings. The output schema presumably covers return values, so no further explanation needed.
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?
With 0% schema description coverage, the description adds meaning by documenting parameters: 'name: Context identifier' and 'chunk_index: Index of chunk to retrieve.' This clarifies purpose beyond the raw 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 clearly states 'Get a specific chunk by index' and provides context 'Use after chunking to retrieve individual pieces.' It distinguishes itself from sibling tools like rlm_chunk_context (likely creates chunks) and rlm_get_results (likely gets results).
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 explicitly says 'Use after chunking to retrieve individual pieces,' indicating when to use it. Although it does not mention when not to use it or alternatives, the guidance is sufficient for a simple retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve stored results for aggregation.
Args: name: Result set identifier
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'retrieve', but does not disclose if operation is read-only, safety implications, or error handling (e.g., if name not found). 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?
Two short sentences, no fluff. Front-loaded with action and resource. Could be clearer by mentioning output or usage scope, but 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 elsewhere, but description lacks usage guidelines and behavioral transparency. For a simple one-param tool, it's adequate but leaves gaps for an AI agent to understand when and how to use it effectively.
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?
Input schema has 0% description coverage. Description barely adds: 'name: Result set identifier' only repeats the parameter name with a generic label. No details on format, allowed values, or constraints beyond 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?
Description clearly states 'Retrieve stored results for aggregation', indicating action and resource. However, lacks explicit differentiation from siblings like rlm_get_chunk, and 'stored results' is somewhat vague.
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_store_result or rlm_get_chunk. The description does not mention context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a loaded context - get structure info without loading full content into prompt.
Args: name: Context identifier preview_chars: Number of chars to preview (default 500)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| preview_chars | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states read-only behavior ('without loading full content') but does not mention permissions, side effects, or other traits typical for inspection tools.
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: two sentences plus param details. Front-loaded with key purpose. Every sentence adds value with no redundancy.
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?
Tool has output schema so return values likely documented there. Description covers purpose and params adequately for a simple inspection tool. Missing explicit example or sibling differentiation, but complete enough.
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%, yet description fully compensates by explaining 'name' as context identifier and 'preview_chars' as number of chars to preview with default, adding meaning beyond bare schema types.
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 verb 'inspect', resource 'loaded context', and what it does 'get structure info without loading full content'. Distinguishes from siblings by specifying it does not load full content.
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?
Description implies when to use (when structure info is needed without full content) but lacks explicit when-not or alternative tool names. The note about not loading full content provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all loaded contexts and their metadata.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description implies a read-only operation but provides no additional behavioral details (e.g., cost, pagination, or what 'metadata' includes).
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?
A single, front-loaded sentence with no extraneous words, efficiently conveying the tool's purpose.
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 presence of an output schema and the simplicity of the tool, the description is nearly complete, though it could elaborate on what 'metadata' entails.
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?
No parameters exist, so the schema covers 100%; the description adds no parameter info but is not required to, earning a baseline of 4.
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 a specific verb 'List' and identifies the resource as 'all loaded contexts' with 'their metadata', clearly distinguishing it from sibling tools like rlm_load_context or rlm_filter_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?
No explicit guidance on when to use this tool versus alternatives; usage is implied (list contexts when needed) but lacks exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a large context as an external variable.
Returns metadata without the content itself.
Args: name: Identifier for this context content: The full context content
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| content | 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 disclose side effects and behavior. It only states that metadata is returned without content, but omits whether this is a destructive operation, idempotent, or requires permissions.
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?
Three sentences, front-loaded with the main purpose, and no unnecessary words. Efficient and clear.
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 presence of an output schema, the description does not need to detail return values. However, it lacks usage context and behavioral details, making it only partially complete for effective use.
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 adds basic meaning to the two parameters ('Identifier' for name, 'full context content' for content), but does not provide constraints, examples, or format requirements. Schema coverage is 0%, so some compensation is needed.
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 ('Load a large context as an external variable') and key distinction ('Returns metadata without the content itself'), which differentiates it from siblings like rlm_chunk_context or rlm_filter_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?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Ollama server status and available models.
Returns whether Ollama is running, list of available models, and if the default model (gemma3:12b) is available. Use this to determine if free local inference is available.
Args: force_refresh: Force refresh the cached status (default: false)
| Name | Required | Description | Default |
|---|---|---|---|
| force_refresh | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses caching behavior and the force_refresh parameter to bypass cache, adding transparency. No side effects mentioned but none expected for a read-only status check.
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 succinct with three sentences and an Args section, each sentence providing essential information without redundancy. Well-structured and front-loaded.
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 simplicity and the presence of an output schema, the description covers the key return information: whether running, list of models, and default model availability. Complete for the intended use.
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 fully explains the sole parameter 'force_refresh' with its purpose and default value, adding meaningful semantics beyond the schema type.
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 checks Ollama server status and available models. It uses specific verb 'Check' and specific resource 'Ollama server status and available models', distinguishing it from sibling tools like setup commands.
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 explicitly says 'Use this to determine if free local inference is available', providing a clear usage context. It does not specify when not to use, but the context with siblings implies alternatives for setup or analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install Ollama via Homebrew (macOS).
Requires Homebrew pre-installed. Uses 'brew install' and 'brew services'. PROS: Auto-updates, pre-built binaries, managed service. CONS: Requires Homebrew, may prompt for sudo on first Homebrew install.
Args: install: Install Ollama via Homebrew (requires Homebrew) start_service: Start Ollama as a background service via brew services pull_model: Pull the default model (gemma3:12b) model: Model to pull (default: gemma3:12b). Use gemma3:4b or gemma3:1b for lower RAM systems.
| Name | Required | Description | Default |
|---|---|---|---|
| install | No | ||
| start_service | No | ||
| pull_model | No | ||
| model | No | gemma3:12b |
| 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 discloses installation method, dependency on Homebrew, potential sudo prompt, and explains each boolean flag. It also suggests model alternatives for lower RAM. However, it does not mention error handling or idempotency, so not a 5.
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, front-loads the purpose, and uses bullet points for args. Every sentence adds value (purpose, prerequisite, pros/cons, parameter details). No unnecessary text.
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 existence of an output schema, return value details are not needed. The description covers prerequisites, pros/cons, and all parameters. Missing some behavioral details like idempotency, but overall complete for a setup tool with 4 params.
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 must explain all parameters. It clearly explains each boolean flag's action (install, start service, pull model) and the model parameter's default and alternatives, fully compensating for the 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?
The description clearly states the tool installs Ollama via Homebrew on macOS, and lists specific sub-actions. However, it does not explicitly differentiate from sibling tool rlm_setup_ollama_direct, so it falls short of a 5.
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 mentions a prerequisite (Homebrew pre-installed) and lists pros/cons, but does not explicitly state when to use this tool versus alternatives like rlm_setup_ollama_direct. Usage context is present but no exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install Ollama via direct download (macOS).
Downloads from ollama.com to ~/Applications. PROS: No Homebrew needed, no sudo required, fully headless, works on locked-down machines. CONS: Manual PATH setup, no auto-updates, service runs as foreground process.
Args: install: Download and install Ollama to ~/Applications (no sudo needed) start_service: Start Ollama server (ollama serve) in background pull_model: Pull the default model (gemma3:12b) model: Model to pull (default: gemma3:12b). Use gemma3:4b or gemma3:1b for lower RAM systems.
| Name | Required | Description | Default |
|---|---|---|---|
| install | No | ||
| start_service | No | ||
| pull_model | No | ||
| model | No | gemma3:12b |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully carries the burden. Discloses download source, installation path, PATH setup, auto-update absence, foreground process, and behavior of each argument (e.g., background service).
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?
Structured with header, pros/cons bullet list, and argument list. No superfluous text; each sentence adds value. Front-loaded with purpose and context.
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?
Output schema exists (not shown) so return values need not be explained. Description covers installation, service start, and model pull steps. Minor gap: does not indicate how to verify success or handle errors, but sufficient for typical use.
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 0% but description explains each parameter: install, start_service, pull_model (as booleans) and model string with defaults and alternatives (gemma3:12b, gemma3:4b, gemma3:1b). Adds significant meaning beyond 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?
Description clearly states the tool installs Ollama via direct download on macOS, specifying the resource and action. It differentiates from sibling rlm_setup_ollama by noting pros/cons versus Homebrew.
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?
Explicitly lists pros/cons and steps (install, start_service, pull_model). Implies usage scenarios (headless, locked-down, no sudo). Lacks explicit when-not-to-use or direct comparison with sibling rlm_setup_ollama, but implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a sub-call result for later aggregation.
Args: name: Result set identifier result: Result content to store metadata: Optional metadata about this result
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| result | Yes | ||
| metadata | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions storing but omits details like overwrite behavior, size limits, idempotency, or any required context. This is insufficient for safe invocation.
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 clear docstring format, immediately stating the purpose and listing parameters with brief explanations. No extraneous content.
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 presence of an output schema (not shown), return value explanation is not required. However, the description lacks behavioral context (e.g., side effects, dependencies) and usage guidelines, making it only partially complete for a tool with 3 parameters.
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?
With 0% schema coverage, the description adds meaningful context: 'name: Result set identifier', 'result: Result content to store', 'metadata: Optional metadata about this result'. This clarifies each parameter's role, though additional constraints (e.g., format, length) are missing.
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 'Store a sub-call result for later aggregation', which identifies the verb and resource. However, it does not differentiate from sibling tools like rlm_get_results or rlm_sub_query, though the purpose is generally clear.
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. There is no mention of prerequisites or context where storing is appropriate, leaving the agent without clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a sub-LLM call on a chunk or filtered context. Core of recursive pattern.
Args: query: Question/instruction for the sub-call context_name: Context identifier to query against chunk_index: Optional: specific chunk index provider: LLM provider - 'auto', 'ollama', or 'claude-sdk'. 'auto' prefers Ollama if available (free local inference) model: Model to use (provider-specific defaults apply)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| context_name | Yes | ||
| chunk_index | No | ||
| provider | No | auto | |
| model | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks behavioral details such as side effects, required permissions, rate limits, or what happens to data; only lists parameters.
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?
Concise with clear header and bulleted args, 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?
Adequate for parameter listing but lacks behavioral context and integration details with sibling tools; output schema exists so return values not needed, but behavioral transparency gap remains.
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?
Adds meaning for provider (with 'auto' explanation) and chunk_index (optional), but does not explain query or context_name beyond names; schema coverage 0% makes description necessary.
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 makes a sub-LLM call on a chunk or filtered context, distinguishing it from siblings like rlm_sub_query_batch and rlm_filter_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?
Implied usage as 'core of recursive pattern' but no explicit when-to-use or when-not-to-use, nor comparison with alternatives like rlm_sub_query_batch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Process multiple chunks in parallel. Respects concurrency limit to manage system resources.
Args: query: Question/instruction for each sub-call context_name: Context identifier chunk_indices: List of chunk indices to process provider: LLM provider - 'auto', 'ollama', or 'claude-sdk' model: Model to use (provider-specific defaults apply) concurrency: Max parallel requests (default 4, max 8)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| context_name | Yes | ||
| chunk_indices | Yes | ||
| provider | No | auto | |
| model | No | ||
| concurrency | 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 fully disclose behavior. It mentions parallelism and concurrency limits but fails to indicate side effects (e.g., whether results are stored), idempotency, or prerequisites like context loading. The output schema is present, so return values are covered, but behavioral traits are underexplained.
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 concise: one sentence for purpose and a bullet-style list of parameters. No extraneous information; every sentence is necessary. It is well-structured and front-loaded.
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 existence of an output schema and sibling tools, the description covers the core functionality and parameter details well. However, it lacks mention of prerequisites (e.g., context must be loaded) and error handling in parallel processing, which would enhance 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?
The schema description coverage is 0%, so the description carries the full burden. It provides clear explanations for all 6 parameters, including default values, allowed values (e.g., provider options), and clarification on model defaults. This adds significant value beyond the raw 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 clearly states the tool processes multiple chunks in parallel, but it does not explicitly distinguish it from the sibling tool 'rlm_sub_query', which likely handles single sub-queries. The inclusion of 'batch' in the name and 'multiple chunks' provides some differentiation but not explicit contrast.
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 is provided on when to use this tool versus alternatives like 'rlm_sub_query'. The description only states what the tool does, without context on appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if system meets requirements for Ollama with gemma3:12b.
Verifies: macOS, Apple Silicon (M1/M2/M3/M4), 16GB+ RAM, Homebrew installed. Use before attempting Ollama setup.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden of behavioral disclosure. Description implies a read-only verification but does not explicitly state if any side effects occur. The existence of an output schema partially compensates, but without mentioning return format, transparency is adequate but not enhanced.
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?
Two concise sentences: first sentence states purpose, second lists specifics and usage context. No fluff, well structured, and front-loaded with critical 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 no parameters and presence of output schema, description is fairly complete. It explains what the tool checks and when to use it. Could mention the output format, but that is likely handled by the output schema.
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?
Input schema has zero parameters, so description need not add parameter info. Schema coverage is 100%. The description adds no extra parameter information, which is acceptable given no parameters exist.
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 the tool checks system requirements for Ollama with a specific model, using the verb 'check' and resource 'system requirements'. It distinguishes itself from sibling tools like rlm_ollama_status and rlm_setup_ollama, which deal with status and setup respectively.
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?
Explicitly states 'Use before attempting Ollama setup', providing clear context for when to invoke. Lists what it verifies (macOS, Apple Silicon, etc.), but does not mention when not to use or alternatives, though the sibling tools imply alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes (load, inspect, filter, chunk, analyze). However, the two setup tools (rlm_setup_ollama and rlm_setup_ollama_direct) are very similar and could confuse an agent, and auto_analyze overlaps somewhat with sub_query in using LLMs.
All tools follow a consistent 'rlm_verb_noun' pattern in snake_case. Verbs are descriptive and uniform (load, inspect, list, filter, chunk, get, store, etc.), with no mixing of conventions.
17 tools is well-scoped for managing large contexts, chunking, analysis, and system integration. Each tool serves a clear role; the count is not excessive nor too sparse.
Covers the majority of expected operations: loading, inspecting, filtering, chunking, analyzing, storing results, and system checks. Missing an explicit way to delete or combine contexts, but core workflows are covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/egoughnour/massive-context-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
