# MCP is not going to change everything (yet)

Sam Partee, Arcade AI & Rahul Parundekar, AI Hero | MLOps Community | 1:04:43
Hosted by Demetrios Brinkmann

Source: https://www.youtube.com/watch?v=5_Ii1JkD0wY
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/mcp-is-not-going-to-change-everything-yet
Published: 2025-05-21
Tags: evals, human-in-the-loop, security, tool-use

## TL;DR
- An agent combines a language model with deterministic processes it can call, and tools expand what the model can access and do.
- MCP still has serious problems around delegated permissions, server trust, transport, testing, and long-running tasks.
- The useful future may involve AI-native services that agents can call under explicit contracts, rather than a giant marketplace of loosely described tools.

## Summary
The conversation defines an agent as a language model that can pass text into deterministic processes and run them as tools. Tools let models retrieve private information and take actions, but action creates difficult security problems. An agent may need to act as a user with narrowly scoped permissions, rather than receive a broad bot token. The speakers describe MCP as a young ecosystem with community-built servers, immature authorization, changing transports, and weak testing practices. They compare MCP with agent-to-agent delegation, where a service hides its internal process and promises to complete a task. The discussion then moves to tool descriptions, observability, model regressions, memory, unlearning, asynchronous work, and approval steps. Their preferred direction is a set of AI-native services with clear interfaces, auditing, testing, and contracts. They are skeptical that simply adding more tools or creating an MCP proxy will solve the underlying problems.

