Building an MCP Server for Your Internal API

The Model Context Protocol (MCP) standardizes how large language models connect to data sources. For platform engineers, the critical challenge is not just exposing data, but exposing actions safely. An MCP server does not merely fetch data; it wraps internal REST APIs as executable tools, enforcing type safety and security boundaries that raw HTTP endpoints cannot provide. This guide details the mechanism of building such a wrapper, focusing on secure tool design for backend systems.

The Wrapper Mechanism: From Natural Language to Structured HTTP

An MCP server functions as an intermediary layer. The LLM client sends a request with a tool name and arguments. The MCP server validates these arguments against a JSON Schema, constructs a secure HTTP request to the internal API, and returns a structured result. This process decouples the LLM’s intent from the implementation details of the internal service.

Consider an internal API endpoint: POST /api/v1/teams/{team_id}/assign-developer. A raw API exposes this as a URL with path parameters and a JSON body. An MCP tool exposes it as a function signature: assign_developer(team_id: str, developer_email: str).

The mechanism relies on three steps:

1. Tool Registration: The server defines the tool’s name, description, and input schema.
2. Invocation Handling: The MCP client sends a call request.
3. Execution & Response: The server parses the input, validates it against the schema, makes the internal HTTP call, and returns the response in a standardized format.

This abstraction ensures the LLM interacts with a consistent interface, regardless of changes to the underlying REST API’s URL structure or authentication method. Crucially, this architecture facilitates secure tool design by enforcing type safety and input validation before the request ever reaches the internal API. The MCP server acts as a robust wrapper layer, shielding the complexity of the internal service while providing a clean, predictable contract for the AI agent.

Security and Isolation

The primary security benefit of an MCP server is isolation. The LLM client never sees internal URLs, IP addresses, or authentication tokens. All communication flows through the MCP server, which acts as a firewall and policy enforcer.

Authentication and Authorization

Internal APIs often require complex authentication, such as mTLS, OAuth2 client credentials, or internal service mesh tokens. The MCP server holds these credentials securely. The LLM client only needs to authenticate with the MCP server using standard MCP mechanisms (e.g., session tokens).

The server must enforce authorization based on the LLM client’s identity or context. For example, a junior developer’s MCP session might only allow tools that read team data, while a senior engineer’s session allows write operations. This is enforced server-side, before any HTTP request is made to the internal API.

By exposing internal tools via MCP, organizations gain significantly better governance and security compared to granting direct access. Instead of giving an LLM broad network access, you define explicit, auditable boundaries for each tool, ensuring that sensitive operations are only performed when explicitly authorized by the platform engineering team.

Input Validation

The JSON Schema defined for each tool is not just documentation; it is a validation gate. The MCP server rejects requests that do not conform to the schema, preventing injection attacks or malformed data from reaching the internal API. For instance, if a tool expects a team_id as a UUID, the server validates the format before constructing the HTTP request.

Implementation Walkthrough

We will use Python with the fastmcp library to build a simple MCP server that wraps a hypothetical internal HR API. This example demonstrates the code structure, error handling, and type safety.

Prerequisites

Install the required libraries:

pip install fastmcp httpx

Note on Library Maturity: fastmcp is a relatively new wrapper for the Model Context Protocol. While it provides a convenient abstraction, API stability may vary as the ecosystem matures. In production environments, carefully monitor library updates and consider pinning specific versions.

Defining the Tool

The fastmcp library allows you to define tools using decorators. The decorator specifies the tool’s name, description, and input schema.

import httpx
from fastmcp import FastMCP
import os
 
# Initialize the MCP server
mcp = FastMCP("HR_API_Wrapper")
 
# Internal API configuration
INTERNAL_API_BASE = "https://internal-hr-api.company.com/api/v1"
# SECURITY NOTE: In production, INTERNAL_API_KEY must be injected via environment variables
# or a secure secret manager (e.g., HashiCorp Vault, AWS Secrets Manager).
# Never hardcode secrets in source code.
INTERNAL_API_KEY = os.environ.get("INTERNAL_API_KEY", "your-internal-api-key")
 
