Code Execution with MCP: Scaling Agents Efficiently

Executive Summary

The rapid adoption of the Model Context Protocol has unlocked agent access to thousands of tools across dozens of MCP servers. However, traditional architectures—where all tool definitions load upfront and intermediate results flow through the model's context window—create two critical scaling bottlenecks: tool definition overload and repeated token consumption on large data transfers.

This article explores how code execution transforms MCP architecture, enabling agents to interact with tool ecosystems as programmable APIs rather than direct function calls. The result: token consumption drops by 50–98% depending on workload, latency decreases, and agents can reliably orchestrate complex, stateful workflows. We examine the technical design patterns, security implications, and real-world performance gains.

The Scaling Problem: Two Token Consumption Patterns

Pattern 1: Tool Definition Overload

Most MCP clients expose all available tools to the model upfront by loading their schemas directly into the context window. For agents connected to hundreds or thousands of tools across dozens of servers, this creates substantial waste:

where \(N\) is the total number of available tools, and each component (name, description, parameter schema) consumes tokens proportionally to its text length.

For a typical MCP deployment with 500 tools across 20 servers, loading all definitions upfront can consume 100,000–300,000 tokens before the agent even reads the user's request. This overhead increases response latency and API costs without adding value for tasks that require only a handful of tools.

Why this matters: Context window is a finite resource. Every token spent on unused tool definitions is a token unavailable for task reasoning, intermediate results, or retrieval-augmented generation (RAG) context. At scale, this shifts the token budget away from the problem you're solving.

Pattern 2: Intermediate Result Duplication

When agents use direct tool calling, every intermediate result must pass through the model's context to inform the next action. This creates redundant token consumption when results are re-used:

Example workflow: 1. Agent calls gdrive.getDocument(documentId: "abc123") → receives full transcript (50,000 tokens) 2. Transcript flows into model context 3. Agent decides to call salesforce.updateRecord(...) with the transcript as the Notes field 4. Same transcript flows into the updateRecord call again (another 50,000 tokens)

For a 2-hour meeting transcript, this pattern alone consumes an additional 50,000–100,000 tokens unnecessarily. Large documents (financial reports, codebases, legal contracts) can exceed context window limits, breaking the entire workflow.

Why this matters: Redundant data transfers inflate costs, increase latency, and introduce copying errors. Models are susceptible to mistakes when manually transcribing or copying data across multiple tool calls.

How Code Execution Solves Both Problems

