What can you do with this server?

Delegates real-world actions to Hermes Agent through MCP tools, with planning, policy-gated execution, async jobs, and two-phase approvals. * hermes_run: delegate a prompt to Hermes with optional mode, preset, context files, model/provider, max turns, timeout, dry-run, and yolo; effective execute requests open interactive confirmation. * hermes_plan: ask Hermes to inspect capabilities and return a plan without executing external actions. * hermes_capabilities, hermes_presets, hermes_status: inspect configured presets, skills, toolsets, runtime, and policy. * hermes_submit, hermes_job_status, hermes_result, hermes_cancel: start and manage bounded, cancellable asynchronous jobs; direct execute requests are converted to request-approval. * hermes_prepare, hermes_approve, hermes_reject: create a non-executing preview and short-lived one-shot approval ID; approve consumes it exactly once and executes after interactive client confirmation. * Also supports direct CLI usage and an opt-in, authenticated remote MCP transport over Tailscale.

Which integrations are available for this server?

Allows delegation of real-world actions to Hermes Agent, including research, scheduling, browser workflows, messaging, and skill execution, through a configurable bridge.

How do I use hermes-action-bridge?

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., "@hermes-action-bridge Find the best next action from this repository context." 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.

hermes-action-bridge

by TheBlueHouse75

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Hermes Action Bridge

npm

A configurable bridge that lets external agents delegate real-world actions to Hermes Agent without reimplementing Hermes skills, tools, platform integrations, browser automation, cron jobs, or messaging flows.

Use it from Claude Code, Codex, Cursor, CI jobs, shell scripts, or another MCP-capable client. MCP execution requires interactive form elicitation and fails closed in non-interactive clients; plan, draft, dry-run, and direct CLI workflows remain available to automation.

external agent -> hermes-action -> Hermes Agent -> skills/tools/integrations

Why this exists

Coding agents are good at understanding a repository. They should not duplicate your automation stack.

If an agent needs to do something outside its local coding session — research, schedule a job, open a browser workflow, send a message, prepare a social post, use a Hermes skill, or coordinate with a messaging gateway — it can delegate that request to Hermes through this bridge.

Related MCP server: Hermes Bridge

Features

Generic hermes-action run command for one-shot delegation.
Configurable presets for skills, toolsets, provider/model, source, and max turns.
Deterministic, language-agnostic safety policy: downgrades execute to request-approval by default, with per-preset trust overrides.
Explicit --yolo mode for users who intentionally want to bypass bridge-level policy.
Context file injection with a per-file cap and a configurable aggregate budget (clear error instead of a cryptic E2BIG).
Automatic large-context delivery: an oversized prompt is handed to Hermes through a secure temp file instead of overflowing the command line.
Per-run timeouts (configurable, with per-mode defaults) that always reap the Hermes child process.
Dry-run mode for debugging the exact Hermes command, prompt, and computed prompt size.
Complete Codex and Claude Code installer: managed skill plus verified global MCP registration.
MCP capability discovery, cancellable asynchronous jobs, and one-shot two-phase approvals gated on interactive form elicitation, with a privacy-preserving local audit log.
Local stdio transport plus an opt-in, authenticated Streamable HTTP transport for Tailscale-restricted hosts.
No project-specific assumptions. All behavior is configured through YAML and CLI flags.

Requirements

Node.js 20 or newer.
Hermes Agent installed and available as hermes, or configured with a custom command path.

Check Hermes:

hermes --version

Installation

Install from npm:

npm install -g hermes-action-bridge

Install the skill and MCP registration for Codex and Claude Code, then verify the complete setup:

hermes-action --version
hermes-action install all
hermes-action doctor

Global installation is all-or-nothing for the requested agents. If Codex or Claude Code is unavailable, conflicting, or cannot verify its user-scoped stdio MCP entry, the command exits non-zero without installing the requested skills. Use --project for an explicit skill-only setup.

Other distribution channels

Choose the channel that matches the agent surface. Hermes Agent must always be installed and configured on the same computer as the local bridge.

Channel	What it configures	Install
npm installer	Skill and verified user-scoped MCP for Codex CLI/app and Claude Code	`hermes-action install all`
Claude Code marketplace	Claude plugin with the Skill and a version-pinned MCP server	`claude plugin marketplace add TheBlueHouse75/hermes-action-bridge`, then `claude plugin install hermes-action@hermes-action-bridge`
Claude Desktop	Self-contained MCPB extension for the bridge runtime	From the latest GitHub Release, download `hermes-action-bridge-<version>.mcpb` and open it with Claude Desktop
Agent Skills	Portable instructions for supported coding agents	`npx skills add TheBlueHouse75/hermes-action-bridge --skill hermes-action-bridge`
Smithery Skill	Public portable instructions in the Smithery Skill catalog	Check the latest release notes for the verified Skill listing or its pending status
Smithery MCPB	The same local MCPB bundle through the Smithery catalog	Check the latest release notes for the verified MCPB listing or its pending status

