Watch Odile Gate: runs, held actions, audit log with signed export, metrics and refusal reasons.
Scored across 13 tools
Most tools target distinct actions (create/delegate/revoke a run, apply learning, verify exports), and the descriptions explicitly cross-reference siblings ("use it rather than gate_read_audit", "for one run use gate_get_run_timeline"), which strongly separates the observability cluster. The remaining overlap is in the five auditing/metrics tools (read_audit, export_audit_proof, get_metrics, get_run_timeline, get_run_tree), where an agent must read long prose to pick correctly — distinct but easy to misselect at a glance.
Every tool follows the same gate_<verb>_<noun> snake_case pattern: gate_create_run, gate_revoke_run, gate_read_audit, gate_update_app, gate_list_actions, gate_get_metrics. Verb style is uniform (create/delegate/revoke/get/read/list/export/verify/explain/update/learn) with no mixed camelCase or bare nouns.
13 tools sits in the well-scoped 3-15 band, and each one earns its place: run lifecycle, delegation, audit read/export/verify, metrics, timeline/tree views, learning read/apply, approval queue, and refusal explanation. No obviously redundant or filler tools are present.
Coverage of run lifecycle, audit, and learning is solid, but gate_create_run instructs users to call gate_add_approver before granting approval:true actions — and that tool is absent from the surface, a hard dead end for any approval-requiring run. There is also no approve/deny or app-creation/listing tool (the agent must fall back to the dashboard or API), so several core workflows terminate outside the tool set.
Gate Actions: give one agent session narrow, expiring permission. Actions are rules with {placeholders} bound by scope (e.g. "PATCH /customers/{customer}/tickets/:id" with scope {"customer":"A"}), each with an optional max and approval. Add a human approver with gate_add_approver before granting approval:true actions; without an active approver the grant is refused. Returns a run token (shown once) the agent sends as x-odile-run with its app key. Writes in a run need an Idempotency-Key. Give a write a check ("GET /bookings?idempotency_key={key}") and the agent can settle a lost answer with POST /g//_gate/recover.
Inputs: app (required), actions (required), admin_key (required), project_id (required), +4 more.
Hand a narrower run to another active app in the same project. Uses the parent app key and run token, never the admin key. Scope, expiry, approvals and ancestor budgets stay enforced; maximum depth five.
Inputs: app (required), actions (required), app_key (required), run_token (required), +4 more.
What a Gate refusal means and how to fix it, from the x-gate-refused header value (e.g. route_not_allowed).
Inputs: reason (required), recoverable.
Returns chained audit rows, decided-action feature snapshots and signed anchors; use it for a portable tamper-evident export instead of gate_read_audit's recent-call view, then check it with gate_verify_audit_proof. No sealed paths/bodies, notes, keys or IPs in the action labels. Legacy actions lack snapshots and are excluded. store_audit=false has no chain. Follow next_from for audit rows and next_actions_after as actions_after for labels (10,000 each). Use API/SDK to verify exports above the MCP request size limit. The signature is HMAC-SHA256.
Inputs: admin_key (required), project_id (required), to, from, +1 more.
Returns project-wide 24-hour call aggregates, anomaly scores, idle apps and current-month usage; use it for operational trends rather than individual calls in gate_read_audit or one run in gate_get_run_timeline. Includes stored call counts by HTTP status and reason, measured duration through response headers (including upstream wait), per-app anomaly scores and 24-hour anomaly counts, idle apps (active apps whose key made no allowed call in the project's idle_days, default 14; a flag only, never a revoke), and separate current-month gateway usage: plan, used, allowed, plus upgrade URL and checkout path on Free at 80% or above. Only POST the checkout path when the admin asks to upgrade; reading metrics never starts checkout. Requires the project owner key or an active member key. Audit may be partial: invalid-key sampling and audit-off periods are disclosed. No upstream requests, quota use or policy changes; not a health certificate or performance guarantee. For individual calls use gate_read_audit.
Inputs: admin_key (required), project_id (required).
Returns one run's call metadata, approvals and approver names, recovery outcomes and delegated children; use it to reconstruct that session instead of gate_read_audit's project-wide calls or gate_get_run_tree's permission state. No bodies or query values. One run only; the project-wide log is gate_read_audit.
Inputs: run_id (required), admin_key (required), project_id (required), before.
Returns one run and its delegated descendants without tokens; use it to inspect delegation and permission state instead of gate_get_run_timeline events. One run only; the project-wide log is gate_read_audit.
Inputs: run_id (required), admin_key (required), project_id (required).
Read normalized routes and a suggested per-minute limit from an admin-enabled, time-boxed learning session. Records only method, normalized path templates and counts per minute; no query values, raw ids, headers or bodies. Never enables learning or applies rules.
Inputs: app (required), admin_key (required), project_id (required).
Actions waiting for approval (or in another state), with the exact call. With an installed approval-risk model, pending actions sort by risk descending and include risk (0–1) and risk_features (top two advisory signals). No model means no score and newest first. Only a person decides in the dashboard.
Inputs: admin_key (required), project_id (required), state.
Returns recent gateway calls (time, app, matched route, status, reason, duration); use it to investigate individual calls across the project rather than gate_get_metrics aggregates or a single gate_get_run_timeline. Newest first, with totals by status and refusal reason for the returned calls. This view never returns bodies, query values or headers. For 24-hour totals and anomaly scores use gate_get_metrics; for a signed export an auditor can check, gate_export_audit_proof; for one run's history, gate_get_run_timeline.
Inputs: admin_key (required), project_id (required), app, limit, +1 more.
End one run granted with gate_create_run: its token stops working at once (403 run_revoked) while the app itself keeps working. Use it to stop an agent mid-job; grant a new run with gate_create_run if the work should continue.
Inputs: run_id (required), admin_key (required), project_id (required).
Apply stored learning suggestions to an existing app and return the applied routes, suggested per-minute limit and learning-session metadata. Review gate_learn_suggestions first, then explicitly confirm; requires the project owner key or an admin member key. mode="extend" adds learned routes (default); "replace" removes existing routes before applying them. Both modes set the learned rate limit and keep the app key. Only learned suggestions can be applied: arbitrary routes or rate limits are not accepted, and this tool never starts learning.
Inputs: app (required), confirm (required), admin_key (required), project_id (required), +1 more.
Returns intact or broken_at for a supplied signed export; use it to check a gate_export_audit_proof export rather than retrieve audit rows. Recomputes the chain and project signature; broken_at is a one-based row position. Does not approve actions or change permissions.
Inputs: proof (required), admin_key (required), project_id (required).
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
EU AI Act Art-14 runtime oversight: allow / flag / gate-to-human on an agent action, with receipt.
Set up Odile Gate: per-app keys, allowed calls, approvers and config for your API or model key.
Watchdog for unattended AI agents: alerts, evidence checks and a verifiable proof per run.
Runtime AI governance: decision gates, human approval, hash-chained audit, compliance mapping.
Add one secure layer between your agents and this server.
