Dynamoi

Manage Team

dynamoi_manage_team

Destructive

Invite an editor with action=invite_editor: targetId is the artist ID; email and clientRequestId are required. Preview first, obtain user confirmation, then send phase=confirm with expectedSnapshot. Confirmation sends a transactional email, limited to 10 confirmed invitations per inviter/workspace/hour. Other actions change an organization member's role, remove a member or revoke a pending organization invitation using the same authority and transactional protections as web. targetId is the membership or pending invitation row ID from dynamoi_get_team; scope defaults to organization and may explicitly select artist. Admin and verified last-admin protections apply; removal can revoke access and pending invitations.

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": {
      "action": "<action>",
      "targetId": "<targetId>"
    },
    "name": "dynamoi_manage_team"
  }
}

Input Schema

Name	Required	Description
`role`	No
`email`	No
`phase`	No
`scope`	No
`action`	Yes
`targetId`	Yes	Organization membership or pending invitation row ID from dynamoi_get_team.
`expectedRole`	No
`clientRequestId`	No
`expectedSnapshot`	No

Output Schema

Name	Required	Description	Default
`code`	No
`data`	No
`kind`	No
`field`	No
`reason`	No
`status`	Yes
`draftId`	No
`message`	No
`retryable`	No
`nextAction`	No
`failureStage`	No
`prerequisite`	No
`screeningResult`	No
`retryAfterSeconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 8, 2026

addedInput schema / properties / expectedRole

Added value: +{
+  "enum": [
+    "admin",
+    "editor",
+    "viewer"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / reason

Added value: +{
+  "enum": [
+    "member_changed",
+    "invitation_changed"
+  ],
+  "type": "string"
+}

Changed6 schema fields changedNov 5, 2026

changedInput schema / properties / action / enum

Previous value: -[
-  "update_role",
-  "remove_member",
-  "revoke_invitation"
-]New value: +[
+  "update_role",
+  "remove_member",
+  "revoke_invitation",
+  "invite_editor"
+]

addedInput schema / properties / clientRequestId

Added value: +{
+  "format": "uuid",
+  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+  "type": "string"
+}

addedInput schema / properties / email

Added value: +{
+  "format": "email",
+  "maxLength": 320,
+  "pattern": "^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+  "type": "string"
+}

addedInput schema / properties / expectedSnapshot
```
Added value: +{
+  "type": "string"
+}
```

addedInput schema / properties / phase

Added value: +{
+  "enum": [
+    "preview",
+    "confirm"
+  ],
+  "type": "string"
+}

addedInput schema / properties / scope

Added value: +{
+  "enum": [
+    "artist",
+    "organization"
+  ],
+  "type": "string"
+}

AddedNov 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only state destructiveHint=true and openWorldHint=true; the description adds real behavioral context beyond that: confirmation sends a transactional email, a rate limit of 10 confirmed invitations per inviter/workspace/hour, optimistic-concurrency via expectedSnapshot, and admin/verified-last-admin protections. It also warns that removal revokes access and pending invitations, which is exactly the blast radius an agent needs before calling a destructive tool.

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?

It is a single dense paragraph with no filler sentences - rate limits, phase protocol, ID semantics and safety guards each carry weight. Front-loading the invite flow before the other actions is sensible, though the paragraph is long enough that an agent skimming it could miss the scope-default or last-admin clauses.

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

Completeness5/5

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

For a 9-parameter destructive multi-action tool, the description covers the phase protocol, ID sourcing, rate limits, permission guards and revocation side effects, and an output schema exists so return values need no explanation. Only the role/expectedRole pairing is left implicit.

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 only 11% (only targetId is documented), so the description must compensate and largely does: it explains that targetId means an artist ID for invite_editor but a membership or pending invitation row ID for the other actions, that email and clientRequestId are required for invites, that scope defaults to organization and can explicitly select artist, and that expectedSnapshot belongs to the confirm phase. It leaves role versus expectedRole unexplained, which is the main remaining ambiguity.

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 names concrete verbs and resources for every action variant: 'Invite an editor', "change an organization member's role", 'remove a member' and 'revoke a pending organization invitation'. It also distinguishes the invite path from the member-management paths, so an agent can tell which action value maps to which operation without inspecting the schema.

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?

For the invite path it is explicit: preview first, obtain user confirmation, then send phase=confirm with expectedSnapshot. It also directs the agent to dynamoi_get_team for targetId values. The gap is that it never says whether the other three actions also require the preview/confirm dance, or whether they are single-shot - an ambiguity an agent will hit at call time.

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

All Dynamoi 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.