Mockbird

snapshots

Deterministic test fixtures + eval grading: save the project's entire dataset under a name, restore it exactly later, or DIFF it against live data (list/delete too). action:"diff" is machine-checkable grading — compares the named snapshot (expected) against live data (actual, or another snapshot via against) and returns {identical, summary, resources[] with per-record added/removed/changed field detail}: author an answer-key snapshot, let the agent work the fork, then assert .identical. Any GET can also be served read-only FROM a snapshot without touching live data via query param mock_snapshot= in query_records params — parallel test scenarios on one project.

Input Schema

TableJSON Schema

Name	Required	Description
`data`	No	save only, optional: AUTHOR the snapshot inline instead of capturing live state — {"tasks":[{...records...}],"labels":[]} (records verbatim, ids preserved, [] = expected-empty, new resource names allowed). Author an eval answer key, then grade with the diff endpoint.
`name`	No	Snapshot name (required for restore/delete/diff; default for save: snapshot-<n>).
`action`	Yes
`ignore`	No	diff only, optional: comma-separated field names excluded from comparison (volatile timestamps etc.), e.g. "updatedAt,id".
`against`	No	diff only, optional: compare the named snapshot against THIS other snapshot instead of live data.
`project`	Yes
`adminKey`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 9, 2026

changedInput schema / properties / action / enum

Previous value: -[
-  "save",
-  "list",
-  "restore",
-  "delete"
-]New value: +[
+  "save",
+  "list",
+  "restore",
+  "delete",
+  "diff"
+]

addedInput schema / properties / against

Added value: +{
+  "description": "diff only, optional: compare the named snapshot against THIS other snapshot instead of live data.",
+  "type": "string"
+}

addedInput schema / properties / ignore

Added value: +{
+  "description": "diff only, optional: comma-separated field names excluded from comparison (volatile timestamps etc.), e.g. \"updatedAt,id\".",
+  "type": "string"
+}

changedInput schema / properties / name / description

Previous value: -"Snapshot name (required for restore/delete; default for save: snapshot-<n>)."New value: +"Snapshot name (required for restore/delete/diff; default for save: snapshot-<n>)."

Changed1 schema field changedSep 9, 2026

addedInput schema / properties / data

Added value: +{
+  "description": "save only, optional: AUTHOR the snapshot inline instead of capturing live state — {\"tasks\":[{...records...}],\"labels\":[]} (records verbatim, ids preserved, [] = expected-empty, new resource names allowed). Author an eval answer key, then grade with the diff endpoint.",
+  "type": "object"
+}

First observedSep 6, 2026

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that snapshots are deterministic, restore is exact, and diff returns a structured result ({identical, summary, resources[]}). However, it does not explicitly state the side effects of restore (overwriting live data) or delete, or any authorization requirements. These are significant for a mutation-capable tool.

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 front-loaded with the core purpose and then elaborates on diff and mock usage. While it is longer than two sentences, every sentence adds value—no fluff or repetition of schema details. The structure could be tightened, but it remains readable and focused.

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?

Given the tool's complexity (7 parameters, multiple actions, nested data), the description covers the major concepts: snapshot naming, diff grading, and read-only serving via mock_snapshot. It doesn't mention error handling, permission prerequisites, or the exact behavior of restore beyond 'exact', but the coverage is adequate for an agent to understand how to use the tool.

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 description coverage is 57%, so the description must add meaning. It explains the diff action's return structure and the mock_snapshot query param usage, which complement the schema's per-parameter notes (data, name, ignore, against). It also clarifies the workflow for authoring inline data. This goes beyond the schema's plain descriptions.

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 clearly states the tool's purpose: saving, restoring, diffing, listing, and deleting project dataset snapshots. It uses specific verbs and a resource ('project's entire dataset'), and it distinguishes itself from siblings by framing snapshots as deterministic test fixtures and eval grading rather than live data operations.

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 provides concrete usage scenarios: authoring answer-key snapshots, grading via diff, and serving GETs from snapshots via mock_snapshot in query_records. It explains the diff workflow and parallel test scenarios, but it doesn't explicitly state when to avoid this tool or name alternative tools that might be better for live operations.

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

All Mockbird tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?