Skip to main content
Glama

oto_admin_tenant

[platform admin] Tenant tracking (identity tier, ADR 0052). op=list → one row per declared tenant: issuer + jwks + hosts + oauth client + dashboard url, the tool-name prefix shown to its accounts (tool_prefix declared vs tool_prefix_effectif actually applied), whether it is LOADED in this process's issuer registry (declared but not restarted ⇒ its tokens are still rejected), orgs (via orgs.tenant_id), accounts (via sub qualification), active accounts + MCP calls over days (default 30), and orgs_desalignees — orgs attached to this tenant whose creator is qualified under another one. op=get (slug) adds the lists behind those counters (orgs, accounts by activity, misaligned orgs). Declaring a tenant remains a provisioning runbook, not an API — but op=reload (super_admin) makes THIS process re-read the declarations without a restart: the issuer registry and the accepted issuers are swapped live, which clears pending_restart. Per-process: prod and preprod share the DB but not their registry. op=keys (slug) → the connector keys posed on the tenant (never the secret): one shared key serves every org of the tenant that has no closer key (member/team/org), resolved before the platform key. op=key_clear (slug, provider, optional account; super_admin) removes one. Posing a key is REST only: PUT /api/admin/tenants/{slug}/keys/{provider}. op=admins (slug) → the tenant's admins (accounts qualified under it: they manage the tenant's keys and org grants from the REST face); admin_add / admin_remove (slug, sub; super_admin). op=org_grants (slug, provider) → orgs granted the tenant's key with their shared daily budget and usage; org_grant (org_id, optional daily_quota, 0 = unlimited; replaces) / org_revoke (org_id; the org falls back to the platform key) — super_admin. Without any grant the key serves every org of the tenant; the anonymous endpoint of an org gets it only through a live grant. op=disable (slug, reason; super_admin) disables the tenant: every request of its accounts is refused from the next one on (any token, dashboard sessions included), new authorizations on its hosts are refused, its API/delegation tokens are revoked — counts by type returned. op=enable (slug) reopens new connections only; revoked tokens stay revoked. Never edit issuer by hand to disable a tenant.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "oto_admin_tenant"
  }
}

Input Schema

NameRequiredDescriptionDefault
opNolist
subNo
_orgNo
daysNo
slugNo
org_idNo
reasonNo
accountNo
providerNo
daily_quotaNo

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses that a declared-but-not-restarted tenant has its tokens rejected, that reload swaps the issuer registry live and clears pending_restart, that state is per-process (prod and preprod share the DB but not the registry), that keys are never returned in secret form, that key resolution prefers the closest org/team/member key over the platform key, and exactly what disable/enable destroy (revoked tokens stay revoked).

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?

Almost every clause carries real information, and op=list (the default) is front-loaded correctly, but the whole thing is a single undifferentiated paragraph of 13 ops that is hard to scan. Minor redundancy and heavy parenthetical nesting reduce retrievability even though little is strictly wasted.

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 13-op, 10-param admin tool with no output schema and no annotations, this is unusually complete: return contents for list and get are described, permission gates (super_admin) are marked per op, and destructive effects are spelled out. Residual gaps are the unexplained `_org` parameter and the response shape of the mutating ops (admin_add, org_grant, key_clear).

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 0% across 10 params, so the description must compensate, and it does for nearly all of them: every op enum value is explained, days is given a default of 30, daily_quota is defined ('0 = unlimited', replaces), provider/account/org_id/reason/sub all get contextual meaning. The notable gap is `_org`, which is never mentioned anywhere in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The headline 'Tenant tracking (identity tier)' is specific enough, and the body enumerates exactly what each op does (list, get, reload, keys, admins, org_grants, disable, enable) against a clearly tenant-scoped resource. It distinguishes itself implicitly from oto_admin_org/oto_admin_account by scoping orgs 'via orgs.tenant_id' and accounts 'via sub qualification', but never states the boundary against those siblings explicitly.

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?

Usage is well-routed per op: op=reload is framed as the no-restart alternative to a provisioning runbook, key posing is explicitly redirected to REST (PUT /api/admin/tenants/{slug}/keys/{provider}), and 'Never edit issuer by hand to disable a tenant' is a direct when-not instruction. It lacks only an explicit statement of when to reach for a sibling admin tool instead.

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