remove_peopleRemoves people from a site (owner; two steps): Site Developers and Viewers lose access (a workspace Viewer: every workspace site), users are signed out. Others may remove only themselves.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | ||
| entries | Yes | Emails or company domains | |
| confirm_token | No |
| Name | Required | Description | Default |
|---|---|---|---|
| agent_message | No | ||
| confirm_token | No |
Changes observed during successful MCP inspections.
Output schema / properties / agent_messageAdded value: +{
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "confirm_token": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Input schema / properties / confirm_token / descriptionRemoved value: -"After the user's yes"Input schema / properties / site / descriptionRemoved value: -"Site name"Input schema / properties / confirm_token / descriptionPrevious value: -"From the first call, once the user said yes"New value: +"After the user's yes"Input schema / properties / entries / maxItemsRemoved value: -50Input schema / properties / site / descriptionPrevious value: -"Site name, e.g. brave-otter-4821"New value: +"Site name"Output schema / (root)Previous value: -{
- "additionalProperties": {},
- "properties": {
- "agent_message": {
- "type": "string"
- },
- "confirm_token": {
- "type": "string"
- },
- "error": {
- "description": "On failure (isError): {code, message}"
- }
- },
- "type": "object"
-}New value: +nullDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructive annotation, the description discloses concrete effects: Site Developers and Viewers lose access, workspace Viewers lose access to every workspace site, and users are signed out. It also clarifies the permission boundary that non-owners can only remove themselves.
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 with no wasted framing. It is slightly dense due to nested parentheses and the compressed '(owner; two steps)' phrase, which could be easier to parse.
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?
The description covers the destructive consequences and permission model well, and output-schema richness means return values need not be explained. But for a destructive two-step operation, it leaves confirm_token and the confirmation workflow unexplained, which is a meaningful gap.
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 coverage is only 33%. The description implies the site target but does not explain entries or confirm_token, and 'two steps' does not clarify how confirm_token is used. Most parameter meaning must be inferred from the schema, which itself documents only entries.
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 and resource: 'Removes people from a site.' The site scope and role effects distinguish it from siblings such as remove_user, leave_workspace, and add_people without needing to name them explicitly.
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?
It gives clear permission context: owners can remove people, while others may remove only themselves. However, it does not explicitly name alternative tools or state when not to use this versus remove_user or leave_workspace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.