Which integrations are available for this server?

Integrates with Hermes Agent as an orchestrator, providing an MCP executor lane for repetitive repo work such as edits, test runs, and commits. Supports Ollama as a free local executor LLM for running mechanical tasks via the HermitAgent MCP server.

How do I use HermitAgent?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@HermitAgent run the tests and commit the changes" 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.

HermitAgent

by cafitac

Overview Schema Source Related Servers Discussions Admin

Python

Local

Hermit

Spend premium agent tokens on judgment, not on routine execution.

Hermit is a cost-optimized MCP coding executor for Claude Code, Codex, and Claude Desktop. Your paid host agent plans, reviews, and makes the important calls; Hermit delegates bounded repository work—reading and editing files, running commands, and tests—to a local or lower-cost executor model.

It is a cost-optimization layer for agentic coding, not another chat UI and not a replacement for Claude Code or Codex.

Claude Code or Codex: plan, review, decide
                 │ delegate a bounded task
                 ▼
Hermit: execute with a local or lower-cost model
                 │ return status and result
                 ▼
Claude Code or Codex: verify and continue

Install and run your first task

Requires Node.js 20+ and Python 3.11+.

Hermit deliberately does not use the Claude or Codex subscription as its executor. Before delegating work, configure either a local Ollama model or one OpenAI-compatible endpoint. hermit doctor verifies this explicitly, so a host registration alone is never presented as a working executor.

1. Install Hermit

npm install -g @cafitac/hermit-agent

2. Choose an executor

For a local, no-per-token-cost executor:

ollama pull qwen3-coder:30b

For any OpenAI-compatible Chat Completions API, keep the secret in your shell or operating-system secret store and register only its environment-variable name:

export BUDGET_PROVIDER_API_KEY="…"
hermit configure \
  --model coder-small \
  --base-url https://llm.example.com/v1 \
  --api-key-env BUDGET_PROVIDER_API_KEY

hermit configure never accepts or writes an API key. It stores the endpoint, model, and environment-variable reference in ~/.hermit/settings.json.

3. Register the host

Claude Code

hermit install claude

Codex

hermit install codex

hermit install claude registers only Claude Code, and hermit install codex registers only Codex. Bare hermit install registers both hosts. Each command creates local Hermit settings if needed, starts or recovers the local gateway, and registers this stable stdio command with the selected host:

hermit mcp-server

The gateway binds to loopback only. If another process owns its default port, Hermit leaves that process untouched and selects a free local port for its own gateway.

4. Verify readiness

hermit doctor

Only delegate work after it reports a ready executor. Restart the selected host after installation. hermit install codex writes the shared Codex MCP configuration, so the same registration is available to the Codex CLI, desktop app, and IDE extension after they restart.

5. Delegate one bounded task

In Claude Code, Codex, or Claude Desktop, ask the host agent:

Use Hermit's run_task tool to add a focused test for <change> in this repository.

Hermit returns a task ID immediately. The host polls it with check_task, and uses reply_task only if Hermit asks a question or permission decision. If the executor is not ready, run_task does not create a task; it returns the same specific diagnosis and setup command shown by hermit doctor.

Claude Desktop

Download hermit-<version>.mcpb from the matching GitHub Release and either double-click it or choose Settings → Extensions → Advanced settings → Install Extension in Claude Desktop. The extension uses the MCPB UV runtime, so it installs Hermit's matching PyPI dependency without requiring a global Python installation. It creates ~/.hermit/settings.json on first launch. It supports Claude Desktop on macOS and Windows; network access is required the first time UV resolves the Hermit package. The installation screen optionally accepts an executor model, OpenAI-compatible base URL, and API key; these values are held by Claude Desktop and applied only to Hermit's MCP process, rather than written to settings.json. Leave them blank to keep existing Hermit/Ollama settings.

Related MCP server: dsh-mcp

Use

Ask Claude Code, Codex, or Claude Desktop to delegate a scoped repository task to Hermit. The MCP server exposes four task-lifecycle tools:

run_task(task, cwd, model?, max_turns?)
check_task(task_id)
reply_task(task_id, message)
cancel_task(task_id)

run_task starts a background task. Poll with check_task; if Hermit needs input or a permission decision, reply through reply_task.

Hermit also supplies a small server instruction that recommends delegation for bounded implementation, debugging, test, and maintenance work. It is guidance, not a hidden autopilot: the host still owns the decision to delegate.

Quality and multi-agent work

run_task defaults to strategy: "single": one low-cost executor, with no quality trade-off from orchestration. For a complex refactor, migration, or security-sensitive change, the host can use strategy: "auto". Hermit then runs a read-only planner, one writing executor, and a read-only reviewer.

There are never parallel writing agents. If the reviewer does not return VERDICT: PASS, Hermit returns needs_review instead of done; the host gets the execution result and review findings together. Users can make auto their local default in ~/.hermit/settings.json:

{
  "orchestration": {
    "mode": "auto",
    "max_agents": 3,
    "allow_parallel_writes": false
  }
}

Configuration

Settings live at ~/.hermit/settings.json. hermit configure is the preferred way to configure a remote executor because it persists an environment-variable reference rather than an API key. The default routing tries a configured GLM provider first, then a locally installed Ollama model:

{
  "routing": {
    "priority_models": [
      {"model": "glm-5.1"},
      {"model": "qwen3-coder:30b"}
    ]
  }
}

Use Ollama for a local executor (no per-token API cost) or any provider that offers the OpenAI-compatible Chat Completions API with tool calling. Give a custom endpoint an explicit provider profile; model names never need to match a built-in prefix:

{
  "providers": {
    "budget-provider": {
      "base_url": "https://llm.example.com/v1",
      "api_key_env": "BUDGET_PROVIDER_API_KEY"
    }
  },
  "routing": {
    "priority_models": [
      {"model": "coder-small", "provider": "budget-provider"},
      {"model": "qwen3-coder:30b"}
    ]
  }
}

Codex is a supported MCP host; it is not part of the default executor fallback chain.

Architecture

Claude Code or Codex
        │ MCP over stdio
        ▼
  hermit mcp-server
        │ REST + task status
        ▼
 FastAPI gateway (loopback)
        ▼
 AgentLoop → repository tools → local/flat-rate LLM

The gateway owns background execution, cancellation, permission waits, model routing, and task state. The MCP process stays small and transports only the four public task operations.

Development

.venv/bin/python -m pytest tests/

Hermit is MIT licensed and currently in alpha.

Available Tools

4 tools

cancel_taskC

Cancel a running task.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full responsibility for disclosing behavioral traits. It does not mention side effects, reversibility, permission requirements, or error behavior for non-running tasks. The description is too terse to be transparent about the operation's impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, which is efficient for such a simple tool. However, it barely adds value beyond the tool name and lacks any additional contextual structure, so it does not fully earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description does not explain expected outcomes (e.g., success/failure responses, whether cancellation is immediate or asynchronous). Given the tool's mutation-like nature and the existence of siblings, the description is incomplete for safe and correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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 for parameter meaning, but it does not mention task_id at all. While 'task_id' is somewhat self-explanatory, the description fails to clarify what values are valid or what happens with an invalid ID.

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 'Cancel a running task' uses a specific verb (cancel) and resource (running task), clearly distinguishing it from siblings like run_task or check_task. It is unambiguous and directly states the tool's function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, no prerequisites (e.g., task must be running), and no exclusions. It simply states what it does, leaving the agent without context for appropriate invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_taskA

Check the current status of a background task (use after run_task with background=true). Return values: {status:"running"} — still running. {status:"waiting", question, options} — user input required. {status:"done", result} — completed. {status:"needs_review", result} — completed execution requires host review. {status:"not_found"} — task_id not found (already completed and removed). Use full=true to retrieve the complete result without truncation.

ParametersJSON Schema

