# RealWorldAPIs

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

- name: com.realworldapis/realworldapis
- version: 3.0.1
- connection class: R0 (autonomous)
- trust: 92/100
- quality: 84/100 (good)
- owner: not claimed
- descriptor: https://api.protogrid.dev/v1/servers/com.realworldapis%2Frealworldapis
- tools: https://api.protogrid.dev/v1/servers/com.realworldapis%2Frealworldapis/tools

**An agent can connect right now, no human step.** Remote endpoint, no authentication, reachable on the last probe.

## Connection (mcpServers)

```json
{
  "mcpServers": {
    "realworldapis": {
      "type": "http",
      "url": "https://mcp.realworldapis.com/mcp"
    }
  }
}
```


## Trust

- hygiene: 100
- liveness: 99
- freshness: 100
- provenance: 75
- drivers: +repository +dns-namespace +reachable +uptime-98% +updated-23d-ago
- Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed.

## Quality 84/100 (good)

### protocol: 100 (weight 25)

- pass `protocol.modern`: supports 2026-07-28 (server/discover)
- pass `protocol.stateless`: answers without a session
- pass `protocol.transport`: streamable HTTP
- pass `protocol.list_ttl`: tool list is cacheable (ttlMs 3600000)

### authorization: n/a (weight 15)

- n/a `auth.prm`, `auth.as_metadata`, `auth.cimd`: no remote uses OAuth
- n/a `auth.secret_in_url`: no templated URL

### tool hygiene: 100 (weight 30)

- pass `tools.descriptions`: every tool has a description
- pass `tools.description_length`: descriptions are concise
- pass `tools.schemas`: every tool has an object input schema
- pass `tools.annotations`: 6 of 6 tools declare readOnlyHint or destructiveHint
- pass `tools.directory_hints`: every tool declares readOnlyHint, destructiveHint, idempotentHint and openWorldHint
- pass `tools.token_cost`: about 3,356 tokens to load every tool
- pass `tools.api_dump`: tools are not a one-to-one API dump

### stability: 25 (weight 15)

- warn `stability.changes`: 17 tool changes in 30 days
- fail `stability.rug_pull`: 8 tools kept their name but changed most of their description in 30 days; review before trusting them

### dependencies: n/a (weight 15)

- n/a `deps.known_vulns`, `deps.mcp_sdk_version`, `deps.resolvable`: no npm or PyPI package

- tools: 6, about 3,356 tokens to load them all
- tool set hash: 107a3cc033bf1b4ff548edd79c4bd6fb
- tools last changed: 2026-09-30T14:04:53.642Z
- badge: [![protogrid quality](https://protogrid.dev/badge/com.realworldapis/realworldapis.svg)](https://protogrid.dev/servers/com.realworldapis/realworldapis)
- Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed.

### Tool changes

- 2026-09-30 `verify_requirement` added
  - 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.
- 2026-09-30 `search_capabilities` changed (inputSchema)
- 2026-09-30 `compare_apis` changed (description, inputSchema, outputSchema) **meaning changed**
  - before: Compare 2–8 already-known APIs side by side using only canonical RealWorldAPIs fields. Use this after find_api_for_task or search_apis has produced candidates; use get_api when only one record is needed. If fields is omitted, the tool returns the default core comparison fields: provider, category, capabilities, agent capabilities, authentication, protocol statuses, readiness and verification/actionability fields, excluding long description and URLs. Unresolved names/slugs are listed in unresolved; at least two identifiers must resolve. No missing value is inferred and Unknown remains Unknown.
  - after: 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.
- 2026-09-30 `get_api` changed (description, outputSchema) **meaning changed**
  - before: Retrieve one canonical verified API record when you already know its name or slug. Exact slug or exact API name is preferred; a partial identifier is accepted only when it uniquely resolves to one record. Missing or ambiguous identifiers return an error directing the agent to search_apis. Use compare_apis instead when you want fields from multiple known APIs.
  - after: 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.
- 2026-09-30 `search_capabilities` added
  - 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.
- 2026-09-30 `search_apis` changed (description, outputSchema)
  - before: 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 are sorted by agent_readiness_score descending and then API name, with 1–20 results returned (default 10); total_matches reports the complete match count and there is no pagination. Use find_api_for_task for open-ended task recommendations, get_api for one known API, and compare_apis for side-by-side inspection.
  - after: 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.
- 2026-09-30 `find_api_for_task` changed (description, inputSchema)
  - before: 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 browser-parity flow always returns five structured candidates: limit is retained only for backward compatibility. requirements.categories, capabilities, mcp, openapi and auth are added as task hints; free_tier and min_readiness are accepted for compatibility but are not hard filters. Unknown remains Unknown.
  - after: 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.
- 2026-09-27 `compare_apis` changed (description, inputSchema, outputSchema) **meaning changed**
  - before: Compare two to eight canonical RealWorldAPIs records side by side using only verified catalog fields. No missing field is inferred.
  - after: Compare 2–8 already-known APIs side by side using only canonical RealWorldAPIs fields. Use this after find_api_for_task or search_apis has produced candidates; use get_api when only one record is needed. If fields is omitted, the tool returns the default core comparison fields: provider, category, capabilities, agent capabilities, authentication, protocol statuses, readiness and verification/actionability fields, excluding long description and URLs. Unresolved names/slugs are listed in unresolved; at least two identifiers must resolve. No missing value is inferred and Unknown remains Unknown.
- 2026-09-27 `get_api` changed (description, inputSchema, outputSchema) **meaning changed**
  - before: Retrieve one canonical verified RealWorldAPIs record by exact slug or API name. A unique partial match is accepted.
  - after: Retrieve one canonical verified API record when you already know its name or slug. Exact slug or exact API name is preferred; a partial identifier is accepted only when it uniquely resolves to one record. Missing or ambiguous identifiers return an error directing the agent to search_apis. Use compare_apis instead when you want fields from multiple known APIs.
- 2026-09-27 `search_apis` changed (description, inputSchema, outputSchema) **meaning changed**
  - before: Search and filter the canonical RealWorldAPIs registry using verified catalog fields only. Multiple supplied filters use AND logic. Unknown never satisfies a Yes filter.
  - after: 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 are sorted by agent_readiness_score descending and then API name, with 1–20 results returned (default 10); total_matches reports the complete match count and there is no pagination. Use find_api_for_task for open-ended task recommendations, get_api for one known API, and compare_apis for side-by-side inspection.

Full history: https://api.protogrid.dev/v1/servers/com.realworldapis%2Frealworldapis/changes

## Remotes

- https://mcp.realworldapis.com/mcp (streamable-http, auth none, reachable true, uptime30d 0.9777778)

## Packages

_none_

## Tools (6)

- `compare_apis`: 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.
- `find_api_for_task`: 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.
- `get_api`: 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.
- `search_apis`: 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.
- `search_capabilities`: 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.
- `verify_requirement`: 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.