Skip to main content
Glama

Mockbird

by dev.workers.mockbird.mockbird
OverviewDiscussionsAdmin

image_url

Mint a permanent, keyless image URL rendered by Mockbird — README badges (including LIVE record-count badges), chart images, QR codes, Open Graph cards, placeholder images, initials avatars. Deterministic: the same URL renders the same image forever (no account, no expiry, no watermark). Params are validated against the real endpoint before the URL is returned, so a returned URL is guaranteed to render. Returns {url, markdown} ready to paste into READMEs, PR comments, issues, chat, dashboards, or HTML tags. Kinds and their params: badge (SVG): {label, value, color (shields-style names like brightgreen/red/blue or hex), labelColor, style: flat|flat-square|plastic|for-the-badge|social}; label ALONE renders a message-only badge (single colored segment) — OR live mode: {resource:"products"} renders the CURRENT record count of that resource in the project (extra field:value entries filter exact-match, e.g. {resource:"orders", status:"shipped"}); re-counted on every render (~60s cache) — a README badge that tracks live mock data. chart (PNG; format:"svg" for vector): {data:"1,4,2,8" — comma-separated numbers, up to 6 pipe-separated series "1,4,2|3,5,8", type: line|area|bar|spark|pie|donut, labels:"mon,tue,wed", title, theme: light|dark}; size like "800x400". qr (PNG or svg): {data:"https://…"} — any text up to 1000 chars: URLs, WIFI:T:WPA;S:net;P:pw;; strings, mailto:, plain text; optional {ecc: L|M|Q|H, margin, fg, bg (hex, no #)}; size like "512". og (PNG at the og:image-standard 1200x630 — paste straight into ): {title (≤120 chars, wrapped), subtitle (≤200), site (footer text), logo: (deterministic identicon), theme: dark|light}. placeholder: size "300x200" (WxH, default) plus {text, bg, fg (hex, no #), seed (deterministic palette), round:1 (circle)}. avatar: {name:"Ada Lovelace"} — deterministic initials avatar. By default images render under the shared demo project; pass project: to point live badge counts at YOUR mock data.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYesWhich image to mint.
sizeNoOptional size path: "WxH" for chart/og/placeholder (e.g. "800x400"), a single number for qr (e.g. "512") or a square placeholder.
formatNoOptional. badge is always SVG; chart/qr/og/placeholder default to PNG (og/chart/qr) or SVG (placeholder/avatar) — svg forces the vector twin.
paramsNoQuery params for the endpoint (see the per-kind lists in the tool description). Values are strings or numbers (arrays of numbers join with commas). Passing these directly as top-level properties (e.g. {"kind":"badge","label":"build","value":"passing"}) works too.
projectNoOptional project id (default "demo", the shared public playground). Use your own project id so live badge counts track your data.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / params / description
      Previous value: -"Query params for the endpoint (see the per-kind lists in the tool description). Values are strings or numbers."New value: +"Query params for the endpoint (see the per-kind lists in the tool description). Values are strings or numbers (arrays of numbers join with commas). Passing these directly as top-level properties (e.g. {\"kind\":\"badge\",\"label\":\"build\",\"value\":\"passing\"}) works too."
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses determinism, no account/expiry/watermark, pre-validation against the real endpoint so a returned URL is guaranteed to render, and the exact return shape {url, markdown}. It also explains live badge behavior (re-counted on every render, ~60s cache), the message-only badge case, hex color conventions without '#', and per-kind format defaults. These are significant behavioral details beyond the schema.

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

Conciseness3/5

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

The description is a dense wall of text with heavy parenthetical chains and inline examples. Every sentence carries real content, but it lacks structural formatting (bullet-like delineation, line breaks per kind) that would aid parsing. The opening sentence front-loads the core purpose well, but the overall structure is cramped for the amount of information it conveys.

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 complex, param-rich tool with no output schema, the description is remarkably complete: it covers the return format, all six kinds with their parameter sets, format defaults, size conventions, several character limits, and the optional project scoping. It does not mention error behavior beyond the validation guarantee, but that is a minor omission given the breadth of coverage.

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 schema already describes kind, size, format, params, and project. The description adds substantial meaning to the nested params object: per-kind parameter lists, punctuation rules for chart data (commas and pipes), live-mode resource/filter syntax, QR ecc options, and text length limits. It loses a point because the massive per-kind detail is embedded in the description, making it hard to quickly extract a single canonical param list, but it clearly adds value beyond the schema.

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 names a specific verb and resource: 'Mint a permanent, keyless image URL rendered by Mockbird.' It goes on to enumerate concrete use cases (README badges, charts, QR codes, OG cards, placeholders, avatars) and states the deterministic/never-expires guarantee, which separates it from sibling tools. The main purpose is unmistakable despite the length.

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?

Each kind is paired with a usage context: badges for READMEs (including live record-count badges), charts for data visualization, QR for URLs/WIFI/mailto, og for social meta tags, placeholder for sizing, and avatar for initials. It also says when to use the shared demo project versus passing your own project id, and explains that params can be passed directly as top-level properties for convenience. This is strong practical routing guidance.

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