Overview

The Model Context Protocol (MCP) lets AI applications connect to your tools and data through a standardized interface. Instead of building bespoke integrations for every combination of AI model and external system, you build one MCP server and any compatible client can use it. For GTM engineers wiring together CRMs, enrichment tools, and sequencers, that's a meaningful reduction in plumbing work.

This tutorial walks you through building your first MCP server from scratch. We'll cover both Python and Node.js implementations, define resources, tools, and prompts, handle authentication, and connect everything to Claude Desktop and Claude Code. By the end, you'll have a working server you can extend with your own GTM data sources.

If you're new to MCP concepts, start with our MCP guide for GTM teams first. This tutorial assumes you understand the basics and are ready to build.

Prerequisites and Environment Setup

Before writing any code, make sure your development environment is ready. MCP servers can be built in Python or Node.js (TypeScript). Choose whichever your team is most comfortable with—the protocol is the same either way.

Python Setup

Create a new project directory and install the MCP SDK:

mkdir my-mcp-server && cd my-mcp-server
python -m venv .venv
source .venv/bin/activate
pip install mcp httpx

The mcp package includes the server framework, protocol types, and stdio transport. We add httpx for making async HTTP requests to external APIs—you'll need this for most GTM integrations.

Node.js/TypeScript Setup

mkdir my-mcp-server && cd my-mcp-server
npm init -y
npm install @modelcontextprotocol/sdk zod
npm install -D typescript @types/node
npx tsc --init

The zod library handles input validation for tool parameters. TypeScript isn't strictly required, but the SDK's type definitions will save you debugging time.

Building an MCP Server in Python

Let's build a practical MCP server that exposes GTM-relevant functionality: reading account data, looking up contacts, and qualifying leads. This mirrors what you'd build for a real CRM-enrichment-sequencer workflow.

Server Skeleton

Start with the basic server structure:

from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Resource, Tool, TextContent
import json

# Initialize the server
server = Server("gtm-context-server")

# Run with stdio transport
async def main():
    async with stdio_server() as (read_stream, write_stream):
        await server.run(
            read_stream,
            write_stream,
            server.create_initialization_options()
        )

if __name__ == "__main__":
    import asyncio
    asyncio.run(main())

This creates an empty server that communicates over stdio—the standard transport for local MCP servers. Claude Desktop and Claude Code both launch servers as child processes and communicate through stdin/stdout.

Defining Resources

Resources are read-only data that the AI can access. For a GTM server, these might include account records, ICP definitions, or enrichment data. Define them with the @server.list_resources and @server.read_resource decorators:

@server.list_resources()
async def list_resources():
    return [
        Resource(
            uri="gtm://accounts/list",
            name="Account List",
            description="Current target accounts with firmographic data",
            mimeType="application/json"
        ),
        Resource(
            uri="gtm://icp/definition",
            name="ICP Definition",
            description="Ideal customer profile criteria and scoring weights",
            mimeType="application/json"
        )
    ]

@server.read_resource()
async def read_resource(uri: str):
    if uri == "gtm://accounts/list":
        # In production, query your CRM or database
        accounts = await fetch_accounts_from_crm()
        return json.dumps(accounts, indent=2)
    elif uri == "gtm://icp/definition":
        return json.dumps({
            "target_employee_range": [50, 500],
            "target_industries": ["SaaS", "FinTech", "HealthTech"],
            "required_signals": ["recent_funding", "hiring_engineers"],
            "disqualifiers": ["government", "non_profit"]
        }, indent=2)
    raise ValueError(f"Unknown resource: {uri}")

Resources use URIs for identification. The convention is protocol://category/identifier, but you can structure these however makes sense for your data. The key is that resource descriptions are clear enough for the AI to understand when each resource is relevant.

Defining Tools

Tools are actions the AI can invoke. Unlike resources, tools accept input parameters and can have side effects—writing to your CRM, triggering a sequence enrollment, or calling an enrichment API.

