hmesh-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HARNESS_MESH_CONFIG | No | Path to an optional YAML configuration file (equivalent to `--config`). | |
| HARNESS_MESH_WORKSPACE | No | The primary project root / workspace directory for the MCP server. |
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_harnessesC | List locally available harnesses, discovered authorised models, tier bindings and quota state. |
| discover_harness_modelsC | Run the three-layer model discovery waterfall for one or all harnesses. |
| get_model_marketB | Read cached model prices, context windows and intelligence scores.
|
| preview_routingB | Preview the routing decision for an objective without dispatching it. |
| list_skills_and_pluginsC | Search indexed SKILL.md files and MCP/plugin manifests. |
| dispatch_taskB | Dispatch a ticket. Only the objective is required. Leave target_harness at "auto" and model unset to let the mesh choose; pass task_kind when it is known. Quota exhaustion creates a new Assignment on another harness and resumes in the same worktree. |
| parallel_dispatchA | Dispatch multiple tickets concurrently. Every task accepts the same fields as |
| get_task_statusC | Return ticket status plus every assignment and failover hop. |
| read_task_resourceB | Page through a large diff/transcript/assignments payload to protect the controller context window. |
| get_quota_statusA | Show quota circuits and the waiting_for_quota queue.
|
| report_quota_statusC | Manually reset or mark a quota circuit (actions: reset, open, half_open). |
| apply_task_patchB | Apply the isolated worktree changes back into the primary workspace. Only |
| cancel_taskB | Cancel a running or waiting ticket. The worktree is retained for inspection. |
| get_project_contextC | Read the cross-harness project memory blackboard and instruction files. |
| update_project_contextC | Write or update one shared project fact or interface contract. |
| get_integration_statusA | Report whether each installed harness can reach Mesh as a controller. States are |
| plan_integrationA | Return the exact installation plan and
|
| install_integrationA | Install one harness after the user approved the reviewed plan. This is a write tool: it refuses workers and |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Most tools map to a distinct resource+action, and the three-phase integration flow (status → plan → install) is explicitly separated by read/write semantics. Minor ambiguity remains between get_quota_status and report_quota_status, since 'report' sounds like a read but actually mutates the circuit, and the model-information trio (discover_harness_models, list_harnesses, get_model_market) requires reading descriptions to separate cache reads from live discovery.
The surface is overwhelmingly verb_noun snake_case (get_task_status, cancel_task, update_project_context) with clear read/write prefixes. Deviations are cosmetic: parallel_dispatch inverts the verb order, preview_routing lacks an explicit object, and discover_harness_models/get_model_market stretch the pattern without breaking it.
18 tools sit at the high end of comfortable but each corresponds to a real operation across dispatch, quota, integration, model discovery and project context. Nothing looks like filler, though the set is broad enough that a controller may need a session to build a mental map.
Core lifecycle is well covered: routing preview, dispatch (single and parallel), status, cancel, patch application, quota read/write and integration detect/plan/install. Gaps are real but workaroundable: there is no list_tasks to enumerate tickets before calling get_task_status, no uninstall/ignore integration despite the 'ignored' state, and no tool to edit tier bindings that list_harnesses reports.