## Key ideas
### Tools connect language models to deterministic actions
[01:26](https://www.youtube.com/watch?v=5_Ii1JkD0wY&t=86s)
Sam Partee defines an agent as a piece of text produced by a large language model, a way to feed that text into a deterministic process, and a way to run the process. Any function can become a tool when the model's output can serve as its input. Rahul Parundekar adds that tools let a model retrieve information it did not memorize and act on it. This differs from reasoning: reasoning is the model thinking through a problem, while tools retrieve data or perform actions. The example is a model searching the web or accessing private enterprise files and databases.

### MCP has to handle delegated user permissions
[03:30](https://www.youtube.com/watch?v=5_Ii1JkD0wY&t=210s)
The hardest part begins when an agent acts for a person. The speakers warn that a model asked to edit a file could decide to delete everything, or that an agent with database access could drop tables. A bot token with broad access is not enough because the agent needs to act with the user's permissions for a particular task. Their proposed flow adds an agent between the user and service: user, agent, site, service. Listing recent Stripe payments and making a Stripe payment should require different scopes, claims, and permissions. The agent also needs a way to stop and ask the user before a sensitive action.

### The MCP ecosystem is still immature and hard to trust
[09:41](https://www.youtube.com/watch?v=5_Ii1JkD0wY&t=581s)
The speakers describe fewer than 200 official MCP servers and many community-created servers. They question who runs a server or proxy on a user's machine and what privileges it receives. They criticize configuration flows that ask developers to paste long-lived tokens into newly created websites. Transport choices are also changing. They recommend moving from the older HTTPS SSE approach to streamable HTTPS because serverless deployments need to reattach to a server after interruptions. Official discovery and authentication metadata, such as the example discussed for Stripe, could make it easier to find the real service instead of copying code from an untrusted source.

### Agent-to-agent delegation hides implementation details
[14:28](https://www.youtube.com/watch?v=5_Ii1JkD0wY&t=868s)
The discussion contrasts MCP with Google's agent-to-agent approach. MCP exposes tools and lets one agent control the sequence of actions. Agent-to-agent delegation lets a service receive a task and decide internally how to complete it. Rahul Parundekar uses a KYC provider as an example: the client could ask the provider to perform KYC without knowing whether it needs criminal-record checks or another investigation. Sam Partee is less convinced that a separate protocol is always needed, since one agent can call another through a typed tool call and remain observable. They agree that payments and enterprise services may need explicit trust, contracts, and handoff rules.

### Tool descriptions need their own testing and evaluation
[22:56](https://www.youtube.com/watch?v=5_Ii1JkD0wY&t=1376s)
The speakers argue that tool descriptions and annotations are becoming a programming layer for agents. Developers should be able to test whether a tool produces the expected kind of result, whether a date falls within a range, or whether text is semantically close enough to an expected answer. They ask why teams do not already run continuous integration for tool descriptions and agent behavior. Model providers can change behavior under the same model name, so smoke tests should reveal when a new release breaks an agent. Tool developers and agent developers are becoming separate roles, which makes ownership of testing and evaluation more important.

### AI-native services should expose a task interface
[37:32](https://www.youtube.com/watch?v=5_Ii1JkD0wY&t=2252s)
Rahul describes a future in which an AI-native company does not put AI in its marketing promise. Instead, it designs a service from the bottom up around a specific action and lets an agent use it through a protocol. His KYC example is a service that handles the whole process and returns an agreed result. The open issue is how the client knows what that result means and whether it is reliable. The speakers discuss older service-discovery and ontology problems, where two systems may use different words for similar concepts. Language models may help map between schemas, but Sam says that remains a bet rather than a guarantee.

### Memory needs success paths, corrections, and time
[45:34](https://www.youtube.com/watch?v=5_Ii1JkD0wY&t=2734s)
The speakers compare agent memory to trails up a mountain. An agent that succeeds through one path should remember that path instead of randomly trying again. But memory can also preserve mistakes. Sam gives the example of a system continuing to call him Alex because of one earlier email. They say memory must account for the user, service, and action, while preferences, vendors, and contracts change over time. A complete system also needs unlearning or rollback when a stored preference is wrong. Long-running work creates another gap: crawling a website or completing a task over a week needs scheduled checks and background processing rather than one permanently open connection.

### Human approval remains part of real work
[55:10](https://www.youtube.com/watch?v=5_Ii1JkD0wY&t=3310s)
The final section moves from individual agent actions to organizational workflows. A product launch may involve a product manager, writers, reviewers, and approvals, and the speakers say agents have not yet solved this end-to-end coordination problem. They like interfaces where an agent gathers information, drafts a result, and pauses for a person to approve it. Rahul argues that people should rethink how work gets done and use AI as a regular part of the process, while still applying human creativity and judgment. Sam says companies may be outpaced by one person who learns to work extremely well with tools such as Cursor, rather than by a large army of autonomous agents.

## Notable quotes
- Sam Partee: "MCP is not prepared to act as anyone." (03:30)
- Rahul Parundekar: "You don't want it to send an email as the bot. You want it to send an email as you." (06:24)
- Sam Partee: "Why don't we have a CI for it?" (26:37)
- Sam Partee: "I think memory is one of the hardest things and one of the most underestimated." (48:55)
- Rahul Parundekar: "You're not going to get beat by an army of agents that are programming. You're going to get beat by one person." (1:01:45)

## Tools & references mentioned
- Model Context Protocol
- MCP
- Arcade AI
- LangChain
- LlamaIndex
- Smithery
- Spotify
- Stripe
- Vercel
- Google agent-to-agent protocol
- A2A
- LangGraph
- Salesforce
- PostHog
- FastMCP
- Cloudflare R2
- Celery
- Cursor
- Anthropic
- OpenAI
- Andre Karpathy
- Harrison Chase
- Vanta
- Redis

## Who should watch
- You are building an MCP server or agent and need to decide how to handle permissions, authentication, testing, and deployment.
- Your agent can call tools, but you do not yet have approval steps, audit logs, regression tests, or a plan for model changes.
- You are evaluating MCP against agent-to-agent services and want concrete examples involving KYC, payments, memory, and long-running work.

## Related talks

- [Responsible Autonomy: Building Governance Frameworks for AI That Act in the Real World via MCP](https://mlopstalks.com/talks/responsible-autonomy-building-governance-frameworks-for-ai-that-act-in-the-real) (Saurabh Mishra, Optum, 27:55)
- [AI Agents Are About to Get Real, Here's Why It Matters](https://mlopstalks.com/talks/ai-agents-are-about-to-get-real-heres-why-it-matters) (Sam Partee, Arcade AI, 13:20)
- [MCP Security: What Happens When Your Agents Talk to Everything?](https://mlopstalks.com/talks/mcp-security-what-happens-when-your-agents-talk-to-everything) (, 24:26)
- [Enterprise-ready MCP](https://mlopstalks.com/talks/enterprise-ready-mcp) (Jiquan Ngiam, MintMCP, 28:36)
- [Yes, we do need MCP](https://mlopstalks.com/talks/yes-we-do-need-mcp) (Ben Hindman, reboot.dev, 26:32)