Skip to main content
Glama
cherninlab

Ennodia

Official
by cherninlab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Run Ennodia

ennodia_run

Starts a high-level orchestration to route tasks to local AI harnesses, plans routing, runs one or more tasks, optionally compares outputs, and returns a run ID.

Instructions

Start a high-level Ennodia orchestration. Set pragmatic for evidence-focused investigation or patch proposals with one or more independent workers. Use Plan Advisor for tailored model and skill assignments. Use this as the default entrypoint: it plans routing, starts one or more local harness tasks, optionally compares successful outputs, and returns a run ID. Runs usually take minutes; use ennodia_get_run with waitMs: 30000 and includeEvents: false until terminal, then consume and verify its answer. A wait timeout does not cancel or finish the run.

Input Schema

NameRequiredDescriptionDefault
cwdNoWorking directory for child harness commands.
modeNoauto follows the planner; single runs one selected harness; parallel runs all candidate harnesses.auto
modelNoOptional model override passed to the selected task harnesses.
budgetNoOptional preflight budget limits for an Ennodia operation.
promptYesThe user task to route to local AI harnesses. For native media, first read ennodia_list_harnesses inputGuidance, specify local paths and a harness/model, then verify one small sample with mode single and compare false. Ennodia sends text, not media attachments.
compareNoWhether to run the Judge + Result Advisor after tasks finish. auto compares when the planner sees value and at least two tasks produce output.auto
refreshNoRe-scan harnesses before planning the run.
categoryNoOptional caller-provided route category. Pass this when you know the task category; Ennodia then skips keyword classification.
skillIdsNoInstalled native skill IDs to request from child harnesses. Returned metadata does not prove that an agent loaded the skill.
harnessIdNoForce one harness by ID, such as codex or claude-code. Omit to let Ennodia plan.
pragmaticNoExperimental evidence contract for one or more independent workers. Preserves routing and comparison choices. Use Plan Advisor for tailored model and skill assignments. This is workflow guidance, not a permission sandbox or a savings guarantee.
timeoutMsNoPer-task timeout in milliseconds. Defaults to the task manager timeout and is capped at one hour.
isolateCwdNoRun each selected harness against an ephemeral isolated copy of cwd instead of cwd itself. Use this in parallel mode or whenever comparing skills/harnesses against the same cwd, so concurrent file writes cannot clobber each other. Isolation fails before task spawn if the copied tree contains a symbolic link. The reported task cwd is an execution trace; its temporary directory is deleted when the task becomes terminal.
judgeModelNoOptional model override for the comparison Judge.
advisorModelNoOptional model override for the Result Advisor.
nativeSandboxNoCodex worker native sandbox. Defaults to read-only on every turn, including continuation. Request workspace-write only for authorized edits. Other harnesses reject this setting; Judge/Advisor settings are unchanged.
continueTaskIdNoContinue the latest settled persistent task owned by this server. Use its Ennodia task ID. The working directory and harness stay the same. Each follow-up gets a new task and execution allowance.
judgeHarnessIdNoHarness to use as the comparison Judge. Omit to use the default priority: claude-code, codex, antigravity, opencode, kilo, kiro, cline, then hermes-agent.
maxOutputCharsNoMaximum characters from each successful task output to pass into the Judge + Result Advisor workflow. Use 0 to suppress candidate text.
persistSessionNoOpt in to native Codex session persistence. Requires one explicit harness and a persistent cwd. Default tasks remain ephemeral.
nativeSubagentsNoDisable Codex built-in subagent tools for workers. Other harnesses reject this setting. Does not block external commands or affect Judge/Advisor tasks.
reasoningEffortNoOptional reasoning effort for a Codex worker. Other harnesses reject explicit effort settings; omit to preserve native defaults.
advisorHarnessIdNoHarness that runs the Result Advisor after the Judge. Defaults to the judge harness selection.
synthesizerModelNoDeprecated alias for advisorModel. Do not send both fields with different values.
synthesizerHarnessIdNoDeprecated alias for advisorHarnessId. Do not send both fields with different values.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false and openWorldHint=true; the description adds the operational profile that matters here: runs "usually take minutes," they are asynchronous, and "a wait timeout does not cancel or finish the run." That is genuinely useful beyond the annotations, though it says nothing about cost, concurrency limits, or failure modes of the harness tasks.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four dense, front-loaded sentences that lead with what the tool does and end with the polling contract. Slightly redundant: "Use Plan Advisor for tailored model and skill assignments" repeats guidance already present in the pragmatic schema description.

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 25-parameter orchestration tool with no output schema, the description covers the full lifecycle (plan -> run -> poll -> verdict), the return value (run ID), and the async/polling contract. It leaves unstated what the run-ID payload or final answer looks like, and gives no scope on run cost, which keeps it short of complete.

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?

Schema description coverage is 100%, so the baseline is 3 and the schema already covers all 25 parameters. The description still adds selection guidance the schema does not: when to set pragmatic (investigate vs patch) and how to poll via waitMs/includeEvents. It does not attempt to explain the many tuning parameters (judgeModel, nativeSandbox, isolateCwd), leaving those to the schema.

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?

States a specific verb (start) and resource (Ennodia orchestration) and spells out the mechanics: plans routing, starts local harness tasks, optionally compares outputs, returns a run ID. It also distinguishes itself from the sibling ennodia_get_run by naming it as the follow-up poll step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly positions itself as "the default entrypoint," names the alternative (ennodia_get_run) with concrete parameters (waitMs: 30000, includeEvents: false) and the condition (until terminal). It also routes agents to pragmatic mode for evidence/patch work and to Plan Advisor for model/skill assignments.

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

Deploy Server

Other Tools