Building a Sales Intelligence Agent with Google ADK and MCP

Sales teams are drowning in dashboards. The average rep toggles between 6-10 tools per day - CRM, lead scoring, conversation intelligence, email sequences - and spends more time navigating software than talking to buyers. McKinsey's 2025 State of AI report found that fewer than 10% of organisations have scaled agentic AI in any business function, even though the technology is ready.

The opportunity is not another dashboard. It is an agent that sits inside the AI assistant sales leaders already use and answers questions like "which leads went hot this week?" by pulling from multiple data sources automatically.

This post walks through how to build one using Google's Agent Development Kit (ADK), Gemini, and the Model Context Protocol (MCP) - the emerging standard for connecting AI assistants to external tools.

The Problem with Sales Dashboards

Gartner predicts 40% of enterprise applications will integrate task-specific AI agents by 2026 - up from less than 5% today. By 2027, multi-agent collaboration within applications becomes the norm.

Source: Gartner

The sales intelligence category is ripe for this shift. Today, buyer intent signals - what prospects ask about, which MEDDIC signals they reveal, how engaged they are - sit locked inside individual platforms. A sales leader who wants to cross-reference lead scores with CRM activity has to open two tabs, run two reports, and mentally join the data.

An AI agent eliminates that friction. Connect your lead intelligence and CRM as MCP tool providers, and the agent orchestrates across both in a single conversation.

MCP Servers vs Agents - Understanding the Layers

Before diving into code, it helps to understand the two-layer architecture:

An MCP server is a tool provider - it answers individual queries. An agent wraps those tools in workflows that chain multiple calls together and deliver synthesised, actionable output.

If you already have an MCP server exposing your data, you are halfway there. The agent is the layer that turns raw tools into daily workflows.

The Architecture Pattern

The pattern that works for sales intelligence is a root agent with specialised sub-agents:

User (Claude Desktop / Cursor / CLI)
  -> Root Agent (Gemini - routes queries)
    -> Morning Briefing sub-agent
    -> Stale Leads Check sub-agent
    -> Coaching Gaps sub-agent
    -> Content Opportunities sub-agent
    -> Deal Prep sub-agent
  -> Sales Intelligence MCP Server (lead data, intent signals)
  -> CRM MCP Server (pipeline data, contacts)

The root agent receives a natural language question and delegates to the right sub-agent. Each sub-agent has focused instructions - it knows which tools to call and how to synthesise the results. All sub-agents inherit the connected MCP tools automatically.

This maps to five workflows that sales leaders and RevOps teams run daily:

1. Morning Briefing - hot leads with MEDDIC evidence and recommended follow-up actions
2. Stale Leads Check - qualified leads that have gone cold in the CRM
3. Coaching Gaps - MEDDIC signal gaps with suggested questions to fill them
4. Content Opportunities - unanswered prospect questions turned into content ideas
5. Deal Prep - pre-call briefing with full conversation context and enrichment data

---

Building It with Google ADK

Google's Agent Development Kit is a TypeScript-first framework for building AI agents. Three classes do most of the work:

• LlmAgent - wraps a Gemini model with tools and instructions
• MCPToolset - connects to any MCP server and exposes its tools to the agent
• InMemoryRunner - runs the agent with in-memory session management

Connecting to an MCP Server

MCPToolset supports both Streamable HTTP (for deployed servers) and stdio (for local development):

import { LlmAgent, MCPToolset } from "@google/adk"

// Connect to a deployed MCP server over HTTP
const salesIntelMcp = new MCPToolset({
  type: "StreamableHTTPConnectionParams",
  url: "https://your-app.com/api/mcp",
  transportOptions: {
    requestInit: {
      headers: { "X-API-Key": process.env.SALES_INTEL_API_KEY },
    },
  },
})

The agent discovers available tools automatically via MCP's tool listing protocol. No manual tool definitions needed.

Creating Sub-Agents

Each workflow becomes a sub-agent with focused instructions:

const morningBriefing = new LlmAgent({
  model: "gemini-2.5-flash",
  name: "morning_briefing",
  description: "Daily summary of hot leads with follow-up priorities",
  instruction: `Fetch hot and warm leads from the last 7 days.
    For each lead, summarise who they are, what they asked about,
    and which MEDDIC signals were detected. 
    If CRM tools are available, check whether each lead 
    has been contacted. End with a prioritised action list.`,
})

The description field is what the root agent uses to decide when to delegate - make it specific enough that the routing works accurately.

Wiring Up the Root Agent

The root agent connects everything:

