UI Verify

Page through a build's stories by status

list_build_stories

Read-only

Page through one build's stories filtered by status (resolved by commitSha/prNumber/buildId). Use it to read past get_build's first page, or to browse the unchanged/passed stories get_build only counts. status='changed' returns changed stories (same shape + order as get_build, regression-first); status='failed' returns failed stories; status='unchanged' returns the stories that did NOT change this build but have a baseline on this branch (storyId, viewport, browser) - fetch any of their images by storyId with get_diff or render_diff_image to confirm 'identical to baseline'. Returns { stories, nextCursor }: pass nextCursor back as cursor for the next page; null means no more. limit defaults to 25 (max 100). Unchanged is only available once the build has settled (an in-progress build has rendered nothing, so it returns an empty page).

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Page size (default 25, max 100).
`cursor`	No	The nextCursor from a prior page; omit for the first page.
`status`	Yes	Which stories to page: changed, failed, or unchanged (baselined, didn't change this build).
`buildId`	No	Resolve this exact build id.
`prNumber`	No	Resolve the latest build for this PR number.
`commitSha`	No	Resolve the build for this git commit SHA.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`stories`	Yes
`nextCursor`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedSep 5, 2026

changedOutput schema / (root)

Before

null

After

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "additionalProperties": false,
  "properties": {
    "nextCursor": {
      "type": [
        "string",
        "null"
      ]
    },
    "stories": {
      "items": {
        "anyOf": [
          {
            "additionalProperties": false,
            "properties": {
              "aiClassification": {
                "type": [
                  "string",
                  "null"
                ]
              },
              "aiConfidence": {
                "type": [
                  "string",
                  "null"
                ]
              },
              "aiFlagReason": {
                "type": [
                  "string",
                  "null"
                ]
              },
              "aiIntroducedBy": {
                "type": [
                  "string",
                  "null"
                ]
              },
              "aiSummary": {
                "type": [
                  "string",
                  "null"
                ]
              },
              "aiVerdict": {
                "type": [
                  "string",
                  "null"
                ]
              },
              "browser": {
                "type": "string"
              },
              "changedPct": {
                "type": [
                  "number",
                  "null"
                ]
              },
              "decision": {
                "type": [
                  "string",
                  "null"
                ]
              },
              "diffResultId": {
                "format": "uuid",
                "type": "string"
              },
              "isNew": {
                "type": "boolean"
              },
              "name": {
                "type": "string"
              },
              "storyId": {
                "type": "string"
              },
              "title": {
                "type": "string"
              },
              "unstable": {
                "type": "boolean"
              },
              "viewport": {
                "type": "string"
              }
            },
            "required": [
              "diffResultId",
              "storyId",
              "title",
              "name",
              "viewport",
              "browser",
              "changedPct",
              "decision",
              "isNew",
              "unstable",
              "aiVerdict",
              "aiClassification",
              "aiIntroducedBy",
              "aiConfidence",
              "aiSummary",
              "aiFlagReason"
            ],
            "type": "object"
          },
          {
            "additionalProperties": false,
            "properties": {
              "browser": {
                "type": "string"
              },
              "error": {
                "type": "string"
              },
              "errorTruncated": {
                "type": "boolean"
              },
              "kind": {
                "enum": [
                  "render",
                  "interaction"
                ],
                "type": "string"
              },
              "name": {
                "type": "string"
              },
              "storyId": {
                "type": "string"
              },
              "title": {
                "type": "string"
              },
              "viewport": {
                "type": "string"
              }
            },
            "required": [
              "storyId",
              "title",
              "name",
              "viewport",
              "browser",
              "error",
              "errorTruncated",
              "kind"
            ],
            "type": "object"
          },
          {
            "additionalProperties": false,
            "properties": {
              "browser": {
                "type": "string"
              },
              "storyId": {
                "type": "string"
              },
              "viewport": {
                "type": "string"
              }
            },
            "required": [
              "storyId",
              "viewport",
              "browser"
            ],
            "type": "object"
          }
        ]
      },
      "type": "array"
    }
  },
  "required": [
    "stories",
    "nextCursor"
  ],
  "type": "object"
}

First observedSep 5, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true, and the description is fully consistent with that read-only profile. It adds rich behavior beyond the annotations: per-status return semantics (changed = regression-first, same shape/order as get_build), the cursor contract (pass nextCursor back as the cursor; null terminates), the limit default/max (25/100), and the edge case that unchanged returns an empty page for in-progress builds.

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?

At roughly 120 words, the description follows a strict logical order: purpose, when-to-use, per-status semantics, pagination mechanics, defaults, then the in-progress edge case. Every clause carries operational value and nothing restates the title or schema.

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?

For a 6-parameter pagination tool with three behaviorally distinct status modes, this description covers cursor flow, defaults, the build-settling prerequisite, and cross-tool follow-up. Since an output schema exists and annotations cover safety, nothing an agent needs to call it correctly is left to guesswork.

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 rubric baseline is 3; the description earns a 4 by adding relational meaning not in the schema: the three resolver params are presented as equivalent ways to select the build, and the status values are explained behaviorally (regression-first ordering, 'did NOT change this build but have a baseline' for unchanged).

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 ('Page through'), a bounded resource ('one build's stories'), and the filtering dimension ('by status'), while naming the resolution mechanism (commitSha/prNumber/buildId). It also distinguishes itself from the closest sibling by explicitly referencing get_build's first-page limitation.

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?

The description explicitly frames when to choose this tool: use it to read past get_build's first page, or to browse the unchanged/passed stories get_build only counts. It also routes follow-up image confirmation to get_diff or render_diff_image, giving the agent a complete decision path.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All UI Verify tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

Each tool targets a distinct concern: list vs get vs pagination, build triage vs PR changeset, diff URL vs inline pixels, single-review vs bulk-accept. The descriptions explicitly call out the differences between similar-sounding tools, so an agent can reliably choose the right one.

Naming Consistency5/5

All tool names follow a consistent lowercase verb_noun pattern: get_* for single entities, list_* for collections, and review_diff/accept_build for actions. There are no mixed conventions or vague verbs.

Tool Count5/5

Nine tools fit the visual regression review workflow well: discovery, triage, pagination, image inspection, and reviewing. Each tool fills a distinct role without redundancy, and the count is in the sweet spot for an agent to keep all tool purposes in context.

Completeness5/5

The surface covers the full review lifecycle: find builds, triage changed/failed/unchanged stories, paginate, inspect diffs as URLs or inline images, review per-diff, and bulk-accept an entire build. The PR-changeset tools also cover cross-PR questions and deletion cases that would otherwise be dead ends.

Resources

Need Help?