Skip to main content
Glama
Sign In

AI Agents API Library

by io.github.eater2
OverviewDiscussionsAdmin

Search APIs and MCP servers

search_apis
Read-onlyIdempotent

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) and notes. 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)
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. Changed3 schema fields changed
    • 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"
+}
    • changedInput schema / properties / sort / description
      Previous value: -"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. Services without the signal go last; ties keep fit order"New value: +"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"
    • changedInput schema / properties / sort / enum
      Previous value: -[
-  "fit",
-  "rating",
-  "reviews",
-  "usage"
-]New value: +[
+  "fit",
+  "rating",
+  "reviews",
+  "usage",
+  "issues"
+]
  2. Changed3 schema fields changed
    • 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"
+}
    • changedInput schema / properties / sort / description
      Previous value: -"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. Services without reviews go last; ties keep fit order"New value: +"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. Services without the signal go last; ties keep fit order"
    • changedInput schema / properties / sort / enum
      Previous value: -[
-  "fit",
-  "rating",
-  "reviews"
-]New value: +[
+  "fit",
+  "rating",
+  "reviews",
+  "usage"
+]
  3. Changed3 schema fields changed
    • 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. Services without reviews go last; ties keep fit order",
+  "enum": [
+    "fit",
+    "rating",
+    "reviews"
+  ],
+  "type": "string"
+}
  4. Changed1 schema field changed
    • 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"
  5. Changed1 schema field changed
    • addedInput schema / properties / include_trials
      Added value: +{
+  "description": "With free_tier: also accept one-off trial or signup credits",
+  "type": "boolean"
+}
  6. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare a safe, idempotent read (readOnlyHint, idempotentHint, destructiveHint false, openWorldHint false) and the description honors them while adding material context: filter exclusion semantics ('services without reviews are excluded'), ranking weights and what ranking does NOT use (budget, region), the free_tier vs trial distinction, and the explicit caveat that exact matches are not proof the endpoint accepts the user's inputs.

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?

Purpose and eligibility caveat are front-loaded, then match semantics, then ranking, then each signal family in turn. Information density is high with little filler, but it is one very long block paragraph covering both filter semantics and output fields, which could be segmented for faster scanning.

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?

There is no output schema, and the description compensates by naming the returned signals an agent must interpret (match, mcp_fit, ratings.usage, ratings.issues, reviews_summary, free_plan.kind) and warning that reviews rate the product rather than task fit. For a 15-parameter, zero-required search tool this is unusually complete.

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 93%, so the baseline is 3, but the description meaningfully extends it by explaining the match/mcp_fit output vocabulary and the ranking model behind sort=fit, plus how ratings.usage and ratings.issues are derived. Some parameter text (min_issue_health, sort enums, min_downloads) is largely restated from the schema, which keeps it from a 5.

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?

States a specific verb and resource ('Search 300+ catalog entries of third-party APIs and MCP servers'), specifies the search axis (operation or keywords) and the optional filter families. The catalog-search role is clearly distinct from sibling get_api (fetch one entry), get_reviews (review text) and list_categories (enumerate categories, which the description explicitly points to for category ids).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives substantial usage guidance: it defines what the match labels mean, states that 'exact' is a search label not proof of input compatibility, explains what empty results mean, and tells the agent how to drive reviews/usage/issues signals via specific filters and sort values. It does not explicitly state when to prefer a sibling (e.g. 'use get_api once you have an id'), so it stops short of full when/when-not routing.

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

All AI Agents API Library toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources