Skip to main content
Glama
Sign In
ai-agents-api-library

ai-agents-api-library

by eater2
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Search APIs and MCP servers

search_apis
Read-onlyIdempotent

Search 300+ third-party APIs and MCP servers by operation or keyword, then filter by category, auth, free tier, ratings, usage, or maintenance to find a suitable service.

Instructions

Search 300+ catalog entries of third-party APIs and MCP servers (each with a last-checked date) by operation or keywords, with optional category and quality filters. match: exact = the entry lists the operation and its example call or an MCP tool performs it; listed = the entry lists it without that evidence; adjacent = a related operation; topic = word match only. Exact is still a search label, not proof that the endpoint or tool accepts the user's actual inputs. mcp_fit says whether the MCP server has a tool for the operation. Ranking weighs operation fit, evidence, lasting free plan, card and auth effort, and bulk limits, not budget or region: read free_plan.kind (free_tier lasts, trial is one-off), no_card, unit_price and notes (coverage, coordinate systems, bulk and trial restrictions). Ratings and the MCP client config come with verbose=true or from get_api. User opinions (SourceForge product reviews): filter with min_rating / min_reviews, order with sort=rating or sort=reviews; results with stored review texts carry reviews_summary (praised and complained-about aspects). Usage: ratings.usage gives monthly downloads of the official SDKs, Stack Overflow questions and the vendor's iOS app rating; filter with min_downloads, order with sort=usage. Maintenance: ratings.issues gives the vendor's GitHub issues (share resolved, median days to fix, issue_health 0-100); filter with min_issue_health, order with sort=issues. Reviews rate the product, not whether the API fits the task. An empty result means no catalogued fit for the query and filters.

Input Schema

NameRequiredDescriptionDefault
mcpNoofficial: MCP server by the vendor; remote: hosted endpoint that answered an MCP handshake (no install); any: any MCP server. Docs-only servers never count
authNo
sortNofit (default): operation fit and task factors; rating: user rating weighted by review count, so 5/5 from one review does not lead; reviews: most reviewed first; usage: most monthly SDK downloads (npm + PyPI) first; issues: highest issue_health (GitHub issues resolved and fixed fast) first. Services without the signal go last; ties keep fit order
limitNoMax results, default 10
queryNoThe operation you need, e.g. 'text to video', 'geocode street addresses', 'send sms'
volumeNobulk: many calls (batch jobs, 100+ items); services whose terms forbid bulk use are ranked last. Inferred from the query if omitted
no_authNoOnly services usable without any key
no_cardNoOnly services whose free plan needs no payment card (or no account at all)
verboseNoAlso return ratings (reviews, usage, issues, uptime) and the full MCP block with client config; on by default with an opinion filter or sort
categoryNoCategory id from list_categories, e.g. 'video-generation'
free_tierNoOnly services with lasting free usage (not one-off trial credits)
min_ratingNoOnly services whose user reviews (SourceForge) average at least this, e.g. 4. Services without reviews are excluded
min_reviewsNoOnly services with at least this many user reviews, e.g. 10. Services without reviews are excluded
min_downloadsNoOnly services whose official SDKs (npm + PyPI) have at least this many downloads per month, e.g. 100000. Services without a known SDK are excluded
include_trialsNoWith free_tier: also accept one-off trial or signup credits
min_issue_healthNoOnly services whose main GitHub repo (official SDK, MCP server or spec) scores at least this issue_health, e.g. 60. 0-100: 40% share of issues resolved (open vs fixed now; closed as not planned does not count), 40% fix speed (median days from report to fix over the last 12 months; 14 days = half), 20% closes vs new issues in the last 90 days. Services without a repo with 10+ issues are excluded

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.12
    • addedInput schema / properties / verbose
      Added value: +{
+  "description": "Also return ratings (reviews, usage, issues, uptime) and the full MCP block with client config; on by default with an opinion filter or sort",
+  "type": "boolean"
+}
  2. Changed5 schema fields changedv0.3.11
    • addedInput schema / properties / min_downloads
      Added value: +{
+  "description": "Only services whose official SDKs (npm + PyPI) have at least this many downloads per month, e.g. 100000. Services without a known SDK are excluded",
+  "maximum": 9007199254740991,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / min_issue_health
      Added value: +{
+  "description": "Only services whose main GitHub repo (official SDK, MCP server or spec) scores at least this issue_health, e.g. 60. 0-100: 40% share of issues resolved (open vs fixed now; closed as not planned does not count), 40% fix speed (median days from report to fix over the last 12 months; 14 days = half), 20% closes vs new issues in the last 90 days. Services without a repo with 10+ issues are excluded",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / min_rating
      Added value: +{
+  "description": "Only services whose user reviews (SourceForge) average at least this, e.g. 4. Services without reviews are excluded",
+  "maximum": 5,
+  "minimum": 1,
+  "type": "number"
+}
    • addedInput schema / properties / min_reviews
      Added value: +{
+  "description": "Only services with at least this many user reviews, e.g. 10. Services without reviews are excluded",
+  "maximum": 9007199254740991,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / sort
      Added value: +{
+  "description": "fit (default): operation fit and task factors; rating: user rating weighted by review count, so 5/5 from one review does not lead; reviews: most reviewed first; usage: most monthly SDK downloads (npm + PyPI) first; issues: highest issue_health (GitHub issues resolved and fixed fast) first. Services without the signal go last; ties keep fit order",
+  "enum": [
+    "fit",
+    "rating",
+    "reviews",
+    "usage",
+    "issues"
+  ],
+  "type": "string"
+}
  3. Changed2 schema fields changedv0.3.7
    • addedInput schema / properties / include_trials
      Added value: +{
+  "description": "With free_tier: also accept one-off trial or signup credits",
+  "type": "boolean"
+}
    • changedInput schema / properties / mcp / description
      Previous value: -"official: MCP server by the vendor; remote: hosted MCP endpoint (no install); any: any MCP server"New value: +"official: MCP server by the vendor; remote: hosted endpoint that answered an MCP handshake (no install); any: any MCP server. Docs-only servers never count"
  4. First observedv0.3.3

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the read-only, non-destructive annotations, it discloses catalog freshness, match-evidence levels, ranking factors and exclusions, and the meaning of an empty result. It also explains important result-interpretation limits involving trials, pricing, reviews, and regional or budget coverage.

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 purpose is front-loaded, and the description progresses logically through matching, ranking, reviews, usage, maintenance, and empty results with little filler. However, the dense single paragraph and repeated filter/sort details make it harder to scan than necessary.

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 complex 16-parameter search tool without an output schema, it documents the essential result fields and labels, ranking behavior, verbosity, and interpretation caveats needed to invoke and use it correctly. Together with the rich schema and safety annotations, it leaves no significant operational gap.

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?

The schema already covers 94% of parameters, including detailed enum, exclusion, and sorting behavior. The description adds useful context about ranking, verbose retrieval, and combining filters with their corresponding sorts, but much of its parameter-specific material restates information already present in the 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 opening sentence gives a specific verb, resource, catalog scope, and search criteria: searching 300+ third-party API and MCP-server entries by operation or keywords. The later reference to obtaining ratings and MCP client configuration from get_api also helps distinguish discovery from retrieving details for a particular entry.

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 gives concrete guidance for choosing opinion, usage, and maintenance filters and sorts, and offers verbose=true or get_api as alternative routes to ratings and client configuration. Warnings that exact matches do not validate actual inputs and that reviews do not establish task fit help prevent misuse of the results.

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

Deploy Server

Other Tools