AnyAPI

Browse APIs

list_apis

Read-only

Browse available AnyAPI APIs as lightweight summaries (id, name, category, USD pricing) - no descriptions or schemas, so it stays cheap even across the whole catalog. Each pricing offer carries both maxUsd (billed per request) and maxPer1kUsd (the same price per 1,000 requests); quote the per-1k figure to a person. Optionally filter by category. Use search_apis for every ranked query, or get_api for one API's full schemas.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`context`	Yes	Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization."
`category`	No	optional category slug to filter by

Output Schema

TableJSON Schema

Name	Required	Description	Default
`scrapers`	Yes	matching APIs (lightweight summaries: no description or schemas)

Schema Changelog

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

Changed17 schema fields changedSep 3, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / context

Added value: +{
+  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
+  "type": "string"
+}

removedInput schema / properties / query

Removed value: -{
-  "description": "optional free-text filter over API name and description",
-  "type": "string"
-}

addedInput schema / required
```
Added value: +[
+  "context"
+]
```

removedOutput schema / properties / scrapers / items / properties / baseUsd

Removed value: -{
-  "description": "fixed cost per request in USD, charged regardless of count",
-  "type": "number"
-}

addedOutput schema / properties / scrapers / items / properties / excludesCallerDelay
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / scrapers / items / properties / execution

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "mode": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "mode"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / scrapers / items / properties / failover
```
Added value: +{
+  "type": "boolean"
+}
```

removedOutput schema / properties / scrapers / items / properties / heavy / description

Removed value: -"true when this API's responses are typically large; pass fields, max_items, or summary to run_api (and a small limit in the input) to keep the result out of your context"

addedOutput schema / properties / scrapers / items / properties / method
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / scrapers / items / properties / path
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / scrapers / items / properties / perItemUnit

Removed value: -{
-  "description": "the unit perItemUsd is charged per: 'result' (default) or an input unit like 'username' for input-priced SKUs",
-  "type": "string"
-}

removedOutput schema / properties / scrapers / items / properties / perItemUsd

Removed value: -{
-  "description": "marginal cost in USD per billable unit (see perItemUnit); total = baseUsd + perItemUsd × unitCount, capped at priceUsd",
-  "type": "number"
-}

removedOutput schema / properties / scrapers / items / properties / priceUsd

Removed value: -{
-  "description": "maximum price per request in USD (the reserved ceiling at the default limit)",
-  "type": "number"
-}

addedOutput schema / properties / scrapers / items / properties / pricing

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "failoverMaxPer1kUsd": {
+      "type": "number"
+    },
+    "failoverMaxUsd": {
+      "type": "number"
+    },
+    "from": {
+      "additionalProperties": false,
+      "properties": {
+        "baseUsd": {
+          "type": [
+            "null",
+            "number"
+          ]
+        },
+        "maxPer1kUsd": {
+          "type": "number"
+        },
+        "maxUsd": {
+          "type": "number"
+        },
+        "model": {
+          "type": "string"
+        },
+        "perUnitUsd": {
+          "type": [
+            "null",
+            "number"
+          ]
+        },
+        "unit": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "model",
+        "unit",
+        "maxUsd",
+        "maxPer1kUsd"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "from",
+    "failoverMaxUsd",
+    "failoverMaxPer1kUsd"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / scrapers / items / properties / provider
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / scrapers / items / required

Previous value: -[
-  "id",
-  "slug",
-  "category",
-  "name",
-  "priceUsd",
-  "baseUsd",
-  "perItemUsd"
-]New value: +[
+  "id",
+  "slug",
+  "category",
+  "name",
+  "method",
+  "path",
+  "provider",
+  "execution",
+  "pricing",
+  "failover"
+]

Changed1 schema field changedJul 10, 2026

addedOutput schema / properties / scrapers / items / properties / heavy

Added value: +{
+  "description": "true when this API's responses are typically large; pass fields, max_items, or summary to run_api (and a small limit in the input) to keep the result out of your context",
+  "type": "boolean"
+}

Changed5 schema fields changedJun 24, 2026

changedOutput schema / properties / scrapers / description

Previous value: -"matching APIs"New value: +"matching APIs (lightweight summaries: no description or schemas)"

removedOutput schema / properties / scrapers / items / properties / description
```
Removed value: -{
-  "type": "string"
-}
```
removedOutput schema / properties / scrapers / items / properties / inputSchema
```
Removed value: -{
-  "description": "normalized input JSON Schema"
-}
```
removedOutput schema / properties / scrapers / items / properties / outputSchema
```
Removed value: -{
-  "description": "normalized output JSON Schema"
-}
```

changedOutput schema / properties / scrapers / items / required

Previous value: -[
-  "id",
-  "slug",
-  "category",
-  "name",
-  "description",
-  "priceUsd",
-  "baseUsd",
-  "perItemUsd"
-]New value: +[
+  "id",
+  "slug",
+  "category",
+  "name",
+  "priceUsd",
+  "baseUsd",
+  "perItemUsd"
+]

First observedJun 17, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark this as read-only, and the description adds rich behavioral context: results are lightweight summaries with no descriptions/schemas to keep cost low, and pricing offers expose both maxUsd and maxPer1kUsd with guidance to quote the per-1k figure. This goes well beyond the structured annotations.

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?

Three dense sentences front-load the purpose, then add the key pricing nuance and sibling routing. Every sentence contributes information; there is no filler or repetition.

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?

Given the read-only annotation, 100% parameter coverage, and an existing output schema, the description covers the catalog scope, return format, pricing quirk, optional filtering, and when to use alternatives. Nothing needed for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with context and category already documented in the input schema. The description only restates the optional category filter and does not materially add meaning beyond the schema, so it earns the baseline 3.

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?

Description names a specific verb ('Browse available AnyAPI APIs'), a precise resource (the API catalog), and the returned summary shape (id, name, category, USD pricing). It explicitly distinguishes itself from siblings by directing ranked queries to search_apis and full schemas to get_api.

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?

Provides explicit routing: 'Use search_apis for every ranked query, or get_api for one API's full schemas.' It also states optional category filtering, leaving no ambiguity about when list_apis is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All AnyAPI 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.5/5.0

Disambiguation5/5

Each tool has a clearly distinct role: discovery (list_apis, search_apis, get_api), pricing (quote_api), execution (run_api), request/result inspection (get_request, read_result), account status (get_balance), and feedback (report_bug, send_feedback). Even the two feedback tools are cleanly separated by defect vs. non-defect.

Naming Consistency5/5

Names consistently follow a snake_case verb_noun pattern: get_api, get_balance, get_request, list_apis, quote_api, read_result, report_bug, run_api, search_apis, send_feedback. There is no mixing of conventions or vague single-word verbs.

Tool Count5/5

Ten tools is well-scoped for an API gateway/aggregator. Each tool covers a necessary phase of the workflow—discovery, schema/pricing inspection, execution, result retrieval, account balance, and user feedback—without redundancy or bloat.

Completeness4/5

The lifecycle from discovering APIs through quoting, executing, checking request status, and reading cached results is well covered. Minor gaps such as no explicit way to cancel a queued/running request or list past requests are workable but not fully closed.

Resources

Need Help?