Topic
MCP
8 episodes
-
Building Agents for Teams: Turning conversations into outcomes Microsoft 365 Developer Blog
The Microsoft Teams dev blog argues agents should live *in* chats, channels, and meetings—where work happens—so teams turn conversations into outcomes in real time. They preview a new monthly series and a Teams SDK that hands devs authentication, routing, and MCP/A2A plumbing so you can ship a task agent in hours. We dissect whether ‘collaborative agent’ is the right abstraction, how MCP and A2A are now the default integration layer, and who this actually helps.
-
The MCP debate has a context problem
Ava opens skeptical on the 'MCP context problem' framing—questioning whether the article's governance tension is a real bottleneck or a vendor-invented problem. Vince steelmans: for teams actually shipping agentic workflows, the boundary between what an agent can access and what it shouldn't is genuinely hard to specify upstream, and MCP's protocol-layer answer to that is a real unlock. They argue through whether the problem is *real* (both land yes) versus *urgent* (Ava: solved at runtime anyway; Vince: solved earlier costs less). Honest verdict: MCP's governance layer is architecturally sound but the article oversells urgency—the real win is that you CAN specify it at protocol time now, not that you MUST.
-
MCP gets its missing enterprise authorization layer
MCP (Model Context Protocol) has been missing a proper authorization layer for enterprise deployments—the protocol itself handles tool definitions and interoperability, but doesn't specify who can call what tools or enforce access controls at the protocol level. A new enterprise authorization layer fills that gap by adding fine-grained permission boundaries, letting teams enforce 'agent A can call tool X with parameter Y, but not Z' without rebuilding the entire agent harness. The insight is that authorization is a runtime problem in cloud-native systems, not a model problem—and MCP needed to solve it at the protocol boundary, not in application code.
-
Why pgEdge thinks MCP (not an API) is the right way for AI agents to talk to databases
Episode 268 of Exploring Next discusses pgEdge's approach to AI agents talking to databases using MCP, a non-API solution. Izzo and Boone dive into the substance of MCP, explaining its key mechanisms, design choices, and architecture. They connect it to real-world problems and current trends, exploring the product angle and tech behind it.
-
Anthropic extends MCP with a UI framework
Anthropic's latest extension of its MCP (Managed Conversation Platform) introduces a UI framework, allowing developers to create customized applications that leverage AI capabilities. This development could democratize access to advanced AI tools and improve application design.
-
Anthropic working on MCP Apps with interactive UI components
Anthropic is enhancing its Claude Cowork platform with new interactive UI components that can revolutionize how users engage with AI applications. This development could streamline workflows, improve collaboration, and empower developers to create richer interactions, drawing clearer parallels with existing technology.
-
Agent Skills vs MCP
The discussion centers on the relationship between Skills and MCP (Multi-Channel Protocol) in AI development, emphasizing how they complement rather than replace each other. Host A and Host B explore the implications of this synergy, the role of institution knowledge, and how this understanding can improve AI functionality in real-world applications.
-
Stumbling into AI: Part 6—I’ve been thinking about Agents and MCP all wrong
Ever tried to hammer a nail in with a potato? Nor me, but that’s what I’ve felt like I’ve been attempting to do when trying to really understand agents, as well as to come up with an example agent to build.