top of page
Navigating the Technology Landscape This visual captures the essence of Techquity’s mission—guiding companies through the complexities of today’s tech terrain. The glowing circuits reflect innovation and connectivity, while the undulating landscape symbolizes the inevitable ups and downs of technology transformation. At Techquity, we bring clarity, structure, and momentum to help our partners traverse this evolving landscape with confidence.

I Want My MCP!

  • Writer: Brian Lakamp
    Brian Lakamp
  • Jan 30
  • 5 min read


For twenty years, enterprise SaaS vendors have optimized for human operators. They addressed pain points acute enough to convince their customers' finance teams to underwrite the expense. Once entrenched, they optimized UIs, simplified onboarding flows, and counted seats. The model worked because humans were comfortable clicking through interfaces, forgiving enough to interpret ambiguous API documentation, and paying on a per-user basis made sense.


Now the target user is evolving.


Agents are evolving into primary users, which requires SaaS providers to rethink and reposition their offering. Agents don’t care about carefully crafted user interfaces. Agents don't behave predictably with ambiguity. 


Agents are powerful but have limited context windows, so they benefit from structured context to be successful in composing tasks and chaining across multiple systems. Like humans, they benefit from clear "onboarding" for the task and their role in achieving the end result.


Existing SaaS APIs weren't built for this. They were not designed for agents and LLMs. 


The API Gap


Most SaaS APIs were built for developers who write integration code, not for agents that need to chain micro-operations. APIs commonly return large payloads (e.g. a CRM API might return 50 fields when an agent only needs 3.)


That's not just inefficient; it's context bloat that burns tokens, dilutes intent and slows agent reasoning. Worse still, API documentation is often sparse, inconsistent, and assumes human interpretation of gaps. "The user object contains various fields" is not a specification an agent will reliably interpret.


An MCP (Model Context Protocol) is a deterministic, AI-native interface that exposes discrete, tightly scoped actions through LLM-interpretable schemas. “Agent-ready” means interfaces that behave predictably and can be composed without requiring human interpretation.

Agents need MCPs, predictable interfaces that are cleanly described, tightly scoped, and expose only what's required for a specific action… not everything SaaS APIs typically return. Just the precise building blocks that enable reliable composition.


The Wrapper Fallacy


In the early days of MCP adoption, a common assumption emerged. “Just wrap your existing API in MCP format and you're done”. Translate REST endpoints to MCP tools, generate some schema definitions, and ship it.


That's a fallacy.


Enterprise agents require infrastructure that the MCP standard alone doesn't provide:


  • Authentication that works across organizational boundaries

  • Security models that handle delegation and access control

  • Scalability that supports agents making thousands of calls per minute

  • Observability that traces calls across vendor boundaries

  • Analytics that capture new usage measurements and reveal new patterns

  • Monetization scaffolding that captures the usage economics of agent work


All of this must be built as enterprise-grade infrastructure around the MCP standard itself.


But even with all that infrastructure in place, it's insufficient to simply re-express old APIs as MCPs. SaaS APIs were designed for flexibility and comprehensiveness. Agents demand the opposite: stricter definitions, tighter scoping, with precision on inputs and outputs. If an agent is going to rely on an MCP as part of a multi-step workflow, that MCP must behave like a reliable component in a deterministic system, not a flexible endpoint that might return different shapes of data depending on the request.


The Business Model Challenge


When the user is an agent, seat-based licensing doesn’t work. An agent doesn't "use" a SaaS platform the way a human does. It doesn't log in Monday through Friday, 9-to-5, bound by the limitations of human productivity. An agent might make 1,000 calls in an hour at 3 AM.


The shift demands usage-based pricing. But what defines "usage"? API calls are granular. Tokens processed don't capture business value. Tasks completed require defining what constitutes a "task." Outcomes delivered come closest to value but are hardest to measure.


The answer is some combination, but many legacy SaaS vendors haven't begun this conversation. Many are still thinking about "power users" and "seat expansion." Meanwhile, their APIs are increasingly being called by agents that represent entire teams, entire departments, entire workflows.


If usage is the answer, the next question becomes: How do you price discrete agent actions in a way that reflects both computational cost and business value?

Pricing needs to reflect the modular nature of MCP actions. Maybe title.find_by_titleID costs $0.001 because it's a simple lookup. Maybe orders.generate_annual_summary costs $0.05 because it's computationally expensive and delivers high value. Maybe media.transcribe_and_analyze costs $0.50 because it involves AI processing and storage.


This requires better metering, clearer tracking, and transparent pricing models that make sense to the workflow builder, not just the end customer.


The Observability Requirement


When humans interact with one SaaS product at a time, debugging is messy but manageable. You check logs. You retry the action. You file a support ticket.

When agents chain MCPs from five different vendors into a single workflow, that approach collapses. Imagine: an agent workflow fails at step 7 of 10. Which MCP broke? Was it bad input from step 4? A timeout at step 6? A schema mismatch? A rate limit you didn't know existed?


Without common observability, you're flying blind.


Every MCP call needs:


  • Trace identifiers that follow a request across vendor boundaries

  • Structured logs in consistent formats

  • Performance metrics (latency, token usage, cost)

  • Clear error taxonomy (transient vs. permanent failures, retry-able vs. not)

  • State visibility for debugging multi-step workflows


This isn't optional. Without it, you can't maintain deterministic workflows. You can't debug failures. You can't maintain trust in the system. 


From MCPs to Agentic Ecosystems


For legacy SaaS providers, the challenge isn't just creating an MCP interface. It's about strategically integrating into a larger environment where those interfaces compose reliably with other resources. The individual problems explored above (authentication, pricing, observability) aren't isolated technical hurdles. They're symptoms of a fundamental architectural shift.


Here's what's coming into focus. The future won't be a collection of isolated MCPs published by each ecosystem vendor. The future lies in robust, vertically-oriented agentic ecosystems with shared standards for authentication, observability, economics, and composable workflows.


SaaS providers who treat MCPs (and the agentic ecosystem in which they live) as afterthoughts, as “just another API to maintain”, will watch their relevance wither and seat revenue erode. Those who build for predictable composition will find themselves integrated into far more workflows than their original SaaS platforms ever enabled.


The Stakes


This transition is not optional. The platforms most vulnerable are those that built moats around data and complex UIs. Both can be unbundled into discrete MCP actions and recomposed by someone who understands agent workflows better.


The disruptors are already building. They're MCP-native from day one. They're not burdened by legacy APIs designed for developers. They're not trying to protect seat-based revenue. They're designing for a world where agents are the primary user, and they're moving fast.


Incumbents may have only 24 months before workflows start ossifying around the vendors who got there first. After that, it’s not about competing on features or UI; it’s about competing on whether agents can even access legacy capabilities in a workflow.


The platforms that make the leap early will define the next decade. They'll be the reliable building blocks that agents reach for first. They'll capture economics from thousands of workflows they never imagined.


The ones that wait will watch their functionality be rebuilt by someone else, someone who understands that the agent doesn't want the legacy platform. It just wants context, cleanly packaged and reliably delivered.


The agentic era is here. Legacy SaaS vendors can keep upgrading their UI and counting seats, or they can pursue an MCP strategy that fits how work will be done.



 
 
 

Comments


bottom of page