Skip to main content
Glama

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 headroom

  • License: Apache-2.0

  • Upstream 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_research

  • logs_triage

  • codebase_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 run

  • objective_type: docs_research | logs_triage | codebase_discovery

  • scope_paths: files, directories, or URLs

  • query_hints: extra terms to bias search

  • terminal_commands: optional tokenized safe commands like ["git", "status"]

  • command_allowlist_profile: safe_readonly or safe_terminal

Output highlights:

  • relevant_findings

  • candidate_files

  • candidate_symbols

  • small_snippets

  • raw_reads_needed_by_parent

  • recommended_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 itself

Why 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_PROVIDER

  • HEADROOM_AGENT_MODEL_NAME

  • HEADROOM_AGENT_BASE_URL

  • HEADROOM_AGENT_API_KEY

  • HEADROOM_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 -q

DGX smoke scripts:

  • scripts/run_tests_dgx.sh

  • scripts/smoke_check_dgx.sh

  • scripts/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 headroom is Apache-2.0 licensed

  • this 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:

  • LICENSE

  • NOTICE

Upstream reference:

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 tool
run_discoveryA
Read-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"]]

ParametersJSON Schema
NameRequiredDescriptionDefault
paramsYes

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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. 1 tool updatev0.1.0
    • First observedrun_discovery

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

The single tool name run_discovery follows a clear verb_noun convention. There are no other tools to create naming inconsistencies or mixed conventions.

Tool Count4/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    B
    maintenance
    Enables 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.
    3
    1
    MIT
  • F
    license
    Not graded
    quality
    B
    maintenance
    Enables 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 npm
    1
    -
  • F
    license
    A
    quality
    C
    maintenance
    Enables 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
    -