integrations.sh maps every integration agents can reach — and Solana isn't on the map

integrations.sh calls itself "every integration, in every format agents speak." It is a registry of integration surfaces — MCP servers, REST/OpenAPI, GraphQL — for thousands of services, each mapped to the credential it needs and exactly how to mint it. As of this week it lists 5,758 surfaces across 3,230 domains. I queried its live catalog for the Solana ecosystem — Helius, Jupiter, Magic Eden, Metaplex, USDC — and got back zero. Not "a few." Zero.

That is worth a closer look, because the thing integrations.sh is building is exactly the piece the agent stack on Solana keeps hand-waving past: not the protocol, not the payment, but the map that tells an agent a service exists and how to authenticate to it.

The bet: auth, not discovery

The project's own framing is the sharpest part. Discovery takes a minute; auth takes an hour. Finding out that Stripe has an MCP server is easy — figuring out which key it wants, where to mint one with least privilege, and which header to put it in is the part that actually costs you. So every surface on integrations.sh leads with a grounded, cited credential guide rather than a link dump.

The data model is small and clean:

• Service — a network-addressable primitive an agent talks to (Gmail, Stripe). The unit of authentication; owns a credential model. Lives at /gmail/, /stripe/.
• Access paths, grouped by format — the ways to reach a service: the direct REST/GraphQL API, an MCP server, a CLI, or an SDK. Deliberately not forced into one noun, because they aren't one kind of thing.
• Credential facts — defined once per service, bound per-surface: which credential, where to create it, which scopes, which header.

The detail that earns trust: every fact carries a provenance badge. detected means it's re-verifiable from a machine signal the service publishes; discovered means it was read from the docs. The page a human reads and the JSON an agent fetches are the same content — no drift between the marketing site and the machine surface.

It dogfoods its own model

integrations.sh is itself a catalogued service: a public REST API and a public MCP server, no credentials required. The entire catalog is one envelope.

# The whole catalog: { version, generatedAt, data[] }, one record per surface
curl https://integrations.sh/api.json

# OpenAPI 3.1 description of the REST API
curl https://integrations.sh/openapi.json

Each record is a compact summary; the credential detail lives on the surface page:

// one record from /api.json
{
  "id": "mcp/stripe",
  "kind": "mcp",
  "slug": "stripe",
  "name": "Stripe",
  "description": "The Stripe Model Context Protocol server defines tools AI agents can use to interact with the Stripe API…",
  "url": "https://docs.stripe.com/mcp",
  "domain": "stripe.com",
  "categories": ["financial-services"],
  "feeds": ["claude", "openai"],
  "popularity": 17582
}

The architecture will feel familiar if you read our Cloudflare piece: it's an Astro site on Cloudflare Workers, MIT-licensed, catalog regenerated daily. You can read the source at UsefulSoftwareCo/integrationsdotsh.

The Solana-shaped hole

Here is the catalog I pulled (generated 2026-07-03), filtered for the terms a Solana developer would expect to find:

Catalog: 5,758 surfaces · 3,230 domains

  solana      → 0
  helius      → 0
  jupiter     → 0
  usdc        → 0
  magic eden  → 0
  metaplex    → 0
  coinbase    → 0

The crypto that IS present:
  CeFi exchange REST → binance.com · kraken.com · okx.com · crypto.com
  multichain infra   → quicknode.com (RPC) · bitquery.io (on-chain data)
                       · pocket.network (RPC) — Solana is one chain among many
(the "pyth" hits are Python packages; "circle" is CircleCI;
 "phantom" is PhantomBuster; "tensor" is Google Cloud TPU — false positives.)

So the only way to touch Solana through integrations.sh today is a general multichain provider that happens to include it — QuickNode's RPC, Bitquery's on-chain data, Pocket Network — alongside the REST APIs of centralized exchanges. What's missing is any Solana-native service publishing its own surface and credential guide. That is the real omission, because Solana arguably has the most mature agent tooling in crypto right now. Helius ships the first (and, per its own account, only) crypto company Claude Code plugin in Anthropic's curated registry, bundling MCP servers for live RPC, the DAS API, webhooks, and transaction sending. Jupiter, Magic Eden, Metaplex, and Pyth all expose clean APIs. None of them is on the map yet.

What a Solana service should publish

integrations.sh has an "add your service" path, and its schema is exactly the shape a Solana infra provider already has the facts for. Take Helius: it has an MCP surface and a REST surface, sharing one credential. In the integrations.sh model that's one service with two access paths and a single credential guide:

// Illustrative: what a Helius service record could carry
{
  "service": "helius",
  "domain": "helius.dev",
  "categories": ["blockchain", "solana", "rpc"],
  "credential": {
    "id": "HELIUS_API_KEY",
    "create_at": "https://dashboard.helius.dev  → API Keys → New",
    "least_privilege": "scope the key to the RPC + DAS methods you call; rotate per environment",
    "placement": "query param ?api-key= on RPC, or x-api-key header on REST",
    "provenance": "detected"   // key format re-verifiable from the dashboard
  },
  "surfaces": [
    { "format": "mcp",  "url": "https://…/helius-mcp", "tools": ["getAsset","sendTransaction","createWebhook"] },
    { "format": "rest", "openapi": "https://…/helius-openapi.json" }
  ]
}

The credential guide is the whole point. An agent that finds "Helius has an MCP server" still can't use it until it knows the key goes in ?api-key=, where to mint one, and how to scope it. Publishing that once, in a machine-readable form an agent can act on, is higher-leverage than another blog post — and right now no Solana service has done it.

Where it sits in the agent stack

integrations.sh isn't competing with MCP or with agent payments — it's the discovery layer beneath both. The full loop for a paid Solana service looks like three composable pieces:

1. DISCOVER   integrations.sh  → agent learns the service exists,
                                 which surface to use, and how to auth
2. CONNECT    MCP               → agent speaks to the service's tools
3. PAY        x402 on Solana    → agent settles per-call in USDC,
                                 sub-second, sub-cent

We've covered the bottom two layers in depth: x402 + MCP agent payments, the agentic payments landscape, and Solana's own registries like the Solana skills directory and ProofNetwork's MCP skills server. integrations.sh is the missing top layer — the cross-ecosystem index where an agent that has never heard of Helius can find it.

One design choice is worth flagging for anyone building agents that touch wallets: integrations.sh carries depends_on edges on every contributed connector, and its planned execution model derives a domain allowlist from those edges — a snippet that declares it needs Gmail can reach gmail.googleapis.com and nothing else. Trust is enforced at execution, not attribution. That is precisely the containment property you want when an agent is authorized to send transactions or read a key, and it's a model Solana agent frameworks should copy.

The takeaway

The map of the agent-reachable internet is being drawn right now, one cited credential guide at a time, and Solana is a blank region on it. That's not a knock on the ecosystem's tooling — it's a distribution gap. The agents that will consume Solana services in a year are learning what exists from indexes like this one. If you run Solana infrastructure — an RPC, an API, an MCP server — the highest-leverage hour this month is publishing your service and its credential guide to integrations.sh/publishing so the next agent that needs you can actually find and authenticate to you.