Tulina

oto_admin_access_shadow

[platform admin] L7 shadow window (ADR 0053): during the double-read window the grant CHAIN computes alongside while the legacy cascade decides; every pair of verdicts is compared and filed under a closed set of classes. op=read (days, default 7; optional connector, classe) → one row per day x connector x org x class, with the first sample of the day (sub is hashed, never in clear), plus a verdict block. These divergence classes are EXPECTED and named by the ADR — elargissement_equipe (the chain reads every team of the caller, the cascade only the ACTIVE one; counted per org because it changes served behaviour), free_tier_hors_modele (an open platform key has no grantee in 0053 — the everyone-edge exists now (grants_chain.EVERYONE, the platform scope), so this counts what is LEFT to migrate and reaches zero once the seeding command has run), partage_hors_modele (its sibling: a platform key CLOSED on an allowlist that no edge accounts for — the NOMINAL edges are missing, L5 only seeded the switched connectors), perso_cross_org (the cascade follows a personal key across orgs). Only inconnu must stay at zero: verdict.porte_ouverte is true when there is no unknown divergence AND the denominator is non-zero, for the origin it names; verdict.origine_inconnue counts observations left out because they predate the origin column. Read-only — the counter is fed by the resolution path and switched off by the OTO_L7_SHADOW env, never from here.

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_access_shadow"
  }
}

Input Schema

Name	Required	Default
`op`	No	read
`_org`	No
`days`	No
`classe`	No
`origine`	No	prod
`connector`	No

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

B3/5.0

Behavior4/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 well: it declares the tool read-only, states that the counter is fed externally by the resolution path and switched off by OTO_L7_SHADOW, and clarifies that data is never written from here. It also explains the verdict fields and expected divergence classes, though it does not cover permissions or edge-case behavior when the env switch is off.

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

Conciseness2/5

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

The purpose is front-loaded but the body is a dense, run-on wall of internal ADR terminology and parenthetical caveats. Much of the class taxonomy is necessary, but the lack of structure makes it harder to scan than it needs to be.

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

Completeness3/5

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

For a complex admin tool with no output schema and no annotations, the description does substantial work by explaining the returned dimensions, verdict fields, and divergence classes. It leaves important gaps around the `_org` and `origine` parameters and does not state operational prerequisites for invoking it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain all six parameters. It covers `op=read`, `days` default 7, and partially covers `connector` and `classe`, but it never explains `_org` and only indirectly references `origine` through the `verdict` 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 description names a specific administrative read operation: comparing grant-chain verdicts against the legacy cascade during the L7 shadow window and returning divergence rows. The resource and output shape are concrete enough to distinguish it from generic admin inspection tools, though the heavy ADR/domain jargon makes the purpose slower to grasp.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

It explains that certain divergence classes are expected and that `inconnu` must remain zero, which helps interpret results. It does not say when an agent should call this tool, when it should avoid it, or which sibling admin monitoring tool is the alternative.

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

All Tulina 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?