Skip to main content
Glama

List a tree's changes

list_changes
Read-onlyIdempotent

The changes people have asked for or proposed to a tree in OKForest, newest first: each one's title, where it is (requested, drafting, in review, or done), who asked and when, the files it touches, and its page. Everyone who reads the tree sees them, so check here before asking for something already asked. get_change shows one in full.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_changes"
  }
}

Input Schema

NameRequiredDescriptionDefault
treeNoThe tree's slug, as list_trees gives it (not its name). Required unless the Forest has one tree.
statesNoOnly changes in these states; omit for all of them.

Output Schema

NameRequiredDescriptionDefault
treeYesThe tree.
changesYesIts changes, newest first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds useful context annotations do not: results are ordered newest-first and are visible to everyone who reads the tree. It doesn't discuss pagination or rate limits, but with annotations and an output schema the bar is lower.

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 tightly written sentences with no waste. The resource definition and ordering are front-loaded, followed by the duplicate-check guidance and the pointer to get_change.

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 read-only list tool with full annotations, an output schema, and fully described params, the description supplies what structured fields do not: ordering, visibility, and the dedup-check rationale. The only gap is the partial state list, which could momentarily mislead about available states, but the schema corrects it.

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 both parameters are documented in the schema itself, making 3 the baseline. The description gestures at state filtering ('where it is (requested, drafting, in review, or done)') but lists only four of the six enum values, and adds no detail about the tree slug requirement beyond what the schema states.

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 and resource ('changes people have asked for or proposed to a tree'), plus ordering ('newest first') and the fields returned. It also explicitly differentiates from the sibling get_change ('get_change shows one in full'), so an agent can choose between list and detail views without opening either schema.

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?

Gives clear usage context: 'check here before asking for something already asked', because everyone who reads the tree sees changes. It names the detail alternative get_change. It stops short of explicit when-not-to-use criteria beyond the duplicate check, so not a 5.

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