AI
The Two Sides of MCP
Servers give clients three things. Tools are functions the client calls to take actions. Resources are read-only data like file systems that add context. Prompts are templated instructions and workflows. Ganguly called tools the most used feature and prompts the least used. The other direction is less discussed: clients give servers sampling (requests to use the client’s LLM), roots (file system boundary hints), and elicitation (asking the end user for more information). Elicitation cannot ask for sensitive details like passwords. URL elicitation sends the user to a browser for OAuth or payment flows.
Agents Using Agents via MCP
Sub agents are practically client‑server pairs. An overall agent plans a task and creates smaller agents for isolated pieces. Context management is the game: agents focused on one thing outperform general agents. Trust boundaries matter most. When an agent crosses from one organization to another, separate agents become necessary. Ganguly cited David Cramer’s Sentry MCP server experiment, which added an agent mode. The mode used a prompt that said “I’m an agent too. Let me do it too.” It started as a context management trick but reemerged as a trust boundary solution.
OAuth in a Multi‑Agent World
MCP’s OAuth flow assumes a client gets a token for one server. Ganguly showed what happens when that server (agent B) needs its own downstream credentials. URL elicitation lets agent B ask agent A to send the user to a login page. But when a main agent talks to three downstream agents—Linear, a custom service, and Sentry—the consent chain breaks. Every sub agent requires another consent screen. MCP assumes a human is always present with the client. Autonomous agents like Open Claude challenge that assumption.
Runtime Discovery and State Problems
Preconfigured server connections work. Runtime discovery does not. Agents need a way to discover what other agents can do on the fly. Ganguly noted tools discovery exists today, but a directory of servers at runtime is still missing. Client‑server design assumes one hop at a time. Long‑running tasks, peer‑to‑peer connectivity, and cross‑hop state are not priorities. State lives mostly on the client. Servers are stateless thumbs‑ups. Stretching MCP into agent‑to‑agent territory reveals these gaps.
What’s Next: Enterprise Auth, Server Cards, and Triggers
Ganguly pointed to three roadmap items. Enterprise managed authorization lets identity providers give a single grant so users do not consent multiple times. The server cards project looks like agent cards for runtime discovery. Nested task execution is planned for long‑running tasks with check‑ins. Triggers and event‑driven updates are explicitly on the MCP roadmap. Ganguly closed with a pitch: vendors build agents for their own products because they can do it better than customers, and agents expose functionality as servers.
Q&A
Can you pass task flow IDs downstream for nested tasks? Yes, that is exactly what the nested task execution specification intends to solve for delegation of tasks and permissions. ▶ Watch (19:32)
Are there planned extensions for verifiable credentials in MCP? Several projects exist around workload identity and federation, but I do not know about verifiable credentials specifically. ▶ Watch (20:31)
Notable Quotes
“We often look at the server as just this is the tools that I need to give my client. And I agree it’s a great use case. It is the simplest use case. It is the reason why MCP became popular. But there’s also features that clients can give to servers.” Rohit Ganguly · ▶ Watch (5:18)
“If I’m building an agent that’s supposed to be for my project, my product, my service, why wouldn’t I build the agent? because then I don’t need to get someone else’s agent to use my product. I can build a specialized agent that actually uses my project well and very effectively.” Rohit Ganguly · ▶ Watch (10:30)
“MCP wasn’t designed for this, but a lot of the points I mentioned earlier are having, you know, they they are working on this.” Rohit Ganguly · ▶ Watch (16:06)
Key Takeaways
- MCP’s asymmetry: servers offer tools, resources, prompts; clients offer sampling, roots, elicitation.
- Agent-to-agent MCP solves trust boundaries but breaks OAuth consent chains and runtime discovery.
- Vendors should build specialized MCP agents for their own products rather than relying on third-party clients.
About the Speaker(s)
Rohit is an AI Product Manager at Descope, where he leads the MCP Auth and Agentic Identity efforts. Previously, he worked in Microsoft’s Developer Division across products like the Azure SDKs and VS Code before launching the Azure MCP Server.