Skip to main content
Glama
sushiHex
by sushiHex

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
HARDLINE_CODEX_CMDNoPath to the codex executable; overrides auto-discovery
HARDLINE_CLAUDE_CMDNoPath to the claude executable
HARDLINE_HERMES_CMDNoPath to the hermes executable, e.g., C:/Users/you/AppData/Local/hermes/hermes-agent/venv/Scripts/hermes.exe

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
sendA

Send a message from one agent to another.

Always persists to the durable mailbox. If deliver is true, also pushes a one-shot notice to the recipient via its native mechanism (hermes chat / codex exec / claude -p) so it sees the message without polling.

from_agent/to_agent are one of: claude, hermes, codex; an unknown agent is rejected. Returns {"ok": true, "message_id", "created_at"} (plus delivery when deliver set), or {"ok": false, "error"}.

inboxA

Read messages addressed to agent, oldest first.

unread_only (default true) hides messages already ack'd. Returns {"messages": [...], "count": N}.

ackA

Mark a message read so it stops appearing in the unread inbox.

Returns {"ok": true} only if a still-unread message with that id existed (idempotent — a second ack returns false).

historyA

Recent messages, newest first — the visibility / audit feed.

agent, if given, filters to messages where it is either sender or recipient. Returns {"messages": [...], "count": N}.

ask_hermesA

Ask the Hermes agent (MrAnderson) a question and wait for its reply.

Spawns a one-shot hermes chat -q — this is slower and heavier than the async mailbox; use it when you need an answer NOW. Returns {"ok", "reply"} or {"ok": false, "error"}.

ask_codexA

Ask Codex a question and wait for its reply.

Spawns an ephemeral codex exec. Omitting model passes no --model flag, so Codex's own configured default applies. Optional model/effort selection enables JSONL usage/thread telemetry. Advisory mode uses ChatGPT auth preflight, a temporary auth-only CODEX_HOME, a neutral read-only directory, ignored user/project configuration, and stripped API-provider overrides. workdir targets a repository in default mode and is rejected in advisory mode. write=True opts into a workspace-write sandbox with approvals disabled (unattended) — it requires workdir, is rejected in advisory mode, and is refused unless this hardline-mcp process has HARDLINE_ALLOW_WRITE set to a recognized truthy value (1/true/yes, case-insensitive); omitted, Codex stays read-only. Codex JSONL does not currently report served model/effective effort, so those telemetry fields remain null rather than being guessed.

ask_codex_asyncA

Dispatch a Codex task in the background; returns immediately.

Runs the same ask_codex in a background thread, then delivers the result through the existing mailbox as a message from "codex" to from_agent — poll it with inbox(agent=from_agent). The delivered message body is the JSON-encoded ask_codex result, plus label if supplied (use it to match results when firing several concurrent dispatches). from_agent must be a known agent. Fire-and-forget: not persisted, so a hardline-mcp restart before completion loses the task.

ask_claudeA

Ask Claude Code a question and wait for its reply.

With no options, preserves the original one-shot claude -p behavior and response shape — omitting model passes no --model flag, so Claude Code's own configured default applies — plus (parity with Codex) Edit/Write/NotebookEdit are denied by default — inspection tools like Read/Grep/Bash still work. model pins a Claude alias/full model ID. effort is one of default|low|medium|high|xhigh|max; default omits the flag. workdir targets a repository in default mode and is rejected in advisory mode. write=True opts into full tool access plus --permission-mode bypassPermissions (unattended — stdin is /dev/null, so an interactive prompt would hang to timeout instead of being answered); it requires workdir, is rejected in advisory mode, and is refused unless this hardline-mcp process has HARDLINE_ALLOW_WRITE set to a recognized truthy value (1/true/yes, case-insensitive). Mode advisory disables tools/project customizations, runs in a neutral cwd, strips API-provider overrides, and fails closed unless response telemetry verifies first-party account auth without overage. Optioned calls return actual-model, usage, rate-limit, auth-verification, and safeguard fallback metadata in addition to ok/reply.

ask_claude_asyncA

Dispatch a Claude task in the background; returns immediately.

Runs the same ask_claude in a background thread, then delivers the result through the existing mailbox as a message from "claude" to from_agent — poll it with inbox(agent=from_agent). The delivered message body is the JSON-encoded ask_claude result, plus label if supplied (use it to match results when firing several concurrent dispatches). from_agent must be a known agent. Fire-and-forget: not persisted, so a hardline-mcp restart before completion loses the task.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.3/5.0

Scored across 9 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: mailbox operations (send, inbox, ack, history) are separate from asking agents (ask_hermes, ask_codex, ask_claude), and sync vs async variants are clearly differentiated by name. The only potential overlap is among the three ask_* tools, but they target different agents and the descriptions name them explicitly.

Naming Consistency4/5

Mostly consistent: mailbox tools are single verbs/nouns (send, ack, inbox, history) and query tools follow 'ask_<agent>' with '_async' suffix for background variants. Minor inconsistency is the mix of verb and noun forms for mailbox tools and the absence of 'ask_hermes_async' (which is a completeness gap, not naming), but the overall pattern is readable and predictable.

Tool Count5/5

Nine tools is well-scoped for a messaging and agent-query server. Each tool covers a distinct function without redundancy, and the count is within the ideal 3-15 range.

Completeness4/5

The core lifecycle is covered: send, read, ack, and history for the mailbox; synchronous ask for all three agents; asynchronous for two of them. Missing async for Hermes and no delete/clear operations are minor gaps that don't severely hamper workflows, but a fully complete surface would include ask_hermes_async and maybe message deletion.

Maintenance

ActivityActive
ResponsivenessUnresponsive