Skip to main content
Glama

oto_admin_monitoring

Platform observability console (platform admin). ⚠️ TWO journals, never one: summary/calls cover AGENT (MCP) calls ONLY — what a person does from the dashboard or the API is NOT there, it is in op=rest. An account at zero calls is therefore NOT an idle account: check op=rest before saying so. ⚠️ A filter an op does not read is REFUSED (error param_not_read_by_op), never silently ignored. op=summary (aggregates: totals, by tool w/ avg+p95 latency, by user, by day; optional days, org_id, sub email|sub) / calls (raw MCP call log, newest first; filters sub, tool, errors, days, org_id, run_id, session_id, min_duration_ms slow calls, error_contains) / call (call_id → full record incl. truncated args + correlation ids) / run (run_id → timeline; content_archived = body in cold archive, bounds kept) / runs (recent runs) / rest (REST lens by route — days, org_id, sub, and route (prefix match) for an EXACT count/errors/last_call_at on one route — by_route is capped at the top 100, so a low-volume route can be invisible there without saying so; by_status splits the errors by HTTP code over the same window and filters, so an expected 4xx is not read as an outage — status: null means NO response went through the log: an unhandled exception (the 500 is served above it — that is what a crash looks like) or a client that left; ⚠️ org_id here is the consultation org claimed by a header (best-effort): a request without it carries none and drops out of the filter, so a 0 does not prove an idle org — cross-check with sub) / rest_calls (raw REST call log, newest first, same filters as rest — route is a prefix of METHOD /route, e.g. GET /api/orgs — plus limit (max 200); the ONLY lens that serves view_as_sub: the account a platform operator's view-as was actually APPLIED to (operator verified, existing target other than themself), null otherwise — a refused or no-op X-Oto-View-As header leaves it null. Rows logged before 2026-09-21 carry the header as claimed, unverified) / connectors (credential resolution failures; optional org_id) / transport (MCP transport refusals by cause, plus rate_limit: the app rate limiter per env/class/mode — would_refuse is what enforce would cut, peak_pct the fullest bucket; and rate_limit_top: per day, env and limiter (debit | platform_rate | the process bounds), the top hashed keys enforce would cut — and under credits, the units-budget SIGNALS unpriced:<connector.function> / unreported:<tool>, not refusals; days) / funnel (accounts vs real usage) / gaps · tool_quality (aggregated usage signals) / agents_en_echec (hosted agents whose JOBS are dying, grouped by agent AND by reason — days (default 1), optional org_id; each row carries travaux, tentatives, depuis, dernier). ⚠️ This is the one nobody asks for: a triggered agent breaks SILENTLY — its queue empties because dead jobs stop waiting, its screen says active, and its last run can be green. Grouped by reason because three times the same fault is a bug to fix, while three different ones is a misconfigured agent — one count would read them alike. This is the lens a nightly report reads to say it in one line. / connecteurs_orphelins (no filter): the rows that NAME a connector absent from the served catalog — member installations, removals, activations, credentials, settings, live instances, org kits — per table and per name (lignes). Such a row resolves nothing: an installation that mounts no tool, a key nobody reads. Every table is listed, an empty one included, so a zero reads as checked; total = 0 is the healthy state. Read only: nothing is moved or deleted here. For raw signals use oto_admin_signal.

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": {
      "op": "<op>"
    },
    "name": "oto_admin_monitoring"
  }
}

Input Schema

NameRequiredDescriptionDefault
opYes
subNo
_orgNo
daysNo
toolNo
limitNo
routeNo
errorsNo
org_idNo
run_idNo
call_idNo
session_idNo
error_containsNo
min_duration_msNo

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.4/5.0
Behavior5/5

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

No annotations exist, and the description carries the full burden well: it states read-only explicitly ("nothing is moved or deleted here"), discloses that unread filters are refused with `param_not_read_by_op` rather than ignored, explains `status: null` as an unhandled exception the 500 is served above, flags `by_route` truncation at the top 100, notes archived bodies via `content_archived`, and warns that pre-2026-09-21 view-as headers are unverified.

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 critical warnings are front-loaded, which is right, but the body is a single mega-sentence of slash-separated ops with nested parentheticals and inline ⚠️ markers that is hard to scan. Nearly every clause carries information, yet a per-op list structure would have delivered the same content with far less parsing effort.

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

Completeness4/5

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

For a 14-parameter, 14-operation console with no output schema and no annotations, the description covers return semantics, null cases, refusal behavior and per-op filters thoroughly. What is missing is the op-to-parameter applicability table and any explanation of `_org`, leaving the agent to infer which filters each op accepts — partly mitigated by the refusal error.

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?

With 0% schema description coverage the description must do all the work, and it largely does: `route` is a prefix of `METHOD /route`, `limit` capped at 200, `sub` accepts email or sub, `route` gives an exact count where `by_route` is capped, `days` defaults to 1 for agents_en_echec, `error_contains`/`min_duration_ms` are scoped to their ops. The one real gap is `_org`, which is never mentioned or distinguished from `org_id`.

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?

Names a specific resource and scope ("Platform observability console (platform admin)") and then enumerates all 14 ops with what each returns — summary aggregates, raw call log, single-call detail, run timeline, REST lens, credential failures, rate limiter, funnel, failing agents. It also draws an explicit boundary against the nearest sibling ("For raw signals use oto_admin_signal"), so an agent can place it 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives strong operational routing: check op=rest before declaring an account idle, use agents_en_echec for silently dying triggered agents, use rest_calls when view_as_sub matters. It names one alternative (oto_admin_signal) but never contrasts itself with oto_org_monitoring, the sibling an agent is most likely to confuse with a platform-admin console.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources