What can you do with this server?

This server acts as a bridge between Hermes and the oh-my-pi (omp) coding agent CLI, exposing two tools: * prompt: Runs omp in one-shot mode with a given prompt, returning output as plain text or JSON. Supports optional parameters: * cwd – working directory for context-aware execution * mode – output format (text or json) * model / provider – select a specific AI model or provider * profile – use a custom profile for tailored behavior * noSession – disable session persistence for fully stateless calls * doctor: Verifies that both omp and bun are installed and accessible on the local system. No input required — useful for diagnosing environment issues before running prompts.

Which integrations are available for this server?

Provides tools for executing oh-my-pi coding tasks via the omp CLI, enabling code generation, refactoring, and analysis within the Hermes AI assistant.

How do I use hermes-oh-my-pi-mcp?

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-oh-my-pi-mcp prompt: write a Python script to fetch weather data" 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-oh-my-pi-mcp

A tiny Hermes-friendly bridge for oh-my-pi / omp.

This repository now includes both the working MCP bridge and the full integration explanation for GitHub readers.

What this repo provides

It exposes two MCP tools:

prompt — run omp in one-shot mode and return the output
doctor — verify omp and bun are available locally

Related MCP server: @staticpayload/gemini-mcp

Why this exists

Hermes works well with MCP, plugins, and custom tools. oh-my-pi already provides a strong CLI/runtime, so this bridge lets Hermes users call it without reimplementing the agent stack.

The recommended operating model is:

User → Hermes → MCP bridge → bun → omp → result

Hermes vs MCP vs Skill

Hermes: decides what to do
MCP bridge: actually calls omp
omp: performs the coding task
Skill: teaches Hermes when to prefer omp and how to fall back when needed

In other words, the skill is helpful but optional; the MCP bridge is the execution layer.

Detailed integration guide

See the full explanation here:

docs/hermes-omp-integration.md

That guide covers:

call structure
why MCP is the right wrapper
when a skill helps
example Hermes configuration
troubleshooting and usage policy

Release notes

RELEASE_NOTES.md

Use this file to see what changed in each published version.

Requirements

Node.js 20+
omp installed and on PATH
bun installed and on PATH because omp is Bun-based

Install oh-my-pi

npm install -g @oh-my-pi/pi-coding-agent

If the omp binary fails with bun: No such file or directory, install Bun 1.3.14+ and retry.

Local development

npm install
npm test
npm run doctor

Run as an MCP server

npx hermes-oh-my-pi-mcp

Or from source:

node ./src/index.js

Hermes config example

Add this to Hermes MCP config:

{
  "mcpServers": {
    "oh-my-pi": {
      "command": "npx",
      "args": ["-y", "hermes-oh-my-pi-mcp"]
    }
  }
}

If you want to point Hermes at a local checkout instead:

{
  "mcpServers": {
    "oh-my-pi": {
      "command": "node",
      "args": ["/absolute/path/to/hermes-oh-my-pi-mcp/src/index.js"]
    }
  }
}

Verified local setup

On this machine, Hermes is actually connected to oh-my-pi and the MCP server is enabled.

The working registration looks like this:

hermes mcp add oh-my-pi \
  --command node \
  --args /home/ubuntu/oh-my-pi-hermes-mcp/src/index.js \
  --env OMP_BIN=/home/ubuntu/.local/share/mise/installs/node/24.16.0/lib/node_modules/@oh-my-pi/pi-coding-agent/dist/cli.js \
  --env BUN_BIN=/home/ubuntu/.bun/bin/bun

That setup was verified with:

hermes mcp test oh-my-pi

If your machine uses different paths, keep the same shape but replace the absolute values with your own OMP_BIN and BUN_BIN locations.

Suggested skill policy

If you also want Hermes to prefer omp for coding requests, add a small skill that says:

Code generation / refactoring / analysis requests should consider omp first.
If the environment looks broken, run doctor first.
If omp output is insufficient, Hermes should supplement it with its own reasoning and tools.

That skill is not required for the bridge to work; it just makes the usage pattern consistent.

Notes

The bridge runs omp in a one-shot JSON-friendly mode and returns the text response.
Set OMP_BIN if your binary is not just omp.
Set BUN_BIN if Bun is installed somewhere custom.
The long-form architecture and usage notes live in docs/hermes-omp-integration.md.

Available Tools

2 tools

doctorA

Check whether the local oh-my-pi and bun runtime are available.

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?

The description indicates a read-only diagnostic action ('Check'), which implies no side effects. However, with no annotations, it does not elaborate on potential behaviors like error handling, output format, or permission requirements.

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, front-loaded sentence that conveys the essential information without waste. Every word is purposeful.

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?

