Tulina

oto_admin_org_member

Manage an org's members (org_admin of org_id; list = platform admin). op=add (target email|sub, role org_member|org_admin) / remove (target) / set_role (target, role) / list / connectors (target — the member's configured connectors: connector/account/secret_kind/set_at/public meta, NEVER any secret — diagnose a failing byo_user key) / events (membership log: who joined, left or changed role, when, by whom; newest first, limit, before_id = previous page's next_before_id). Anti-lockout on the last 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>",
      "org_id": "<org_id>"
    },
    "name": "oto_admin_org_member"
  }
}

Input Schema

Name	Required	Description	Default
`op`	Yes
`_org`	No
`role`	No
`limit`	No
`org_id`	Yes
`target`	No
`before_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.3/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 behavioral burden and does well: it discloses permission requirements, anti-lockout protection for the last org_admin, that connector secrets are never returned, and that events are ordered newest first. It leaves some mutation side effects unspecified, such as what happens to a removed member's connectors.

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

Conciseness4/5

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

The description is dense but front-loaded and wastes little space, packing permissions, op variants, security constraints, and pagination into a compact block. The slash-and-semicolon structure is efficient, though somewhat harder to scan than shorter prose.

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 seven-parameter, six-operation admin tool with no annotations or output schema, the definition covers the critical operational semantics: permissions, anti-lockout, secret safety, pagination, and per-op purpose. It is not fully complete because `_org` is unexplained and mutation outcomes are not described.

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%, so the description must explain parameters itself. It defines the op enum values, target semantics for add/remove/set_role/connectors, role values, limit, and before_id pagination. The unexplained `_org` parameter is a notable gap, but most operational parameters are covered.

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?

The description states a specific resource ('an org's members') and enumerates all six supported operations with their key parameters, making the tool's scope immediately clear. It also distinguishes permission levels for org admins versus platform admins.

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?

It gives clear per-operation guidance, including required role values, the special platform-admin condition for list, connector diagnostics use, and event pagination. It does not explicitly compare against sibling admin tools such as oto_admin_org or oto_admin_user, but the operation-level guidance is strong.

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?