Name	Required	Description	Default
`full`	No
`task_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses every possible return status, including nuanced ones like 'needs_review' and 'not_found', and explains the behavior of full=true for retrieving untruncated results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: a one-sentence usage note, a bullet-like list of statuses, and a final parameter tip. Every sentence earns its place with no repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two parameters and an output schema, the description covers all essential behavior: when to call it, all possible return values, and the meaning of the optional flag. Nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It clearly explains the effect of full=true, and task_id is given meaning through the not_found status. It could additionally state that task_id comes from run_task's response, but the usage line makes that inferable.

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 opens with 'Check the current status of a background task', a specific verb and resource that makes the tool's purpose immediately clear. It also distinguishes itself from siblings by explicitly linking to run_task with background=true and enumerating the exact statuses it returns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage context: 'use after run_task with background=true'. It does not explicitly name alternatives or conditions when not to use, but the sibling context and the status list imply when check_task applies versus reply_task or cancel_task.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reply_taskA

Send a reply to HermitAgent when run_task returned {status:"waiting"}. Return format is the same as run_task (waiting or done).

ParametersJSON Schema

Name	Required	Description	Default
`message`	Yes
`task_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the return format is the same as run_task (waiting or done), but does not disclose side effects such as whether the reply mutates task state, whether replies can be sent multiple times, or what happens if the task is not waiting. 'Send a reply' implies an action, but the consequences are not explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary action and trigger, and contains no filler. Every sentence contributes necessary context: when to call it and what to expect as a return.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no annotations and 0% parameter coverage, the tool is simple (two required scalar params) and has an output schema, so the description does not need to explain return values in depth. It mentions the return format and trigger, which is enough for basic invocation. It falls short only in behavioral and parameter detail, which are already penalized separately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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 for parameter guidance. It only implies 'message' is the reply content, and does not clarify the role of task_id (e.g., that it comes from run_task) or describe valid message formats. The parameter names are self-explanatory to a degree, but the description adds little semantic value beyond those names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Send a reply') and a specific resource/target (HermitAgent) with an explicit trigger condition ('when run_task returned {status:"waiting"}'). This distinguishes it from siblings like run_task, check_task, and cancel_task by defining its role as the follow-up action for waiting tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear context for use ('when run_task returned {status:"waiting"}') and mentions the return format consistency with run_task. It does not explicitly name alternatives or exclusions, but the trigger condition is specific enough to guide selection among sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_taskA

Run a coding task using a local LLM (default: qwen3-coder:30b). Immediately returns {status:'running', task_id}; poll with check_task(task_id). Return values: {status:"running", task_id} — task is running. {status:"waiting", task_id, question, options} — HermitAgent is asking a question. Reply with reply_task(task_id, message). {status:"done", result} — task completed. {status:"needs_review", result} — execution finished but Hermit found a likely issue.

ParametersJSON Schema

Name	Required	Default
`cwd`	Yes
`task`	Yes
`model`	No
`strategy`	No	single
`max_turns`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden. It discloses asynchronous execution, immediate return of a task_id, and four distinct status states including the interactive 'waiting' state and the 'needs_review' outcome. However, it omits error handling, timeout behavior, cancellation semantics, and whether the task modifies the filesystem, which are relevant 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and async behavior, and the return-state list is compact and scannable. There is minor redundancy between the first sentence's 'Immediately returns {status:'running', task_id}' and the subsequent enumerated return values, but overall the structure is effective.

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 state machine and output values are well documented, which covers a major part of the tool's complexity. Still, with 5 parameters, 0% schema coverage, and no annotations, the absence of parameter semantics and failure/error handling leaves significant gaps for an agent attempting to invoke the tool correctly without relying on external documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds only minimal parameter meaning: 'task' is a coding task and the model defaults to qwen3-coder:30b. The required cwd parameter and the optional strategy and max_turns parameters are not explained, so the description does not compensate for the absent schema documentation.

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 opens with a specific verb and resource: 'Run a coding task using a local LLM.' It also names the default model and immediately distinguishes itself from sibling tools by directing the agent to poll with check_task(task_id) and reply via reply_task(task_id, message). This makes it unambiguous that run_task is the initiating tool in the workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool versus its siblings: it launches a task, then the agent should poll with check_task and reply with reply_task when a question is waiting. It names alternatives explicitly, though it does not explicitly say 'use check_task instead of run_task for status checks.' The workflow guidance is strong but not exhaustive.

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.

