Skip to main content
Glama

Ogen

by com.ogenhq
OverviewDiscussionsAdmin

Tenant settings

settings

Change one of this tenant's standing settings. action "mode": gate (the default) or observe — observe watches every read and action and counts what it would have caught without holding anything; switching to observe needs acknowledge: true and confirm: "nothing will be held", switching back to gate needs neither. action "contact": the email Ogen reaches you at (stored encrypted, never returned), your timezone and your weekend days. action "evidence": keep a keyed fingerprint of what each read saw, verifiable only with your secret. action "assist": an assistant on your own model-provider key that explains every hold and lists the questions only a person can answer — it never confirms, rejects, or picks. action "caller_set": register a counterparty's agent by label and grant it the action kinds it may request with commit_gated_action — a fresh or previously-removed label mints a key, shown once; re-registering a live label only updates the granted kinds. action "caller_remove": revoke a caller's key (the record stays). action "caller_list": every caller's label and granted kinds, never a key. A caller may only ever call commit_gated_action (for a granted kind) and explain_hold (for a hold it requested) — never decide, release, read a fact, bind a source or administer. action "door": a public page at /door/ naming your registered action kinds, for an agent that wants to know what it may ask before it asks it. Record.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoaction "mode" (required): 'gate' is the ordinary behaviour; 'observe' never holds anything, it only keeps count.
slugNoaction "door": your public handle, e.g. 'acme-support' — 3 to 32 lowercase letters, digits and hyphens. Required the first time you turn the door on.
emailNoaction "contact": the address Ogen sends account notices to.
labelNoaction "caller_set"/"caller_remove" (required): a name for the caller, e.g. "acme-procurement-agent".
modelNoaction "assist": model id to use. Default claude-opus-5.
actionYesWhich setting: "mode", "contact", "evidence", "assist", "door", "caller_set", "caller_remove" or "caller_list".
publicNoaction "door" (required): whether <pod>/door/<slug> is publicly reachable.
secretNoaction "evidence": your own verification secret. Omit and Ogen generates one, returned once.
confirmNoaction "mode": required (with acknowledge: true) only to switch to "observe" — exactly "nothing will be held".
enabledNoaction "evidence" or "assist" (required): turn it on or off. Assist off clears the stored key and every open draft.
weekendNoaction "contact": which days are your weekend — "sat-sun" (the default), "fri-sat", or "none".
timezoneNoaction "contact": your IANA timezone, e.g. "Europe/London". Unknown names are refused.
daily_capNoaction "assist": max drafts per UTC day (default 50, max 500). Past it, holds are still created, just without a draft.
acknowledgeNoaction "mode": required (with confirm) only to switch to "observe".
provider_keyNoaction "assist": your own Anthropic API key. Required to enable (Team tenants may omit it). Encrypted at rest, never returned.
allowed_kindsNoaction "caller_set" (required): action kinds this caller may request — each must already be registered with register_action.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / action / description
      Previous value: -"Which setting: \"mode\", \"contact\", \"evidence\" or \"assist\"."New value: +"Which setting: \"mode\", \"contact\", \"evidence\", \"assist\", \"door\", \"caller_set\", \"caller_remove\" or \"caller_list\"."
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "mode",
-  "contact",
-  "evidence",
-  "assist"
-]New value: +[
+  "mode",
+  "contact",
+  "evidence",
+  "assist",
+  "door",
+  "caller_set",
+  "caller_remove",
+  "caller_list"
+]
    • addedInput schema / properties / allowed_kinds
      Added value: +{
+  "description": "action \"caller_set\" (required): action kinds this caller may request — each must already be registered with register_action.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / label
      Added value: +{
+  "description": "action \"caller_set\"/\"caller_remove\" (required): a name for the caller, e.g. \"acme-procurement-agent\".",
+  "type": "string"
+}
    • addedInput schema / properties / public
      Added value: +{
+  "description": "action \"door\" (required): whether <pod>/door/<slug> is publicly reachable.",
+  "type": "boolean"
+}
    • addedInput schema / properties / slug
      Added value: +{
+  "description": "action \"door\": your public handle, e.g. 'acme-support' — 3 to 32 lowercase letters, digits and hyphens. Required the first time you turn the door on.",
+  "type": "string"
+}
  2. Added

TDQS

A4.1/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses important behaviors: 'stored encrypted, never returned', 'shown once', the exact confirm phrase needed to switch to observe, that deleting/off ensures key clearing, and the caller's hard limits. That is strong transparency. It could go further on whether observations/evidence are retained, what a 'door' page exposes publicly, and whether disabling assist is reversible.

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 description is one long dense block. It front-loads the overall purpose and then enumerates actions, which is good structure, but the sentences are very long and packed with clauses. There is little visual separation between action behaviors, making it harder to scan than necessary. The final 'Record.' is terse and slightly confusing. It's appropriately sized for the complexity, but the structure could be improved with clearer segmentation.

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?

Given 16 parameters, 8 actions, no output schema, and no annotations, the description does a thorough job covering what each action does and key constraints. It leaves some gaps: what the caller_list output looks like, what the door page exposes, and whether mode/contact changes are reversible. But for a complex multi-action tool, this is close to complete for an agent to pick the right action and parameters.

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 description coverage is 100%, so the baseline is 3. The description adds action-specific semantics for several parameters that the schema alone doesn't emphasize: the exact confirm string for observe, the acknowledge+confirm pairing, the one-time key display, the constraint that allowed_kinds must be registered via register_action, and that a fresh label mints a key. Some parameters (model default, daily_cap default 50, weekend enum) are only in the schema, so it doesn't fully compensate, but it adds clear value.

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?

States a specific verb and resource ('Change one of this tenant's standing settings'), and enumerates the eight action values, each with a clear functional description (mode, contact, evidence, assist, caller_set, caller_remove, caller_list, door). It's a polymorphic settings tool with multiple sub-resources, so 5 would require clearer top-level framing that 'action' selects one of eight distinct settings. Still, the purpose is unambiguous.

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?

For each action, the description explains the when/why: gate vs observe tradeoff, switching conditions, and what 'observe' watches. It also names constraints on callers (what a caller may only call). This goes well beyond siblings, routing the agent to the correct action and the correct constraints. The only gap is no explicit references to sibling tools like register_action or commit_gated_action by name for cross-tool flow, though commit_gated_action and explain_hold are mentioned.

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

All Ogen toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources