Two MCP Servers, One Chat: Reconciling Ad Metrics With Form Outcomes Without a Dashboard

gh efficiency. However, by joining ad-side placement data with form-side conversion outcomes, the analysis exposed that 96% of impressions came from Audience Network rewarded-video slots, which are prone to near-mistap clicks. The actual target placements (Facebook and Instagram feeds) received negligible delivery. This insight would have been difficult to surface without fusing the two data sources in a single analytical context.

Core Solution

Implementing the client-side join pattern requires a disciplined approach to tool design and orchestration. The core principle is single-source responsibility: each MCP server returns only the data it owns, keyed in a way that allows the client to align it with other sources.

Step 1: Define Single-Source Tools with Stable Join Keys

Tools must return data that is accurate, granular, and keyed by stable identifiers. The tool should never fetch data from external services to "complete" the response. If a user asks for a cross-service metric, the tool returns its half of the picture, and the client retrieves the other half.

Consider a form service exposing conversion data. The tool should return form outcomes keyed by the ad identifier used in the campaign.

// Interface for form-side conversion data.
// Keyed by campaignRef to allow client-side alignment with ad metrics.
interface CampaignConversionKey {
  campaignRef: string;       // Stable join key matching ad platform ID
  sourceChannel: string;     // e.g., "facebook", "instagram"
  totalViews: number;        // Form-side view count
  completedSubmissions: number; // Form-side response count
  conversionRatio: number;   // Pre-calculated ratio for client convenience
}

// Tool handler: Returns ONLY form-side data.
// No external API calls to ad platforms.
async function fetchFormOutcomeData(
  tenantId: string,
  formIdentifier: string,
  dateRange: { start: string; end: string }
): Promise<CampaignConversionKey[]> {
  
  // 1. Enforce tenant isolation and access control.
  const access = await validateTenantPermissions(tenantId, formIdentifier, {
    requiredRole: "analytics_viewer"
  });
  
  if (!access.granted) {
    throw new AccessDeniedError("Insufficient permissions for form analytics.");
  }

  // 2. Aggregate internal data by campaign reference.
  // The aggregation logic lives entirely within the form service.
  const rawAggregates = await db.formResponses.aggregateByCampaign(
    formIdentifier,
    dateRange
  );

  // 3. Map to the contract schema.
  return rawAggregates.map(row => ({
    campaignRef: row.adCampaignId,
    sourceChannel: row.utmSource,
    totalViews: row.viewCount,
    completedSubmissions: row.submissionCount,
    conversionRatio: row.viewCount > 0 
      ? row.submissionCount / row.viewCount 
      : 0
  }));
}

Architecture Rationale:

• Isolation: The handler performs no network calls to external services. This eliminates credential management for third-party APIs and removes dependency on external service availability.
• Stable Keys: The campaignRef field provides a deterministic join key. This must be a value that persists across both services, such as the ad campaign ID or a UTM parameter.
• Pre-calculation: The tool provides conversionRatio to reduce client-side computation errors, but the raw counts (totalViews, completedSubmissions) are also returned to allow the client to perform custom aggregations.

Step 2: Establish Client-Side Orchestration Logic

The AI client receives the tool definitions from both MCP servers. When the user requests a cross-service analysis, the client executes the tools in parallel or sequence, depending on dependencies.

For example, to calculate acquisition cost per conversion, the client must:

1. Call the ad-side tool to retrieve spend and clicks.
2. Call the form-side tool to retrieve conversions.
3. Align the results using the join key.
4. Compute the derived metric: Acquisition Cost = Ad Spend / Form Conversions.

The client performs this logic dynamically. If the user asks for a breakdown by placement, the client requests placement-level data from the ad server and aligns it with the form data. This flexibility is impossible with static connectors.

Step 3: Validate and Act

The client-side join pattern supports not only analysis but also remediation. In the validation cycle, the analysis revealed that the ad delivery was skewed toward low-value placements. The client used the ad-side MCP server to modify the ad set configuration directly:

• Excluded Audience Network placements.
• Restricted delivery to Facebook and Instagram feeds.
• Disabled automatic audience expansion.
• Set targeting to Japan, age 25+.

These actions were executed within the same conversation that surfaced the insight, closing the loop between diagnosis and remediation.

Pitfall Guide

Implementing the client-side join pattern requires avoiding common architectural mistakes. The following pitfalls are derived from production experience with MCP integrations.

1. The "God Tool" Anti-Pattern

   • Explanation: A tool attempts to fetch data from multiple services to provide a "complete" answer. This recreates the embedded connector problem, introducing coupling and credential sprawl.
   • Fix: Enforce single-source responsibility. If a tool needs data from another service, it should return an error or a placeholder, signaling the client to fetch the missing data via its own tool.

2. Volatile Join Keys

   • Explanation: Using keys that change over time or differ between services makes alignment impossible. For example, using a generated UUID that is not shared across platforms.
   • Fix: Use stable, shared identifiers such as campaign IDs, UTM sources, or customer email hashes. Document the key format in the tool schema.

3. Implicit Aggregation

   • Explanation: Tools return pre-aggregated summaries that hide granular details. The client cannot perform custom aggregations or drill down into specific segments.
   • Fix: Return granular data whenever possible. Allow the client to aggregate. If data volume is high, provide pagination or filtering parameters rather than forcing aggregation.

4. Context Window Bloat

   • Explanation: Returning excessive data in tool responses consumes the client's context window, reducing the LLM's ability to reason and increasing latency.
   • Fix: Implement response limits and pagination. Use summary endpoints for high-level queries and detail endpoints for deep dives. Compress data structures where feasible.

5. Unverified Client Math

   • Explanation: Relying on the LLM to perform complex calculations without verification can lead to arithmetic errors, especially with large numbers or multiple steps.
   • Fix: Provide pre-calculated ratios in the tool response where possible. For critical metrics, implement a verification step where the client re-computes the value or uses a code execution environment.

6. Credential Sprawl

   • Explanation: Storing credentials for multiple services within a single MCP server or client configuration increases the attack surface.
   • Fix: Isolate credentials per server. Use scoped tokens with minimal permissions. The client should manage the auth context for each server independently.

7. Lack of Idempotency in Actions

   • Explanation: Tools that modify state (e.g., updating ad settings) may be called multiple times by the client, leading to unintended side effects.
   • Fix: Design tools to be idempotent. Use idempotency keys or check the current state before applying changes. Return the resulting state so the client can verify the action.

Production Bundle

Action Checklist

• Define Join Keys: Identify stable identifiers that exist across all services involved in the join. Document these in the tool schemas.
• Isolate Tool Scopes: Audit all MCP tools to ensure they return only single-source data. Remove any cross-service fetches.
• Implement Access Control: Enforce tenant isolation and role-based permissions in every tool handler. Validate inputs before processing.
• Design Output Contracts: Create clear TypeScript interfaces for tool responses. Include both raw data and pre-calculated metrics where appropriate.
• Test Orchestration Scenarios: Simulate cross-service queries in the AI client. Verify that the client can align data correctly and compute derived metrics.
• Monitor Context Usage: Track token consumption for tool responses. Implement pagination or filtering if responses approach context limits.
• Validate Action Idempotency: Test state-modifying tools for repeated calls. Ensure actions are reversible and safe to retry.

Decision Matrix

Use this matrix to determine the appropriate integration strategy based on your use case.

Scenario	Recommended Approach	Why	Cost Impact
Real-time ad-hoc analysis	MCP Client-Side Join	Dynamic fusion without code changes. Supports complex, multi-step reasoning.	Low (No infra, pay-per-use)
High-volume batch reporting	ETL Pipeline	Efficient processing of large datasets. Lower latency for repeated queries.	Medium (Infrastructure costs)
Event-driven workflows	Webhooks	Immediate notification of state changes. Decoupled from polling.	Low (Event-based costs)
Static cross-service metrics	Embedded Connector	Predictable performance. Simplified client logic.	High (Maintenance, coupling)
Compliance-sensitive joins	MCP Client-Side Join	Data remains in source systems. Client orchestrates without persisting joined data.	Low (No data movement)

Configuration Template

The following JSON template demonstrates how to configure multiple MCP servers in a client application. Each server is defined with its own transport and environment variables, ensuring isolation.

{
  "mcpServers": {
    "ad-analytics": {
      "command": "npx",
      "args": ["-y", "@acme/ad-mcp-server"],
      "env": {
        "AD_PLATFORM_API_KEY": "${AD_API_KEY}",
        "AD_ACCOUNT_ID": "${AD_ACCOUNT_ID}"
      }
    },
    "form-analytics": {
      "command": "npx",
      "args": ["-y", "@acme/form-mcp-server"],
      "env": {
        "FORM_SERVICE_TOKEN": "${FORM_TOKEN}",
        "TENANT_ID": "${TENANT_ID}"
      }
    }
  }
}

Quick Start Guide

1. Install MCP Client: Set up an MCP-capable AI client (e.g., Claude Desktop, Cursor, or a custom implementation using the MCP SDK).
2. Add Server Configurations: Add the JSON configuration for each MCP server to the client's settings file. Ensure environment variables are securely injected.
3. Verify Connections: Open the client and confirm that both servers are connected. Test a simple query against each server to validate authentication and tool availability.
4. Execute Cross-Service Query: Prompt the client to perform a join. Example: "Compare the ad spend from the ad-analytics server with the form conversions from the form-analytics server for the last 7 days, aligned by campaign ID."
5. Review and Refine: Analyze the results. If the join is misaligned, check the tool schemas for join key consistency. Iterate on the prompt or tool definitions as needed.