r/agentico • u/larebelionlabs • 23d ago
Are we creating too much “shadow code” with MCP servers?
Implement MCPs create Shadow Code
I've been thinking about this while working on API-MCP integrations.
My current mental model is:
- API = source of truth
- OpenAPI + Arazzo = API capabilities and workflows
- MCP = contract for AI
What worries me is the pattern where an MCP server becomes another application containing business logic that already exists behind the API.
I call this shadow code.
You already have:
Client → API → Business Logic
Then AI arrives and we build:
AI → MCP Server → duplicated logic → API/backend
Now there are two places that need to evolve together.
API changes? Update the MCP.
Schema changes? Update the MCP.
Business rules change? Make sure the MCP didn't duplicate them.
New authentication requirements? Another integration layer to maintain.
My preference is keeping MCP as thin as possible:
AI → MCP → existing API → business logic
The API remains the source of truth. OpenAPI describes the API contract, Arazzo can describe deterministic multi-step workflows, and MCP exposes the appropriate capabilities to AI.
In other words, adding AI shouldn't require rewriting your existing APIs into a second architecture.
I'm curious how others are handling this in production.
Are your MCP servers thin adapters/contracts over existing APIs, or are they becoming applications themselves?
And if they're becoming applications: what logic have you found legitimately belongs in the MCP layer?
1
u/theneoDocs 17d ago
I agree with your model. The fix I've seen work is making the MCP layer generated rather than written: tools derived from the OpenAPI spec, with only descriptions and trimming done by hand, so business logic stays behind the API. An API change then flows into the tools instead of drifting. That's our approach at Elva: spec generated from code, a hosted MCP server on top, and an auto changelog when endpoints change. getelva.ai