Auto-discovery

FlashMCP automatically finds your API's OpenAPI specification. No configuration needed for the vast majority of APIs - just point FlashMCP at any API hostname and it handles the rest.

How it works

When you point FlashMCP at an API, our intelligent discovery engine automatically locates the API's OpenAPI spec. You don't need to know where the spec lives, what format it's in, or how to fetch it - FlashMCP figures it all out.

Behind the scenes, FlashMCP uses a multi-phase intelligent resolution pipeline. First, it checks a continuously-updated catalog of over 100,000 public APIs. If the API isn't in the catalog, it falls back to industry-standard discovery protocols (RFC 8631 Link headers, RFC 9727 .well-known/api-catalog) to locate the spec. The entire process is fast, lightweight, and non-invasive - typically 1–3 HTTP requests at most.

Here's what the discovery engine supports:

• OpenAPI 3.x and Swagger 2.0 specs, in both JSON and YAML formats
• 100,000+ APIs covered out of the box through a continuously-updated catalog - the world's largest MCP-ready API directory
• Standard discovery protocols (RFC 8631, RFC 9727) that let well-configured APIs advertise their own specs
• Bring your own spec - provide any spec via ?spec= when auto-discovery isn't enough
• Edge caching - once a spec is found, it's cached globally for instant subsequent access

For most APIs, discovery is completely automatic. You configure a single URL and your LLM gets tools within seconds:

{
  "mcpServers": {
    "petstore": {
      "url": "https://flashmcp.dev/petstore.swagger.io"
    }
  }
}

That's it. FlashMCP's discovery engine takes over from here - locating the spec, parsing every endpoint, resolving all schemas, and serving optimized tool definitions to your LLM.

What gets discovered

Once FlashMCP locates an API's spec, it extracts everything your LLM needs to interact with the API:

• All endpoints - every path and operation defined in the spec
• All HTTP methods - GET, POST, PUT, PATCH, and DELETE operations
• Request parameters - path parameters, query parameters, and request bodies are all extracted and flattened into LLM-friendly schemas
• Complex schemas - nested objects, arrays, polymorphic types (allOf, oneOf, anyOf), and $ref pointers are fully resolved automatically
• Response types - JSON, text, images, and audio are all handled with appropriate MCP content blocks

Schema resolution is deep and thorough. FlashMCP recursively resolves $ref references - including chained refs and circular references - so your LLM always gets a complete, self-contained schema for every tool.

Bring your own spec

Auto-discovery covers the vast majority of APIs, but some don't publish their specs at discoverable locations, or host them on a different domain. For these cases, use the ?spec= parameter to provide the spec yourself. This works with any OpenAPI 3.x or Swagger 2.0 spec - public or private.

Relative path

If the spec is hosted on the same domain as the API, provide a relative path:

"url": "https://flashmcp.dev/api.example.com?spec=/api/v3/openapi.json"

FlashMCP will fetch the spec from https://api.example.com/api/v3/openapi.json.

Absolute URL (cross-domain specs)

Many major APIs host their specs on a completely different domain - GitHub raw content, docs subdomains, or dedicated spec hosting services. For these, provide a full absolute URL:

{
  "mcpServers": {
    "stripe": {
      "url": "https://flashmcp.dev/api.stripe.com?spec=https://raw.githubusercontent.com/stripe/openapi/master/openapi/spec3.json"
    }
  }
}

FlashMCP detects that the ?spec= value is a full URL (starts with https://) and fetches it directly from that location, while still routing API calls to the target host (api.stripe.com).

Edge caching

Once a spec is discovered, FlashMCP caches it at the edge for fast repeated access. This means:

• First request - the discovery engine locates and fetches the spec (typically under a second)
• Subsequent requests - the spec is served instantly from the nearest edge node
• Automatic refresh - cached specs are refreshed periodically so your tools stay current when the API evolves
• No manual cache management - you never need to clear caches or force refreshes

If the discovery engine can't find a spec for a given API, that negative result is also cached to avoid redundant lookups on repeated requests.