Critique of MCP's Abstraction Boundary and Service Integration Approach

A Reddit discussion on r/ClaudeAI examines where MCP draws its abstraction boundary and argues it gets this wrong in a way that goes beyond typical implementation criticisms like security, token bloat, or transport issues.

Core Argument About Service Integration

The post identifies three separate concerns when an agent needs to work with a service: API access, efficient tooling that wraps it, and domain knowledge about how to use it well. According to the source, MCP bundles all three into one layer, resulting in a limited subset of what the underlying API can actually do.

Lattice as a Concrete Example

The discussion uses Lattice as a specific example. Their web client is powered by a full GraphQL API that covers everything an employee would want to do. However, their public API only covers HR admin workflows. The post argues that MCP incentivizes services to build yet another limited interface rather than just opening up the APIs they already have.

Proposed Alternative Approach

The author suggests a better path: services making their primary APIs universally accessible, noting that the authentication problem is already solved by OAuth 2.0 with PKCE. Domain knowledge should be distributed as agent skills rather than baked into MCP tool definitions.

The full post is available at tomyandell.dev/blog/my-problem-with-mcp, and the Reddit discussion invites others to share their thoughts on whether this critique of the abstraction boundary is correct.