@server.list_tools()
async def list_tools():
    return [
        Tool(
            name="lookup_contact",
            description="Look up a contact by email or domain. Returns "
                        "firmographic data, engagement history, and fit score.",
            inputSchema={
                "type": "object",
                "properties": {
                    "email": {
                        "type": "string",
                        "description": "Contact email address"
                    },
                    "domain": {
                        "type": "string",
                        "description": "Company domain (alternative to email)"
                    }
                },
                "oneOf": [
                    {"required": ["email"]},
                    {"required": ["domain"]}
                ]
            }
        ),
        Tool(
            name="qualify_lead",
            description="Score a lead against the current ICP definition. "
                        "Returns a score (0-100), tier (A/B/C/D), and reasoning.",
            inputSchema={
                "type": "object",
                "properties": {
                    "company_name": {
                        "type": "string",
                        "description": "Company name to qualify"
                    },
                    "domain": {
                        "type": "string",
                        "description": "Company domain"
                    }
                },
                "required": ["domain"]
            }
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "lookup_contact":
        result = await perform_contact_lookup(arguments)
        return [TextContent(
            type="text",
            text=json.dumps(result, indent=2)
        )]
    elif name == "qualify_lead":
        result = await perform_qualification(arguments)
        return [TextContent(
            type="text",
            text=json.dumps(result, indent=2)
        )]
    raise ValueError(f"Unknown tool: {name}")

The inputSchema follows JSON Schema format. Be explicit about required vs. optional fields—the AI uses these schemas to determine what parameters to pass. Vague schemas lead to bad tool invocations.

Defining Prompts

Prompts are reusable instruction templates for common tasks. They're especially useful when you want the AI to follow a specific workflow consistently, like qualifying leads using your team's exact criteria:

from mcp.types import Prompt, PromptMessage, PromptArgument

@server.list_prompts()
async def list_prompts():
    return [
        Prompt(
            name="qualify_and_route",
            description="Qualify a lead and recommend the appropriate "
                        "outbound sequence based on ICP fit and signals.",
            arguments=[
                PromptArgument(
                    name="domain",
                    description="Company domain to qualify",
                    required=True
                )
            ]
        )
    ]

@server.get_prompt()
async def get_prompt(name: str, arguments: dict):
    if name == "qualify_and_route":
        domain = arguments["domain"]
        return {
            "messages": [
                PromptMessage(
                    role="user",
                    content=TextContent(
                        type="text",
                        text=f"Look up the company at {domain}. "
                             f"Check their firmographics against our ICP definition. "
                             f"Score them 0-100 and assign a tier. "
                             f"If they score above 70, recommend which outbound "
                             f"sequence to enroll them in based on their industry "
                             f"and company size. Include your reasoning."
                    )
                )
            ]
        }

Prompts are optional but powerful. They encode your team's qualification logic directly into the MCP server, so anyone using the server gets consistent behavior without writing custom instructions each time.

Building an MCP Server in Node.js

If your team works primarily in TypeScript—common for teams building on top of webhook-driven workflows—here's the equivalent server in Node.js.

Server Skeleton

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "gtm-context-server",
  version: "1.0.0"
});

// Resources, tools, and prompts go here

const transport = new StdioServerTransport();
await server.connect(transport);

Defining Resources and Tools

The Node.js SDK uses a slightly different API with method chaining and Zod schemas for validation:

// Resource: ICP Definition
server.resource(
  "icp-definition",
  "gtm://icp/definition",
  async (uri) => ({
    contents: [{
      uri: uri.href,
      mimeType: "application/json",
      text: JSON.stringify({
        target_employee_range: [50, 500],
        target_industries: ["SaaS", "FinTech", "HealthTech"],
        required_signals: ["recent_funding", "hiring_engineers"],
        disqualifiers: ["government", "non_profit"]
      }, null, 2)
    }]
  })
);

// Tool: Contact Lookup
server.tool(
  "lookup_contact",
  "Look up a contact by email or domain. Returns firmographic data, "
  + "engagement history, and fit score.",
  {
    email: z.string().email().optional()
      .describe("Contact email address"),
    domain: z.string().optional()
      .describe("Company domain (alternative to email)")
  },
  async ({ email, domain }) => {
    if (!email && !domain) {
      return {
        content: [{
          type: "text",
          text: "Error: Either email or domain is required."
        }],
        isError: true
      };
    }

    const result = await performContactLookup({ email, domain });
    return {
      content: [{
        type: "text",
        text: JSON.stringify(result, null, 2)
      }]
    };
  }
);

// Tool: Lead Qualification
server.tool(
  "qualify_lead",
  "Score a lead against the current ICP definition.",
  {
    domain: z.string().describe("Company domain to qualify"),
    company_name: z.string().optional()
      .describe("Company name")
  },
  async ({ domain, company_name }) => {
    const result = await performQualification({ domain, company_name });
    return {
      content: [{
        type: "text",
        text: JSON.stringify(result, null, 2)
      }]
    };
  }
);

The Zod-based schema validation in the Node.js SDK catches malformed inputs before your handler runs. This is especially important when the AI is calling tools autonomously—you want clear validation errors, not cryptic runtime crashes.

Authentication and Security

