Rethinking MCP: From App to Workflow Servers


The core insight driving this analysis: “Users don’t care about servers, they care about actions and outcomes.” After extensive experience building MCP servers for daily operations, I’ve identified a fundamental architectural challenge affecting user experience.

The Problem

Tool Limits

Platforms like Claude enforce strict tool caps (40 maximum), requiring constant toggling between tools. This creates risks when tools have dependencies—for instance, retrieving Jira metadata before ticket creation—that the LLM may not recognize.

MCP Architecture

Performance Degradation

Excessive tools degrade LLM performance through:

  • Unnecessary web searches despite adequate context
  • Ambiguity when the same term appears across multiple systems (e.g., “ticket” in both Jira and Pylon)

Tool Customization

Generic tools often fail specific workflows. A workflow requiring engineering bug tickets differs from one needing integration tickets, yet both use identical “Create Jira ticket” functionality.

Two Extreme Approaches

Option 1: Open Approach — Provide all tools and context, controlled through prompts

Option 2: Scoped Approach — Restrict agents to workflow-specific tools with focused prompts

I advocate for the scoped direction, valuing consistent outcomes over maximum flexibility.

Workflow-based Architecture

Proposed Solutions

Better LLM Clients

Improve tool interaction within existing LLM platforms through enhanced interface design.

Workflow-Based Tool Servers

Decouple tools from app-centric servers, allowing users to bundle platform tools into workflow-specific servers. Sales teams, for example, might read Pylon and Jira tickets but never create Jira tickets.

Key Implementation Areas:

  • Authentication: Control available tools at the app level post-authentication
  • Customization: Tailor generic tools for specific use cases through configuration
  • Bundling: Create workflow servers containing only necessary cross-platform tools
  • Prompts: Bundle system prompts with tool collections for consistency
  • Portability: Enable workflows across multiple platforms (Raycast, Claude, Relay.app, etc.)

Better Tool Calling

Improve the mechanism for determining appropriate tool usage, essential as app ecosystems expand.

Conclusion

The workflow-based approach aligns infrastructure with how people actually work—outcome-focused rather than platform-focused. The future likely involves all three solutions operating in parallel, delivering substantial improvements to AI-assisted workflows.