Skip to main content
Glama

Mockbird

by dev.workers.mockbird.mockbird

check_api_status

Live status of ~58 public mock/testing APIs — JSONPlaceholder, httpbin.org, ReqRes, FakeStoreAPI, DummyJSON, Postman Echo, httpstat.us, Mocky, Mockbin, CrudCrud, restcountries, and more — checked with a plain keyless GET every 30 minutes from Cloudflare's network (a service answering HTTP 200 error envelopes is probed by body and honestly reported as failing). No arguments → compact summary: up/down counts plus full detail for every failing service. Pass service (id, name, or hostname substring — e.g. "httpbin", "reqres.in") for one service's detail: latest check, last_success_at, down_since, 24h/7d uptime, note, recent check history. Use it before pointing tests or tutorials at a public API — and if it's down, the result links a Mockbird alternative guide plus the one-call hosted mock replacement.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
serviceNoService id, name, or hostname substring (e.g. httpbin, reqres.in). Optional — omit for the summary.

Schema Changelog

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

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden and does so thoroughly. It discloses the keyless GET method, 30-minute check frequency, Cloudflare network origin, body-based failure detection, and honest reporting behavior. It also explains the summary vs. single-service detail output, including fields like down_since and 24h/7d uptime.

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 long but dense and well-structured: scope, method, frequency, no-argument behavior, single-service behavior, and use case all appear in logical order. Every sentence adds practical information, and the examples are illustrative rather than filler.

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 one-optional-parameter tool with no output schema and no annotations, the description is remarkably complete. It covers authentication, frequency, result contents for both invocation modes, failure semantics, and even expected follow-up guidance when a service is down. Nothing essential for calling the tool correctly is missing.

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 semantics: the parameter accepts id, name, or hostname substring, gives concrete examples like 'httpbin' and 'reqres.in', and clarifies that omitting it returns the summary. This goes beyond the schema's already good description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb+resource: it checks the live status of ~58 public mock/testing APIs, listing concrete examples like JSONPlaceholder and httpbin.org. It is unambiguous about what the tool does, though it does not explicitly contrast itself with sibling tools such as watch_service_status or 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear usage context: 'Use it before pointing tests or tutorials at a public API.' It also explains what happens when a service is down, linking alternatives. However, it does not explicitly say when not to use this tool or mention sibling alternatives, so it stops short of full 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
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