Introducing MCP Proxy to an API Call Demo

This article introduces an MCP Proxy into an existing client-server API Call Demo, allowing the app to access data through an MCP tool layer while preserving the original project structure.

The point of the refactor is not to replace the original API. It is to keep the direct call path intact and add a second path that is closer to a real Agent-style tool-calling architecture.

1. MCP Basics for This Demo

You can think of MCP (Model Context Protocol) as a standard interface for tools and context. The model understands user intent, plans steps, and generates call parameters; MCP packages external capabilities as discoverable, callable, and governable tools.

In this demo, MCP Proxy sits between the API Call Demo and the MCP Server. It does not replace the model or the business API. Instead, it decouples what the application wants to call from how backend tools are actually exposed.

MCP Server

The side that provides real capabilities, such as reading a database, calling an internal API, accessing documents, or running a script.

MCP Client / Proxy

The layer that initiates tool calls and governs routing, authorization, logging, error handling, and future extension.

2. Original Demo and Refactoring Principle

The original demo has one direct path: the frontend calls GET /api/profile on the Express server, and the backend returns profile data directly.

The refactoring principle is additive: keep the original structure intact. The original /api/profile route remains available, while the new /api/profile-via-mcp route demonstrates how to call a tool layer through MCP Proxy.

The most important rule is: do not break the original structure. Keep the direct API and add only the MCP Proxy entry point plus the MCP Server tool layer.

3. Call Flow After the Refactor

After the change, the demo supports both Direct API and MCP Proxy paths. The frontend can switch between them with a pair of radio buttons.

01 ClientSelect MCP Proxy and submit a name.

02 Express RouteEnter /api/profile-via-mcp.

03 MCP ClientCall the corresponding tool.

04 MCP ServerRun the MySQL query.

05 ResponseReturn JSON shaped like the original API response.

Route	Description
`GET /api/profile`	The original Direct API route, kept for compatibility.
`GET /api/profile-via-mcp`	Queries profile data through MCP Proxy.
`GET /api/mcp/health`	Checks MCP Server and MySQL health.

4. Module Split

Server Config Cleanup

.env stores database connection settings, while dbConfig.js exports one shared MySQL configuration for both the Express server and the MCP server.

MCP Server Tools

db_health checks whether the database connection is healthy; get_profile_by_name queries profile data by name.

mcpClient.js

Starts or connects to mysqlToolsServer.js, reads available tools, calls a selected tool, and returns the tool result.

mcpProxy.js

Reads req.query.name, calls get_profile_by_name, then converts the MCP result into the same JSON shape as /api/profile.

5. Final Project Structure

The final structure keeps node_modules\ under both server\ and mcp-server\, making it clear that the two Node projects manage their own dependencies.

C:\api-demo
  client\
    index.html
    script.js

  server\
    server.js
    mcpClient.js
    mcpProxy.js
    dbConfig.js
    .env
    package.json
    package-lock.json
    node_modules\

  mcp-server\
    mysqlToolsServer.js
    package.json
    package-lock.json
    node_modules\

Summary

The core idea is to add an MCP Proxy layer on top of the existing API Call Demo, not to replace the original API. The original /api/profile remains the Direct API path, while /api/profile-via-mcp demonstrates tool access through MCP Proxy.