Skip to main content
Glama

oto_org_settings

Org settings, by domain. domain=email (per-connector senders + quiet hours: set takes connector scaleway|resend, senders [{email,name?,reply_to?}], quiet_hours {tz,start,end} or clear_quiet_hours=true, footer {unsubscribe_url?,unsubscribe_email?} = the org's own unsubscribe — once declared it REPLACES the platform footer on that connector's sends, refused without either field; clear_footer=true restores ours) | mfa (set require true|false — org-wide mandatory MFA) | field_filters (redaction policy ADR 0015: get returns policies, include_schemas=true adds the observed field catalog; set takes service + rules (None clears) + optional salt; a server-default (floor) field leaves masking only when NAMED in unmask [field, …] — rules: [] alone lifts nothing — and the service's documents are served only with documents: true; op=preview dry-runs rules against a real payload sample) | model_subscriptions (the org's consumption cap on members' personal model subscriptions, family e.g. claude_subscription: get returns limit_pct + default; set takes limit_pct 1..100 = max % of each member's provider account TOTAL usage (5-hour and 7-day windows) before the org's next jobs wait for the reset, or null = back to the default 80; a member's own cap (1..95) replaces it for them; OR, in a separate call, mode personnel|pool — pool runs the org's jobs, fleets included, ONLY on subscriptions members explicitly lent to the org, least recently used first; unset, lent subscriptions complement: they serve members with no usable subscription of their own, and fleets; OR, in a separate call, api_fallback true|false — true lets a job whose subscription is exhausted replay on the org's OWN deposited API key, same tier, instead of waiting (the default depends on the instance); get also returns mode, pool_size, lenders (who lends, and whether each is usable now — never their tier or usage) and api_fallback) | time_saved (minutes per result type behind the agents' time saved — report, action, record, research; the defaults are estimates, the org may override them; get returns each kind's default and applied minutes; set takes minutes {kind: 0..240 | null} — null restores that kind's default, {} all) | partage_par_defaut (what a NEW object of the org is shared with by default, per type: set takes partage {agent: aucun|lecture}; default aucun = born private; lecture = the whole org may see new agents, not edit them; their creator may still keep one private. ecriture is refused for agents: a scheduled run runs as its owner; preset_agent permis|refuse allows or refuses members' personal presets (oto_trigger op=default_sharing), future agents only; an org admin's get also lists in preset_agent_shared the members whose new agents are born shared) | apify_charge_cap (the org's ceiling per Apify run, $25 by default: set takes usd; at most the platform maximum without an Apify key of the org's own, at most the platform's safety bound with one; get also returns the bound and the ceiling in force on each key). op=get is member, set is org admin.

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>",
      "domain": "<domain>",
      "org_id": "<org_id>"
    },
    "name": "oto_org_settings"
  }
}

Input Schema

NameRequiredDescriptionDefault
opYes
usdNo
_orgNo
modeNo
saltNo
rulesNo
domainYes
familyNo
footerNo
org_idYes
unmaskNo
minutesNo
partageNo
payloadNo
requireNo
sendersNo
serviceNo
connectorNo
documentsNo
limit_pctNo
quiet_hoursNo
api_fallbackNo
clear_footerNo
include_schemasNo
clear_quiet_hoursNo

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations at all, the description carries the full behavioral burden and does so unusually well: it discloses that a declared footer REPLACES the platform footer and is refused without an unsubscribe field, that clear_footer/clear_quiet_hours restore platform defaults, that a floor field is only unmasked when NAMED in `unmask` (rules: [] alone lifts nothing), that mode/api_fallback must be set in separate calls, and that api_fallback's default is instance-dependent. It stops short of covering rate limits, reversibility/audit, or error behavior, so a 4 rather than a 5.

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?

It is front-loaded with a good one-line frame, and little is pure filler given how many domains must be covered, but the body is a single dense paragraph built from pipes and nested parentheses that is hard to parse at a glance. Splitting per domain or using a clearer list structure would cost nothing in length and gain a lot in scannability.

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 25-parameter, seven-domain, annotation-free tool with no output schema, this is close to complete: get-return shapes are described for model_subscriptions (limit_pct, default, mode, pool_size, lenders, api_fallback), field_filters (policies, include_schemas catalog), time_saved and apify_charge_cap. The remaining holes are the _org/org_id plumbing, per-domain error behavior, and any note on whether changes take effect immediately.

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 0% across 25 parameters, so the description must compensate and largely does: it defines connector values (scaleway|resend), sender/footer/quiet_hours shapes, require, service/rules/salt/unmask/documents/payload, family/limit_pct with its 1..100 and 5-hour/7-day semantics, mode personnel|pool, api_fallback, minutes {kind: 0..240|null} including the {} shorthand, partage keys with aucun|lecture, and usd bounds. The gaps are _org (never mentioned), org_id, and the op/domain enums which are left to the schema.

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 opening 'Org settings, by domain' plus an explicit enumeration of all seven domains (email, mfa, field_filters, model_subscriptions, time_saved, partage_par_defaut, apify_charge_cap) makes the verb and resource unmistakable, and the per-domain detail lets an agent know exactly which settings surface it is touching. It does not name or differentiate itself from neighbouring settings tools (oto_org, oto_admin_org, oto_admin_connector_setting), which keeps it from a 5.

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

Usage Guidelines3/5

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

The closing line 'op=get is member, set is org admin' gives a real usage/permission rule, and 'op=preview dry-runs rules against a real `payload` sample' tells the agent when preview applies. However there is no guidance on choosing between this tool and sibling org/admin tools, and no statement of when a domain should be read versus written beyond the implicit op enum.

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