Skip to main content
Glama
liyanfu896-cpu

hermes-local-agent-lanes

by liyanfu896-cpu
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Hermes Local Agent Lanes

Safe local-model support lanes for a cloud owner agent.

This project packages a pattern we use with Hermes Agent: keep the strongest cloud model as the owner that makes decisions, mutates files, verifies, and reports; route low-risk background work to fast local models through narrow MCP tools.

Local models should be useful coworkers, not unsupervised operators.

What this repo shows

  • Local MLX model as a safe MCP support lane for a cloud owner agent.

  • SSH stdio MCP mounting so another computer can use the local model without exposing a LAN HTTP port.

  • Support-only boundary guards: summary/classification/critique/draft are allowed; shell/patch/git/deploy/config/cron/hook/secrets are blocked.

  • Owner router demo for deciding task intensity and whether support models may be used.

  • Separate quota support lane pattern for using a secondary coding model as an advisory reviewer/patch-sketcher while the owner agent applies and verifies changes.

Related MCP server: cn-llm-mcp

Architecture

Cloud owner agent (Hermes / GPT-class model)
  ├─ owns architecture, mutations, tests, commits, final QC
  ├─ calls narrow local MCP support tools when useful
  │
  └─ Local support lanes
      ├─ MLX/OpenAI-compatible model server on localhost
      ├─ stdio MCP wrapper: support + health tools only
      ├─ optional SSH stdio mount from another computer
      └─ optional coding support lane in read-only/advisory mode

Why this matters

Most local-agent demos fail in one of two ways:

  1. They let a weaker local model execute risky actions.

  2. They use the expensive frontier model for every low-value summarization or log-reading step.

This repo uses a stricter split:

Layer

Allowed

Forbidden

Cloud owner

plan, decide, edit, test, commit, report

surprise paid/external actions

Local MCP support

summarize, classify, critique, draft, explain

shell, patch, git, deploy, config, cron, hooks, secrets

Secondary coding quota lane

read-only review, patch sketches, bug hypotheses

direct workspace mutation unless owner verifies

Quick start

1. Run a local OpenAI-compatible model server

Any local server with /v1/chat/completions works. Example environment variables:

export LOCAL_MODEL_BASE_URL="http://127.0.0.1:18085/v1/chat/completions"
export LOCAL_MODEL_NAME="your-local-mlx-model"

2. Start the MCP server locally

python3 -m hermes_local_agent_lanes.mcp_support_server

3. Mount it from a local MCP client

{
  "mcpServers": {
    "local-support-lane": {
      "command": "python3",
      "args": ["-m", "hermes_local_agent_lanes.mcp_support_server"]
    }
  }
}

4. Mount it from another computer over SSH

This avoids exposing the model server to your LAN:

{
  "mcpServers": {
    "local-support-lane": {
      "command": "ssh",
      "args": [
        "user@your-mac-or-workstation",
        "cd /path/to/hermes-local-agent-lanes && python3 -m hermes_local_agent_lanes.mcp_support_server"
      ]
    }
  }
}

Tools exposed

local_support

Ask the local model for low-risk support only:

  • summary

  • classification

  • critique

  • draft

  • simple code explanation

  • read-only long-context compression

Risky prompts are blocked before reaching the model and return:

TASK_REQUIRES_OWNER_AGENT

local_support_health

Checks whether the local model endpoint is reachable.

Run tests

python3 -m unittest discover -s tests

The tests exercise JSON-RPC MCP initialize/tool listing and the hard boundary guard without requiring a real model.

Repo status

This is a small pattern repo, not a full Hermes fork. It is intentionally portable and public-safe: no private paths, no credentials, no runtime databases, no model weights.

See also

  • docs/architecture.md — deeper design notes

  • examples/mcp-config-ssh.json — remote MCP mount example

  • examples/owner-router-demo.json — intensity-routing example

  • src/hermes_local_agent_lanes/owner_router.py — small callable router demo

License

MIT

Available Tools

2 tools
local_supportA

Ask a local model for low-risk support only: summary, classification, critique, draft, simple code explanation, and read-only long-context compression. Risky mutation prompts are blocked.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesTask prompt for the local support model.
max_tokensNoMaximum output tokens, 1-2048.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It discloses that risky mutations are blocked, adding behavioral context beyond the input schema. However, it lacks details on auth, rate limits, or what exactly happens when a prompt is blocked.

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, front-loaded with purpose and examples, concise without wasted words. Every sentence earns its place.

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 tool with two parameters and no output schema, the description is fairly complete, covering purpose, constraints, and examples. Minor missing detail on blocked behavior behavior but overall sufficient.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema for either prompt or max_tokens parameters.

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 asks a local model for low-risk support, listing specific tasks (summary, classification, critique, draft, simple code explanation, read-only long-context compression), distinguishing it from the sibling tool local_support_health.

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 explicitly says to use for low-risk support and lists example tasks, while also stating risky mutation prompts are blocked. However, it does not explicitly mention alternatives or when to use the sibling tool.

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

local_support_healthA

Check whether the configured local model endpoint is reachable.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior2/5

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

No annotations provided, so the description must carry full burden. It only states a connectivity check without detailing behavior like timeouts, error handling, or return format. Minimal transparency beyond verb and object.

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 sentence, 8 words, with no redundancy. It is appropriately concise and front-loaded.

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 zero-parameter tool with no output schema, the description is largely adequate. It could mention return type (e.g., boolean or status object), but the simplicity allows for a high score.

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 no parameters, so the description adds value by clarifying the tool's purpose. With 100% schema coverage (vacuously), baseline is 4; the description does not need to compensate for missing parameter details.

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 endpoint reachability, with a specific verb and resource. It implicitly distinguishes from the sibling tool 'local_support' by focusing on health rather than general support operations.

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 'local_support' or other alternatives. The description implies a readiness check but lacks context about prerequisites or follow-up actions.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0
Disambiguation5/5

The two tools are clearly distinct: one is for querying a local model with restrictions, the other is a health check for endpoint connectivity. No overlap in purpose.

Naming Consistency4/5

Both tools share the prefix 'local_support', creating a consistent pattern. The health tool appends '_health', which is predictable but not a strict verb_noun structure.

Tool Count3/5

With only two tools, the surface is minimal. While a focused health-check server might justify this count, the support tool covers broad tasks, suggesting additional tools (e.g., configuration) could be expected.

Completeness3/5

The set provides a basic query interface and health check, covering primary needs. However, missing tools for configuration, model listing, or error handling leaves notable gaps for a local model server.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Sentinel

    JureJan
    A
    license
    Not graded
    quality
    C
    maintenance
    A safe, allowlisted MCP server that lets AI agents run only a tiny set of harmless tools (echo, datetime, hash, dig, GET-only curl, whois, status checks) against explicitly allowed hosts, with sanitization, rate limiting, timeouts, and full audit logging.
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/liyanfu896-cpu/hermes-local-agent-lanes'

If you have feedback or need assistance with the MCP directory API, please join our Discord server