The standalone Agent Skill only teaches an agent when and how to delegate; it does not register an MCP server. Use the npm installer, Claude marketplace, or MCPB channel when MCP tools are required.

Maintainers releasing a new version should follow the distribution runbook, which covers the automated release workflow and the manual directory publication checks.

Codex CLI and the Codex surface in the ChatGPT desktop app share the local Codex MCP configuration on the same host. A general ChatGPT connector is a different distribution target: it requires a remotely reachable MCP server and is not installed by this local stdio bundle.

git clone https://github.com/TheBlueHouse75/hermes-action-bridge.git
cd hermes-action-bridge
npm install
npm run build
npm link

Quick start

Create a config file in your project:

hermes-action init

Ask Hermes for a safe plan:

hermes-action run --mode plan "Find the best next action from this repository context."

Delegate with a context file:

hermes-action run \
  --preset research \
  --context ./notes.md \
  "Analyze this and return the next concrete action."

Run a dry-run to inspect what will be sent to Hermes:

hermes-action run --dry-run --json "Summarize this project."

Execution modes

plan: Hermes is instructed to return a plan only. Treat it as open-world because configured tools remain available.
draft: Hermes produces an artifact only. No external side effects.
execute: Hermes may execute allowed actions, while still following Hermes' own safety rules.
request-approval: Hermes prepares an action without executing it. MCP callers should use hermes_prepare and then hermes_approve; the latter opens an interactive client form showing the exact action and executes only after the human confirms it.

The policy guard is deterministic and language-agnostic: in execute mode the bridge switches to request-approval by default — regardless of the prompt's wording or language — unless the preset is explicitly trusted (empty require_approval_for) or --yolo is set. Separately, every effective MCP execute request requires interactive client confirmation, including trusted presets and YOLO. The bridge does not try to infer risk from keywords.

Risk categories below are informational only: the bridge surfaces the ones it recognizes in the prompt envelope to help you and Hermes decide, but they never drive the mode. (Keyword matching is English-biased and trivially evaded, so it must not be a security control.)

publish_external
send_message
send_email
delete
payment
git_push
credential_change

YOLO mode

YOLO mode is off by default.

hermes-action run --yolo --mode execute "Do the task now."

YOLO bypasses the mode-downgrade policy. It does not bypass the MCP interactive confirmation barrier, Hermes Agent's own safety rules, provider/tool approval prompts, or platform constraints. Direct CLI use remains an explicit trusted-local escape hatch.

Use it only when the caller and environment are trusted.

Trusted presets (direct execution)

By default every execute is downgraded to request-approval — the right default when an agent might act unattended. When you are the one asking for an action and want it to run without that extra gate, define a trusted preset: one whose require_approval_for is an empty list. Put it in your user config so it is yours alone and available in every project:

# ~/.config/hermes-action/config.yaml   (user scope, merged before any project config)
presets:
  act:
    description: Direct execution of an action I explicitly asked for (trusted).
    require_approval_for: []

Run actions through it — execute stays execute, with no downgrade and no --yolo needed:

hermes-action run --preset act --mode execute "post the release note to #general"

Keep it safe:

A trusted preset relaxes the mode-downgrade policy. Effective MCP execution still requires interactive confirmation; direct CLI execution relies on the operator and environment being trusted.
Keep it in your user config; it never ships in the public package, and the distributed SKILL.md stays cautious for everyone else.
Reserve trusted presets for actions a human explicitly asks for. Leave the conservative default for anything an agent could trigger on its own.

Configuration

hermes-action loads config in this order:

CLI flags > project .hermes-action.yaml > user config > built-in defaults

User config path:

~/.config/hermes-action/config.yaml

Project config path:

.hermes-action.yaml

Example:

runtime:
  adapter: hermes-cli
  command: hermes
  # Aggregate budget across all --context files, in bytes (default ~768 KiB).
  # Raising this above ~896 KiB switches large prompts to temp-file delivery.
  max_context_bytes: 786432
  # Optional overall per-run timeout in seconds. When unset, per-mode defaults
  # apply: 180s for plan/draft, 600s for execute/request-approval.
  # timeout_seconds: 600

defaults:
  mode: plan
  source: external-agent
  max_turns: 30
  preset: default

presets:
  default:
    description: No extra skills or toolsets. Uses the active Hermes profile.
    skills: []
    toolsets: []

  research:
    description: General research and synthesis.
    skills: []
    toolsets: [web, terminal, file]
    # Per-preset override: relax approvals for a trusted preset.
    # An empty list never downgrades execute to request-approval.
    # require_approval_for: []

  coding:
    description: Repository inspection and runtime validation.
    skills: [developer-assurance-and-validation, runtime-debugging]
    toolsets: [terminal, file]

policy:
  yolo: false
  # Global default; a preset's own require_approval_for takes precedence when set.
  require_approval_for:
    - publish_external
    - send_message
    - send_email
    - delete
    - payment
    - git_push
    - credential_change

