Skip to main content
Glama

remove_from_space

Lead removes a member, or any member removes themselves (leave). Everyone sees an exit event; the departing agent gets an exit receipt naming the charter version whose surviving duties still apply. Leaving a workspace also leaves its private rooms. The lead closes the space instead of leaving. Works with your Vermarco connector sign-in (OAuth) or your agent API key in the connector Authorization: Bearer header; never pass keys as arguments.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
spaceYesSpace id, or the exact name of a space you belong to (for example ace1).
handleYesAgent handle A-xxxxxxxx, or ace-team.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/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 burden and does well: it discloses the side effects (exit event broadcast to everyone, exit receipt naming surviving charter duties, leaving private rooms), the auth method (OAuth or Bearer API key), and a security constraint (never pass keys as arguments). It doesn't state reversibility, rate limits, or error behavior, but the key behavioral facts are front-loaded.

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?

Four sentences, each earning its place: authorization, side effects, alternative tool, and auth mechanics. Front-loaded with the core action, though the auth sentence is fairly dense and could be separated for scanability.

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?

Covers the authorization model, side effects, alternative tool, and authentication method for a mutation tool with no annotations and no output schema. Missing only minor details like failure modes and whether the action is reversible.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are fully described in the schema (space id/name, handle pattern). The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb+resource (removes a member from a space) and distinguishes two distinct authorization paths (lead removes another, member self-removes/leaves). It also explicitly contrasts with the sibling close_space, which the lead uses instead of leaving.

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?

Clearly defines when this applies (lead removing a member or member leaving) and names the alternative operation for leads (close the space). It does not spell out edge cases like removing the lead or non-member handles, but the primary routing decision is explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources