Construindo Servidores MCP Leves e Transmitíveis na AWS Lambda com Python

Os servidores MCP nem sempre precisam de contêineres, processos persistentes ou de um framework web completo.

Para muitas ferramentas, uma Lambda Python regular da AWS é suficiente:

Solicitação MCP
    ↓
API Gateway
    ↓
Lambda
    ↓
Ferramenta Python
    ↓
Resposta JSON-RPC

Mas algumas operações são diferentes.

Uma ferramenta pode passar 30 segundos pesquisando, analisando ou coordenando trabalho e precisa relatar progresso enquanto está em execução.

Para essas cargas de trabalho, precisamos de HTTP real transmitível:

ferramentas/chamada
    ↓
progresso
    ↓
progresso
    ↓
progresso
    ↓
resultado final

Queríamos ambos os modelos em Python sem exigir que as aplicações adotassem diferentes modelos de programação MCP.

Isso levou a dois projetos de código aberto:

• modmex-lambda — o runtime e modelo de programação MCP em Python.
• serverless-python-mcp — a integração de implantação do Serverless Framework.

Juntos, eles permitem que uma aplicação Python comece com um servidor MCP leve e em buffer e opte por streaming de resposta real do Lambda quando a carga de trabalho realmente precisar.

Comece com uma Lambda Python regular

A implantação mais simples não requer o Adaptador Web do Lambda ou streaming de resposta.

Instale modmex-lambda:

pip install modmex-lambda

Crie um servidor MCP:

from modmex_lambda import APIGatewayHttpResolver
from modmex_lambda.mcp import MCPServer

mcp = MCPServer(
    name="pedidos",
    version="1.0.0",
)

Então exponha capacidades como funções Python regulares.

Ferramentas

@mcp.tool()
def get_order(order_id: str) -> dict:
    return {
        "id": order_id,
        "status": "confirmado",
    }

Recursos

@mcp.resource("pedidos://{order_id}")
def order_resource(order_id: str) -> dict:
    return load_order(order_id)

Prompts

@mcp.prompt()
def order_assistant(customer_id: str):
    return build_order_prompt(customer_id)

Monte o servidor MCP no resolvedor normal do API Gateway:

app = APIGatewayHttpResolver()

app.include_mcp(
    mcp,
    path="/mcp",
)

handler = app.handler

A arquitetura resultante é deliberadamente entediante:

Cliente MCP
    ↓
API Gateway HTTP API v2
    ↓
AWS Lambda
    ↓
modmex-lambda
    ↓
MCPServer

Para ferramentas, recursos e prompts de curta duração, isso geralmente é exatamente o que queremos.

Sem FastAPI.

Sem Flask.

Sem servidor ASGI.

Sem infraestrutura de streaming de resposta.

Apenas Python e Lambda.

MCP é outra interface para a camada de aplicação

Um dos objetivos de design era não criar uma arquitetura de aplicação separada para o MCP.

As ferramentas podem usar os mesmos mecanismos de injeção de dependência que os endpoints Lambda regulares:

@mcp.tool()
def get_order(
    order_id: str,
    service: Annotation[OrderService, Depends()],
):
    return service.get(order_id)

Isso significa que REST e MCP podem permanecer interfaces finas sobre os mesmos serviços de aplicação:

                 OrderService
                     ▲
                     │
          ┌──────────┴──────────┐
          │                     │
       API REST                MCP

A mesma ideia se aplica ao middleware.

Autorização, resolução de inquilinos, registro, auditoria, rastreamento e políticas não precisam ser implementadas dentro de cada ferramenta:

@mcp.to