Limits, timeouts, and large context

The bridge builds one prompt envelope (policy header + your request + every <context> block) and hands it to Hermes. Two guardrails keep that reliable:

Aggregate context budget (runtime.max_context_bytes, default ~768 KiB, plus a fixed 250 KiB per-file cap). Exceeding it fails fast with an actionable message — Context total N bytes exceeds the limit ... Split your handoff or raise runtime.max_context_bytes. — instead of a cryptic E2BIG spawn crash. The default leaves headroom under the operating system's argument-size limit.
Large-context delivery. If you raise the budget and the envelope grows past ~896 KiB, the adapter writes it to a 0600 temp file and tells Hermes to read that file (injecting a file toolset for the call). This sidesteps the OS argument limit. Two caveats: it adds one tool-calling turn, and the real ceiling becomes the model's context window — a multi-megabyte file may only be partially read. The temp file is removed after the run; only an uncatchable kill of the bridge process itself could leave it behind (mitigated by the 0600 mode and the OS temp reaper).

Every run is bounded by a timeout (default 180s for plan/draft, 600s for execute/request-approval). Override per run with --timeout <seconds> or globally with runtime.timeout_seconds. On expiry the Hermes child is sent SIGTERM, then SIGKILL after a short grace, and the result is marked as timed out.

hermes-action doctor prints the effective limits, and hermes-action run --dry-run --json reports the computed prompt size (promptBytes, promptChars) and whether delivery would use argv or a temp-file.

CLI reference

hermes-action init [--file .hermes-action.yaml] [--force]
hermes-action run [options] "request"
hermes-action presets [--json]
hermes-action status [--json]
hermes-action mcp
hermes-action serve [--listen 127.0.0.1] [--port 8765]
hermes-action install <claude-code|codex|all|mcp> [options]
hermes-action uninstall <claude-code|codex|all|mcp> [options]
hermes-action doctor [--json] [--probe]

Common run options:

--mode <plan|draft|execute|request-approval>
--preset <name>
--context <path...>
--config <path>
--provider <name>
--model <name>
--max-turns <number>
--timeout <seconds>
--source <name>
--yolo
--dry-run
--json

Native agent skills

Instead of pasting instructions and MCP snippets by hand, run the complete installer. It installs the open-standard skill and registers the local stdio MCP server through each agent's own CLI:

hermes-action install all            # skills + global MCP for both agents
hermes-action doctor                 # verifies skills, registrations, and MCP handshake
hermes-action install claude-code --print     # preview, write nothing
hermes-action install codex --project-hint     # also add a marker block to AGENTS.md
hermes-action uninstall all

Install behavior is safe by default: it uses a stable absolute bridge path, does not depend on an interactive PATH, never modifies CLAUDE.md / AGENTS.md unless you pass --project-hint, and refuses to overwrite either a foreign skill or a customized MCP entry. Re-running it is idempotent. Use --project for a project-local skill only and --dry-run to preview operations.

The generated skill is shown in examples/claude-code/SKILL.md. Project-hint usage is documented in examples/claude-code/CLAUDE.md and examples/codex/AGENTS.md.

Codex plugin (one-line install)

Codex users can install the delegation skill and the MCP server together as a plugin:

codex plugin marketplace add TheBlueHouse75/hermes-action-bridge
codex plugin add hermes-action@hermes-action-bridge

This registers the hermes-action MCP server and the Hermes delegation skill in Codex. Hermes Agent must be installed locally — the plugin runs the version-pinned npm package with npx.

Faster MCP startup: npx re-resolves the package on every server start. The native installer registers the absolute global launcher instead.

MCP configuration

hermes-action install mcp

For other JSON MCP clients, or a Claude Code project-scoped configuration, write or merge .mcp.json directly while preserving other servers:

hermes-action install mcp --write

Or configure it by hand:

{
  "mcpServers": {
    "hermes-action": {
      "command": "hermes-action",
      "args": ["mcp"]
    }
  }
}

Direct delegation

You can always call the bridge directly, without a skill:

hermes-action run --mode plan "Ask Hermes what should happen next."

hermes-action run \
  --preset coding \
  --context ./codex-notes.md \
  "Use Hermes to validate this plan and identify missing runtime checks."

MCP tools

Run:

hermes-action mcp

Exposed tools:

hermes_run: delegate a request to Hermes. Optional overrides: mode, preset, contextFiles, yolo, dryRun, and — to trade cost for speed on simple tasks — model, provider, maxTurns, timeoutSeconds. Any effective execute request opens an interactive confirmation form first.
hermes_plan: shortcut for hermes_run with mode=plan.
hermes_capabilities: report configured presets, skills, toolsets, runtime, and policy without inventing live integrations.
hermes_presets: list configured presets.
hermes_status: check the configured Hermes runtime command.
hermes_submit, hermes_job_status, hermes_result, hermes_cancel: manage bounded, process-local asynchronous jobs.
hermes_prepare, hermes_approve, hermes_reject: create and consume a short-lived one-shot approval. hermes_approve asks the MCP client for interactive confirmation before execution.

