Why We Built an MCP Layer

Multi-repo ecosystems need a single place to discover services, fetch OpenAPI, and align on versions.

When a system grows beyond one repo, people start solving the same problem repeatedly:

  • “What is the base URL for this service in dev?”
  • “Where is the OpenAPI schema?”
  • “Did the schema change?”
  • “What capabilities does the service expose?”

The naive approach is to hardcode answers in multiple places. That works until it doesn’t, and then it becomes a maintenance tax.

MCP as the integration point

In our ecosystem, MCP is the central place to:

  • discover services and their environment-specific base URLs
  • fetch OpenAPI JSON and cache snapshots
  • read capabilities and version metadata
  • expose a design system manifest for UI alignment

This makes the system easier to automate. It also makes agent workflows more reliable: tools ask MCP, not random files or ad-hoc scripts.

What “robust fetching” means

Fetching OpenAPI in production is not the same as in local dev. You need to handle:

  • auth and scoped metadata permissions
  • content-type mismatches
  • invalid JSON with actionable error snippets
  • caching via ETag or upstream version identifiers

We built those behaviors into the platform so every consumer benefits.

The payoff

The payoff is not just convenience. It’s consistency:

  • fewer surprises when a schema changes
  • fewer “works on my machine” mismatches
  • fewer silent breakages across repos

MCP is the boring part of the system. That’s why we’re investing in it early.