Skip to main content
Glama

review_changes

Idempotent

Review queue: what changed and isn't live yet. list (counts first) → get one item (hidden changes, optional diff, bodyChanged: false means only title/meta/route fields changed — review hidden, not the visible page) → mark_ready / unmark (≤50 ids). Then publish_site onlyReady:true. Drafts-only sites: a person marks.

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": {
      "site": "<site>"
    },
    "name": "review_changes"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoget: item id from list (p:/path, s:key, m:menus)
allNounmark: clear every ready mark
idsNomark_ready / unmark: item ids from list (≤50)
diffNoget: include first diff rows
siteYesSite slug, e.g. acme-studio
stateNolist filter (default all)
actionNolist (default) · get one item · mark_ready · unmarklist
cursorNolist pagination (full only)
detailNolist detail (default summary)
dryRunNomark_ready / unmark: preview only
contextNoWhy you're calling this (activity log).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • changedInput schema / properties / context / description
      Previous value: -"Optional: one sentence on why you are calling this (shown in the site's activity log; no personal data)."New value: +"Why you're calling this (activity log)."
  2. Changed3 schema fields changed
    • changedInput schema / properties / context / description
      Previous value: -"One sentence: why you are calling this tool and what you are trying to accomplish. Stored on the site's activity log and visible to everyone on the site — never put secrets or personal data here."New value: +"Optional: one sentence on why you are calling this (shown in the site's activity log; no personal data)."
    • removedInput schema / properties / guestToken
      Removed value: -{
      -  "description": "Guest token from start_site. Send it on every call until claim_site. Omit when this chat is already signed in to Dotsy.",
      -  "minLength": 20,
      -  "type": "string"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "site",
      -  "context"
      -]New value: +[
      +  "site"
      +]
  3. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (idempotent, non-destructive, not read-only), and the description adds real behavioral context beyond them: get returns hidden changes with an optional diff, and bodyChanged:false means only title/meta/route fields changed so the agent should review the hidden change rather than the visible page. It omits side-effect detail such as what mark_ready does to live state, 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.

Conciseness5/5

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

Compact arrow-chained flow with the queue definition front-loaded and no redundant sentences. The telegraphic style is dense but every clause carries distinct information about workflow, limits, or return semantics.

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 an 11-parameter, four-action tool with no output schema, the description covers the workflow, the hidden-vs-visible distinction, the batch limit, and the drafts-only caveat. Remaining gaps are minor: exact list payload shape and pagination are left to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds value: it explains the counts-first behavior of list, that diff is optional on get, and that ids are capped at 50 for mark_ready/unmark. It also interprets the bodyChanged return field, which the schema cannot describe since no output schema exists.

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 resource and scope precisely: a review queue of changes that are not live yet, with the four actions it supports. It distinguishes itself from publish_site by naming the downstream step, but does not explicitly separate itself from nearby siblings such as get_draft_status or discard_drafts, keeping it short of a 5.

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

Usage Guidelines5/5

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

It lays out the exact sequence: list (counts first) → get one item → mark_ready/unmark, then publish_site onlyReady:true. It also gives an explicit edge case: on drafts-only sites a person must do the marking, so the agent knows when not to attempt automation.

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