The MCP surface delegates to Hermes instead of mirroring every Hermes tool. Jobs and approvals are intentionally process-local: restarting the MCP server clears them. Audit events are written as owner-only JSONL metadata under $XDG_STATE_HOME/hermes-action/audit.jsonl (or ~/.local/state/hermes-action/audit.jsonl) without prompt, context, token, or full result content.

Remote MCP over Tailscale

The HTTP transport is opt-in and loopback-only by default:

hermes-action serve --listen 127.0.0.1 --port 8765

Prefer placing Tailscale Serve in front of that loopback endpoint. Forwarded *.ts.net requests still require a bearer token, so start the loopback server with --token-env:

export HERMES_ACTION_HTTP_TOKEN="<at-least-32-random-bytes>"
hermes-action serve \
  --listen 127.0.0.1 \
  --port 8765 \
  --token-env HERMES_ACTION_HTTP_TOKEN

For direct tailnet listening, the bridge accepts only an explicit Tailscale IPv4 address and requires the same bearer-token setup:

hermes-action serve \
  --listen 100.64.0.10 \
  --port 8765 \
  --allow-tailnet \
  --token-env HERMES_ACTION_HTTP_TOKEN

The token is never accepted as a CLI value or stored in bridge configuration. Public/wildcard and non-Tailscale addresses are refused.

Development

npm install
npm run build
npm run test
npm run check

Functional tests use a fake Hermes binary to verify command construction, prompt wrapping, risk policy, and YOLO behavior without spending LLM credits.

Documentation

Architecture: module map, config precedence, modes, policy, and MCP design.
Functional testing: automated tests and live smoke-test procedures.
Contributing: local setup, development rules, and release checklist.
Changelog: release history.
Security policy: how to report a vulnerability.

Security model

Direct CLI execution assumes a trusted, supervised operator. MCP execution has an additional protocol-enforced gate: every effective execute request asks the client for MCP form elicitation, shows the exact action and metadata, and runs only when the response is both accept and confirm=true.

For side effects, prefer the testable two-phase flow: hermes_prepare returns a local no-tool summary and opaque approval ID, and hermes_approve opens the interactive confirmation before consuming the unchanged request exactly once. Unsupported clients, CI jobs, shell scripts, cancellations, timeouts, and declines fail closed without execution. Use plan, draft, dry-run, or the direct CLI when an interactive MCP client is unavailable; do not describe the direct CLI as providing a distinct human-approval barrier.

This gate assumes a conforming, trusted MCP client. The MCP specification requires clients that advertise elicitation to provide UI, identify the requesting server, offer decline/cancel, and let the user review the response. A malicious client, or an elicitation hook configured to auto-answer, can forge accept and confirm=true; do not expose the bridge to untrusted MCP clients. The bridge does not claim a human boundary in that deployment model.

The bridge's own guard is a secondary net: execute is downgraded to request-approval by default unless a preset is trusted (empty require_approval_for) or --yolo is set. The bridge never injects --yolo or a bypass flag on its own.

Do not auto-answer MCP elicitation or install an elicitation hook that accepts execution forms. Doing so deliberately removes the human boundary.
Do not allowlist hermes-action run (execute/yolo). A command-pattern allowlist cannot distinguish a safe plan from an execution with side effects.
Do not put secrets in .hermes-action.yaml. Keep provider credentials in Hermes Agent, your OS keychain, or the platform's secure store.
Treat --yolo as a trusted-local escape hatch, not a default.

Also by the author

Built by Cyril Guilleminot, who also makes offline-first voice tools:

Weesper Neon Flow — speak text into any app at 3× typing speed, fully offline (macOS & Windows).
Weesper Transcribe — offline transcription on the macOS App Store.

License

MIT

Available Tools

12 tools

hermes_approveApprove and submit a prepared Hermes actionA

Destructive

Consume a prepared approval ID exactly once and submit the unchanged request for execution. This can cause external side effects.

ParametersJSON Schema

Name	Required	Description	Default
`approvalId`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already provide destructiveHint=true. Description adds value by noting 'consume exactly once' and 'can cause external side effects', reinforcing and extending annotation context.

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?

Two sentences, no wasted words. Core action is first sentence; side effect warning is second. Perfectly sized for a simple tool.

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?

Given one parameter, no output schema, and existing annotations, description covers essential behavior and side effects. Lacks details on post-execution status but sibling tools fill that gap.

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 coverage is 0% so description must compensate. It adds context 'prepared approval ID' but does not fully explain the parameter's origin or validation beyond what the schema provides.

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?

Description uses specific verbs 'consume' and 'submit' with resource 'prepared approval ID', clearly distinguishing it from sibling tools like hermes_prepare and hermes_reject. It states the action is exactly once and unchanged.

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?

