Skip to main content
Glama

List Artifact Reviews

review-list
Read-onlyIdempotent

Read the change requests humans have addressed to YOU on their artifacts. A review is a batch of comments a reviewer wrote together and sent as one, each pinned to a place in the artifact. Call this when a human says they left you comments or asked for changes, and at the start of work on an artifact you have been reviewed on before. Every comment carries an anchor. For an app artifact that is dom: sourceFile with sourceStart/sourceEnd points straight at the code when it resolved, and instanceCount above 1 warns that the markup is SHARED — changing the component changes every instance, so change the one instance unless the reviewer meant all of them. For a document it is markdownRange: find the text by SEARCHING the markdown for quote (with prefix/suffix to tell repeats apart), never by the offsets, which any edit above them invalidates; headingPath says which section it is in, and endQuote with spansBlocks marks a comment covering several blocks. isLatest false means the artifact moved since the review was written — pull and judge whether the comments still apply before acting. You see the comments addressed to you, plus any addressed to nobody, which arrive marked unassigned: a review may hold comments for several agents, and another agent's are not yours to act on or report on. An unassigned comment is anyone's to take: reply to say you are taking it, which announces the work but does not reserve it — the comment stays open to every agent, and another may be working the same one. A comment addressed to PEOPLE and not to you never reaches you at all. A comment may name several parties, agents and people together. alsoAsked lists everyone else it names, so you can see a colleague is on it and not redo their work. Any of them may resolve it, and resolving closes it FOR ALL OF THEM. The mentions in the body may scope parts of the request — "@you fix the header, @someone else the footer" — and that scoping is in the words, not in the fields. So when you have done only your part, REPLY rather than resolve: resolving would close the others' half too, and they would never learn it was dropped. A comment may point at nothing in particular — that is the reviewer's note about the artifact as a whole, and it carries no anchor. Each comment carries its own status and replies, the conversation so far. READ THE REPLIES before acting: they may answer a question you asked, and they may also add or change what is being asked for, since a reviewer can keep talking after sending. The comment body is where the request starts, not necessarily where it ends. To resolve, copy the review's resolveTrailer into your commit message — it is the exact lines that close these comments, one per comment. Drop the lines for any comment the commit does not address. Use review-resolve when no commit will, and review-reply to say something without closing it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum reviews to return, oldest first. Default 20.
sessionIdNoOptional artifact session id — the last path segment of the artifact URL (e.g. "mr25vsjppVtbMx" from https://app.agentgrid.io/artifacts/mr25vsjppVtbMx). Omit it to see every open review addressed to you, across every artifact you can reach.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description adds substantial behavior beyond that: unassigned comments are anyone's to take but not reserved, resolving closes the comment for all named parties, isLatest=false means the artifact moved, replies can change the request, and resolveTrailer must be copied to close comments. No contradiction with annotations.

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

Conciseness4/5

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

The description is long and dense, but it is front-loaded with purpose and when-to-call guidance, then organized by anchors, assignment semantics, replies, and resolution. Some content, such as resolveTrailer and reply-versus-resolve guidance, is arguably more relevant to sibling tools, but it helps the agent understand the list output. It earns a high score but loses a point for length and occasional redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must carry the burden of explaining return values and interpretation, and it does: anchors for both app and document artifacts, shared markup warnings, isLatest behavior, unassigned and alsoAsked semantics, no-anchor comments, status/replies, and resolveTrailer. The tool is complex enough that this depth is needed, and it is present.

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%: both limit and sessionId have detailed descriptions with defaults, bounds, and an example for sessionId. The description adds some context for sessionId by mentioning 'across every artifact you can reach,' but it does not need to compensate for schema gaps. Baseline 3 is appropriate.

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?

The description states a specific verb and resource: 'Read the change requests humans have addressed to YOU on their artifacts.' It defines what a review is and clearly separates this tool from review-resolve and review-reply by noting those are for closing or replying rather than listing. An agent can tell what this tool is for without needing the title or schema.

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 gives explicit triggers: 'Call this when a human says they left you comments or asked for changes, and at the start of work on an artifact you have been reviewed on before.' It also provides alternatives: 'Use review-resolve when no commit will, and review-reply to say something without closing it.' This is strong when/when-not guidance.

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.