Your MCP server will likely need to authenticate with external systems—CRMs, enrichment APIs, email platforms. How you handle credentials matters for both security and usability.

API Key Authentication

The simplest pattern: pass API keys as environment variables when the server starts. Claude Desktop and Claude Code both support this natively.

# Python: Read credentials from environment
import os

SALESFORCE_TOKEN = os.environ.get("SALESFORCE_TOKEN")
CLAY_API_KEY = os.environ.get("CLAY_API_KEY")

if not SALESFORCE_TOKEN:
    raise RuntimeError("SALESFORCE_TOKEN environment variable is required")

In your Claude Desktop configuration:

{
  "mcpServers": {
    "gtm-context": {
      "command": "python",
      "args": ["/path/to/server.py"],
      "env": {
        "SALESFORCE_TOKEN": "your-token-here",
        "CLAY_API_KEY": "your-clay-key"
      }
    }
  }
}

OAuth 2.0 for Production Servers

For remote MCP servers (using HTTP/SSE transport instead of stdio), the MCP specification includes an OAuth 2.0 authorization flow. This is relevant when you're deploying a shared server that multiple team members connect to.

The flow works like this:

# Python: Validating OAuth tokens in a remote MCP server
from mcp.server.auth import OAuthProvider, TokenValidator

class GTMOAuthProvider(OAuthProvider):
    async def validate_token(self, token: str) -> dict:
        # Validate against your auth provider (Auth0, Okta, etc.)
        claims = await verify_jwt(token)
        return {
            "user_id": claims["sub"],
            "scopes": claims.get("scope", "").split(),
            "team_id": claims.get("team_id")
        }

    async def check_scope(self, required_scope: str, token_scopes: list):
        if required_scope not in token_scopes:
            raise PermissionError(
                f"Token missing required scope: {required_scope}"
            )

For most teams getting started, environment variable-based API keys with stdio transport is the right choice. Move to OAuth when you need multi-user access or are deploying shared infrastructure.

Scoping Access Per Tool

Not every user should be able to invoke every tool. A rep using the server for research shouldn't be able to trigger bulk sequence enrollments. Implement per-tool authorization checks:

TOOL_PERMISSIONS = {
    "lookup_contact": ["read"],
    "qualify_lead": ["read"],
    "enroll_in_sequence": ["read", "write"],
    "update_crm_record": ["read", "write", "admin"]
}

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    required_scopes = TOOL_PERMISSIONS.get(name, [])
    # Validate user has required scopes before executing
    await validate_user_scopes(required_scopes)
    # ... execute tool

Testing and Debugging Your Server

MCP servers are backend services. Test them like backend services—not by connecting to Claude and hoping for the best.

Using the MCP Inspector

The MCP Inspector is a browser-based debugging tool that connects to your server and lets you interact with it directly. It's the single most useful tool for development:

# Install and run the inspector
npx @modelcontextprotocol/inspector

# Or point it at your Python server directly
npx @modelcontextprotocol/inspector python server.py

The Inspector shows you exactly what resources your server exposes, lets you invoke tools with custom parameters, and displays the raw JSON-RPC messages flowing back and forth. If something doesn't work in Claude, reproduce it in the Inspector first—it eliminates the AI layer as a variable.

Unit Testing Tools

Test your tool handlers independently, outside the MCP protocol layer:

# test_tools.py
import pytest
from server import perform_contact_lookup, perform_qualification

@pytest.mark.asyncio
async def test_contact_lookup_by_email():
    result = await perform_contact_lookup({
        "email": "test@example.com"
    })
    assert "company" in result
    assert "fit_score" in result

@pytest.mark.asyncio
async def test_qualification_scoring():
    result = await perform_qualification({
        "domain": "example-saas.com"
    })
    assert 0 <= result["score"] <= 100
    assert result["tier"] in ["A", "B", "C", "D"]
    assert "reasoning" in result

@pytest.mark.asyncio
async def test_lookup_missing_params():
    with pytest.raises(ValueError):
        await perform_contact_lookup({})

Separate your business logic from the MCP transport layer. Your tool handlers should be pure async functions that are easy to test in isolation. The MCP decorator layer just wires them to the protocol.

Debugging Common Issues

These are the problems that trip up most first-time server builders:

Error Handling Patterns

GTM systems fail constantly. APIs rate-limit you. CRM records are missing fields. Enrichment data comes back empty. Your MCP server needs to handle all of this gracefully—because the AI can't recover from a crashed server process.

Return Errors, Don't Throw Them

