Skip to main content
Glama

get_space_changes

Read-only

Members poll bounded metadata events, including tombstones. Copy cursor until has_more=false; latest skips history. Read changed resources; honor poll_after_seconds.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesResource ID from a prior response. For memory use your stable note name, e.g. working-context.
limitNoMaximum items per page. Follow next_cursor until absent.
cursorNoCopy returned next_cursor unchanged, keeping filters. For sync copy cursor; latest starts without history.
max_tokensNoEstimated response budget: 3 UTF-8 bytes per token. Increase on BUDGET_TOO_SMALL.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
replayedNo
operationNo
truncatedNo
next_cursorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "description": "Structured result for get_space_changes. Resource fields vary by detail, permissions and operation. Paginated results use items/next_cursor; operation-key replays use operation/replayed. Failures have error and the MCP result has isError=true. See get_help for this tool's contract.",
      +  "properties": {
      +    "error": {
      +      "properties": {
      +        "code": {
      +          "type": "string"
      +        },
      +        "help": {
      +          "type": "string"
      +        },
      +        "message": {
      +          "type": "string"
      +        },
      +        "next_action": {
      +          "type": "string"
      +        },
      +        "retry_after_seconds": {
      +          "type": "integer"
      +        }
      +      },
      +      "required": [
      +        "code",
      +        "message",
      +        "next_action",
      +        "help"
      +      ],
      +      "type": "object"
      +    },
      +    "next_cursor": {
      +      "type": "string"
      +    },
      +    "operation": {
      +      "type": "object"
      +    },
      +    "replayed": {
      +      "type": "boolean"
      +    },
      +    "truncated": {
      +      "type": "boolean"
      +    }
      +  },
      +  "type": "object"
      +}
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavior beyond those: tombstones are included, cursor pagination is terminal, and poll_after_seconds must be respected. It does not mention rate limits or auth, but those are less essential given the output schema and annotation safety profile.

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?

The description is extremely tight: each sentence carries operational value, the most important action is front-loaded, and there is no filler or repeated schema content. It reads like a stable instruction manual, not prose.

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 four-parameter read-only polling tool with a complete schema and an output schema, the description covers the key interplay: cursor, has_more, latest, and poll_after_seconds. It does not discuss alternatives or edge-case data semantics, but an agent can call the tool correctly with this description plus the schema.

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?

Input schema covers all 4 parameters at 100%, so the schema already carries parameter meaning. The description mostly re-expresses the cursor rule already documented in the schema, adding only the compact phrase 'latest skips history'. Parameter burden is on the schema, which is complete, so baseline 3 is appropriate.

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 the verb 'poll' plus a resource ('bounded metadata events, including tombstones') and adds pagination/latest behavior that clarifies its use. It does not explicitly distinguish itself from the nearby sibling get_sync_changes, leaving some ambiguity about the exact scope boundary.

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?

The description gives direct procedural guidance: copy cursor until has_more=false, 'latest skips history', and honor poll_after_seconds. It does not mention when to prefer this over get_sync_changes or other polling tools, but the usage pattern itself is concrete enough to act on.

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