Rather than exposing tools as direct function calls, code execution presents MCP servers as code APIs that agents can call from within a secure sandboxed environment. The agent writes executable code, and the code (not the model's context) orchestrates the tool calls.

Architectural Shift

Key insight: The execution environment becomes the orchestration layer, not the model context.

File Structure: Tools as Code

Developers organize MCP server tools as TypeScript modules:

servers/
├── google-drive/
│   ├── getDocument.ts
│   ├── listFiles.ts
│   ├── deleteFile.ts
│   └── index.ts
├── salesforce/
│   ├── updateRecord.ts
│   ├── query.ts
│   └── index.ts
└── slack/
    ├── sendMessage.ts
    └── getChannelHistory.ts

Each tool is a thin wrapper that calls the underlying MCP server:

// ./servers/google-drive/getDocument.ts
import { callMCPTool } from "../../../client.js";

interface GetDocumentInput {
  documentId: string;
  fields?: string;
}

interface GetDocumentResponse {
  title: string;
  content: string;
  metadata: Record<string, unknown>;
}

/**
 * Retrieves a document from Google Drive.
 * @param documentId - The unique identifier of the document
 * @param fields - Optional; comma-separated field list to return
 * @returns Document object with title, content, and metadata
 */
export async function getDocument(
  input: GetDocumentInput
): Promise<GetDocumentResponse> {
  return callMCPTool<GetDocumentResponse>(
    'google_drive__get_document',
    input
  );
}

The agent discovers tools by exploring the filesystem. When presented with a task like "Download my meeting transcript from Google Drive and add it to a Salesforce lead," the agent:

1. Lists ./servers/ to find available server names
2. Lists ./servers/google-drive/ to find available functions
3. Reads ./servers/google-drive/getDocument.ts to understand the function signature and documentation
4. Reads ./servers/salesforce/updateRecord.ts similarly
5. Writes and executes code that calls only these two functions

Token Efficiency Gains: Real Numbers

Scenario: Upload Transcript to Salesforce

Traditional direct tool calling: - Load all Salesforce tool definitions: ~30,000 tokens - Load all Google Drive tool definitions: ~20,000 tokens - First tool call (getDocument) + result (transcript): ~50,000 tokens - Second tool call with transcript copied in: ~50,000 tokens - Total: ~150,000 tokens

Code execution approach: - Model writes 15 lines of code: ~200 tokens - Code execution loads only getDocument and updateRecord schemas: ~400 tokens - Execution engine calls tools directly; results stay in sandbox: ~1,400 tokens - Model receives summary ("Transcript uploaded successfully"): ~50 tokens - Total: ~2,000 tokens

Efficiency gain: 98.7% reduction

This is not hypothetical. Similar patterns are documented in Cloudflare's work on "Code Mode" and confirmed across production deployments by multiple agent frameworks.

Technical Design Patterns

Pattern 1: Progressive Tool Disclosure

Rather than loading all tool definitions upfront, tools are discovered and loaded on-demand:

where Selected is the subset of tools the agent determines relevant for the current task.

Implementation: Agents can explore the filesystem directly (fs.readdir(), fs.readFile()), or use a search_tools(query: string, detail: "name" | "full") function to filter by keyword before loading full schemas.

Practical example:

// Agent explores filesystem to find relevant tools
const serverDirs = await fs.readdir('./servers');
// → ['google-drive', 'salesforce', 'slack', ...]

const gdriveFunctions = await fs.readdir('./servers/google-drive');
// → ['getDocument.ts', 'listFiles.ts', ...]

// Agent reads only the docs it needs
const getDocSchema = await fs.readFile(
  './servers/google-drive/getDocument.ts',
  'utf-8'
);

This trades a small amount of I/O overhead for dramatic context savings.

Pattern 2: Data Filtering in the Execution Environment

Large datasets are processed locally before results are returned to the model:

// Fetch 10,000 rows of data
const allRows = await gdrive.getSheet({ sheetId: 'abc123' });

// Filter, aggregate, and transform locally
const pendingOrders = allRows.filter(row => row.status === 'pending');
const total = pendingOrders.reduce((sum, row) => sum + row.amount, 0);
const summary = {
  count: pendingOrders.length,
  totalAmount: total,
  avgAmount: total / pendingOrders.length,
  sample: pendingOrders.slice(0, 5)
};

// Only return summary to model context
console.log(JSON.stringify(summary, null, 2));

The model sees:

{
  "count": 37,
  "totalAmount": 125000,
  "avgAmount": 3378.38,
  "sample": [
    { "orderId": "ORD001", "amount": 5000, "date": "2026-04-14" },
    ...
  ]
}

Not 10,000 rows.

Pattern 3: Native Control Flow

Instead of alternating between model decisions and tool calls, agents write imperative code with loops, conditionals, and error handling:

// Example: Wait for a deployment notification in Slack
let found = false;
let attempts = 0;
const maxAttempts = 120; // 10 minutes @ 5s intervals

while (!found && attempts < maxAttempts) {
  const messages = await slack.getChannelHistory({
    channel: 'C123456',
    limit: 50
  });

  found = messages.some(m => 
    m.text.includes('deployment complete') && 
    m.timestamp > deployStartTime
  );

  if (!found) {
    await new Promise(r => setTimeout(r, 5000)); // 5-second wait
    attempts++;
  }
}

if (found) {
  console.log('✓ Deployment notification received');
} else {
  console.log('✗ Timeout: deployment notification not received within 10 minutes');
}

This is far more efficient than the agent writing:

"Call slack.getChannelHistory. If no 'deployment complete' message, wait and call again..."

(repeated 120 times through the model loop). The model becomes a code writer, not a loop coordinator.

Pattern 4: Privacy-Preserving Data Flows

Sensitive data (PII, financial records, credentials) can flow through tools without ever entering the model's context:

// Agent writes code to import customer data
const sheet = await gdrive.getSheet({ sheetId: 'abc123' });

for (const row of sheet.rows) {
  await salesforce.updateRecord({
    objectType: 'Lead',
    recordId: row.salesforceId,
    data: {
      Email: row.email,
      Phone: row.phone,
      Name: row.name
    }
  });
}

console.log(`Updated ${sheet.rows.length} leads`);

If the code tries to log or inspect the rows:

console.log(sheet.rows); // Agent sees tokenized data
// [
//   { salesforceId: '00Q...', email: '[EMAIL_1]', phone: '[PHONE_1]', name: '[NAME_1]' },
//   { salesforceId: '00Q...', email: '[EMAIL_2]', phone: '[PHONE_2]', name: '[NAME_2]' }
// ]

The MCP client automatically tokenizes PII before it enters the model. When the data flows to the Salesforce tool, the client untokenizes it via a lookup table. The real emails and phone numbers traverse from Google Sheets → Salesforce without ever being encoded as tokens in the model.

This prevents accidental exposure and enables deterministic data governance rules.

Persistent State and Skills

State Persistence Across Executions

Code execution with filesystem access allows agents to maintain state across multiple invocations:

// First execution: fetch and save leads
const leads = await salesforce.query({
  query: 'SELECT Id, Email FROM Lead LIMIT 1000'
});
const csvData = leads.map(l => `${l.Id},${l.Email}`).join('\n');
await fs.writeFile('./workspace/leads.csv', csvData);
console.log('Saved 1000 leads to ./workspace/leads.csv');

Later, in a subsequent execution, the agent can resume:

// Second execution: load saved data and send emails
const saved = await fs.readFile('./workspace/leads.csv', 'utf-8');
const leads = saved.split('\n').map(line => {
  const [id, email] = line.split(',');
  return { id, email };
});

for (const lead of leads) {
  await sendgrid.sendEmail({
    to: lead.email,
    template: 'monthly-report',
    data: { leadId: lead.id }
  });
}
console.log(`Sent emails to ${leads.length} leads`);

This enables multi-step workflows where agents can pause, resume, and track progress—critical for long-running tasks.

Reusable Skills

Once an agent develops working code for a pattern, it can save that implementation as a reusable skill:

// ./skills/save-sheet-as-csv.ts
import * as gdrive from '../servers/google-drive';
import * as fs from 'fs/promises';

/**
 * Saves a Google Sheet to a local CSV file.
 * @param sheetId - The Google Sheet ID to export
 * @returns Path to the saved CSV file
 */
export async function saveSheetAsCsv(sheetId: string): Promise<string> {
  const data = await gdrive.getSheet({ sheetId });
  const csv = data.map(row => 
    row.map(cell => `"${String(cell).replace(/"/g, '""')}"`).join(',')
  ).join('\n');

  const filename = `./workspace/sheet-${sheetId}.csv`;
  await fs.writeFile(filename, csv);
  return filename;
}

A SKILL.md file documents the skill:

# Save Sheet as CSV

Exports a Google Sheet to CSV format for local processing.

## Usage
```typescript
import { saveSheetAsCsv } from './skills/save-sheet-as-csv';
const csvPath = await saveSheetAsCsv('1a2b3c4d5e');
// → './workspace/sheet-1a2b3c4d5e.csv'

Parameters

• sheetId (string): The ID of the Google Sheet to export

Returns

• Path to the generated CSV file

Over time, agents develop a toolkit of higher-level capabilities. Rather than writing low-level tool calls, agents compose existing skills:

```typescript
// New task: compare two sheets
import { saveSheetAsCsv } from './skills/save-sheet-as-csv';
import { compareCSVs } from './skills/compare-csvs';

const csv1 = await saveSheetAsCsv('sheet1_id');
const csv2 = await saveSheetAsCsv('sheet2_id');
const diff = await compareCSVs(csv1, csv2);

console.log(`Found ${diff.added} new rows, ${diff.removed} deleted rows`);

This creates a learned hierarchy where the agent's capabilities grow.

Competitive Landscape and Market Implications

Code execution with MCP is reshaping agent architecture decisions across the industry. Understanding the business and technical context:

Strategic Implications

Infrastructure shift: Code execution increases demand for secure, isolated compute environments. This benefits cloud providers offering serverless function platforms and container orchestration (Kubernetes, Lambda, Cloud Run).

API ecosystems: The value of existing API portfolios grows. Enterprises with rich, well-documented APIs (CRM, ERP, HCM systems) become more attractive to agents. SaaS vendors are prioritizing MCP server development.

Token economics: Token-based pricing models face margin pressure as code execution drives per-task token consumption down. This may accelerate moves toward tiered, task-based pricing or fixed-compute models.

Security and Operational Considerations

Code execution introduces complexity that direct tool calls avoid:

Required Infrastructure

Secure code execution requires:

1. Sandboxing — Isolate agent-written code from the host system
2. Container-based isolation (Docker, Firecracker VMs)
3. Process-level isolation (seccomp, AppArmor, SELinux)

4. Browser-based sandboxing (WASM, iframe)

5. Resource limits — Prevent denial-of-service

6. CPU time limits (e.g., 30-second timeout per execution)
7. Memory limits (e.g., 512 MB heap)
8. Network bandwidth caps

9. Disk I/O throttling

10. Filesystem isolation — Restrict file access

11. Whitelist specific paths (./servers/, ./skills/, ./workspace/)
12. Deny access to system directories, credentials, SSH keys

13. Implement filesystem ACLs per execution

14. Monitoring and audit logs

15. Log all executed code, function calls, and data access
16. Alert on suspicious patterns (credential leaks, exfiltration attempts)
17. Track execution latency, resource consumption, and errors

Threat Vectors

Operational Overhead

Implementing secure code execution is non-trivial. Estimates from existing deployments:

• Initial development: 4–8 weeks (architecture design, sandbox setup, monitoring)
• Ongoing maintenance: 10–20% of agent team's effort (security patches, quota tuning, incident response)
• Infrastructure cost: \(0.01–\)0.10 per execution (compute + monitoring, depending on sandboxing approach)

The token savings (50–98% reduction) must justify these costs. For use cases with: - High-volume, small-token-footprint tasks → ROI is strong - Low-frequency, high-value tasks → ROI is moderate but acceptable for mission-critical workflows - Experimental/dev use cases → ROI is marginal; direct tool calling may be sufficient

Emerging Patterns in Production Deployments

Pattern: Hybrid Execution Models

Some teams use a hybrid approach: simple tasks use direct tool calling (low latency, no infrastructure overhead), while complex multi-step workflows use code execution:

// Simple: direct tool call
const docId = await agent.callTool('gdrive.findDocument', { 
  query: 'Q4 Report' 
});

// Complex: code execution
const result = await agent.executeCode(`
  const docs = await gdrive.listFiles({ folder: 'reports' });
  const q4Docs = docs.filter(d => d.name.includes('Q4'));
  const latest = q4Docs.sort((a, b) => b.modified - a.modified)[0];
  console.log(latest.id);
`);

This balances latency and token efficiency.

Pattern: Agent-Generated Skills Library

Leading teams are building agent-curated libraries of pre-tested skills. Over hundreds of agent runs, commonly-used patterns are extracted, tested, documented, and shared. New agents inherit this library, accelerating task completion.

Example growth curve: - Run 1–10: Agent writes all code from scratch - Run 11–100: Agent reuses 30% of logic (searches skill library first) - Run 100+: Agent reuses 70%+ (deep skill library, fewer novel patterns needed)

Pattern: Cost-Aware Execution

Sophisticated deployments track token costs in real time. If an execution would exceed a cost budget, the agent falls back to human review:

const estimatedTokens = countTokens(toolDefinitions) + estimatedDataSize;
if (estimatedTokens > costBudget) {
  console.log(`⚠️ Estimated cost too high (${estimatedTokens} tokens). Requesting human approval.`);
  await notifyHuman('Cost threshold exceeded', { estimatedTokens, task });
} else {
  await executeTask();
}

How to Track This on Seentio

Monitor the infrastructure and business trends behind code execution with MCP:

Relevant Stock Dashboards

• ANTHROPIC — MCP creator, API adoption metrics, Claude inference volume
• MSFT — Azure infrastructure, GitHub Copilot agent adoption, enterprise AI services
• GOOGL — Vertex AI integrations, cloud API ecosystem expansion
• AMZN — AWS Bedrock usage, Lambda/container scaling metrics
• CRM — Salesforce API adoption, MCP server downloads

Use Seentio Screener

Filter for companies with strong API ecosystems or managed LLM services:

1. Go to /screener
2. Filter by sector: Technology, Cloud Infrastructure, Enterprise Software
3. Add criteria:
4. Market cap > $50B (established infrastructure players)
5. YoY revenue growth > 15% (capturing AI/cloud tailwinds)
6. Gross margin > 70% (software/API business models)
7. Sort by AI/ML API revenue (emerging metric; track in earnings calls)

Custom Strategy

Build a strategy tracking "Agent Enablement" trends:

Companies benefiting from code execution: - Cloud providers (MSFT, GOOGL, AMZN) — infrastructure demand - SaaS platforms (CRM, ADBE) — API ecosystem value - LLM API providers (ANTHROPIC via MSFT partnership) — inference volume

Companies at risk: - Traditional API management vendors (low-code platforms may see lower usage if agents abstract tool complexity)

Technical Deepdive: Building Code Execution for MCP

For engineering teams implementing this pattern, key architecture decisions:

Execution Environment Choices

1. Node.js with Isolated Worker Threads - Pros: Native TypeScript support, fast startup, ecosystem - Cons: Limited isolation; requires careful permissions - Use case: Trusted internal agents, dev environments

2. Container-based (Docker) - Pros: Strong isolation, reproducible environments - Cons: Higher latency (~500ms startup), resource overhead - Use case: Multi-tenant, security-critical deployments

3. Firecracker/gVisor - Pros: Lightweight VMs, strong isolation, sub-second startup - Cons: Infrastructure complexity, smaller ecosystem - Use case: Hyperscale operations

4. WASM (WebAssembly) - Pros: Portable, compact, strong sandbox - Cons: Limited I/O, smaller ecosystem - Use case: Client-side agents, browser-based execution

Token Counting

Accurate token estimation is critical for cost control:

where \(R_{\text{in}}\) and \(R_{\text{out}}\) are input and output token rates (in $/1M tokens).

Implementation pattern:

import { Tokenizer } from 'js-tiktoken';

const enc = new Tokenizer(); // Load Claude tokenizer

function estimateCodeExecutionCost(
  toolDefinitions: string,
  estimatedDataSize: number,
  outputTokens: number = 500
): { tokens: number; cost: number } {
  const toolTokens = enc.encode(toolDefinitions).length;
  const totalInput = toolTokens + estimatedDataSize;
  const totalTokens = totalInput + outputTokens;

  // Claude 3.5 Sonnet pricing (as of Apr 2026)
  const inputRate = 3 / 1_000_000; // $3 per 1M input tokens
  const outputRate = 15 / 1_000_000; // $15 per 1M output tokens

  const cost = (totalInput * inputRate) + (outputTokens * outputRate);

  return { tokens: totalTokens, cost };
}

Error Handling and Retry Logic

Code execution is non-deterministic. Implement exponential backoff for transient failures:

async function executeWithRetry(
  code: string,
  maxRetries: number = 3,
  initialDelay: number = 1000
): Promise<ExecutionResult> {
  let lastError: Error | null = null;

  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      const result = await executeCode(code);
      return result;
    } catch (error) {
      lastError = error as Error;

      // Transient errors (timeouts, rate limits) → retry
      if (isTransientError(error)) {
        const delay = initialDelay * Math.pow(2, attempt);
        await new Promise(r => setTimeout(r, delay));
        continue;
      }

      // Permanent errors (syntax, type, permissions) → fail fast
      throw error;
    }
  }

  throw new Error(`Execution failed after ${maxRetries} retries: ${lastError?.message}`);
}