const agent = new LlmAgent({
  model: "gemini-2.5-flash",
  name: "sales_intelligence_agent",
  instruction: `Route to the appropriate sub-agent based on 
    the user's request. For direct data queries, use the 
    MCP tools directly.`,
  tools: [salesIntelMcp],
  subAgents: [morningBriefing, staleLeadsCheck, coachingGaps, contentOpportunities, dealPrep],
})

Sub-agents inherit the tools from the root agent. When the user asks "brief me before my call with Acme", the root agent delegates to deal_prep, which chains search_by_intent, get_lead_enrichment, and get_conversation_detail - all from the same MCP connection.

Adding Cross-MCP Intelligence

This is the most powerful pattern. Connect a second MCP server - your CRM - and the agent cross-references automatically:

const crmMcp = new MCPToolset(
  {
    type: "StreamableHTTPConnectionParams",
    url: process.env.CRM_MCP_URL,
    transportOptions: {
      requestInit: {
        headers: { Authorization: `Bearer ${process.env.CRM_API_KEY}` },
      },
    },
  },
  undefined,
  "crm" // prefix to avoid tool name collisions
)

const agent = new LlmAgent({
  tools: [salesIntelMcp, crmMcp],
  subAgents: [
    /* ... */
  ],
})

Now the Morning Briefing agent can check if each hot lead has been contacted in the CRM. The Stale Leads Check agent can flag leads with no recent CRM activity. No integration code between the two systems - the agent orchestrates across both tool sets in a single conversation.

This works with any CRM that has an MCP server. Attio, HubSpot, Salesforce, Copper, and Pipedrive all ship MCP servers today. One agent, any CRM.

Why This Pattern Matters

The Forrester study showing 210% ROI from AI agents is not about the technology - it is about eliminating the context-switching tax. A sales leader who can ask "any hot leads I haven't followed up on?" and get a cross-referenced answer in 3 seconds will do it every morning. That is a workflow habit, and habits drive retention.

Three reasons this architecture holds up:

• MCP is the standard, not the exception. Major CRMs, databases, and SaaS tools are shipping MCP servers. The ecosystem is growing faster than any previous integration standard.
• Sub-agents scale with complexity. Start with one workflow, add more as you learn what your team actually asks. Each sub-agent is independently testable and deployable.
• No more platform spaghetti. Sales teams juggle a tangle of GTM, RevOps, and marketing platforms that rarely talk to each other. MCP lets an agent query across all of them in a single conversation - without building point-to-point integrations between each one.

---

How Parsley Implements This

At Parsley, we built exactly this architecture. Our MCP server exposes 8 buyer intent tools - conversation history, lead scoring, MEDDIC qualification signals, knowledge gaps, and enrichment data. The ADK agent wraps those tools in the 5 sub-agent workflows described above.

You can run it yourself:

export PARSLEY_API_KEY=pk_live_your_key
export GOOGLE_GENAI_API_KEY=your_gemini_key
npx @tryparsley/adk-agent

The source is open - fork it, swap in your own MCP server, and adapt the sub-agent instructions to your team's workflows.

---

Frequently Asked Questions

What is an MCP server and why does it matter for sales teams?

The Model Context Protocol is an open standard that lets AI assistants connect to external tools. An MCP server exposes your data as structured tools that Claude, Gemini, or any MCP-compatible client can call. For sales teams, this means your lead intelligence is accessible through conversation rather than through another dashboard.

Do I need Google Cloud to build an ADK agent?

No. ADK runs on any Node.js environment. You need a Gemini API key from Google AI Studio, which has a free tier. Google Cloud is only needed if you want managed deployment.

Can this work with models other than Gemini?

ADK is designed around Gemini. If you want to use the same MCP tools with Claude or ChatGPT, connect the MCP server directly to those clients - no agent wrapper needed. MCP is model-agnostic by design.

How does the agent know which sub-agent to use?

Each sub-agent has a description field that the root agent uses for routing. When the user asks "prep me for my call with Acme", the root agent matches the intent to the deal_prep sub-agent's description and delegates. No hardcoded routing rules.

What happens when the agent has no data to return?

Good agents are honest. If there are no hot leads in the timeframe, the agent says so and suggests widening the date range or checking whether the data source is capturing visitor interactions. Transparency builds trust.

---

The shift from dashboards to conversational AI in sales is not a question of if - it is a question of who builds the workflows first. The tools are ready. MCP provides the interoperability standard. ADK provides the agent framework. The remaining work is understanding what your team actually needs to ask, and building the sub-agents to answer.