Skip to main content
Glama

Acknowledge workspace changes

workspace_changes_ack
Idempotent

Explicitly acknowledge one delivered workspace change page. Rendering or polling does not acknowledge it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workspaceId": "<workspaceId>",
      "deliveryToken": "<deliveryToken>"
    },
    "name": "workspace_changes_ack"
  }
}

Input Schema

NameRequiredDescriptionDefault
whyNoOptional, accepted and not recorded: this write keeps no workspace history. If you send one, one sentence on what the person is trying to accomplish. At most 300 characters.
workspaceIdYesThe workspace: its id or its slug.
deliveryTokenYes

Output Schema

NameRequiredDescriptionDefault
acknowledgedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / workspaceId / description
      Previous value: -"The workspace id (UUID)."New value: +"The workspace: its id or its slug."
    • removedInput schema / properties / workspaceId / format
      Removed value: -"uuid"
    • addedInput schema / properties / workspaceId / maxLength
      Added value: +64
    • addedInput schema / properties / workspaceId / minLength
      Added value: +1
    • removedInput schema / properties / workspaceId / pattern
      Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare that this is a non-read-only, idempotent, non-destructive operation. The description adds important behavioral context: acknowledgment is explicit and is not satisfied by rendering or polling, which is essential for an agent to know.

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

Conciseness5/5

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

Two short sentences with no waste, and the key distinction from rendering/polling is front-loaded immediately after the action statement.

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 and annotations already cover return shape, safety, and idempotency. The description supplies the critical semantic that acknowledgment must be explicit, though it could be slightly stronger by tying the tool directly to the workspace_changes workflow.

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 67%, with workspaceId and why documented in the schema. The description adds context that the token relates to one delivered workspace change page, but it does not explain deliveryToken source, scope, or validity beyond what its name implies.

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 description states a specific verb and resource: explicitly acknowledge one delivered workspace change page. It clearly distinguishes acknowledgment from passive rendering or polling, though it does not explicitly name the related workspace_changes sibling.

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?

It implies the tool should be used to acknowledge a delivered change page and clarifies that rendering or polling is insufficient. However, it does not explicitly say when to call it relative to workspace_changes or provide workflow alternatives/exclusions.

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.