2 tool updatesv0.4.2Aug 27, 2026

Removedregister_task

Changedrun_task2 fields changed

removedInput schema / properties / background

Removed value: -{
-  "default": false,
-  "title": "Background",
-  "type": "boolean"
-}

addedInput schema / properties / strategy

Added value: +{
+  "default": "single",
+  "title": "Strategy",
+  "type": "string"
+}

5 tool updatesv0.3.11Aug 6, 2026
- First observedcancel_task
- First observedcheck_task
- First observedregister_task
- First observedreply_task
- First observedrun_task

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-08-27 15:00 across 4 tools

Disambiguation5/5

Each tool maps to a distinct lifecycle action: start (run_task), respond to prompts (reply_task), poll status (check_task), and abort (cancel_task). There is no functional overlap between them.

Naming Consistency5/5

All four tools follow the same verb_task pattern (run, reply, check, cancel). The naming is predictable and makes the API easy to navigate.

Tool Count5/5

Four tools is well-scoped for an async agentic task runner. Each tool earns its place and the surface is neither bloated nor thin.

Completeness4/5

The core lifecycle is covered: launch, interact, poll, and cancel. However, the needs_review state lacks an explicit approve/resume action, and completed tasks are not retrievable after removal, which are minor gaps.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

PlanWrightOAuth
tools.planwright
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
Project Management Autonomous Agents
27
agentmailrooms-mcp
com.clauxel.agentmailrooms
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
Agent Orchestration Autonomous Agents
2
GitHub Repository IntelligenceOAuth
io.github.heisencodex-jpg
Repo intel for AI coding agents: overview, PRs, contributors, hot files, CI, deps. Remote MCP.
Version Control CI/CD & DevOps Code Analysis
2
Bring Your AI A
ai.bringyour
No-data MCP handoff for local Claude Code to Codex harness moves. $49 lifetime.
Developer Tools Coding Agents
72

Related MCP Servers

peer-cli-mcp
Coding Agents Agent Orchestration Command Line
domucchi
A
license
Not graded
quality
D
maintenance
MCP bridge for calling local coding-agent CLIs (Codex, Claude) from another agent, enabling bounded tasks like code review, verification, and bug hunting.
Updated 3 months ago (2026-06-26 21:54 UTC)
MIT
dsh-mcp
File Systems Command Line Code Execution
Mr-potato-123
A
license
Not graded
quality
C
maintenance
A cheap, fast execution layer for MCP agents that delegates file reads, edits, and command runs to a local DeepSeek Harness, reducing cost and latency while keeping the parent agent in control of planning and reasoning.
Updated a month ago (2026-08-19 12:45 UTC)
246 npm
117
MIT
ForgeMCP
Coding Agents Autonomous Agents
Tz22z
A
license
Not graded
quality
D
maintenance
Enables autonomous software-engineering tasks in a repository by coordinating filesystem, GitHub, database, and CI/CD tools through MCP, with a deterministic safety boundary for permissions, validation, timeouts, duplicate protection, and test verification.
Updated 5 days ago (2026-09-22 23:03 UTC)
MIT
Fagan
Autonomous Agents CI/CD & DevOps Coding Agents
motock
A
license
A
quality
A
maintenance
Autonomous coding pipeline exposed as an MCP server: plan, dispatch, review, and merge software stories through worktree-isolated agents. A frontier model (Claude) handles judgment — planning, review, risk adjudication — while a local model does the implementation, gated by TDD and a merge-time test rerun on the rebased branch.
Updated 2 days ago (2026-09-25 21:18 UTC)
25
5
Apache 2.0