headroom_agent_mcp
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., "@headroom_agent_mcpExplore the codebase to locate the billing logic and suggest which files the parent should read first."
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.
headroom_agent_mcp
MCP server overlay for OpenClaw that runs a discovery subagent behind an optional Headroom proxy.
It is designed for the cases where Headroom actually helps:
large docs / README files
noisy logs and terminal output
broad codebase discovery before the parent agent reads raw files
It is not a final code-editing agent. The parent agent still reads raw files and patches them directly.
Status
New standalone repository
Intended to be published separately from upstream
headroomLicense:
Apache-2.0Upstream compatibility target:
headroom+OpenClaw
Related MCP server: openkrak-mcp
What It Exposes
One MCP tool:
run_discovery
Use it when the parent agent needs:
docs_researchlogs_triagecodebase_discovery
Do not use it when:
you already know the exact 1-3 files to edit
you need final patch generation
the input is already small and precise
Tool Contract
Input highlights:
objective: concrete goal for this runobjective_type:docs_research|logs_triage|codebase_discoveryscope_paths: files, directories, or URLsquery_hints: extra terms to bias searchterminal_commands: optional tokenized safe commands like["git", "status"]command_allowlist_profile:safe_readonlyorsafe_terminal
Output highlights:
relevant_findingscandidate_filescandidate_symbolssmall_snippetsraw_reads_needed_by_parentrecommended_next_action
The parent agent should treat raw_reads_needed_by_parent as the handoff for precise next reads before any edit.
Architecture
Parent Agent
-> run_discovery (this MCP)
-> scoped file/url collection
-> safe terminal commands
-> optional LLM summarization
-> optionally routed through Headroom proxy
<- structured discovery output
Parent Agent
-> reads raw target files itself
-> edits code itselfWhy Headroom Is Optional Here
This repo does not reimplement Headroom compression logic.
Instead, if you configure the subagent model to talk to a Headroom proxy, the subagent gets automatic compression on its own model traffic while it explores noisy inputs. That keeps the parent agent precise and uncompressed for final edits.
Configuration
Copy .env.template to .env or export the variables in your runtime:
HEADROOM_AGENT_MODEL_PROVIDERHEADROOM_AGENT_MODEL_NAMEHEADROOM_AGENT_BASE_URLHEADROOM_AGENT_API_KEYHEADROOM_PROXY_URL(optional)
If HEADROOM_PROXY_URL is set, the configured LLM profile can route through it.
OpenClaw Example
Add a server entry like the example in config/openclaw.headroom_agent_mcp.example.json.
The MCP description is intentionally explicit so the parent agent knows:
when to call it
what to pass
what not to expect from it
Development
Windows local test venv:
python -m venv C:\Users\giova\.venvs\headroom_agent_mcp
C:\Users\giova\.venvs\headroom_agent_mcp\Scripts\python -m pip install -e Z:\Repositories\headroom_agent_mcp[dev]
C:\Users\giova\.venvs\headroom_agent_mcp\Scripts\python -m pytest Z:\Repositories\headroom_agent_mcp\tests -qDGX smoke scripts:
scripts/run_tests_dgx.shscripts/smoke_check_dgx.shscripts/smoke_openrouter_headroom_dgx.sh
License And Attribution
This repository is licensed under Apache-2.0, matching the upstream Headroom project.
Why this shape:
upstream
headroomis Apache-2.0 licensedthis repo is a separate overlay/companion project, not a fork that modifies upstream in place
Apache-2.0 allows separate derivative or companion works as long as the license text is included and attribution/trademark rules are respected
Files added for that:
LICENSENOTICE
Upstream reference:
Headroom: headroomlabs-ai/headroom
This project references Headroom for interoperability and architectural patterns, but does not claim affiliation or endorsement.
Current Scope
Implemented:
contract validation
safe terminal policy
deterministic discovery service
optional OpenAI-compatible LLM enrichment
MCP server and CLI smoke check
Not implemented:
write/edit tools
automatic child-process orchestration inside OpenClaw
remote web search provider integration beyond direct URL fetch
Available Tools
1 toolrun_discoveryARead-only
Explore noisy docs, logs, or codebases and return only the evidence a parent agent needs.
Use this tool when the parent agent needs discovery or triage before reading raw files itself. Best cases: docs research, logs/output triage, or codebase discovery over broad scopes. Do not use it for final file edits or precise patch generation.
Inputs:
objective: concrete question or goal for this run
objective_type: docs_research, logs_triage, or codebase_discovery
scope_paths: files, directories, or URLs to inspect
query_hints: optional extra terms to bias search/scoring
terminal_commands: optional tokenized safe commands, e.g. [["git","status"],["pytest","-q"]]
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context: the tool filters noisy inputs, returns only evidence, handles broad scopes, and accepts 'safe commands.' It does not contradict the annotations and provides useful extra context beyond them.
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 well-organized and front-loaded: purpose first, usage guidance second, and a compact bulleted parameter list. Every sentence contributes useful information, and the example for terminal_commands is valuable without adding unnecessary length.
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 description covers purpose, usage, and key parameters, but the tool has no output schema and the description gives only a vague sense of the return value ('return only the evidence'). It also does not explain how budgets, snippets, or command allowlist profiles affect behavior, so an agent may not know how to tune or interpret the call.
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 explains the core parameters well: objective, objective_type, scope_paths, query_hints, and terminal_commands, including a concrete example. However, it omits several meaningful parameters such as raw_read_budget, max_files, return_snippets, and command_allowlist_profile, leaving gaps an agent must infer.
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 action verb and resource ('Explore noisy docs, logs, or codebases') and clearly states the output ('return only the evidence a parent agent needs'). It also enumerates the supported objective types, making the tool's purpose unmistakable.
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 states when to use the tool ('discovery or triage before reading raw files itself'), lists best cases, and gives a concrete exclusion ('Do not use it for final file edits or precise patch generation'). This gives an agent clear routing guidance even without sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
run_discovery
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlap between tools. run_discovery has a clearly defined purpose and inputs, making it unambiguous for an agent to select.
The single tool name run_discovery follows a clear verb_noun convention. There are no other tools to create naming inconsistencies or mixed conventions.
One tool is minimal, but it is appropriate for a narrowly scoped discovery/triage subagent. The count feels slightly thin compared to typical multi-tool servers, but the server's purpose is focused enough that a single tool can reasonably fulfill it.
The tool covers the stated discovery domain across docs research, logs triage, and codebase discovery, with support for scope paths, query hints, and safe terminal commands. Minor gaps exist around iterative refinement or returning raw context, but the core triage workflow is well covered.
Maintenance
Related MCP Connectors
AI agent infrastructure for discovery, authorization, execution, identity, and signed receipts.
Machine-native research commons for agent evidence, discovery, rooms, and bounded research quests.
Outcome-first agent fallback: free discovery, minimal routing, declared costs, verified execution.
MCP delegation fallback for AI agents to discover capabilities, knowledge, tools, and collaborators.
Related MCP Servers
- AlicenseAqualityBmaintenanceEnables Claude Code to delegate bounded repository tasks to DeepSeek as a local sub-agent, handling exploration, routine changes, and test runs within a controlled workspace and budget.31MIT
- FlicenseNot gradedqualityBmaintenanceEnables coding agents to pre-compute repository structure and access structured intelligence briefs, including dependency graphs, hotspots, and blast radius, reducing token usage and improving code understanding.1,668 npm1-
- AlicenseAqualityAmaintenanceEnables Claude Code and Claude Desktop to delegate token-heavy tasks to Antigravity headless subagents, offloading file edits, test runs, and exploration while preserving Claude's context window.1224 npm1MIT
- FlicenseAqualityCmaintenanceEnables main agents to delegate memory retrieval, web research, and multi-step tasks to internal sub-agents, returning concise conclusions while keeping detailed tool calls and raw content out of the main context.3-