When a tool encounters an error, return it as a structured response rather than raising an unhandled exception:

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    try:
        if name == "lookup_contact":
            result = await perform_contact_lookup(arguments)
            return [TextContent(
                type="text",
                text=json.dumps(result, indent=2)
            )]
    except RateLimitError as e:
        return [TextContent(
            type="text",
            text=json.dumps({
                "error": "rate_limited",
                "message": f"API rate limit hit. Retry after {e.retry_after}s.",
                "retry_after": e.retry_after
            })
        )]
    except NotFoundError:
        return [TextContent(
            type="text",
            text=json.dumps({
                "error": "not_found",
                "message": f"No contact found for the provided criteria.",
                "suggestion": "Try searching with a different email or domain."
            })
        )]
    except Exception as e:
        return [TextContent(
            type="text",
            text=json.dumps({
                "error": "internal_error",
                "message": f"Unexpected error: {str(e)}"
            })
        )]

Structured error responses let the AI understand what went wrong and take appropriate action—retry, try alternative parameters, or inform the user. An unhandled crash just leaves the AI (and the user) guessing.

Retry Logic for Flaky APIs

Wrap external API calls with exponential backoff. This is non-negotiable for production servers interacting with rate-limited enrichment APIs:

import asyncio
from httpx import HTTPStatusError

async def call_with_retry(func, *args, max_retries=3, base_delay=1.0):
    for attempt in range(max_retries):
        try:
            return await func(*args)
        except HTTPStatusError as e:
            if e.response.status_code == 429:  # Rate limited
                delay = base_delay * (2 ** attempt)
                await asyncio.sleep(delay)
                continue
            elif e.response.status_code >= 500:  # Server error
                delay = base_delay * (2 ** attempt)
                await asyncio.sleep(delay)
                continue
            raise  # Client errors (4xx) should not be retried
    raise RuntimeError(f"Failed after {max_retries} retries")

Graceful Degradation

If one data source is down, return what you can instead of failing completely:

async def perform_contact_lookup(args):
    result = {"domain": args.get("domain"), "data_sources": {}}

    # Try CRM lookup
    try:
        crm_data = await fetch_from_crm(args)
        result["data_sources"]["crm"] = crm_data
    except Exception as e:
        result["data_sources"]["crm"] = {
            "status": "unavailable",
            "error": str(e)
        }

    # Try enrichment lookup
    try:
        enrichment = await fetch_from_enrichment(args)
        result["data_sources"]["enrichment"] = enrichment
    except Exception as e:
        result["data_sources"]["enrichment"] = {
            "status": "unavailable",
            "error": str(e)
        }

    # Score with whatever data we have
    result["fit_score"] = calculate_score(result["data_sources"])
    result["confidence"] = "high" if len([
        s for s in result["data_sources"].values()
        if "status" not in s
    ]) > 1 else "low"

    return result

The AI can then tell the user: "I found CRM data but enrichment is temporarily unavailable. Here's a partial score with lower confidence." That's far more useful than a generic failure message.

Connecting to Claude Desktop and Claude Code

With your server built and tested, it's time to wire it into an actual AI client. The setup differs slightly between Claude Desktop and Claude Code.

Claude Desktop Configuration

Edit your configuration file (location varies by OS—see the Claude Desktop MCP setup guide for paths):

{
  "mcpServers": {
    "gtm-context": {
      "command": "python",
      "args": ["/absolute/path/to/server.py"],
      "env": {
        "SALESFORCE_TOKEN": "sf_token_here",
        "CLAY_API_KEY": "clay_key_here"
      }
    }
  }
}

For the Node.js version:

{
  "mcpServers": {
    "gtm-context": {
      "command": "node",
      "args": ["/absolute/path/to/dist/server.js"],
      "env": {
        "SALESFORCE_TOKEN": "sf_token_here",
        "CLAY_API_KEY": "clay_key_here"
      }
    }
  }
}

After saving the config and restarting Claude Desktop, look for the hammer icon in the chat interface. Click it to see your server's tools listed. Try asking Claude something like: "Look up the company at acme.com and qualify them against our ICP."

Claude Code Configuration

Claude Code supports MCP servers through the .mcp.json file in your project root or via the claude mcp command:

# Add a server via CLI
claude mcp add gtm-context -- python /absolute/path/to/server.py

# Or create .mcp.json in your project root
{
  "mcpServers": {
    "gtm-context": {
      "command": "python",
      "args": ["/absolute/path/to/server.py"],
      "env": {
        "SALESFORCE_TOKEN": "sf_token_here",
        "CLAY_API_KEY": "clay_key_here"
      }
    }
  }
}

