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. 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.
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
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.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
      +}
  2. 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."
  3. 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"
      +}
  4. 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"
      +}
  5. 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"
      +}
  6. 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"
      +}
  7. 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."
  8. 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"
      +}
  9. 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"
      +}
  10. 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"
      +}
  11. Changed1 schema field changed
    • addedInput schema / properties / area
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  12. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The description adds substantial behavioral nuance beyond the readOnlyHint annotation: it explains how tags resolve on providers versus APIs, that resolved_tag is echoed, that size_status=probed is needed to avoid sweeping unmeasured companies into 'small', and that absent accepts_writes data means unmeasured rather than zero. This goes far beyond the annotation's basic safety signal.

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 dense and front-loaded, leading with the tool's core purpose and the most important filter dimension. Some sentences are long and pack many caveats together, so a bit of restructuring could improve scannability, but for a 33-parameter tool the level of detail is earned and there is no 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?

Given the tool's complexity, the richness of the input schema, and the absence of an output schema, the description provides enough operational context to call it correctly: pagination, sorting, filter semantics, disambiguation from sibling tools, and several edge-case warnings are all covered. An agent has sufficient guidance to select and invoke this tool effectively.

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?

Although schema coverage is already 73%, the description adds crucial meaning beyond the schema: it clarifies the identity vs. touch distinction between tags and api_tags, the swap-vs-add behavior of resolve, the practical intent of accepts_writes for syndication questions, and the caveat about size_status. These are the kinds of semantic traps an agent cannot infer from parameter names alone.

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 opens with a specific verb+resource: 'Paginated, sortable list of providers' and enumerates the filter dimensions (text, tag, artifact type, industry, region, rating band, access model, direction). It also distinguishes itself from siblings by naming find_apis and apis_io_search, so an agent can tell this tool apart without opening 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 gives explicit routing instructions: use apis_io_search first for a cross-type overview, use find_apis?tags= for resource-level terms, and use api_tags= here for providers whose APIs merely touch a term. It also explains when direction filters like accepts_writes matter, making the selection context concrete.

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