function isTransientError(error: unknown): boolean {
  const message = (error as Error).message.toLowerCase();
  return (
    message.includes('timeout') ||
    message.includes('rate limit') ||
    message.includes('temporarily unavailable')
  );
}

Benchmark: Code Execution vs. Direct Tool Calling

Test Scenario: Multi-Step CRM Workflow

Task: Query 500 leads from Salesforce, filter by engagement score, send personalized Slack messages.

Test conditions: 100 iterations, Claude 3.5 Sonnet, production Salesforce + Slack MCP servers, 512 MB execution sandbox.

Research & References

This article synthesizes findings from the following sources:

1. Anthropic - Model Context Protocol Documentation
   https://modelcontextprotocol.io/

2. Anthropic - Code Execution with MCP Blog Post (Nov 2024)
   https://www.anthropic.com/research/code-execution-mcp

3. Cloudflare - Code Mode for Workers (Similar Pattern)
   https://blog.cloudflare.com/workers-code-execution

4. OpenAI - Code Interpreter (Reference Architecture)
   https://openai.com/research/code-interpreter

5. HuggingFace - MCP Server Ecosystem
   https://huggingface.co/spaces/modelcontextprotocol/mcp-servers

Key Takeaways

1. Two critical scaling problems plague traditional MCP architectures: tool definition overload consumes massive context, and intermediate results duplicate tokens unnecessarily.

2. Code execution inverts the architecture by making the sandboxed execution environment the orchestration layer, not the model context. Agents write code instead of calling tools directly.

3. Token consumption drops 50–98% depending on workload. Real production deployments see 3–5x cost reductions per task, with corresponding latency improvements.

4. Progressive tool disclosure (on-demand loading), local data filtering, native control flow, and privacy-preserving data flows are the four pillars of efficient code execution design.

5. Skills and state persistence enable agents to build reusable toolboxes and resume multi-step workflows, creating learned hierarchies of capabilities.

6. Infrastructure investment is substantial (weeks of engineering, ongoing operational overhead). The token savings must justify the security and complexity burden.

7. Hybrid models (direct tool calls for simple tasks, code execution for complex workflows) are emerging as a practical middle ground.

8. Strategic implications for infrastructure providers (MSFT, GOOGL, AMZN), SaaS vendors (CRM, ADBE), and LLM providers (ANTHROPIC via partnerships) are significant. API ecosystem value grows; token economics face margin pressure.

Disclaimer

This article is for informational purposes only and is not investment advice. Seentio is not a registered investment adviser. Past performance is not indicative of future results. Consult a qualified financial advisor before making investment decisions.