The advantage of Claude Code is that it's already a terminal-native tool. Your MCP server becomes part of a larger GTM automation workflow where Claude can read your codebase, invoke your MCP tools, and generate scripts that use the results—all in one session.

Cursor Configuration

For teams using Cursor IDE, MCP servers are configured through the Settings UI or a .cursor/mcp.json file in your workspace:

{
  "mcpServers": {
    "gtm-context": {
      "command": "python",
      "args": ["/absolute/path/to/server.py"],
      "env": {
        "SALESFORCE_TOKEN": "sf_token_here"
      }
    }
  }
}

The configuration format is consistent across all three clients. Build your server once, connect it anywhere.

Real-World Server Patterns for GTM

The examples above show the mechanics. Here are patterns that actually matter in production GTM automation.

CRM Proxy Server

Expose read and write access to your CRM through MCP. This lets AI workflows query accounts, update fields, and log activities without direct CRM API access in every script:

# Tools to expose:
# - search_accounts(query, filters)
# - get_contact(id_or_email)
# - update_contact(id, fields)
# - log_activity(contact_id, type, notes)
# - get_deal_pipeline(account_id)

The server handles authentication, field mapping, and data normalization. Every AI application in your stack gets clean, consistent CRM access.

Enrichment Aggregator

Wrap multiple enrichment sources behind a single MCP interface. Instead of the AI juggling separate calls to Clearbit, ZoomInfo, and Clay, your server calls all three and merges the results:

# Single tool that queries multiple sources:
# - enrich_company(domain) -> merged firmographics
# - enrich_contact(email) -> merged contact data
# - get_signals(domain) -> funding, hiring, tech changes

This is the waterfall enrichment pattern implemented at the MCP layer. The AI gets complete data without managing provider-specific logic.

Sequence Controller

Expose sequence management through MCP for AI-driven qualification-to-enrollment workflows:

# Tools:
# - list_sequences(filters) -> available sequences with descriptions
# - enroll_contact(contact_id, sequence_id, personalization)
# - check_enrollment_status(contact_id)
# - pause_enrollment(contact_id, reason)

With qualification, enrichment, and sequence tools all available through MCP, the AI can run end-to-end workflows: research an account, qualify against ICP, select the right sequence, and enroll with personalized variables—all from a single conversation or automated pipeline.

FAQ

From Single Server to GTM Infrastructure

Building your first MCP server is a milestone. You've got a working connection between AI and your GTM data. But look at what happens as adoption grows across your team.

Each team member configures their own servers with their own credentials. Your CRM server diverges from your enrichment server in how it handles the same accounts. The qualification logic in one person's prompt template differs from another's. And nobody has a unified view of which prospects have been touched, scored, or enrolled across all these individual setups.

The underlying issue isn't the MCP servers—it's context fragmentation. Account data lives in the CRM, enrichment lives in Clay, engagement history lives in your sequencer, and product signals live in your analytics platform. Each MCP server connects to one piece. The AI still has to orchestrate multi-source lookups for every single request, and there's no shared memory across team members or sessions.

What you actually need at that point is a unified context layer that pre-aggregates all of this—keeping a continuously synchronized graph of accounts, contacts, signals, and interactions that any AI client can query without assembling the picture from scratch each time.

This is what platforms like Octave provide. Instead of building and maintaining separate MCP servers for each data source, Octave maintains unified GTM context that includes enrichment data, CRM records, engagement signals, and fit scoring—all accessible through a single integration point. The individual MCP connections to your tools still exist under the hood, but they feed a persistent context graph rather than serving one-off queries. For teams running AI-powered outbound at scale, it eliminates the infrastructure sprawl that custom MCP servers inevitably create.

Conclusion

You now have the building blocks for a working MCP server: resources for exposing data, tools for executing actions, prompts for standardizing AI behavior, and error handling that won't leave your users stranded when something breaks.

The practical path forward: start with a single server that solves one real problem. A CRM lookup tool that saves your team from context-switching. An enrichment proxy that standardizes data across sources. A qualification tool that encodes your ICP logic. Get that working in the MCP Inspector, connect it to Claude Desktop or Code, and iterate based on what your team actually uses.

MCP is infrastructure, not a one-time project. The servers you build today become the foundation for increasingly sophisticated AI workflows—from simple data lookups to fully autonomous outbound pipelines. Build them well, test them properly, and they'll compound in value as your GTM stack evolves.

Related Articles

• MCP Guide for GTM Teams: Architecture and Use Cases
• Claude Desktop MCP Server Setup Guide
• Cursor MCP Server Configuration Guide
• Claude Code for GTM Automation: Complete Setup Guide
• What Is GTM Engineering? Responsibilities and Stack