RealWorldAPIs

Measured conclusion: Deep-tested. L2 outcome: tools_ok.

Evidence-first registry of real-world APIs for AI agents, with verified metadata and comparison.

Add to your agent

Copy this into your MCP client config:

{
  "mcpServers": {
    "RealWorldAPIs": {
      "url": "https://mcp.realworldapis.com/mcp",
      "transport": "streamable-http"
    }
  }
}

Measured tools (6)

• find_api_for_task read-only

  Find the best APIs for a natural-language physical-world task. Use this for open-ended task or outcome-based recommendations; use search_apis when you already know exact filters, get_api for one known API, or compare_apis for known candidates. Returns an authoritative canonical structured_results shortlist plus a best-effort AI comparison restricted to that shortlist. The canonical engine now applies Verified/High capability evidence before ranking: explicit hard requirements expressed with terms such as must, required, no or without can exclude a candidate only when verified evidence contradicts them. Unknown evidence remains eligible and is surfaced as uncertainty. requirements.mcp, openapi and auth are translated into explicit requirements; categories and capabilities remain task-shaping hints. free_tier and min_readiness are accepted for compatibility but are not hard filters.

  Parameters:

  • task (required) — string — Required natural-language goal or workflow, for example 'connect to a car and predict weather on the route'. Describe the desired outcome rather than naming a specific API.
  • limit — integer — Backward-compatible parameter. The canonical browser-parity workflow always produces five structured candidates before the AI comparison, even when another value is supplied.
  • requirements — object — Optional task requirements appended before canonical ranking. categories and capabilities shape task intent. mcp=Yes, openapi=Yes and auth are expressed as hard task requirements and are evaluated against verified evidence; Unknown does not count as a confirmed contradiction and remains eligible with an uncertainty. free_tier and min_readiness are accepted for backward compatibility but are not hard filters.

  Hints: read-only yes · destructive no · idempotent no · open-world no

• search_apis read-only

  Search the canonical registry when you already know keywords or exact requirements. All supplied filter groups combine with AND logic; array capability filters require every supplied value, and protocol fields match the exact Yes/No/Unknown status, so Unknown never satisfies Yes. Results include each API's capability_summary and direct decision-profile URL. Results are sorted by agent_readiness_score descending and then API name, with 1–20 results returned (default 10). Use search_capabilities when you need capability-level filters such as approval, physical consequence, sandbox or access friction.

  Parameters:

  • a2a — string — Exact A2A evidence status required for a match.
  • mcp — string — Exact MCP evidence status required for a match.
  • x402 — string — Exact x402 evidence status required for a match.
  • limit — integer — Maximum number of matching records returned. Results are sorted by readiness descending then API name. total_matches still reports the full count. No pagination is currently exposed.
  • query — string — Optional case-insensitive text search across API name, provider, category, description, capabilities, agent capabilities and authentication fields.
  • openapi — string — Exact OpenAPI evidence status required for a match.
  • llms_txt — string — Exact llms.txt evidence status required for a match.
  • categories — array — Exact category names. Supplying multiple category values allows a record to match any listed category; this category condition still combines with every other supplied filter group using AND logic.
  • capabilities — array — Capability terms that must all be present in the record's verified capabilities. Matching is case-insensitive and allows a capability string to contain the supplied term.
  • min_readiness — integer — Strict minimum agent-readiness score. Records below this score are excluded.
  • agent_actionable — boolean — When true, require agent_actionable = true. False does not exclude actionable records; omit this field unless you need the positive requirement.
  • agent_capabilities — array — Agent capability dimensions that must all be explicitly present on a record.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• search_capabilities read-only

  Search the canonical 770-capability Verified/High decision graph directly. Use this when the question is about what an agent can actually do and under what execution conditions: task/capability text, API, category, action type, acted-on object, human approval, physical consequence, irreversibility, sandbox, hardware dependency, access friction or setup. All supplied filter groups combine with AND logic; multiple values inside one array filter are alternatives (OR). Unknown remains Unknown and may be filtered explicitly by passing the literal value Unknown.

  Parameters:

  • limit — integer — Maximum capability rows returned. total_matches reports the full match count.
  • query — string — Optional case-insensitive text search across API/provider/category, capability key/name, primitive/action type, object, execution fields and constraints. Search terms may match across different capability fields; all supplied terms must be present somewhere in the capability record.
  • object — string — Case-insensitive substring match on the object acted upon, such as smart lock, parcel or charging session.
  • sandbox — array — Exact sandbox/test-environment labels, including Unknown when desired.
  • api_slugs — array — Optional API slugs. Multiple values are OR within this filter.
  • categories — array — Exact category labels. Multiple values are OR within this filter.
  • primitives — array — Exact capability primitives such as Observe, Locate, Predict, Plan, Control or Act.
  • agent_setup — array — Exact agent-setup labels such as Fully self-service or Human setup required.
  • action_types — array — Exact action types such as Read, Search, Analyze, Route or Control.
  • actionability — array — Exact actionability labels such as Information only, Planning or Physical action.
  • human_approval — array — Exact approval labels, for example Required, Not required, Depends on action or Unknown.
  • access_friction — array — Exact access-friction labels such as Self-service signup, Sales contract or Hardware ecosystem.
  • hardware_dependency — array — Exact hardware-dependency labels.
  • physical_consequence — boolean — When supplied, require the exact physical-consequence boolean.
  • irreversible_high_consequence — boolean — When supplied, require the exact irreversible/high-consequence boolean.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• verify_requirement read-only

  Verify whether one specific API can satisfy one exact requirement using the canonical Verified/High capability graph plus linked assertion evidence. Returns YES, NO, PARTIAL or UNKNOWN with matched capability, access/setup prerequisites, approval, safety, reversibility, reliability, coverage and other requested dimensions; direct provider facts remain distinct from inferred policy assertions. Unknown remains Unknown.

  Parameters:

  • api (required) — string — Exact API slug or API name, for example nuki-web-api or Nuki Web API.
  • requirement (required) — string — Specific requirement to verify, for example 'remotely unlock a smart lock without human approval'.
  • location — string — Optional geographic coverage requirement, for example Sweden. Coverage is returned as Unknown/Partial when the normalized capability graph does not contain enough location evidence.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_api read-only

  Retrieve one canonical API decision profile when you already know its name or slug. The response includes the full Verified/High capability profile with execution, access, approval, reversibility, physical-consequence and evidence fields. Exact slug or exact API name is preferred; a partial identifier is accepted only when it uniquely resolves to one record.

  Parameters:

  • identifier (required) — string — Required API slug or API name. Exact matches are preferred; a unique case-insensitive partial slug/name match is accepted. If it is ambiguous or missing, use search_apis to find the exact identifier.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• compare_apis read-only

  Compare 2–8 already-known APIs side by side using canonical catalog fields plus capability-graph summary fields such as verified capability count, physical consequences, approval relevance and irreversibility. Use get_api for the full decision profile of one API and search_capabilities for capability-level filtering. No missing value is inferred and Unknown remains Unknown.

  Parameters:

  • apis (required) — array — Required list of 2–8 API slugs or names. Exact matches are preferred; unique partial matches are accepted. Unresolved identifiers are reported separately, and the call fails if fewer than two records resolve.
  • fields — array — Optional fields to compare. The default includes core catalog fields plus verified capability count, physical-consequence count, approval-relevant count, irreversible/high-consequence count and the decision-profile URL.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

Repository

Measured by MCPYP probing. Untested fields are omitted, never estimated. Listing is always free; MCPYP never proxies calls or stores user tokens.