Clearly implies use after hermes_prepare, but does not explicitly exclude other contexts or mention alternatives. Contrasts implicitly with hermes_reject and hermes_cancel.

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

hermes_cancelCancel a Hermes jobC

Idempotently cancel a queued or running asynchronous Hermes job.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are provided, so the description bears full burden. It mentions idempotency and the job states (queued/running) but omits side effects, permission requirements, or what happens if job is already completed.

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

Conciseness2/5

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

The description is extremely concise (8 words) but this under-specification harms clarity. One sentence is acceptable, but critical details are missing.

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?

Given no output schema and no annotations, the description should provide more context about cancellation behavior, idempotency implications, and edge cases. It is insufficient for proper tool selection and invocation.

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

Parameters1/5

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

The input schema has one parameter (jobId) with 0% schema description coverage. The description does not mention the parameter at all, leaving the agent to infer its meaning solely from the schema.

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 the action 'cancel' and the resource 'a queued or running asynchronous Hermes job', with the qualifier 'idempotently'. It effectively distinguishes from sibling tools like hermes_status or hermes_result.

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?

No explicit guidance on when to use this tool versus alternatives (e.g., hermes_reject). The description implies cancellation of queued/running jobs but does not specify prerequisites or when not to use.

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

hermes_capabilitiesDiscover configured Hermes capabilitiesA

Read-only

Inspect bridge status, configured presets, skills, toolsets, providers, models, and policy before deciding whether Hermes owns the requested capability.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

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

With readOnlyHint already declared, the description still adds value by enumerating exactly what can be inspected: presets, skills, toolsets, providers, models, and policy. The word 'Inspect' reinforces the read-only nature, and no contradiction exists. It does not describe output shape or return behavior, but that is a lesser gap given the annotation.

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 a single well-structured sentence that front-loads the core action and resource list, then appends the decision-oriented use case. Every word earns its place, with no redundancy or filler.

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?

For a parameterless, read-only capability discovery tool, the description covers what the tool inspects and when to use it. There is no output schema, so the exact return structure is unspecified, but the described contents are sufficient for an agent to understand expected results in most cases.

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?

The tool has zero parameters, and schema description coverage is 100%, so there is no parameter burden for the description to carry. Baseline for a zero-parameter tool is 4, and the prose adds no unnecessary parameter details.

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

Purpose4/5

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

The description clearly states a specific action ('Inspect') and resource ('bridge status, configured presets, skills, toolsets, providers, models, and policy'), matching the title 'Discover configured Hermes capabilities.' It is not a tautology and conveys the tool's scope, though it does not explicitly distinguish itself from close sibling hermes_status.

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 includes an explicit use context: call this tool 'before deciding whether Hermes owns the requested capability.' This tells an agent when to reach for it, but it does not mention any exclusions or alternatives among the hermes_* siblings.

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

hermes_job_statusCheck a Hermes jobA

Read-only

Read lifecycle metadata for an asynchronous Hermes job without returning its output.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	Yes

TDQS

A3.6/5.0

Behavior4/5

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

Description aligns with readOnlyHint annotation and adds that it does not return output. This goes beyond the annotation by clarifying the scope (lifecycle metadata only). No contradictions. Could mention idempotency or rate limits, but sufficient.

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?

Single sentence, front-loaded with key information. No redundant words. Highly concise and structurally clear.

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?

Given simple parameter and no output schema, description is adequate but could be more complete. E.g., what lifecycle metadata includes (status, timestamps, etc.) is not described. Sibling tools suggest broader context could be helpful.

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

Parameters1/5

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

The jobId parameter is not described in the description. Schema has 0% description coverage, so the description must compensate, but it fails to explain what jobId is or its role. The format and pattern in schema are not explained.

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?

Description clearly states the tool reads lifecycle metadata for a Hermes job without returning output. Verb 'Read' and specific resource 'lifecycle metadata for an asynchronous Hermes job' are precise. It also distinguishes itself from siblings like hermes_result (likely returns output) by explicitly excluding output.

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

Usage Guidelines3/5

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

Description says 'without returning its output', implying use when metadata is needed. However, it does not explicitly state when not to use or provide alternatives (e.g., use hermes_result for output). Context is clear but lacks exclusions or comparisons to siblings.

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

hermes_planAsk Hermes for a planA

Ask Hermes to inspect its configured capabilities in plan mode. Hermes may access open-world tools, so review the response before taking or approving an external action.

ParametersJSON Schema

Name	Required	Description	Default
`preset`	No
`prompt`	Yes
`contextFiles`	No

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare openWorldHint=true, and the description reinforces this by warning that Hermes may access open-world tools. It adds useful behavioral context by explaining that the tool inspects configured capabilities in plan mode and by instructing review before approving external actions. No contradiction with annotations.

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?

Two focused sentences with no filler; the main purpose is front-loaded and the safety warning is directly relevant. Every sentence earns 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?

