MELRA
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| melra_capabilitiesA | Discover available local execution capabilities, policy defaults, and runtime limits. |
| melra_planA | Persist a bounded task, evaluate policy, and return any scoped approval challenge without executing. Nothing runs until melra_execute. A policy denial comes back as a normal result with status policy_blocked and a reason, not as an error. Any operation that is not a read needs requiredEvidence, and constraints must stay empty. |
| melra_executeA | Execute one previously planned task through policy, runtime, verification, and receipt generation. If melra_plan returned an approval challenge, pass its id and its exact phrase; the phrase is scoped to that one task and expires. Policy is re-evaluated here, so a plan made under a looser policy is still refused. Only reads are retried. |
| melra_task_statusB | Read the current durable state of a task. |
| melra_task_cancelB | Cooperatively cancel a running or pending task. |
| melra_receiptC | Retrieve action receipts and the execution certificate. |
| melra_workflow_planC | Validate, preflight, encrypt, and persist a bounded workflow without executing it. |
| melra_workflow_advanceC | Execute one ready workflow scheduling wave through governed MELRA tasks. |
| melra_workflow_statusC | Read the current durable workflow projection. |
| melra_workflow_cancelB | Cooperatively cancel nonterminal workflow nodes and their tasks. |
| melra_workflow_controlB | Halt a running workflow without losing node state, or lift a halt. Node progress is untouched, so a resumed workflow continues where it stopped. |
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 11 tools
The set is organized into two parallel families (task-level and workflow-level) with clearly distinct plan/execute/status/cancel roles, so most tools are easy to tell apart. A few pairs invite confusion: melra_workflow_control (halt/resume, state preserved) vs melra_workflow_cancel (terminate), and melra_execute vs melra_workflow_advance (both perform execution at different granularities).
All names use snake_case with a consistent melra_ prefix, which is highly predictable. The deviation is structural rather than stylistic: task operations are unprefixed (melra_plan, melra_execute) while the analogous workflow operations are domain-prefixed (melra_workflow_plan, melra_workflow_advance), so the two parallel families don't mirror each other exactly.
Eleven tools is well within the sweet spot and each one maps to a real step in the governed task/workflow lifecycle (discover, plan, execute, status, cancel, control, receipt). No tool appears redundant or trivially included.
The surface covers task and workflow lifecycles well: plan, execute/advance, status, cancel, control, and receipts, plus capability discovery. Minor gaps exist, such as no enumeration/list operation for existing tasks or workflows and no workflow-level receipt retrieval, which an agent would have to work around via status projections.