Skip to main content
Glama

AnyAPI

by io.github.getanyapi-com

Search APIs

search_apis
Read-only

Search APIs by meaning and keyword across name, slug, and description, returning matches WITH their descriptions (schemas omitted), ranked most relevant first. Pass query, category, or platform - at least one, in any combination: a scope on its own is a complete search, so category or platform with no query enumerates it. Add limit to cap matches (default 25, maximum 50). Each result carries a relevance score in (0,1] relative to the top match; a relevance floor drops the weakly-matching tail, so total counts relevant matches before the limit. ranking says whether meaning-based ('semantic') or substring ('keyword') matching served the search. Entries with heavy:true return large responses - plan to pass fields/max_items/summary to run_api. Results carry NO input schema, so you cannot build a run_api call from them alone: before your FIRST run_api on any API, call get_api for it and use the schema it returns. Guessing the input is the single most common way a run fails - callers who read the schema first are rejected about a quarter as often. Use list_apis to browse everything.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNooptional cap on matches returned (default 25, maximum 50)
queryNofree-text search over API name, slug, and description; optional when category or platform is given
contextYesExplain 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."
categoryNooptional category slug to narrow the search
platformNooptional API slug prefix to narrow the search

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
totalYes
rankingYes
resultsYes

Schema Changelog

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

  1. Changed2 schema fields changed
    • changedInput schema / properties / query / description
      Previous value: -"free-text search over API name, slug, and description"New value: +"free-text search over API name, slug, and description; optional when category or platform is given"
    • changedInput schema / required
      Previous value: -[
-  "query",
-  "context"
-]New value: +[
+  "context"
+]
  2. Changed24 schema fields changed
    • 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"
+}
    • changedInput schema / properties / limit / description
      Previous value: -"optional cap on matches returned (default 25); 'total' reports how many relevant matches there were before the cap"New value: +"optional cap on matches returned (default 25, maximum 50)"
    • addedInput schema / properties / platform
      Added value: +{
+  "description": "optional API slug prefix to narrow the search",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "query"
-]New value: +[
+  "query",
+  "context"
+]
    • removedOutput schema / properties / ranking / description
      Removed value: -"'semantic' when meaning-based ranking served this search, 'keyword' when it fell back to substring matching (relevance is coarser)"
    • removedOutput schema / properties / results / description
      Removed value: -"matching APIs with descriptions (schemas omitted), most relevant first"
    • removedOutput schema / properties / results / items / properties / baseUsd
      Removed value: -{
-  "description": "fixed cost per request in USD, charged regardless of count",
-  "type": "number"
-}
    • addedOutput schema / properties / results / items / properties / excludesCallerDelay
      Added value: +{
+  "type": "boolean"
+}
    • addedOutput schema / properties / results / items / properties / execution
      Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "mode": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "mode"
+  ],
+  "type": "object"
+}
    • addedOutput schema / properties / results / items / properties / failover
      Added value: +{
+  "type": "boolean"
+}
    • removedOutput schema / properties / results / 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"
    • removedOutput schema / properties / results / items / properties / inputSchema
      Removed value: -{
-  "description": "normalized input JSON Schema"
-}
    • addedOutput schema / properties / results / items / properties / method
      Added value: +{
+  "type": "string"
+}
    • removedOutput schema / properties / results / items / properties / outputSchema
      Removed value: -{
-  "description": "normalized output JSON Schema"
-}
    • addedOutput schema / properties / results / items / properties / path
      Added value: +{
+  "type": "string"
+}
    • removedOutput schema / properties / results / 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 / results / 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 / results / items / properties / priceUsd
      Removed value: -{
-  "description": "maximum price per request in USD (the reserved ceiling at the default limit)",
-  "type": "number"
-}
    • addedOutput schema / properties / results / 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 / results / items / properties / provider
      Added value: +{
+  "type": "string"
+}
    • changedOutput schema / properties / results / items / properties / relevance / description
      Previous value: -"relative relevance in (0,1], 1.0 = the best match in this response; comparable only within this response"New value: +"relative relevance in (0,1], 1.0 = the best match"
    • changedOutput schema / properties / results / items / required
      Previous value: -[
-  "id",
-  "slug",
-  "category",
-  "name",
-  "description",
-  "priceUsd",
-  "baseUsd",
-  "perItemUsd",
-  "relevance"
-]New value: +[
+  "id",
+  "slug",
+  "category",
+  "name",
+  "description",
+  "method",
+  "path",
+  "provider",
+  "execution",
+  "pricing",
+  "failover",
+  "relevance"
+]
    • removedOutput schema / properties / total / description
      Removed value: -"number of relevant matches (after the relevance floor), before the limit cap - if this is large, narrow your query"
  3. Changed8 schema fields changed
    • changedInput schema / properties / limit / description
      Previous value: -"optional cap on matches returned (default 25); 'total' reports how many matched before the cap"New value: +"optional cap on matches returned (default 25); 'total' reports how many relevant matches there were before the cap"
    • addedOutput schema / properties / ranking
      Added value: +{
+  "description": "'semantic' when meaning-based ranking served this search, 'keyword' when it fell back to substring matching (relevance is coarser)",
+  "type": "string"
+}
    • changedOutput schema / properties / results / description
      Previous value: -"matching APIs with descriptions (schemas omitted)"New value: +"matching APIs with descriptions (schemas omitted), most relevant first"
    • addedOutput schema / properties / results / 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"