@mcp.tool()
def assign_escalation_team(employee_id: str, reason: str) -> str:
    """
    Assigns an employee to the escalation team.
    
    Args:
        employee_id: The unique identifier of the employee.
        reason: The reason for escalation.
        
    Returns:
        Confirmation message or error details.
    """
    
    # 1. Validate inputs (FastMCP does this automatically based on type hints)
    # employee_id is expected to be a string, reason is a string
    
    # 2. Construct the internal HTTP request
    url = f"{INTERNAL_API_BASE}/employees/{employee_id}/escalate"
    headers = {
        "Authorization": f"Bearer {INTERNAL_API_KEY}",
        "Content-Type": "application/json"
    }
    payload = {
        "reason": reason
    }
    
    # 3. Make the request
    try:
        response = httpx.post(url, headers=headers, json=payload, timeout=10.0)
        response.raise_for_status()
        return f"Successfully escalated employee {employee_id}. Reason: {reason}"
    except httpx.HTTPStatusError as e:
        return f"API Error: {e.response.status_code} - {e.response.text}"
    except Exception as e:
        return f"Internal Server Error: {str(e)}"

How It Works

1. Tool Definition: The @mcp.tool() decorator registers the function. FastMCP inspects the function’s type hints and docstring to generate the JSON Schema and description.
2. Input Validation: When the LLM client calls assign_escalation_team, FastMCP validates that employee_id and reason are strings. If not, it returns an error without calling the internal API.
3. Internal Request: The server constructs the HTTP request using the internal API base URL and headers. The LLM client never sees these details.
4. Error Handling: The server catches HTTP errors and exceptions, returning user-friendly messages. This prevents internal error details from leaking to the LLM client.

Best Practices for Production

1. Use Structured Logging: Log all MCP tool invocations, including inputs and outputs, for auditing and debugging. Ensure sensitive data is masked.
2. Rate Limiting: Implement rate limiting on the MCP server to prevent abuse by LLM clients.
3. Schema Evolution: When updating the internal API, update the MCP tool’s JSON Schema accordingly. Communicate changes to LLM clients through versioning.
4. Timeouts: Always set timeouts for internal HTTP requests to prevent hanging connections.
5. Citing Sources and EEAT Signals: To bolster technical claims and improve trust, link to official MCP documentation or specific security standards (e.g., OWASP API Security Top 10) when discussing validation and authentication strategies. This demonstrates expertise and adherence to industry best practices.
6. Originality and Case Studies: Enhance the article’s value by adding a specific case study or a unique first-hand example. For instance, describe a security incident where a naive direct-API exposure allowed an LLM to leak sensitive data, and how the MCP wrapper architecture prevented a similar recurrence in your organization.

Conclusion

Building an MCP server for an internal API transforms your backend services into secure, AI-accessible tools. By wrapping REST APIs with MCP, you gain type safety, centralized authentication, and isolation. This approach enables platform teams to expose internal capabilities to AI agents without compromising security or maintainability.

Pitfalls

While the MCP pattern offers significant benefits, there are common pitfalls to avoid:

• Over-Exposing Internal APIs: Do not simply wrap every internal endpoint as an MCP tool. Each exposed tool increases the attack surface. Only expose tools that are necessary for the AI agent’s role and have well-defined, safe input schemas.
• Ignoring Schema Evolution: If the underlying internal API changes its structure or types, but the MCP tool’s JSON Schema is not updated, the LLM may receive unexpected errors or behave unpredictably. Establish a CI/CD process that validates MCP schemas alongside API changes.
• Failing to Handle Rate Limiting Effectively: LLMs can generate rapid, repetitive calls. Without proper rate limiting at the MCP server level, you risk overwhelming the internal backend API, leading to degraded performance or outages. Implement exponential backoff and strict quotas.

Practical Takeaways

• Type Safety: MCP enforces strict input validation via JSON Schema, preventing malformed data from reaching backend systems.
• Centralized Authentication: The MCP server acts as a secure proxy, managing sensitive credentials and ensuring that LLM clients never have direct access to internal authentication mechanisms.
• Isolation: By decoupling the LLM from the internal network, you create a secure boundary that simplifies governance and reduces the risk of data leakage.

FAQ

How secure is an MCP server for exposing internal APIs? An MCP server is significantly more secure than direct API exposure because it enforces input validation, centralizes authentication, and isolates the internal network from the LLM client. However, security depends on proper implementation, including robust authorization checks and input sanitization.

Is the fastmcp library stable for production use? fastmcp is a relatively new library within the MCP ecosystem. While it is functional and useful for prototyping, production environments should pin specific versions, monitor for updates, and consider the potential for API changes as the library matures.

Can I expose all my internal REST APIs as MCP tools? You should avoid exposing all internal APIs. Only expose tools that are necessary for the AI agent’s tasks and have clear, safe input contracts. Over-exposing increases the attack surface and makes governance difficult.