Given the tool has no parameters, no output schema, and is a simple diagnostic check, the description sufficiently covers its functionality. No additional details are required.

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 input schema has zero parameters, so the description does not need to add parameter meaning. Baseline of 4 applies as no param info is necessary.

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 checks availability of 'oh-my-pi' and 'bun runtime', using a specific verb 'Check' and naming the resources checked. This distinguishes it from the sibling 'prompt' tool.

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 (e.g., 'prompt'). It only states what the tool does without context on preconditions or selection criteria.

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

promptC

Run oh-my-pi (omp) in one-shot mode and return the result as text or JSON.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes
`cwd`	No
`model`	No
`provider`	No
`profile`	No
`noSession`	No
`mode`	No

TDQS

C2.5/5.0

Behavior2/5

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

Minimal disclosure: only mentions one-shot mode and result type. No details on side effects, authentication requirements, or parameter interactions. No annotations exist to compensate.

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?

Single sentence is concise, but it sacrifices necessary detail. It is not overly verbose but lacks structure for a tool with 7 parameters.

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

Completeness1/5

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

With 7 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain return format beyond 'text or JSON', nor cover optional parameters.

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 coverage is 0%, but description only adds context for the required 'prompt' parameter. Other parameters like 'cwd', 'model', 'provider', etc. are left completely unexplained.

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?

Description names the tool (oh-my-pi) and specifies its action: running in one-shot mode and returning text or JSON. It is clear about what it does, though no differentiation from sibling tool 'doctor' is provided.

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 the sibling 'doctor' or any other alternatives. The description does not mention any prerequisites or context for use.

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.1.0Jun 20, 2026
- First observeddoctor
- First observedprompt

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.1/5.0

Scored 2026-06-20 05:15 across 2 tools

Disambiguation5/5

The two tools, 'doctor' and 'prompt', have clearly distinct purposes: one checks environment setup and the other runs the main functionality. There is no overlap or confusion between them.

Naming Consistency3/5

Both tool names are single words but do not follow a consistent verb_noun pattern. While simple and clear, they lack a predictable naming convention across the set.

Tool Count3/5

With only 2 tools, the server is at the lower boundary of acceptable size. For a simple one-shot execution server, this may be appropriate, but it feels thin compared to typical MCP servers.

Completeness3/5

The tool surface covers checking availability and executing the main command, but misses other potential operations like configuration or version info, leaving minor gaps for more complex agent workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

staging-mcpOAuth
dev.riskprofiler
An MCP server that provides a hello tool
Developer Tools
1
test-mcp B
dev.riskprofiler
An MCP server that provides a hello tool
Developer Tools
11
Agentic Mermaid A
io.github.adewale
Render, verify, describe, and safely edit Mermaid diagrams through MCP.
Data Visualization Software Architecture
9210
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748

Related MCP Servers

achmadya-dev/mcp-core
Developer Tools
achmadya-dev
A
license
Not graded
quality
A
maintenance
Provides a shared MCP SDK wrapper for building MCP servers with stdio transport, tool registration, JSON-safe responses, and environment helpers.
Updated 3 months ago (2026-06-21 07:40 UTC)
38 npm
MIT
@staticpayload/gemini-mcp
AI & Machine Learning Command Line
chaitanya-archive
A
license
Not graded
quality
F
maintenance
Bridges Google's Gemini CLI to MCP-compatible AI assistants, enabling prompt execution, model listing, and raw CLI commands.
Updated 9 months ago (2025-12-29 12:18 UTC)
11 npm
1
GPL 3.0
erbina
Developer Tools Command Line
noahhyden
A
license
Not graded
quality
A
maintenance
Bootstraps dev environments by installing, wiring, and verifying CLI tools and MCP servers from curated recipes, and provides scope-aware audit of MCP configurations.
Updated 2 months ago (2026-07-21 11:40 UTC)
MIT
Copilot MCP Server
AI & Machine Learning Command Line
ohaiibuzzle
A
license
B
quality
C
maintenance
Wraps the copilot CLI into MCP tools, allowing third-party MCP clients to invoke Copilot through prompt and command tools.
Updated 2 months ago (2026-07-30 08:34 UTC)
2
GPL 3.0

hermes-oh-my-pi-mcp

What this repo provides

Why this exists

Hermes vs MCP vs Skill

Detailed integration guide

Release notes

Requirements

Install oh-my-pi

Local development

Run as an MCP server

Hermes config example

Verified local setup

Suggested skill policy

Notes

Available Tools

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

achmadya-dev/mcp-core

@staticpayload/gemini-mcp

erbina

Copilot MCP Server