MCP Tools & Tier-First Lifecycle

Six harness routes serve the same five tools and host-execution contract. Select the route assigned to your harness:

Codex / ChatGPT:   https://api.tryelisai.com/api/mcp/openai
Claude connector:   https://api.tryelisai.com/api/mcp/claude
Claude Code:        https://api.tryelisai.com/api/mcp/claude
GitHub Copilot:     https://api.tryelisai.com/api/mcp/openai
Gemini CLI:         https://api.tryelisai.com/api/mcp/gemini
Antigravity:        https://api.tryelisai.com/api/mcp/antigravity

Transport is stateless Streamable HTTP JSON-RPC: initialize, notifications/initialized, tools/list, tools/call.

• setup_elis_host_instructions — returns a dry-run manifest of managed instruction files for Codex, Claude Code, and Copilot. Each host gets three components, in apply order: the always-on rule block, the per-task executor agent, then the /elis command that spawns it — the command references the agent, so the agent has to land first. Narrow the manifest with components: ["rule"], or any subset of rule, agent, and command; the default ships all three. It still never writes local files and never returns secrets — your host previews, then applies with its own file-editing tools once you approve.
• start_elis_token_saver_plan — creates a private plan and returns a quote only: plan id, saved-token estimate, allowance state, planning usage, recall metadata, and a decomposition_request when no proven chain matched.
• submit_elis_task_plan — posts your own decomposition, and only when start asked for one. A recalled chain skips this entirely.
• get_next_elis_task — records results and usage, then discloses ready_tasks.
• finish_elis_plan — completes the plan, settles the reservation at the reserved planning estimate, and records usage plus compact feedback as learning and audit data.

The main session owns the cursor. Each disclosed task carries a public execution_handoff; a delegated agent either continues through the same authenticated MCP API when ownership is explicitly transferred, or returns its result to the main session for reporting.

1. start_elis_token_saver_plan({ goal, ref?, utm_source?, constraints? })
2. submit_elis_task_plan({ plan_id, tasks })        // only if start asked
3. get_next_elis_task({ plan_id, graph_revision,
       results: [{ task_id, status, ... }] })       // batch, parallel hosts
4. repeat 3 until done: true
5. finish_elis_plan({ plan_id, final_answer, total_tokens_used, usage, feedback })

ready_tasks is every task whose dependencies are satisfied — run them concurrently, one subagent per task. next_task is just the first ready task, kept for sequential hosts. The response also carries completed_task_ids, blocked_task_ids, and graph_revision.

Readiness and execution width are separate concerns. A host may cap its local worker pool for memory or CPU safety, but Elis still returns every dependency-ready task and does not rewrite the DAG or its parallel waves. For product task-orchestrated runs, an optional tenant_ctx.request_constraints.orchestration_max_parallel request value can only lower ORCH_TASK_MAX_PARALLEL; omitted, invalid, or nonpositive values keep the configured default. The task_graph trace exposes concurrency.configured, requested, and effective. A persistent per-user preference/setup UI, organization-wide fair-share scheduling, and nested shared budgets are not available yet.

/elis is this loop packaged as a slash command. setup_elis_host_instructions installs it once; after that, drive every task with /elis — it starts the plan, sizes each task to its selected tier, reports every result, and finishes the plan. Installing it once and then working normally hands the savings back. See Token Saver MCP — Six Harnesses for the install.

A disclosed task carries a tier: nano, small, or frontier. A suggested_host_model is optional guidance, not a required route; report what you actually ran inusage.model.

Elis records whether the reported model matched the suggestion. It cannot force a switch inside Claude or ChatGPT, so accurate reporting is the whole signal.

Per-task status is ok, failed, or blocked. A failed task is retried once, then the remaining graph is replanned in place. When the response carries transition: replan, discard un-reported in-flight work from the old graph_revision and never report against a stale revision.

TOKEN_SAVER_MAX_TASK_ATTEMPTS  default 2
TOKEN_SAVER_MAX_REPLANS        default 2

An exhausted budget aborts cleanly to settlement — it does not strand the plan. Always call finish_elis_plan when the cursor is done, including on failure.

Authenticated plans that finish with settled, graded execution are stored privately in the caller's scope as proven chains. Storage is secret-scrubbed and safety-scanned; anonymous plans are never stored. Public MCP v1 uses exact and hint recall only — semantic embedding recall is disabled for MCP callers, so embedding_access.mode stays degraded_lexical.

constraints: { no_store: true }      // no storage, no recall at all
constraints: { no_community: true }  // storage/recall on, community sharing off
chain_hint: "elis_chain:<sig>:<plan_id>"  // direct recall on a similar goal

The chain_hint returned on finish is a ~20-token pointer your host may remember. The chain itself never leaves the server — never persist full task chains in host memory.

Pass {rating: -1|1, facets?: string[], note?: string}. The rating is literal. Negative feedback can cap the outcome grade, demote a recalled chain, and block storage of a bad new one; in live learning mode it mints tenant-scoped canary variants through the same guarded rewrite pipeline as chat feedback. Feedback never bypasses tenant scope, safety scanning, canary gates, or constraints.no_store.