Idea: fetch ecosystem partner docs (OpenZeppelin, Alchemy, providers) as live-fetch sources via mcp

[kalepail]

Note

Migrated from kalepail/stellar-raven#18. Originally opened by @mmazco on 2026-07-09.

Context — our thinking (briefly): A couple of us at SDF have been looking at how well Stellar's developer surface serves agents, not just humans, and Raven is central to that story — so we've been reading how it sources content. This is a suggestion in that spirit; happy to be told it's already on the roadmap or out of scope.

Observation: Raven's three live adapters are all Stellar-first — official docs (Algolia), Lumenloop, and Stellar Light. Ecosystem partner docs are handled differently. Two examples:

• OpenZeppelin — present only as a manually-synced skill mirror (ecosystem-skills/skills/openzeppelin-stellar/), so it refreshes on a human re-sync cadence rather than live.
• Alchemy — not fetched at all, and here's a concrete, current case: Alchemy ships a Stellar Data API (their docs) — indexed transfer history, balances, and NFT holdings — that was documented on their side but missing from the official Stellar docs, so neither our docs nor Raven surfaced it. @mmazco pushed a PR to stellar-docs to add it on our side (Update Alchemy entry on Indexers page — Stellar Data API is now live stellar/stellar-docs#2573); the systemic point is that Raven has no way to pick up partner-side updates like this automatically.

Why it might matter: Partner surfaces move on their own cadence, and Raven's own eval corpus already flags provider/partner rosters as among the most freshness-sensitive content. An agent asking about a partner's current capabilities can get a stale answer even when the official docs are live.

One idea: where a partner already exposes its own MCP server (or a public API), Raven could tap into that directly rather than maintaining a bespoke mirror. So partner updates flow through automatically. Would that be a direction worth exploring?

[kalepail]

Note

Copied from the original comment by @oceans404 on 2026-07-09.

+1 and ideally we'd tap into their docs mcps if they have them!

[kalepail]

Note

Copied from the original comment by @mmazco on 2026-07-09.

yep which most should have by now

+1 and ideally we'd tap into their docs mcps if they have them!

[kalepail]

Note

Copied from the original comment by @mmazco on 2026-07-09.

Follow-up on the Alchemy example, just pushed this PR to stellar-docs Stellar Data API is live Alchemy stellar/stellar-docs#2573

[kalepail]

Note

Copied from the original comment by @kalepail on 2026-07-31.

Closing the loop on this, with a real answer rather than a "noted, thanks".

The concrete example healed, from two directions. Alchemy's Stellar Data API is now on the official Indexers page via your PR (stellar/stellar-docs#2573) — we tracked that as sd-010, live-verified it on 2026-07-15, and it's retired to our resolved ledger. Independently, stellarlight#446 had already corrected the ecosystem alchemy record to name both products and add the Indexer type, four days earlier. So Raven surfaces it now through two lanes.

The systemic point survives that, and you're right about it. Both fixes took a human noticing and shipping. That's the cadence problem you named, and closing the acute instance doesn't answer it.

Where we landed, in two parts:

No partner-MCP federation — this declines @oceans404's "ideally we'd tap into their docs mcps" and @mmazco's "most should have by now" directly, so it owes you a reason rather than a verdict. The reason is what those servers currently are, not a position on MCP: Alchemy's hosted MCP is 168 tools behind OAuth 2.1 including create_app and update_allowlist; OpenZeppelin's advertises contract generation, not documentation retrieval. Raven's core boundary (ADR-0003) is that model code never owns endpoints, arguments, auth, or exposure — federating either would hand that decision to the partner, and their tool surface would change under us without a repo change. We'd reopen this for a genuinely different shape: a read-only, unauthenticated, documentation-scoped partner MCP with a stable tool contract. A partner adding more tools is evidence against, not for.

Allowlisted first-party partner Markdown is credible — and it's the mechanism that would actually deliver what you're asking for. It's designed, it has a measured retrieval harness, and it's held behind a four-phase ship gate with a dated review (2026-10-31) and explicit reopen triggers.

The most interesting thing we learned is a caution about our own answer. "Partner content reaching the official docs gets caught by our improvements pipeline" turns out to be too glib. stellarlight#565 found that after #2573 was ingested, a bare q=Alchemy still returned zero results, and the chunk documenting the Data API ranked below top-15 for its own brand query. Ingested is not retrievable. That argues for fixing retrieval upstream before adding a source here — and the same upstream is now doing exactly that, including a data-providers research anchor built for this issue's exact case (#657) and a monthly partner coverage-and-freshness watch (#561).

The full record — decision, evidence, gate, triggers, and re-evaluation requirements — is landing as ideas/partner-doc-live-sources.md, with the harness and case corpus alongside it. Credit where it's due: that analysis and the eval work are @pedro-pelicioni's, in #58 and #57.

Leaving this open as the parent for the held lane rather than closing it, since the systemic question is still live. If you hit a case where a current first-party partner page has a fact that no exposed source will quote, that's precisely the reopen trigger — please drop it here.