Connect Token Saver to your AI host

Each tab is a complete setup path and has a shareable ?harness=... URL. Do not substitute one harness's endpoint or configuration keys for another.

Connecting the server only exposes tools. The host must still use the same cursor for the whole plan and execute only the tasks Elis discloses. Every ready task includes an authoritative recommended_model_size of nano, small, or frontier. A named model is optional host guidance, not a hardcoded binding.

1. start_elis_token_saver_plan({ goal, setup_version?, speed_mode?, host_billing?,
     constraints?, chain_hint?, session_id? })      // a quote: no tasks are revealed yet
2. submit_elis_task_plan({ plan_id, tasks })          // only when start returned decomposition_request
3. get_next_elis_task({ plan_id })                    // first call: reserves the estimate and reveals
                                                       // ready_tasks plus the first graph_revision
4. Execute every ready task with its execution_handoff and size tier
5. get_next_elis_task({
     plan_id,
     graph_revision,                                   // from the task's execution_handoff
     results: [{ task_id, status, summary | error, evidence?, steps?, artifacts?,
                 usage: { model, model_tier, input_tokens, output_tokens, duration_ms? } }]
   })                                                  // one item per finished task; usage goes INSIDE each item
   // a sequential host may send one previous_result (+ a top-level usage) instead
6. Repeat 4-5 until done: true; a new graph_revision invalidates un-reported work
7. finish_elis_plan({ plan_id, final_answer, total_tokens_used, usage, feedback?, store? })
   // print the response's report_card.lines verbatim; continuation_hint = next task is a NEW plan

Task status is ok, failed, blocked, skipped (needs a reason and evidence, or the task stays open), or refined (only for a task that carried a refinement_offer, together with replan_request.refine_task_id in the same call). A failed task is retried once, then the rest of the graph is replanned; the response's transition is retry, replan, or abort. Work you discover mid-run is not a failure: append it with replan_request { reason, proposed_tasks }, which bumps graph_revision. A report that carries output is not stored; put the result in summary (or error) and evidence.

A raw JSON-RPC client must implement OAuth itself. First read public discovery metadata, register a public client, create an S256 PKCE challenge and state, open consent, validate the returned state, exchange the one-time code, and send the access token in the header.

A successful authenticated finish can store a proven chain privately in the selected Personal or organization scope. Future similar goals can recall that task sequence. Report honest ok, failed, blocked, skipped, or refined task status and actual usage so prediction and savings audits compare against real execution.

// Do not store or recall this plan
start_elis_token_saver_plan({ goal, constraints: { no_store: true } })

// Keep private recall, but exclude this plan from community sharing
start_elis_token_saver_plan({ goal, constraints: { no_community: true } })

// Recall a known private proven chain for a similar goal
start_elis_token_saver_plan({ goal, chain_hint: "elis_chain:<sig>:<plan_id>" })

finish_elis_plan returns chain_hint as { hint, usage }, and only when the chain was stored and graded proven; pass chain_hint.hint back on a later start. Report steps and evidence on every task: a plan graded below the proven floor stores no chain and returns no hint.

• No tools: confirm the exact harness endpoint, Streamable HTTP config, host trust/enablement, and workspace MCP policy. Then refresh tools or restart the host.
• oauth_required or invalid_token: on initialize, tools/list, or a tools/call with no bearer the body is HTTP 401 { error, oauth_required, auth_action: "open_auth_url_and_wait", auth_url, login_url, startup_url, oauth_discovery_url }; on a tools/call with an expired, wrong-mount, or under-scoped token it is a JSON-RPC error (code -32001, data = the same payload). Open auth_url for the user and retry; do not continue anonymously. startup_url only wakes the server. A token minted for one mount is refused on another.
• insufficient_scope: 403 on tools/call. Reconnect and consent again with token_saver in scope.
• payment_method_required: a tool result with payment_method_required: true and a billing_url. Open the returned billing_url, attach a payment method to the selected scope, then retry the lifecycle call.
• rate_limited: HTTP 429 / JSON-RPC -32005 with retry_after in seconds. Back off for that long; never retry in a loop.
• plan_forbidden or plan_not_found: JSON-RPC -32003 / -32004. Usually an anonymous plan continued without its anonymous_client_id, or a plan from another account or scope.
• stale_graph_revision: you reported against an old graph_revision. Discard un-reported work from it, re-read ready_tasks, and report against the revision in the new handoff.
• skip_requires_reason_and_evidence: a skipped report needs both fields; the task stays open until it has them.
• First request times out: wake the API at https://tryelisai.com/mcp and retry after it reports ready.
• /elis missing or setup_status.update_needed: apply every file returned by setup_elis_host_instructions and start a new host session. Gemini CLI can reload commands with /commands reload.

For tool schemas, usage fields, tier semantics, grounding, and finish behavior, continue to MCP Tools & Tier-First Lifecycle.