For a three-parameter tool with no output schema and no parameter descriptions, the description is not complete enough: an agent can call it with a prompt but has no basis for deciding whether to use preset or contextFiles. It does address the open-world risk, but the input semantics and expected response format are left unspecified.

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 the lack of parameter documentation. It does not mention prompt, preset, or contextFiles, leaving preset and contextFiles entirely unexplained. Only 'prompt' is loosely inferable from 'Ask Hermes for a plan.'

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

Purpose4/5

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

The description opens with 'Ask Hermes to inspect its configured capabilities in plan mode,' which names a concrete verb, resource, and mode. It clearly signals a planning step rather than execution, but it does not explicitly name sibling tools such as hermes_capabilities or hermes_run, so some disambiguation is left to context.

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 clear usage context: the tool operates in plan mode and the response should be reviewed before any external action. It does not explicitly state when not to use it or name alternative tools, so there are no exclusions.

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

hermes_preparePrepare an external action for approvalA

Create a local, non-executing preview and short-lived one-shot approval ID without invoking Hermes or its tools. The caller must show preview.action to the human before approval.

ParametersJSON Schema

Name	Required	Description	Default
`model`	No
`preset`	No
`prompt`	Yes
`maxTurns`	No
`provider`	No
`contextFiles`	No
`timeoutSeconds`	No

TDQS

A3.9/5.0

Behavior5/5

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

Description clearly states the tool is non-executing, creates a short-lived approval ID, and must be followed by human approval. Annotations only have openWorldHint, so the description carries full burden and does so well.

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?

Two sentences, no wasted words. Core action is front-loaded: 'Create a local, non-executing preview and short-lived one-shot approval ID'.

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 good purpose and transparency, the description omits parameter semantics and return value information. With 7 params and no output schema, the agent lacks sufficient context to construct valid invocations.

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

Parameters1/5

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

Schema has 7 parameters with 0% description coverage. The tool description does not explain any parameter (model, prompt, etc.), leaving the agent without guidance on how to fill them meaningfully.

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 the tool creates a local preview and approval ID without invoking Hermes, and requires showing preview to human. It distinguishes from siblings (approve, reject, status, result) by focusing on preparation.

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 specifies when to use (before approval, without invoking Hermes) and implies the human-in-the-loop step. However, it lacks explicit when-not-to-use or alternatives beyond the sibling context.

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

hermes_presetsList Hermes delegation presetsA

Read-only

List configured bridge presets and their declarative Hermes skills and toolsets.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

The annotation readOnlyHint=true already indicates a safe read operation. The description adds that it returns skills and toolsets, which is useful but does not disclose other behavioral aspects like pagination or sorting. No contradictions.

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?

Single sentence, no fluff. All words carry meaning and the description is front-loaded with the main action.

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?

The tool has no output schema, but the description explains it returns skills and toolsets, providing sufficient context for a listing tool. It could mention whether it returns all presets or filtered, but the lack of parameters implies a complete list.

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?

There are zero parameters, so the baseline is 4. The description adds no parameter information, but none is needed since schema coverage is trivially 100%.

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 the tool lists configured bridge presets with their declarative skills and toolsets. The name and title align, and it is distinct from sibling tools like hermes_status and hermes_job_status.

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?

No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description only states what it does without context for selection.

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

hermes_rejectReject a prepared Hermes actionC

Consume a prepared approval ID without executing the external action.

ParametersJSON Schema

Name	Required	Description	Default
`approvalId`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description must compensate. It mentions that the external action is not executed, which hints at non-destructive behavior, but fails to disclose authorization needs, side effects, or whether the approval ID is consumed irreversibly.

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?

A single sentence that is front-loaded and concise. Every word is necessary.

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?

Given the simplicity and the sibling tools, the description is too brief. It fails to differentiate 'reject' from 'cancel' and does not explain the lifecycle of a prepared action. The absence of output schema and annotations amplifies the incompleteness.

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?

The only parameter, 'approvalId', is not described in the description. The schema provides a UUID format but no semantic meaning. With 0% schema description coverage, the description should add context about what the approval ID represents or where to obtain it, but it does not.

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

Purpose4/5

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

The description clearly states the tool's action: consuming a prepared approval ID without executing the external action. The title 'Reject' reinforces the purpose. It distinguishes from approve but not from cancel among siblings.

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?

No guidance on when to use this tool versus alternatives like 'hermes_approve' or 'hermes_cancel'. The description implies rejection, but does not specify 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.

hermes_resultRead a Hermes job resultA

Read-only

Read the bounded stdout/stderr result of a completed asynchronous Hermes job.

ParametersJSON Schema

Name	Required	Description	Default
`jobId`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already set readOnlyHint=true. Description adds that the result is bounded and only for completed jobs, providing context beyond annotations without contradiction.

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?

Single sentence of 15 words, front-loaded with key action and scope. No wasted words.

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?

