Mockbird

watch_service_status

Subscribe to down/recovered alerts for any of the public mock/testing APIs tracked by check_api_status (httpbin, JSONPlaceholder, ReqRes, FakeStoreAPI, DummyJSON …). action:"subscribe" {service, notify?}: service is an id from check_api_status (or "*" for all tracked services). With notify, that webhook gets one message when the service goes down and one when it recovers (debounced across two consecutive hourly checks — blips never fire; a confirmation message is delivered immediately so you can see the wiring works). WITHOUT notify you get a pollable subscription instead — no webhook needed. Returns {id, secret} — store both. action:"poll" {id, secret}: (webhook-less watches) returns the down/recovered transitions since your last poll — empty events = nothing changed; checks run hourly so polling more often sees nothing new. action:"info" {id, secret}: subscription state. action:"unsubscribe" {id, secret}: stop alerts. notify formats: Slack/Discord webhooks get native payloads; anything else gets HMAC-signed JSON. Limits: 5 live watches per IP — deleting one frees the slot immediately. To watch YOUR OWN URL instead, use uptime_monitor.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	poll/info/unsubscribe: the watch id (w…) returned by subscribe.
`action`	Yes	What to do.
`notify`	No	subscribe (optional): webhook URL to alert (Slack/Discord webhook, or any HTTPS endpoint — gets HMAC-signed JSON). Omit it to get a pollable subscription instead.
`secret`	No	poll/info/unsubscribe: the secret returned by subscribe.
`service`	No	subscribe: service id from check_api_status (e.g. "reqres", "httpbin"), or "*" for all tracked services.

Schema Changelog

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

First observedSep 6, 2026

TDQS

A4.9/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 full burden, and it delivers rich detail: debouncing across two consecutive hourly checks (blips never fire), immediate confirmation message, HMAC-signed JSON for non-Slack/Discord webhooks, native payloads for Slack/Discord, hourly polling cadence, 5 live watches per IP with immediate slot release, and the need to store both id and secret.

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?

The description is dense but well-structured: it leads with the core purpose, then organizes the actions explicitly (action:'subscribe', action:'poll', action:'info', action:'unsubscribe'), then covers notify formats and limits, and ends with a pointer to the sibling. No filler sentences.

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 multi-action tool with no annotations and no output schema, the description is unusually complete: it covers all actions, return values ({id, secret}, events, state), webhook formats, debouncing, rate limits, and alternatives. An agent can invoke it correctly without additional information.

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 baseline is 3, but the description adds meaningful context beyond the schema: it explains that service is an id from check_api_status or '*', that notify can be omitted for a pollable subscription, and that id/secret must be stored. It doesn't fully describe the semantics of action beyond the enum, but the schema already covers that.

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 uses a clear verb ('Subscribe to down/recovered alerts') and explicitly names the resource (public mock/testing APIs tracked by check_api_status) with concrete examples. It also distinguishes itself from the sibling uptime_monitor by stating 'To watch YOUR OWN URL instead, use uptime_monitor.'

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 explains when to use this tool vs the alternative: it is for public mock/testing APIs, while uptime_monitor is for your own URL. It also details four actions (subscribe, poll, info, unsubscribe) with clear conditions, including when to omit notify for a pollable subscription.

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

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.2/5.0

Disambiguation5/5

Every tool targets a distinct resource or action: project creation, data seeding, record CRUD, traffic inspection, snapshots, and monitoring are all clearly separated. The four monitoring-related tools are carefully differentiated with cross-references, so an agent is unlikely to misselect.

Naming Consistency3/5

Most data and lifecycle tools follow a clear verb_noun pattern (add_resource, create_project, query_records, write_record), but several tools use noun phrases instead (heartbeat, snapshots, project_info, uptime_monitor, custom_route). The split is readable but not a consistent convention.

Tool Count5/5

14 tools is a reasonable, well-scoped size for a combined mock-API platform and monitoring utility. Each tool has a distinct job, and the monitoring tools complement the mock-API lifecycle tools without feeling redundant.

Completeness4/5

The toolset covers project creation/deletion, resource seeding, record CRUD, request inspection, snapshots, and external API monitoring. Minor gaps exist: resources can be added but not individually removed/updated, and custom routes have no delete or update path.

Resources

Need Help?