MCP Tools & Tier-First Lifecycle

Four host-flavoured mounts and one host-neutral mount 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
Any other client:   https://api.tryelisai.com/api/mcp   (host-neutral)

The host-neutral mount stamps plans with the OpenAI host family. For programmatic OAuth prefer one of the four host mounts: they are the only accepted resource values, and a token is bound to the mount it was issued for.

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, GitHub Copilot, Gemini CLI, and Antigravity (omit hosts to receive all five, then apply only your host's entries). 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. Rule files are replaced wholesale (AGENTS.md and GEMINI.md through a managed block); agent and command files are created only if absent, and a conflict is reported rather than overwritten; the Antigravity workflow is a manual install. The response also carries manifest_version, restart_notice, authentication (interactive and programmatic OAuth steps), and endpoint_notes. 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. The optional host_billing (subscription, api or unknown) only changes which report-card line leads.
• 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[] (status ok, failed, blocked, skipped, or refined; summary or error; evidence, steps, artifacts, and usage inside each item), then discloses ready_tasks. Accepts replan_request to append discovered work or to refine a task that carried a refinement_offer.
• finish_elis_plan — completes the plan and settles the reservation. In reported-charge mode the Elis fee is the configured share of the saving your reported per-model usage shows against the frontier baseline, not capped at the estimate; the reserved planning estimate is charged instead only when no reported step has both a model the catalog can price and input/output token counts. It also records usage plus compact feedback as learning and audit data, and returns the display-only usage_extension and report_card described in step 8. The response also carries settlement, chain_tracking (with chain_hint when a proven chain was stored), and continuation_hint: the next task starts a new plan, never this plan_id.

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, setup_version?, speed_mode?, host_billing?, constraints?, chain_hint? })
2. submit_elis_task_plan({ plan_id, tasks })        // only if start asked
3. get_next_elis_task({ plan_id })                  // first call: no graph_revision yet
   get_next_elis_task({ plan_id, graph_revision,
       results: [{ task_id, status, summary, usage }] })   // 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 — Harness Setup 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.

In reported-charge mode (TOKEN_SAVER_REPORTED_CHARGE_MODE=on) that report is also the fee basis: settlement measures the saving from the steps whose usage.model the catalog can price, using their input/output token split. Steps on a model the catalog can't price earn no credit; a plan that reports no usage, or whose steps name no model the catalog can price, is charged its reserved planning estimate instead and flagged for review. With the mode off, or at its shadow default, every disclosed plan is charged its reserved estimate.

Per-task status is ok, failed, blocked, skipped (with reason and evidence), or refined. A failed task is retried once, then the remaining graph is replanned in place. A stale report returns stale_graph_revision. 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. Every signed-in plan gets exact and hint recall. Paid plans add semantic recall and knowledge grounding, and embedding_access.mode reports semantic; free accounts stay on degraded_lexical. The instant and fast speed modes skip the semantic tier. See what each plan gets with Token Saver.

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 { hint, usage }; the hint is a ~20-token pointer your host may remember, returned only when the chain was stored and graded proven. 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.

finish_elis_plan returns two display-only blocks beside the settlement: usage_extension (the numbers) and report_card ({lead, lines[]}, the same numbers worded by the server). Print report_card.lines to the user verbatim, in order, on every run, right after the plan_id line. Do no math, and do not reword or drop a line. If the response has no report_card (an older server), print Usage extension: not provided by this Elis server.

Usage extension (estimate): +<N>% more work per usage window (~<M> extra minutes at this run's pace).
Savings: $<X> measured (Elis fee $<Y>).

• What it measures. For a subscription host, how much further the run stretched a usage window: an estimate from the planner's token counts for the same work with and without Elis's right-sizing. The minutes are the run's active task time scaled by that gain and are labelled "at this run's pace"; report duration_ms per task to ground them.
• Estimate, display-only. It is an estimate from the planner's token counts, and it never enters settlement, the Elis fee, or the ledger. A run with no gain prints "none expected".
• Not available. A plan that carried no token estimate prints "not available (this plan carried no token estimate)". Reported usage does not change this line; keep reporting usage.model on every task so the savings line is measured.
• host_billing. Optional on start. It only picks the leading line: the usage extension for subscription or unknown, the savings for api. Decide it from the host's own login status, never by reading credential files; omit it when unsure.
• Where else it appears. Every plan response carries the same usage_extension block: estimated on the quote, partial while tasks are still running, measured on finish. Only finish carries the report_card.