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 combines a massive pre-built API catalog with industry-standard discovery protocols (RFC 8631, RFC 9727) to locate specs with remarkable accuracy. The entire process is fast, lightweight, and non-invasive — it won't hammer the target API with unnecessary requests.

Here's what the discovery engine supports:

• OpenAPI 3.x and Swagger 2.0 specs, in both JSON and YAML formats
• Thousands of popular APIs covered out of the box through a continuously-updated pre-built catalog
• Standard discovery protocols that let well-configured APIs advertise their own specs
• 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.

When auto-discovery isn't enough

Some APIs don't publish their OpenAPI specs at discoverable locations, or host them on a different domain entirely. For these cases, use the ?spec= parameter to point FlashMCP directly at the spec.

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.