Skip to main content
Glama
debanjanbasu

grr

by debanjanbasu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

chat.spaces.messages.reactions.delete

Deletes a reaction from a Google Chat message by reaction name, removing an emoji response from a space conversation.

Instructions

Deletes a reaction to a message. For an example, see Delete a reaction. Requires user authentication with one of the following authorization scopes: - https://www.googleapis.com/auth/chat.messages.reactions - https://www.googleapis.com/auth/chat.messages - https://www.googleapis.com/auth/chat.import (import mode spaces only) [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: create, list.

Input Schema

NameRequiredDescriptionDefault
nameYes[URL path segment] Required. Name of the reaction to delete. Format: `spaces/{space}/messages/{message}/reactions/{reaction}`
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.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / name / description
      Previous value: -"Required. Name of the reaction to delete. Format: `spaces/{space}/messages/{message}/reactions/{reaction}`"New value: +"[URL path segment] Required. Name of the reaction to delete. Format: `spaces/{space}/messages/{message}/reactions/{reaction}`"
    • addedInput schema / properties / name / pattern
      Added value: +"^spaces/[^/]+/messages/[^/]+/reactions/[^/]+$"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "type": "object"
+}
  2. First observed

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral burden and does well: it states the operation is irreversible, notes it is refused under --readonly safety profiles, specifies required user authentication and exact scope alternatives, and says it returns the post-delete resource state. It lacks detail on error behavior when the reaction doesn't exist, so not a 5.

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 core purpose is front-loaded, but the text is padded with boilerplate ('[HTTP DELETE] — removes the resource; irreversible unless the API documents a trash/undo flow…') and a long inline scope list with links. Useful content is mixed with generic template noise.

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?

An output schema exists, so return values needn't be explained, yet the description still mentions the post-delete resource state. Auth scopes and irreversibility are covered. Only the behavior on a non-existent reaction or auth failure is missing, a minor gap for a simple delete.

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 the `name` pattern/format, `params`, `query`, `dry_run`, and `body_file` are all documented in the schema. The description only echoes the precedence rule ('typed flags win over the `params` map') and body_file behavior, adding no new semantics. 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?

The opening sentence gives a specific verb and resource ('Deletes a reaction to a message'), which is immediately distinguishable from reactions.create and reactions.list. It also names the siblings over the same resource, though it doesn't say how deleting differs functionally from, e.g., messages.delete. Clear but not maximally differentiating.

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?

The description lists the sibling operations (create, list) and the required auth scopes, which implies when to use it, but there is no explicit statement of when to delete versus, say, patch a reaction. Usage is implied rather than spelled out.

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