Skip to main content
Glama

Find fintech providers by licence and capability

find_providers
Read-onlyIdempotent

Find companies by product category, licence (licensed_in matches the home country or any passported country), licence type, authority, and agent access (has_sandbox, has_mcp, has_api), optionally min_agent_ready (1–5, the product's Agent-Ready score; available once those results are published). Returns each company with its approved products (with agent_access), LEI, licence summaries and self-reported certifications. Every licence carries source_url and last_checked_at so you can verify it on the regulator's register. From public registers as of the last-checked date. Always confirm on the regulator's register before relying on it. Use list_provider_filters for valid slugs. Ordered by company name, then slug. cursor is the next_cursor from a previous page. Unknown arguments are rejected.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_providers"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNoq (or query): text matched against company and product names.
limitNoMax companies (≤50, default 20).
queryNoAlias of q; q wins if both are sent.
cursorNonext_cursor from the previous page.
has_apiNoOnly companies with a product that has an API (flag, docs or OpenAPI).
has_mcpNoOnly companies with a product that has a public MCP server.
categoryNoProduct category slug.
authorityNoAuthority slug, e.g. 'bank-of-lithuania'.
has_sandboxNoOnly companies with a product that has a sandbox.
licensed_inNoTwo-letter ISO country code; matches home or passported licences.
licence_typeNoLicence type slug, e.g. 'e-money-institution'.
min_agent_readyNoOnly companies with a product whose Agent-Ready score is at least this (1–5). Available once Agent-Ready results are published.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / min_agent_ready
      Added value: +{
      +  "description": "Only companies with a product whose Agent-Ready score is at least this (1–5). Available once Agent-Ready results are published.",
      +  "maximum": 5,
      +  "minimum": 1,
      +  "type": "integer"
      +}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it discloses the result shape (companies with approved products, agent_access, LEI, licence summaries, certifications), provenance fields (source_url, last_checked_at), data freshness, sort order, cursor semantics, the fact that min_agent_ready only works once results are published, and that unknown arguments are rejected.

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?

Front-loaded with the capability summary before the return-shape and caveat details, and every clause carries information. The first sentence is long and re-lists filter names already visible in the schema, which is slight duplication, but the density is justified for a 12-parameter filter tool.

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, yet the description explains what comes back (companies, products, agent_access, LEI, licence summaries, certifications) and how paging works, plus a data-trust caveat. An agent has everything needed to call and interpret results without additional context.

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 100%, so baseline is 3, but the description adds real semantics the schema does not: licensed_in matching home or any passported country, cursor as next_cursor from a prior page, and the availability caveat on min_agent_ready. Minor redundancy with schema wording 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?

Opening sentence names a specific verb and resource (find companies) and enumerates exactly which dimensions the search covers: category, licence/passporting, licence type, authority, and agent-access capability flags. This is clearly differentiated from name-oriented siblings like search_organizations and search_products.

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?

It explicitly routes the agent to list_provider_filters for resolving valid slugs and states a verification caveat (confirm on the regulator's register before relying on data). It does not explicitly say when to prefer search_organizations over this tool, so guidance is clear but not exhaustive.

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