Skip to main content
Glama

find_providers

Read-only

Paginated, sortable list of providers — filter by text, tag, artifact type, industry, region, rating band, access model (pricing/onboarding/try_now/public), or DIRECTION (accepts_writes/min_acting — whether the surface takes a write or only emits). tags filters on what the COMPANY does (its own top-level classification), not on what its endpoints touch; for a resource-level term use find_apis?tags=, or api_tags= here to find companies whose APIs merely touch it. A row that is a third-party marketplace / app-store / directory LISTING rather than the provider (x_source: marketplace-listing) ranks after every provider; meta.query.marketplace_listings_demoted says how many. Name it in providers to read it where you put it. Use apis_io_search first for a cross-type overview.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFree text over name + description.
areaNo
bandNoRating bands: exemplar, strong, developing, thin, minimal.
pageNo
sortNoOrder results. Default: relevance with a query, composite (quality) when browsing. `demand` = Fortune-1000 adoption, scoped to the query.
tagsNoTag slugs. On PROVIDERS this is identity — what the company says it does, from its own apis.yml. A resource or operation term (webhook, saml, order, oai-pmh) will correctly match no provider; use find_apis?tags= for those, or find_providers?api_tags= to reach companies whose APIs merely touch it.
viewNosummary (default) returns lean discovery records + *_count for dropped sections; full returns the whole record (use get_api / get_provider for one entity).summary
facetNoQuality facet to threshold on: discoverability, contract_quality, governance, operational_transparency, developer_ergonomics, commercial_clarity. Needs min_facet.
groupNoestate = rank each corporate estate ONCE: keep the best-ranked member of each estate root (Cvent, Oracle, Amazon) in the order applied, and nest the other members of that estate found in this result set under it as `estate_members`, with `estate_member_count`. Rows outside any estate are unaffected. meta.query.ungrouped_total is the flat count. Off by default; every row carries `estate` and `estate_root` either way.
limitNo
matchNoany
trendNoup | down | flat — direction of the composite since the previous scoring pass.
fieldsNoReturn exactly these top-level keys (overrides view).
publicNoOnly providers callable publicly with no signup (onboarding=open). (providers only)
regionNo
contextNoOptional: why you are asking. One sentence — the task you are trying to complete, or what you expect to get back. Never included in the answer and never used to rank; it is read only when a result turns out to be wrong, which is when knowing the intent is what makes the report actionable.
countryNoProviders whose derived country membership includes these slugs (e.g. united-kingdom). Membership is partial — a count is a floor.
pricingNoAccess model — pricing: free, freemium, free-trial, paid, enterprise. (providers only)
resolveNoWhen `q` exactly names a tag, apis.io uses it: on PROVIDERS a resource tag (order, webhook, image) replaces the text search with the companies that classify themselves there — 2,182 text matches for "order" become the 92 that claim it; on APIS the tag's members are ADDED to the text matches, never swapped for them. Market tags (payments) and tags almost no company claims are reported and not applied. Set `off` for pure text. The resolution is always echoed as `resolved_tag`.on
try_nowNoOnly providers a developer can start using at no cost right now (free/trial + self-serve/open). (providers only)
api_tagsNoProviders that publish an API, spec or OPERATION carrying these tags, without claiming it as their business. The complement of `tags`, and disjoint from it.
industryNo
platformNoProviders running on these platform vendors, by registry key or catalog slug (mintlify, readme, gitbook, redocly, apigee, kong, cloudflare, vercel…). "Who are Mintlify's customers" = platform=mintlify; "who runs on a competitor" = platform=readme. Each row carries `platforms` with the evidence. Detection covers ~1,240 providers — absent means not detected, not "none".
max_scoreNoOnly providers at or below this composite. Pair with min_score for a band-free range.
min_facetNoMinimum score on `facet`. Without `facet` this does nothing.
min_scoreNo
providersNo
min_actingNoMinimum number of acting (non-read) operations. Use to require real write depth rather than a single write endpoint.
onboardingNoAccess model — how to start: open (no key), self-serve, approval. (providers only)
size_basisNoWhich rung produced the band: sec-edgar | companies-house | wikidata | editorial | derived | inferred | unknown. Ask for the filed ones when you need a defensible number. Understanding plan.
size_statusNoprobed | unprobed. USE size_status=probed when filtering for small companies: without it, "not enterprise" sweeps in every provider we have not looked at yet and counts them as small. Absence of a band is not a measurement. Understanding plan.
revenue_bandNoRevenue band(s): <$1M | $1-10M | $10-100M | $100M-1B | $1B+. Estimates; filed where size_basis is sec-edgar or companies-house. Understanding plan.
platform_areaNoNarrow `platform` (or all detected platforms) to one area: documentation, developer-portal, api-gateway, hosting, cdn, status-page, support, identity, mcp-hosting.
publishes_apiNotrue = the provider publishes at least one API (api_count > 0), including partner-gated APIs whose shape API Evangelist modeled; false = it publishes none. Product areas marked as not an API (unpublished_api_count) are not counted, so a company whose every entry is one reads false.
accepts_writesNotrue = the provider has operations that ACT (create/update/send), so you can push something to it; false = measured and read-only. Use this when the question is "where can I publish/send/post to" — text search cannot tell direction, and without it a query about syndicating content returns RSS feeds and read-only APIs. Providers with no agentic-access reading are excluded either way: absent is unmeasured, not zero.
artifact_typesNo
employees_bandNoCompany size band(s), comma-separated: 1-10 | 11-50 | 51-200 | 201-1000 | 1001-5000 | 5000+ | 1000+ (the last is the open-ended band the inferred rung emits when it can tell "big" but not how big). ESTIMATES from free public sources — Wikidata, SEC EDGAR, the provider's own About page, our own signals — never a headcount. Understanding plan.
include_narrowerNoWith `tags`: also return the members of each tag's CURATED narrower tags (the `narrower` list on get_tag — Payments under Fintech), after the tag's own members. Each added row carries `via: <narrower-tag>`. Off by default, and provider_count on the tag stays the tag's own membership; provider_count_with_narrower is this total. On a tag with senses (payments, media, supply-chain), every row is routed into a sense: it carries `sense: <tag>:<id>`, meta.query.senses counts own and added members per sense, and `sense=<tag>:<id>` with include_narrower=true (REST) reads one routed sense.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / publishes_api
      Added value: +{
      +  "description": "true = the provider publishes at least one API (api_count > 0), including partner-gated APIs whose shape API Evangelist modeled; false = it publishes none. Product areas marked as not an API (unpublished_api_count) are not counted, so a company whose every entry is one reads false.",
      +  "type": "boolean"
      +}
  2. Changed4 schema fields changed
    • addedInput schema / properties / group
      Added value: +{
      +  "description": "estate = rank each corporate estate ONCE: keep the best-ranked member of each estate root (Cvent, Oracle, Amazon) in the order applied, and nest the other members of that estate found in this result set under it as `estate_members`, with `estate_member_count`. Rows outside any estate are unaffected. meta.query.ungrouped_total is the flat count. Off by default; every row carries `estate` and `estate_root` either way.",
      +  "enum": [
      +    "estate"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / include_narrower
      Added value: +{
      +  "description": "With `tags`: also return the members of each tag's CURATED narrower tags (the `narrower` list on get_tag — Payments under Fintech), after the tag's own members. Each added row carries `via: <narrower-tag>`. Off by default, and provider_count on the tag stays the tag's own membership; provider_count_with_narrower is this total. On a tag with senses (payments, media, supply-chain), every row is routed into a sense: it carries `sense: <tag>:<id>`, meta.query.senses counts own and added members per sense, and `sense=<tag>:<id>` with include_narrower=true (REST) reads one routed sense.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / platform
      Added value: +{
      +  "description": "Providers running on these platform vendors, by registry key or catalog slug (mintlify, readme, gitbook, redocly, apigee, kong, cloudflare, vercel…). \"Who are Mintlify's customers\" = platform=mintlify; \"who runs on a competitor\" = platform=readme. Each row carries `platforms` with the evidence. Detection covers ~1,240 providers — absent means not detected, not \"none\".",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / platform_area
      Added value: +{
      +  "description": "Narrow `platform` (or all detected platforms) to one area: documentation, developer-portal, api-gateway, hosting, cdn, status-page, support, identity, mcp-hosting.",
      +  "type": "string"
      +}
  3. Changed4 schema fields changed
    • addedInput schema / properties / employees_band
      Added value: +{
      +  "description": "Company size band(s), comma-separated: 1-10 | 11-50 | 51-200 | 201-1000 | 1001-5000 | 5000+ | 1000+ (the last is the open-ended band the inferred rung emits when it can tell \"big\" but not how big). ESTIMATES from free public sources — Wikidata, SEC EDGAR, the provider's own About page, our own signals — never a headcount. Understanding plan.",
      +  "type": "string"
      +}
    • addedInput schema / properties / revenue_band
      Added value: +{
      +  "description": "Revenue band(s): <$1M | $1-10M | $10-100M | $100M-1B | $1B+. Estimates; filed where size_basis is sec-edgar or companies-house. Understanding plan.",
      +  "type": "string"
      +}
    • addedInput schema / properties / size_basis
      Added value: +{
      +  "description": "Which rung produced the band: sec-edgar | companies-house | wikidata | editorial | derived | inferred | unknown. Ask for the filed ones when you need a defensible number. Understanding plan.",
      +  "type": "string"
      +}
    • addedInput schema / properties / size_status
      Added value: +{
      +  "description": "probed | unprobed. USE size_status=probed when filtering for small companies: without it, \"not enterprise\" sweeps in every provider we have not looked at yet and counts them as small. Absence of a band is not a measurement. Understanding plan.",
      +  "type": "string"
      +}
  4. Changed1 schema field changed
    • changedInput schema / properties / tags / description
      Previous value: -"Tag slugs. On PROVIDERS this is identity — what the company says it does, from its own apis.yml. A resource or operation term (webhook, saml, order, oai-pmh) will correctly match no provider; use find_apis?tags= for those, or api_tags below."New value: +"Tag slugs. On PROVIDERS this is identity — what the company says it does, from its own apis.yml. A resource or operation term (webhook, saml, order, oai-pmh) will correctly match no provider; use find_apis?tags= for those, or find_providers?api_tags= to reach companies whose APIs merely touch it."
  5. Changed1 schema field changed
    • addedInput schema / properties / resolve
      Added value: +{
      +  "default": "on",
      +  "description": "When `q` exactly names a tag, apis.io uses it: on PROVIDERS a resource tag (order, webhook, image) replaces the text search with the companies that classify themselves there — 2,182 text matches for \"order\" become the 92 that claim it; on APIS the tag's members are ADDED to the text matches, never swapped for them. Market tags (payments) and tags almost no company claims are reported and not applied. Set `off` for pure text. The resolution is always echoed as `resolved_tag`.",
      +  "enum": [
      +    "on",
      +    "off"
      +  ],
      +  "type": "string"
      +}
  6. Changed1 schema field changed
    • addedInput schema / properties / country
      Added value: +{
      +  "description": "Providers whose derived country membership includes these slugs (e.g. united-kingdom). Membership is partial — a count is a floor.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  7. Changed4 schema fields changed
    • addedInput schema / properties / facet
      Added value: +{
      +  "description": "Quality facet to threshold on: discoverability, contract_quality, governance, operational_transparency, developer_ergonomics, commercial_clarity. Needs min_facet.",
      +  "type": "string"
      +}
    • addedInput schema / properties / max_score
      Added value: +{
      +  "description": "Only providers at or below this composite. Pair with min_score for a band-free range.",
      +  "type": "number"
      +}
    • addedInput schema / properties / min_facet
      Added value: +{
      +  "description": "Minimum score on `facet`. Without `facet` this does nothing.",
      +  "type": "number"
      +}
    • addedInput schema / properties / trend
      Added value: +{
      +  "description": "up | down | flat — direction of the composite since the previous scoring pass.",
      +  "type": "string"
      +}
  8. Changed2 schema fields changed
    • addedInput schema / properties / accepts_writes
      Added value: +{
      +  "description": "true = the provider has operations that ACT (create/update/send), so you can push something to it; false = measured and read-only. Use this when the question is \"where can I publish/send/post to\" — text search cannot tell direction, and without it a query about syndicating content returns RSS feeds and read-only APIs. Providers with no agentic-access reading are excluded either way: absent is unmeasured, not zero.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / min_acting
      Added value: +{
      +  "description": "Minimum number of acting (non-read) operations. Use to require real write depth rather than a single write endpoint.",
      +  "type": "integer"
      +}
  9. Changed2 schema fields changed
    • addedInput schema / properties / api_tags
      Added value: +{
      +  "description": "Providers that publish an API, spec or OPERATION carrying these tags, without claiming it as their business. The complement of `tags`, and disjoint from it.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / tags / description
      Previous value: -"Tag slugs."New value: +"Tag slugs. On PROVIDERS this is identity — what the company says it does, from its own apis.yml. A resource or operation term (webhook, saml, order, oai-pmh) will correctly match no provider; use find_apis?tags= for those, or api_tags below."
  10. Changed1 schema field changed
    • addedInput schema / properties / context
      Added value: +{
      +  "description": "Optional: why you are asking. One sentence — the task you are trying to complete, or what you expect to get back. Never included in the answer and never used to rank; it is read only when a result turns out to be wrong, which is when knowing the intent is what makes the report actionable.",
      +  "type": "string"
      +}
  11. Changed4 schema fields changed
    • addedInput schema / properties / onboarding
      Added value: +{
      +  "description": "Access model — how to start: open (no key), self-serve, approval. (providers only)",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / pricing
      Added value: +{
      +  "description": "Access model — pricing: free, freemium, free-trial, paid, enterprise. (providers only)",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / public
      Added value: +{
      +  "description": "Only providers callable publicly with no signup (onboarding=open). (providers only)",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / try_now
      Added value: +{
      +  "description": "Only providers a developer can start using at no cost right now (free/trial + self-serve/open). (providers only)",
      +  "type": "boolean"
      +}
  12. Changed4 schema fields changed
    • addedInput schema / properties / fields / description
      Added value: +"Return exactly these top-level keys (overrides view)."
    • addedInput schema / properties / sort / description
      Added value: +"Order results. Default: relevance with a query, composite (quality) when browsing. `demand` = Fortune-1000 adoption, scoped to the query."
    • addedInput schema / properties / sort / enum
      Added value: +[
      +  "relevance",
      +  "composite",
      +  "name",
      +  "created",
      +  "modified",
      +  "api_count",
      +  "demand"
      +]
    • addedInput schema / properties / view
      Added value: +{
      +  "default": "summary",
      +  "description": "summary (default) returns lean discovery records + *_count for dropped sections; full returns the whole record (use get_api / get_provider for one entity).",
      +  "enum": [
      +    "summary",
      +    "full"
      +  ],
      +  "type": "string"
      +}
  13. Changed1 schema field changed
    • addedInput schema / properties / area
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  14. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only state readOnlyHint=true; the description goes well beyond, disclosing pagination, sorting behavior, marketplace listing demotion (x_source: marketplace-listing), tag resolution behavior (resolve), and important caveats like 'absent means unmeasured, not zero' for accepts_writes and size_status. No contradiction with 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 long but dense with essential information, front-loaded with the core purpose and filters. It is well-structured but could be considered verbose; however, given the tool's 38 parameters, the length is justified and every sentence adds 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?

For a tool with 38 parameters and no output schema, the description covers edge cases (e.g., marketplace demotion, resolved_tag echo, estate grouping), result metadata (meta.query fields), and interpretation caveats (size_status, platform detection). It is complete enough for an agent to call correctly without external documentation.

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

Parameters5/5

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

While schema coverage is 76% and many parameters have descriptions, the description adds substantial nuance beyond the schema, especially for tags (identity vs. touch), resolve (swap vs. add), platform (detection coverage and 'absent means not detected'), and accepts_writes (publish/send intent). It compensates for any gaps and enriches parameter understanding.

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 clearly states it lists providers with pagination and sorting, and explicitly contrasts with find_apis for resource-level terms. It also mentions direction (accepts_writes/min_acting) and directs to apis_io_search first, effectively distinguishing from siblings.

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 guidance on when to use this tool vs. alternatives: 'Use apis_io_search first for a cross-type overview' and clarifies that resource-level terms should use find_apis?tags= or api_tags= here. Also explains the semantics of tags vs api_tags, giving clear context for selection.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources