Skip to main content
Glama

Mockbird

by dev.workers.mockbird.mockbird
OverviewDiscussionsAdmin

import_data

Create a live mock API from existing artifacts. Auto-detects: OpenAPI 3.x / Swagger 2.0 spec (JSON or YAML) → resources with realistic seeded data, and non-CRUD paths (login, /search, RPC verbs like POST /invoices/{id}/send) become custom routes serving the spec's own examples verbatim; json-server db.json → hosts your exact records; Postman Collection v2.x → resources from requests, saved example responses become records verbatim; HAR (DevTools network export) or VCR/vcrpy cassette YAML → replayable mock of the recorded JSON APIs (these two up to 8 MB); bare JSON array of objects → one hosted collection; CSV/TSV → one typed collection (numbers/booleans inferred per column). Max 512 KB (HAR/cassette 8 MB). Returns {id, adminKey, baseUrl, warnings[], routes[]}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ttlNoOptional: self-expiring project — auto-deletes after this many seconds (60–604800). Sandboxes for CI/eval runs clean themselves up.
nameNoProject name override. Optional.
seedNoRecords to seed per resource for OpenAPI specs (default 20, max 100).
contentYesThe raw spec / db.json / collection / CSV text.
resourceNoCSV only: collection name (default items).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / ttl
      Added value: +{
+  "description": "Optional: self-expiring project — auto-deletes after this many seconds (60–604800). Sandboxes for CI/eval runs clean themselves up.",
+  "type": "number"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses size limits (512 KB, 8 MB for HAR/cassette), auto-detection behavior, how different formats are handled, seeding defaults, and the exact response shape ({id, adminKey, baseUrl, warnings[], routes[]}). This is highly transparent about what happens when invoked.

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 dense but well-organized with a semicolon-separated list of formats. It front-loads the primary purpose and uses specific details. It could be slightly more scannable as bullet points, but it avoids redundancy and every clause contributes information.

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 tool with 5 parameters, multiple input formats, and no output schema, the description is remarkably complete. It covers format behavior, size limits, seeding, response structure, and even hints at error handling via warnings[]. An agent has enough information to call it correctly.

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 100%, so baseline is 3. The description adds value by specifying that 'seed' applies only to OpenAPI specs and 'resource' is CSV-only, which clarifies parameter usage beyond the schema's generic descriptions. It also explains that 'content' can be multiple formats, enriching the meaning.

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 ('Create a live mock API from existing artifacts') and enumerates supported formats (OpenAPI, Swagger, json-server db.json, Postman Collection, HAR, VCR, bare JSON, CSV/TSV). This clearly distinguishes it from siblings like create_project or generate_fake_data, which are about creation/generation rather than importing.

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 implies when to use it (when you have existing artifacts) but does not explicitly name alternatives or exclusions. However, the format list and behavior make the intended usage clear, and it differentiates from siblings by focusing on importing rather than building from scratch.

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

All Mockbird toolsInspect
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