Skip to main content
Glama
debanjanbasu

grr

by debanjanbasu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

chat.spaces.delete

Deletes a named Google Chat space and all child resources, including messages and memberships, through a cascading delete. Use when permanently removing a space.

Instructions

Deletes a named space. Always performs a cascading delete, which means that the space's child resources—like messages posted in the space and memberships in the space—are also deleted. For an example, see Delete a space. Supports the following types of authentication: - App authentication with administrator approval and the authorization [HTTP DELETE] — removes the resource; irreversible unless the API documents a trash/undo flow; refused under --readonly safety profiles. Returns the post-delete resource state (or empty) as JSON — request bodies are built from the typed parameters (typed flags win over the params map), or read whole from body_file Siblings over the same resource: completeImport, create, findDirectMessage, findGroupChats, get, list, patch, search, setup.

Input Schema

NameRequiredDescriptionDefault
nameYes[URL path segment] Required. Resource name of the space to delete. Format: `spaces/{space}`
queryNoExtra KEY=VALUE query pairs for endpoints whose parameters Discovery does not describe.
paramsNoParameter map merged into the request; typed parameters win.
dry_runNoReturn the request that would be sent, without sending it.
body_fileNoRead the request body from this file ('-' for stdin) instead of building one from the parameters.
useAdminAccessNo[query parameter] Optional. When `true`, the method runs using the user's Google Workspace administrator privileges. The calling user must be a Google Workspace administrator wit

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / name / description
      Previous value: -"Required. Resource name of the space to delete. Format: `spaces/{space}`"New value: +"[URL path segment] Required. Resource name of the space to delete. Format: `spaces/{space}`"
    • addedInput schema / properties / name / pattern
      Added value: +"^spaces/[^/]+$"
    • changedInput schema / properties / useAdminAccess / description
      Previous value: -"Optional. When `true`, the method runs using the user's Google Workspace administrator privileges. The calling user must be a Google Workspace administrator wit"New value: +"[query parameter] Optional. When `true`, the method runs using the user's Google Workspace administrator privileges. The calling user must be a Google Workspace administrator wit"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "type": "object"
+}
  2. First observed

TDQS

A3.8/5.0
Behavior5/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 so well: it discloses that deletion is always cascading and destroys child messages and memberships, that it is irreversible, that administrator approval is required, that it is refused under read-only safety profiles, and that it returns the post-delete resource state (or empty). That is exactly the behavioral context an agent needs before a destructive call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical information (purpose + cascade + irreversibility) is correctly front-loaded, but the text is a concatenation of Google API docs, generated boilerplate ('Returns the post-delete resource state... typed flags win over the `params` map') and a bare sibling name dump, plus a dangling 'HTTP DELETE' fragment. Several sentences do not earn their place.

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?

For a destructive, 6-parameter tool the description covers impact, auth, reversibility and safety-profile behavior, and an output schema exists so return values needn't be explained in depth. Minor incompleteness: the auth text trails off mid-sentence about administrator privileges, and there is no note on what happens when the space is already deleted.

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 description coverage is 100%, so `name`, `query`, `params`, `dry_run`, `body_file` and `useAdminAccess` are already documented individually. The description only adds the precedence rule (typed parameters win over the `params` map) and body-from-`body_file`, both of which the schema already states, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('Deletes a named space') and immediately scopes the blast radius via the cascading-delete explanation. The trailing sibling list ('completeImport, create, findDirectMessage, get, list, patch, search, setup') names related tools but does not say how this one differs from them, so it stops short of true sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: you use it to remove a space, and the auth section tells you app authentication with administrator approval is required and that the call is refused under read-only profiles. There is no explicit 'when not to use' guidance, e.g. removing yourself via chat.spaces.members.delete instead of destroying the space.

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

Deploy Server

Other Tools