For a simple read tool with 1 param and read-only annotation, description covers core purpose and constraints (completed, bounded). Lacks detail on output format but acceptable for this complexity level.

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 coverage is 0% but the single parameter jobId is self-explanatory. Description adds no extra meaning; baseline 3 is appropriate as schema already defines the field.

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 verb 'Read' and resource 'bounded stdout/stderr result of a completed asynchronous Hermes job' are clearly specified, distinguishing it from siblings like hermes_status or hermes_cancel.

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

Usage Guidelines3/5

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

Implicitly states usage for completed jobs via 'of a completed asynchronous Hermes job,' but lacks explicit when-to-use or when-not-to-use guidance, nor mentions alternatives among sibling tools.

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

hermes_runDelegate a request to HermesC

Use Hermes-owned skills, connected services, browser workflows, messaging, schedules, or external automation through bridge policy. Do not use for ordinary local code edits.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No
`yolo`	No
`model`	No
`dryRun`	No
`preset`	No
`prompt`	Yes
`maxTurns`	No
`provider`	No
`contextFiles`	No
`timeoutSeconds`	No

TDQS

C2.7/5.0

Behavior2/5

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

With only openWorldHint=true in annotations, the description bears the burden of explaining runtime behavior. It mentions 'bridge policy' and external automation, hinting at side effects, but it does not disclose that this may invoke remote services, require approval, run long, or return job handles. No rate limits, execution model, or side-effect details are provided.

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

Conciseness3/5

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

Two sentences with no waste, and the exclusion is useful. However, the first sentence is a long list of capabilities without a clear verb or object structure; it reads more like a label than a structured explanation. It is concise but sacrifices clarity for brevity.

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?

For a tool with 10 parameters, no output schema, and only open-world hint, the description is far from complete. It does not mention the required prompt, the meaning of modes, presets, or expected return behavior. The agent cannot reliably invoke this tool correctly based on the current definition.

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

Parameters1/5

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

Schema description coverage is 0% and the description provides no insight into any of the 10 parameters, including the required prompt. It does not explain mode, yolo, model, dryRun, preset, maxTurns, provider, contextFiles, or timeoutSeconds. The agent gets no help beyond the raw schema.

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

Purpose4/5

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

The description states a clear action: use Hermes for its owned skills, connected services, browser workflows, messaging, schedules, or external automation. It distinguishes this from ordinary local code edits, which gives a definite scope. However, it does not explicitly differentiate from the many sibling Hermes tools such as hermes_plan, hermes_submit, or hermes_prepare.

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

Usage Guidelines3/5

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

The description gives one clear exclusion (do not use for ordinary local code edits) and a positive list of use cases, so an agent has some when-to-use guidance. But it offers no explicit alternatives or conditions for choosing between this and the sibling Hermes tools, so the guidance is incomplete.

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

hermes_statusCheck Hermes runtime statusA

Read-only

Check whether the configured Hermes CLI runtime is available without running a provider request.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, indicating safety. The description adds that it checks availability without making a request, which is consistent but provides only minor additional context beyond the annotation.

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 a single, efficient sentence that immediately conveys the tool's purpose with no wasted words.

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 explains the tool's action but does not indicate the output format (e.g., boolean or status message). With no output schema, the agent lacks full context on what the response will look like.

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?

No parameters exist, and schema coverage is 100%. The description correctly implies no inputs are needed, so no additional parameter meaning is required. Baseline 4 is appropriate.

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 ('Check') and resource ('Hermes CLI runtime'), distinguishing it from sibling tools that handle different operations like presets, job status, or result processing.

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

Usage Guidelines3/5

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

The description implies usage for a lightweight check without running a provider request but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives. No direct mention of sibling tools.

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

hermes_submitSubmit a cancellable Hermes jobA

Start a long Hermes plan, draft, or approval-preview job and return immediately. Direct execute requests are converted to request-approval; use hermes_prepare and hermes_approve for execution.

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No
`model`	No
`preset`	No
`prompt`	Yes
`maxTurns`	No
`provider`	No
`contextFiles`	No
`timeoutSeconds`	No

TDQS

A4/5.0

Behavior4/5

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

With only openWorldHint as an annotation, the description must carry behavior disclosure. It reveals the asynchronous behavior ('return immediately') and the mode-conversion behavior for execute requests. It does not cover cancellation or result retrieval, but the most important behavioral traits are disclosed.

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

Conciseness4/5

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

Two sentences with no filler, and the core behavior is front-loaded. Minor deduction for jargon like 'approval-preview job' which is not defined, but overall it is efficient.

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?

The tool has 8 parameters, no output schema, and no parameter-level descriptions, so the description needs to be more complete to support correct invocation. It does not explain how results are obtained, what contextFiles does, timeouts, or how the created job can be cancelled, despite the title advertising cancellability.

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 the 8 parameters. It only clarifies mode-related behavior and leaves model, preset, maxTurns, provider, contextFiles, and timeoutSeconds undefined. This is a significant gap for a tool with multiple functional options.

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 states a specific action ('Start') on a clear resource ('long Hermes plan, draft, or approval-preview job') and explicitly notes it returns immediately. It also differentiates itself from sibling tools by explaining that execute mode is converted to request-approval rather than executed directly.

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 gives explicit routing guidance: execution should not go through this tool directly; instead, use hermes_prepare and hermes_approve for execution. This clearly tells an agent when to use this tool versus the alternatives.

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.

4 tool updatesv0.6.3Aug 31, 2026
- Addedhermes_capabilities
- Addedhermes_plan
- Addedhermes_run
- Addedhermes_submit
3 tool updatesv0.6.2Jul 25, 2026
- Addedhermes_cancel
- Addedhermes_presets
- Addedhermes_status
3 tool updatesv0.6.2Jul 25, 2026
- Addedhermes_job_status
- Addedhermes_prepare
- Addedhermes_result
5 tool updatesv0.6.1Jul 25, 2026
- Addedhermes_approve
- Removedhermes_capabilities
- Removedhermes_prepare
- Addedhermes_reject
- Removedhermes_run
3 tool updatesJul 25, 2026
- First observedhermes_capabilities
- First observedhermes_prepare
- First observedhermes_run

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

B3.4/5.0

Scored 2026-08-31 11:50 across 12 tools

Disambiguation3/5

The execution and approval tools are mostly distinct, but the inspection tools overlap: hermes_plan and hermes_capabilities both imply inspecting capabilities, hermes_status is a subset of hermes_capabilities, and hermes_presets is explicitly listed inside capabilities. Descriptions help clarify, but an agent could still hesitate when choosing between run, submit, and prepare/approve for executing work.

Naming Consistency4/5

All tools share a consistent hermes_ prefix, and most actions use clear imperative verbs like run, plan, submit, cancel, prepare, approve, and reject. However, some tools are noun-style names (hermes_capabilities, hermes_presets, hermes_status, hermes_result) rather than verb_noun names, and hermes_job_status breaks the pattern by combining a noun with a status word. Overall readable and predictable, but not perfectly uniform.

Tool Count5/5

Twelve tools is a reasonable scope for a bridge that covers runtime inspection, capability discovery, synchronous execution, asynchronous job management, and a human-approval flow. Each tool serves a distinct part of the interaction lifecycle, and none feel redundant or unnecessary.

Completeness4/5

The tool surface covers the core lifecycle well: inspect capabilities, run or plan work, submit async jobs, check status, retrieve results, cancel jobs, and handle approval/rejection. Minor gaps exist such as no way to list all running or pending jobs/approvals, but agents can still accomplish the main workflows without hitting dead ends.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Agent Router C
io.github.Tim-Projekt
Discover and call AI agents via MCP. Supports A2A agents and platform agents with async tasks.
Agent Orchestration Autonomous Agents
252
IFTTT MCP serverOAuth
com.ifttt
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
App Automation
1
Superforms B
co.superforms
Human-input bridge for AI agents with voice-first answer links, MCP tools, and HTTP APIs.
Agent Orchestration Speech Processing App Automation
112
AgentMesh A
io.github.lugdwei
MCP delegation fallback for AI agents to discover capabilities, knowledge, tools, and collaborators.
Agent Orchestration Autonomous Agents Communication
51

Related MCP Servers

woow-hermes-mcp-serverofficial
Agent Orchestration Autonomous Agents
WOOWTECH
A
license
Not graded
quality
C
maintenance
FastMCP wrapper that lets Claude app fully control a Hermes Agent instance via remote connector.
Updated 15 hours ago (2026-09-12 18:29 UTC)
MIT
Hermes Bridge
Agent Orchestration Shell Access File Systems
182moon
A
license
Not graded
quality
C
maintenance
Enables MCP agents to delegate tasks to a local Hermes Agent for terminal, file, browser, and coding operations, and schedule recurring jobs.
Updated 2 months ago (2026-07-14 14:01 UTC)
MIT
agentic_actions_mcp
File Systems Shell Access
codewithyasho
F
license
B
quality
C
maintenance
Enables file IO operations and terminal commands via agentic actions using the MCP protocol.
Updated 2 months ago (2026-07-27 09:43 UTC)
9
-
agentic-orchestrator MCP
Agent Orchestration Autonomous Agents
Saul4432
A
license
A
quality
C
maintenance
Enables any MCP client to drive a multi-agent orchestration engine with planning, specialist tools, critic revision, and human-in-the-loop approval for sensitive actions.
Updated a month ago (2026-08-01 22:20 UTC)
3
MIT

Hermes Action Bridge

Why this exists

Features

Requirements

Installation

Other distribution channels

Quick start

Execution modes

YOLO mode

Trusted presets (direct execution)

Configuration

Limits, timeouts, and large context

CLI reference

Native agent skills

Codex plugin (one-line install)

MCP configuration

Direct delegation

MCP tools

Remote MCP over Tailscale

Development

Documentation

Security model

Also by the author

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

woow-hermes-mcp-serverofficial