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 (required), optionally category or platform to narrow, and 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)
queryYesfree-text search over API name, slug, and description
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

TDQS

A4.8/5.0
Behavior5/5

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

Beyond readOnlyHint/destructiveHint annotations, the description discloses rich behavior: relevance scores in (0,1], a relevance floor, ranking modes, heavy:true response implications, and the absence of input schemas in results. It also quantifies failure rates for callers who skip schema lookup, giving agents a strong behavioral expectation.

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 the minimum but every section earns its place: search semantics, parameter usage, return behavior, and the critical get_api prerequisite. The only mild redundancy is repeating the schema's default/max for limit and the cautionary sentence, which slightly extends length but retains instructional value.

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?

An output schema exists, so return-value documentation is not strictly required, yet the description still covers relevance, ranking, total, and heavy-response behavior. It also closes the operational loop by telling the agent to call get_api before run_api, making the tool safely callable in its intended workflow.

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 description coverage is 100%, so the baseline is 3. The description adds value by clarifying that query is required, category/platform are narrowing filters, limit caps matches with defaults, and how relevance/ranking semantics interact with search. This goes beyond the schema's field-level text without being overly verbose.

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 opening sentence states a specific action and object: 'Search APIs by meaning and keyword across name, slug, and description.' It clearly distinguishes itself from siblings by noting returns include descriptions but omit schemas, ranked by relevance, and later points to list_apis for browsing and get_api for schemas.

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 instructs when to switch to alternatives: 'Use list_apis to browse everything' and 'before your FIRST run_api on any API, call get_api for it.' It explains that search results alone cannot support a run_api call, which prevents misuse and gives clear decision guidance.

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