MCP Brings a New Paradigm to Layered AI Application Development

[!TIP] > Preface: While MCP is a hot topic, its most critical aspect decoupling tool providers from application developers through standardized protocols has been overlooked. This shift mirrors the frontend-backend separation in web development, representing a paradigm shift in AI Agent application development.

Using the development of the Agent TARS application as an example, this article details MCP's role in transforming development paradigms and expanding tool ecosystems.

Glossary

Overview

AI has evolved from dialogue-only Chatbots to decision-supporting Copilots and now autonomous Agents, demanding richer context and tools for task execution.

Challenges

The lack of standardized context and tooling creates three major challenges:

1. High Development Coupling: Tool developers must deeply understand Agent internals, embedding tool code within the Agent layer, complicating development and debugging.
2. Poor Tool Reusability: Tight coupling with Agent code leads to inconsistent API adaptations, hindering cross-language reuse.
3. Fragmented Ecosystem: Without standards, tools (e.g., OpenAPIs) are incompatible across Agent ecosystems.

Goal

"All problems in computer science can be solved by another level of indirection" -- Butler Lampson

MCP decouples tools into a dedicated MCP Server layer, standardizing development and invocation. MCP Servers provide Agents with standardized access to context and tools.

Demo

Three examples showcasing MCP's role in AI Agent applications:

Current MCP customization is closed; third-party MCP Servers were manually mounted for testing. More: https://agent-tars.com/showcase

Introduction

What is MCP?

Model Context Protocol is a standard protocol by Anthropic for LLM-to-external communication (data/tools), based on JSON-RPC 2.0. It acts as a USB-C interface for AI, standardizing context provision.

Architecture

• MCP Client: Communicates with Servers via MCP protocol (1:1 connection).
• MCP Servers: Provide context—Resources, Tools, Prompts—to Clients.
• Language Support: TypeScript, Python, Java, Kotlin, C#.

Flowchart

MCP supplies LLMs with three context types: Resources, Prompts, and Tools.

MCP vs. Function Call

MCP as Frontend-Backend Separation

Early web development coupled UIs with backend logic (JSP/PHP), mirroring today's Agent-tool entanglement. AJAX/Node.js/RESTful APIs enabled separation; MCP now does the same for AI:

• Web: Frontend (UI) ↔ Backend (APIs).
• MCP: Tool developers ↔ Agent developers.

This layering lets Agent developers compose tools like building blocks.

Practice

Design Overview

The MCP Browser Tool exemplifies the implementation. To ensure out-of-box usability (avoiding Node.js/UV dependencies per issue#64), we categorize tools as:

• Built-in MCP Servers: Fully MCP-compliant, supporting both Stdio and function calls ("MCP-standardized Function Calls").
• Extended MCP Servers: For advanced users with Npm/UV environments.

MCP Server Development

Taking mcp-server-browser as an example, it is essentially an npm package with the following package.json configuration:

{
  "name": "mcp-server-browser",
  "version": "0.0.1",
  "type": "module",
  "bin": {
    "mcp-server-browser": "dist/index.cjs"
  },
  "main": "dist/server.cjs",
  "module": "dist/server.js",
  "types": "dist/server.d.ts",
  "files": ["dist"],
  "scripts": {
    "build": "rm -rf dist && rslib build && shx chmod +x dist/*.{js,cjs}",
    "dev": "npx -y @modelcontextprotocol/inspector tsx src/index.ts"
  }
}

• bin: Stdio entry
• main / module: In-process function call entry

Development

In practice, using the Inspector to develop and debug MCP Servers proves highly effective. By decoupling Agents from tools, developers can debug and develop tools independently.

Simply run npm run dev to launch a Playground containing all debuggable MCP Server features (Prompts, Resources, Tools, etc.).

$ npx -y @modelcontextprotocol/inspector tsx src/index.ts
Starting MCP inspector...
New SSE connection

Spawned stdio transport
Connected MCP client to backing server transport
Created web app transport
Set up MCP proxy

🔍 MCP Inspector is up and running at http://localhost:5173 🚀

Note: console.log doesn't work in Inspector—debugging requires alternatives.

Implementation

Entry Points

To enable in-process function calls for built-in MCP Servers, we export three shared methods in the entry file src/server.ts:

• listTools: Enumerates all available functions
• callTool: Invokes specific functions
• close: Cleanup function when server is no longer needed

// src/server.ts
export const client: Pick<Client, 'callTool' | 'listTools' | 'close'> = {
  callTool,
  listTools,
  close,
};

For Stdio call support, simply import the module in src/index.ts:

#!/usr/bin/env node
// src/index.ts
import { client as mcpBrowserClient } from "./server.js";

const server = new Server(
  {
    name: "example-servers/puppeteer",
    version: "0.1.0",
  },
  {
    capabilities: {
      tools: {},
    },
  }
);
// listTools
server.setRequestHandler(ListToolsRequestSchema, mcpBrowserClient.listTools);
// callTool
server.setRequestHandler(CallToolRequestSchema, async (request) =>
  return await mcpBrowserClient.callTool(request.params);
);

async function runServer() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
}

runServer().catch(console.error);

process.stdin.on("close", () => {
  console.error("Browser MCP Server closed");
  server.close();
});

Tool Definition

