Odile Gate Oversight

Read Gate operational metrics

gate_get_metrics

Read-onlyIdempotent

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>",
      "admin_key": "<admin_key>"
    },
    "name": "gate_get_metrics"
  }
}

Input Schema

Name	Required	Description	Default
`admin_key`	Yes	The project admin key (ga_...). Read it from the .env; never print it.
`project_id`	Yes	The project id from gate_create_project, e.g. p1a2b3...

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnly, idempotent and non-destructive annotations, it discloses that audit data may be partial due to invalid-key sampling and audit-off periods, that no upstream requests, quota use or policy changes occur, and that the result is not a health certificate. It also adds authorization context (owner key or active member key) and a crucial safety note that reading metrics never starts checkout, with the checkout path only to be POSTed when the admin asks to upgrade.

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

Conciseness3/5

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

The purpose and sibling differentiation are front-loaded, and most clauses carry useful behavioral detail. However, the single dense paragraph runs long and repeats the gate_read_audit routing at the end after already stating it in the first sentence. Better structure and removal of that repetition would improve scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, yet the description explains the returned content in detail: status and reason counts, duration through response headers including upstream wait, per-app anomaly scores, idle app semantics with the idle_days default, and current-month plan/used/allowed plus upgrade details. It also covers partial-audit caveats and side-effect guarantees, which is complete for this read-only metrics tool.

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 coverage is 100%, so both parameters are already documented, but the description adds authorization meaning by stating that the key must be a project owner key or an active member key. That clarifies what kind of admin_key is valid in a way the schema does not. It does not add syntax or format details for project_id, which is already covered by 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?

The description opens with a specific verb and resource: project-wide 24-hour call aggregates, anomaly scores, idle apps and current-month usage. It explicitly distinguishes this from gate_read_audit (individual calls) and gate_get_run_timeline (one run), so an agent can route correctly without opening a schema.

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?

It states the intended use case directly: operational trends rather than individual calls or one run, and names the alternatives to use instead. The final sentence reinforces the routing rule for individual calls, leaving no ambiguity about when to select this tool.

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

All Odile Gate Oversight tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?