Research: Mapping Production Deep-Agent capabilities to MCP Agents

[madhaviai]

This document captures observations from building and operating production deep-agent systems and compares those capabilities against existing MCP primitives and emerging MCP extensions.

The goal is not to propose a specific solution, but to understand:

• Which production agent capabilities are already covered by MCP
• Which capabilities can be modeled using existing MCP patterns
• Where protocol gaps may exist for agent-oriented systems
• Which areas may benefit from future agent definitions, delegation primitives, capability discovery, or orchestration-related extensions

[LucaButBoring]

Sorry for the delay, I meant to follow up on this much sooner - to continue from our discussion on Friday, what I had in mind is conceptually just letting each MCP server declare its own dedicated subagent(s), something like this (not protocol-rigorous, but just to demonstrate the execution model I'm thinking of):

sequenceDiagram
      participant User
      participant Host as Host / MCP Client
      participant Sup as Supervisor LLM
      participant Server as MCP Server
      participant Sub as Local Sub-agent LLM

      Note over Host,Server: Discovery
      Host->>Server: agent/list
      Server-->>Host: agent summaries<br/>[id, description, capabilities]

      User->>Host: Check failed pipelines and pending approvals
      Host->>Sup: user request + agent summaries
      Sup-->>Host: select "workflow-agent"

      Note over Host,Server: Resolve only the selected agent
      Host->>Server: agent/get<br/>{agentId: "workflow-agent"}
      Server-->>Host: agent definition<br/>{instructions, tools: [Tool]}
      Note over Host: Construct sub-agent locally.<br/>Tools belong to this same server.

      Host->>Sub: task + instructions + scoped tools

      loop Local sub-agent tool loop
          Sub-->>Host: call list_failed_pipelines
          Host->>Server: tools/call list_failed_pipelines
          Server-->>Host: CallToolResult
          Host->>Sub: tool result

          Sub-->>Host: call list_pending_approvals
          Host->>Server: tools/call list_pending_approvals
          Server-->>Host: CallToolResult
          Host->>Sub: tool result
      end

      Sub-->>Host: compact task result
      Host->>Sup: sub-agent result
      Sup-->>Host: final response
      Host-->>User: response

Loading

We might represent the result of agent/list as something like this:

[
  {
    "name": "workflow-agent",
    "description": "Used to check pipeline workflows",
    "systemPrompt": "hello",
    "model": "openai:gpt-5.5", // unsure about this one, model IDs are very inconsistent
    "tools": ["list_failed_pipelines", "list_pending_approvals"] // each entry must be a tool from the same server
  }
]

In Deep Agents code, that would mean that we basically get to just swap out the subagent definition with a couple of calls to the MCP server to get the appropriate definitions to register instead:

# research_subagent = {
#     "name": "workflow-agent",
#     "description": "Used to check pipeline workflows",
#     "system_prompt": "hello",
#     "tools": [list_failed_pipelines, list_pending_approvals],
#     "model": "openai:gpt-5.5",
# }
subagents = research_server.list_agents()  # Makes an agent/list call to the MCP server
subagents = map_to_deep_agents(subagents)  # Converts to the actual format Deep Agents uses, with actual tool handlers

agent = create_deep_agent(
    model="google_genai:gemini-3.5-flash",
    subagents=subagents,
)

The entire subagent would run completely locally, but we would be constructing it from metadata provided by the MCP server itself in a generic way; the only constraint is that each subagent's capabilities are limited to what that singular MCP server offers, and can't reference capabilities exposed by sibling MCP servers.

---

As for nested subagents, we could probably make that work too with a slight tweak to the agent/list shape above:

[
  {
    "name": "workflow-agent",
    "description": "Used to check pipeline workflows",
    "systemPrompt": "hello",
    "model": "openai:gpt-5.5",
    // We would generalize to a list of permitted capabilities and support passing both tools and agents to it
    "capabilities": [{ "type": "tool", "name": "list_failed_pipelines" }, { "type": "tool", "name": "list_pending_approvals" }, { "type": "agent", "name": "github-agent" }]
  },
  {
    "name": "github-agent",
    "description": "Used to check GitHub stuff",
    "systemPrompt": "hello",
    "model": "openai:gpt-5.5",
    "capabilities": [{ "type": "tool", "name": "list_branches" }, { "type": "tool", "name": "search_code" }]
  }
]

---

Does this work for your use case? We might be able to POC an extension based on this rough idea.

[madhaviai]

Thanks, this direction works for the Deep Agents “build subagents from MCP catalog” use case. A few tweaks so we also cover progressive disclosure, If we put tool names (or schemas) in agents/list, or still run full tools/list at connect, hosts will load agents and tools into context and we’re back to flat sprawl.

1. Initialize advertises capabilities.agents.
2. agents/list returns only { name, description, capabilities[] } where capabilities are labels (e.g. "pending approvals"), not tool names.
3. Hosts with agents must not call flat tools/list at connect.
4. Tool schemas appear only after agents/select|get (scoped), or only inside the specialist when building Deep Agents subagents locally.

agents/list response:

{
  "agents": [
    {
      "name": "workflow-agent",
      "description": "Pipelines, approvals, deployments, incidents",
      "capabilities": [
        "failed pipelines",
        "pending approvals",
        "change requests"
      ]
    },
    {
      "name": "research-agent",
      "description": "Outages, CVEs, internal runbooks",
      "capabilities": ["web search", "internal docs"]
    },
    {
      "name": "insights-agent",
      "description": "DORA, error budget, release risk chart",
      "capabilities": ["dora", "risk score", "charts"]
    }
  ]
}

agents/get

{
  "agent": "workflow-agent",
  "tools": [
    {
      "name": "list_failed_pipelines",
      "description": "…",
      "inputSchema": { "type": "object", "properties": { "service": { "type": "string" } } }
    },
    {
      "name": "list_pending_approvals",
      "description": "…",
      "inputSchema": { "type": "object", "properties": { "service": { "type": "string" } } }
    }
  ]
}