The MCP protocol requires using JSON Schema to constrain tool inputs and outputs. Based on practical experience, we recommend using zod to define a Zod Schema set, which is then converted to JSON Schema for MCP export.

import { z } from 'zod';

const toolsMap = {
  browser_navigate: {
    description: 'Navigate to a URL',
    inputSchema: z.object({
      url: z.string(),
    }),
    handle: async (args) => {
      // Implements
      const clickableElements = ['...']
      return {
        content: [
          {
            type: 'text',
            text: `Navigated to ${args.url}\nclickable elements: ${clickableElements}`,
          },
        ],
        isError: false,
      }
    }
  },
  browser_scroll: {
    name: 'browser_scroll',
    description: 'Scroll the page',
    inputSchema: z.object({
      amount: z
        .number()
        .describe('Pixels to scroll (positive for down, negative for up)'),
    }),
    handle: async (args) => {
      return {
        content: [
          {
            type: 'text',
            text: `Scrolled ${actualScroll} pixels. ${
              isAtBottom
                ? 'Reached the bottom of the page.'
                : 'Did not reach the bottom of the page.'
            }`,
          },
        ],
        isError: false,
      };
    }
  },
  // more
};

const callTool = async ({ name, arguments: toolArgs }) => {
  return handlers[name].handle(toolArgs);
}

Pro Tip: Unlike OpenAPI's structured data returns, MCP responses are specifically designed for LLM models. To better bridge models and tools, returned text and tool descriptions should be more semantic, improving model comprehension and tool invocation success rates. For example, browser_scroll should return page scroll status after each execution (e.g., remaining pixels to bottom, whether bottom reached). This enables models to provide more precise parameters in subsequent calls.

Agent Integration

After developing the MCP Server, it needs to be integrated into the Agent application. In principle, the Agent shouldn't need to concern itself with the specific details of tools, inputs, and outputs provided by MCP Servers.

MCP Servers Configuration

MCP Servers configuration is divided into "Built-in Servers" and "User Extension Servers". Built-in Servers use in-process Function Calls to ensure out-of-the-box functionality for novice users, while Extension Servers provide advanced users with expanded Agent capabilities.

{
    // Internal MCP Servers(in-process call)
    fileSystem: {
      name: 'fileSystem',
      localClient: mcpFsClient,
    },
    commands: {
      name: 'commands',
      localClient: mcpCommandClient,
    },
    browser: {
      name: 'browser',
      localClient: mcpBrowserClient,
    },

    // External MCP Servers(remote call)
    fetch: {
      command: 'uvx',
      args: ['mcp-server-fetch'],
    },
    longbridge: {
      command: 'longport-mcp',
      args: [],
      env: {}
    }
}

MCP Client

The core mission of the MCP Client is to integrate MCP Servers with different invocation methods (Stdio/SSE/Function Call). The Stdio and SSE implementations directly reuse the Official Examples. Here we focus on how Function Call support was implemented in the Client.

Function Call Invocation

export type MCPServer<ServerNames extends string = string> = {
  name: ServerNames;
  status: 'activate' | 'error';
  description?: string;
  env?: Record<string, string>;
+ /** same-process call, same as function call */
+ localClient?: Pick<Client, 'callTool' | 'listTools' | 'close'>;
  /** Stdio server */
  command?: string;
  args?: string[];
};

The MCP Client invocation works as follows:

import { client as mcpBrowserClient } from '@agent-infra/mcp-server-browser';

 const client = new MCPClient([
    {
      name: 'browser',
      description: 'web browser tools',
      localClient: mcpBrowserClient,
    }
]);

const mcpTools = await client.listTools();

const response = await openai.chat.completions.create({
  model,
  messages,
  // Different model vendors need to convert to the corresponding tools data format.
  tools: convertToTools(tools),
  tool_choice: 'auto',
});

At this point, the entire MCP workflow has been fully implemented, covering all aspects from Server configuration, Client integration to Agent connectivity. More MCP details/code have been open-sourced on GitHub: Agent Integration, mcp-client, mcp-servers

Insights

Ecosystem

The MCP ecosystem continues to grow, with increasing applications supporting MCP and open platforms providing MCP Servers. Services like Cloudflare and Composio, Zapier use SSE to host MCP (i.e., connecting one MCP Endpoint grants access to multiple MCP Servers). The ideal scenario for Stdio implementation would be running MCP Servers and Agent systems within the same Docker container.

Future

• Current MCP lacks mature standardization and engineering frameworks
• According to the MCP Roadmap, three key initiatives are planned:
  • Remote MCP Support: Authentication, service discovery, stateless services - clearly targeting a K8S architecture to build production-ready, scalable MCP services. The recent RFC Replace HTTP+SSE with new "Streamable HTTP" transport proposes Streamable HTTP for low-latency bidirectional communication.
  • Agent Support: Cross-domain workflows with better human-Agent interaction.
  • Developer Ecosystem: Expand MCP Servers ecosystem.
• MCP Model & RL: Models need dynamic MCP tool-library generalization
• Agent K8S: While standardized communication protocols between LLMs and context have been established, unified standards for Agent interaction protocols remain undeveloped. Production-level challenges like Agent service discovery, recovery, and monitoring await solutions. Current explorations like ANP (Agent Network Protocol) are attempting to address these areas.