+}
    • addedOutput schema / properties / results / items / properties / relevance
      Added value: +{
+  "description": "relative relevance in (0,1], 1.0 = the best match in this response; comparable only within this response",
+  "type": "number"
+}
    • changedOutput schema / properties / results / items / required
      Previous value: -[
-  "id",
-  "slug",
-  "category",
-  "name",
-  "description",
-  "priceUsd",
-  "baseUsd",
-  "perItemUsd"
-]New value: +[
+  "id",
+  "slug",
+  "category",
+  "name",
+  "description",
+  "priceUsd",
+  "baseUsd",
+  "perItemUsd",
+  "relevance"
+]
    • changedOutput schema / properties / total / description
      Previous value: -"number of APIs that matched before the limit was applied"New value: +"number of relevant matches (after the relevance floor), before the limit cap - if this is large, narrow your query"
    • changedOutput schema / required
      Previous value: -[
-  "results",
-  "total"
-]New value: +[
+  "results",
+  "total",
+  "ranking"
+]
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral context: relevance scoring, relevance floor, total counting before limit, ranking modes, heavy:true result guidance, and the critical caveat that results carry no input schema. There is no contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average but each sentence earns its place, covering scope, parameter logic, result semantics, and workflow. The motivational warning about guessing input is slightly redundant, but it strongly reinforces the key operational constraint without being 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 search tool with an output schema, the description is complete: it covers what matches contain, how relevance and ranking work, how limit behaves, the heavy:true caveat, the absence of input schemas, and the required get_api pre-step. An agent has everything needed to call search_apis correctly and interpret its results.

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 baseline is 3, but the description adds meaning beyond individual parameter descriptions by explaining that query, category, and platform can be combined, that at least one is needed, and that category/platform without query enumerates the scope. It also connects the heavy:true result field to run_api parameters, which is not in the input schema.

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 names a specific verb and resource: 'Search APIs by meaning and keyword across name, slug, and description,' and clarifies the return format ('matches WITH their descriptions... schemas omitted'). It clearly differentiates from siblings like get_api (which returns schemas) and list_apis ('Use list_apis to browse everything').

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?

It explicitly states when to use search_apis and when not to: 'Use list_apis to browse everything,' and 'before your FIRST run_api on any API, call get_api for it and use the schema it returns.' It also spells out the parameter combination rules: at least one of query, category, or platform, with category/platform alone acting as an enumeration.

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

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

Every tool has a clearly distinct purpose: browsing, searching, retrieving full schemas, quoting, executing, reading cached results, and checking balance. No two tools overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., list_apis, get_balance, run_api), making the set predictable and easy to navigate.

Tool Count5/5

With 7 tools, the set is well-scoped for the domain of an API marketplace. Each tool handles a distinct step in the workflow without unnecessary bloat or missing essentials.

Completeness4/5

The tool surface covers the full lifecycle of discovering, quoting, executing, and retrieving results from APIs. Minor gaps include no tool for managing API keys or viewing past runs, but these are not critical for core functionality.

Resources