srift_kick_userHost-only. Disconnect and ban a peer from the active room.
| Name | Required | Description | Default |
|---|---|---|---|
| userId | Yes | User ID of the participant to disconnect and remove |
| Name | Required | Description | Default |
|---|---|---|---|
| userId | No | ID of kicked peer | |
| success | No | True if peer was successfully kicked |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / userId / descriptionAdded value: +"User ID of the participant to disconnect and remove"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "success": {
+ "description": "True if peer was successfully kicked",
+ "type": "boolean"
+ },
+ "userId": {
+ "description": "ID of kicked peer",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag the operation as destructive and not read-only. The description adds meaningful context beyond those annotations by specifying that only a host may use it and that it acts on the 'active room,' plus 'ban' clarifies the user will be disconnected and prevented from returning. This aligns with the destructiveHint rather than contradicting it.
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 a single front-loaded sentence that names the audience ('Host-only'), the action ('Disconnect and ban a peer'), and the context ('from the active room') without any filler. Every word contributes to the agent's understanding.
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 one-parameter tool with an output schema and destructive annotations, the description covers all critical operational context: who may invoke it, what it does, and where it applies. There is no meaningful gap that would prevent an agent from selecting or invoking this tool correctly.
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?
The input schema already fully documents the single parameter: 'User ID of the participant to disconnect and remove.' With 100% schema description coverage, the baseline is 3, and the tool description adds no additional parameter-specific detail, though it does clarify that the target is in the active room.
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 states a specific verb-plus-resource action: 'Disconnect and ban a peer from the active room.' It also adds a clear scope qualifier, 'Host-only,' which helps distinguish this tool from related session-management siblings like srift_approve_join or srift_reject_join.
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 makes the relevant usage context explicit: this tool is for hosts and applies to the 'active room.' It does not explicitly name alternatives or exclusion criteria, but the host-only and active-room constraints provide clear guidance for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.