Change an event member's role between host and guest. Preview the update first, then confirm to apply the role change.
Change an event member's role between host and guest. Confirm-gated.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | New role for the member. | |
| userId | Yes | Id of the member to update. | |
| confirm | No | Must be true to proceed. Without this, the tool returns a preview. | |
| eventId | Yes | Event id. |
Changes observed during successful MCP inspections.
v1.5.3v1.4.3v1.3.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so this is a write operation. The description adds 'Confirm-gated,' disclosing that a confirmation step exists, which is not present in annotations. This alerts the agent to the two-step nature of the tool, though the specific preview behavior is documented in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. It front-loads the core action and adds the critical confirm-gating note without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with a confirm gate, the description gives the essential purpose and the key behavioral trait ('Confirm-gated'). The input schema fully covers parameters, so the description doesn't need to explain them. The lack of an output schema is acceptable given the simplicity of the operation, though it could have mentioned the preview behavior explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all four parameters with descriptions and enum values. The description adds little beyond the schema: 'between host and guest' restates the enum, and 'Confirm-gated' hints at the confirm parameter but doesn't add syntax or detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Change') and resource ('event member's role'), and clearly identifies the two possible roles ('host and guest'). This distinguishes it from sibling tools like remove_user or invite_users, which have different actions on event members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when an event member's role needs to be toggled between host and guest, but it does not explicitly mention alternatives or when not to use it. No direct comparison is made to sibling tools like vibo_remove_user or vibo_invite_users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.