Skip to main content
Glama

MCP2Lambda

insignia de herrería

Ejecute cualquier función de AWS Lambda como una herramienta de modelo de lenguaje grande (LLM) sin cambios de código utilizando el Protocolo de contexto de modelo (MCP) de Anthropic .

graph LR
    A[Model] <--> B[MCP Client]
    B <--> C["MCP2Lambda<br>(MCP Server)"]
    C <--> D[Lambda Function]
    D <--> E[Other AWS Services]
    D <--> F[Internet]
    D <--> G[VPC]
    
    style A fill:#f9f,stroke:#333,stroke-width:2px
    style B fill:#bbf,stroke:#333,stroke-width:2px
    style C fill:#bfb,stroke:#333,stroke-width:4px
    style D fill:#fbb,stroke:#333,stroke-width:2px
    style E fill:#fbf,stroke:#333,stroke-width:2px
    style F fill:#dff,stroke:#333,stroke-width:2px
    style G fill:#ffd,stroke:#333,stroke-width:2px

Este servidor MCP actúa como puente entre los clientes MCP y las funciones Lambda de AWS, lo que permite que los modelos de IA generativa accedan y ejecuten funciones Lambda como herramientas. Esto resulta útil, por ejemplo, para acceder a recursos privados, como aplicaciones y bases de datos internas, sin necesidad de proporcionar acceso a la red pública. Este enfoque permite que el modelo utilice otros servicios de AWS, redes privadas e internet público.

Desde una perspectiva de seguridad , este enfoque implementa la segregación de funciones al permitir que el modelo invoque las funciones Lambda, pero no acceda directamente a los demás servicios de AWS. El cliente solo necesita las credenciales de AWS para invocar las funciones Lambda. Estas pueden interactuar con otros servicios de AWS (mediante el rol de función) y acceder a redes públicas o privadas.

El servidor MCP da acceso a dos herramientas:

  1. La primera herramienta puede detectar automáticamente todas las funciones Lambda de su cuenta que coincidan con un prefijo o una lista de nombres permitidos. Esta herramienta comparte los nombres de las funciones y sus descripciones con el modelo.

  2. La segunda herramienta permite invocar aquellas funciones Lambda por nombre pasando los parámetros requeridos.

No se requieren cambios de código. Debe cambiar estas configuraciones para mejorar los resultados:

Selección de estrategia

La puerta de enlace admite dos estrategias diferentes para gestionar funciones Lambda:

  1. Modo de predescubrimiento (predeterminado: habilitado): Registra cada función Lambda como una herramienta individual al inicio. Esto proporciona una interfaz más intuitiva donde cada función aparece como una herramienta con su propio nombre.

  2. Modo genérico : utiliza dos herramientas genéricas ( list_lambda_functions e invoke_lambda_function ) para interactuar con funciones Lambda.

Puedes controlar este comportamiento mediante:

  • Variable de entorno: PRE_DISCOVERY=true|false

  • Marca CLI: --no-pre-discovery (desactiva el modo de predescubrimiento)

Ejemplo:

# Disable pre-discovery mode
export PRE_DISCOVERY=false
python main.py

# Or using CLI flag to disable pre-discovery
python main.py --no-pre-discovery
  1. Para que el cliente MCP adquiera los conocimientos necesarios para usar una función Lambda, su descripción debe indicar qué hace y qué parámetros utiliza. Consulte las funciones de ejemplo para obtener una demostración rápida y más detalles.

  2. Para ayudar al modelo a utilizar las herramientas disponibles a través de AWS Lambda, puede agregar algo como esto al indicador de su sistema :

Use the AWS Lambda tools to improve your answers.

Related MCP server: GPT MCP App - User & Loan Info Tools

Descripción general

MCP2Lambda permite que los LLM interactúen con las funciones de AWS Lambda como herramientas, ampliando sus capacidades más allá de la generación de texto. Esto permite a los modelos:

  • Acceda a datos privados y en tiempo real, incluidas las fuentes de datos en sus VPC

  • Ejecutar código personalizado utilizando una función Lambda como entorno sandbox

  • Interactuar con servicios externos y API mediante funciones Lambda, acceso a Internet (y ancho de banda)

  • Realizar cálculos especializados o procesamiento de datos

El servidor utiliza el protocolo MCP, que estandariza la forma en que los modelos de IA pueden acceder a herramientas externas.

De forma predeterminada, solo las funciones cuyo nombre comience con mcp2lambda- estarán disponibles para el modelo.

Prerrequisitos

  • Python 3.12 o superior

  • Cuenta de AWS con credenciales configuradas

  • Funciones de AWS Lambda (funciones de muestra proporcionadas en el repositorio)

  • Una aplicación que utiliza Amazon Bedrock con la API de Converse

  • Un cliente compatible con MCP como Claude Desktop

Instalación

Instalación mediante herrería

Para instalar MCP2Lambda para Claude Desktop automáticamente a través de Smithery :

npx -y @smithery/cli install @danilop/MCP2Lambda --client claude

Instalación manual

  1. Clonar el repositorio:

    git clone https://github.com/yourusername/mcp2lambda.git
    cd mcp2lambda
  2. Configurar las credenciales de AWS. Por ejemplo, usando la CLI de AWS :

    aws configure

Funciones Lambda de muestra

Este repositorio incluye tres funciones Lambda de ejemplo que ilustran diferentes casos de uso. Estas funciones tienen permisos básicos y solo pueden escribir en los registros de CloudWatch.

ID de cliente del correo electrónico

Recupera un ID de cliente a partir de una dirección de correo electrónico. Esta función toma un parámetro de correo electrónico y devuelve el ID de cliente asociado, lo que demuestra cómo crear herramientas de búsqueda sencillas. La función está predefinida para responder a la dirección de correo electrónico ` user@example.com . Por ejemplo, puede solicitar al modelo que obtenga el ID de cliente para el correo electrónico user@example.com .

Información del cliente de Id.

Recupera información detallada del cliente basándose en su ID. Esta función devuelve detalles del cliente, como nombre, correo electrónico y estado, lo que demuestra cómo Lambda puede proporcionar datos contextuales. La función está predefinida para responder al ID de cliente devuelto por la función anterior. Por ejemplo, puede solicitar al modelo que "Obtenga el estado del cliente para el correo electrónico user@example.com ". Esto utilizará ambas funciones para obtener el resultado.

Ejecutar código Python

Ejecuta código Python arbitrario en un entorno de pruebas Lambda. Esta potente función permite a Claude escribir y ejecutar código Python para realizar cálculos, procesamiento de datos u otras operaciones no integradas en el modelo. Por ejemplo, puedes pedirle al modelo que calcule la cantidad de números primos entre 1 y 10, 1 y 100, y así sucesivamente hasta 1 millón.

Implementación de funciones Lambda de muestra

El repositorio incluye funciones Lambda de muestra en el directorio sample_functions .

  1. Instale la CLI de AWS SAM: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html

  2. Implementar las funciones de muestra:

    cd sample_functions
    sam build
    sam deploy

Las funciones de muestra se implementarán con el prefijo mcp2lambda- .

Uso con Amazon Bedrock

MCP2Lambda también se puede utilizar con la API Converse de Amazon Bedrock, lo que le permite utilizar el protocolo MCP con cualquiera de los modelos compatibles con Bedrock.

El directorio mcp_client_bedrock contiene una implementación de cliente que conecta MCP2Lambda con los modelos de Amazon Bedrock.

Consulte https://github.com/mikegc-aws/amazon-bedrock-mcp para obtener más información.

Prerrequisitos

  • Acceso y permisos de Amazon Bedrock para utilizar modelos como Claude, Mistral, Llama, etc.

  • Boto3 configurado con credenciales apropiadas

Instalación y configuración

  1. Navegue al directorio mcp_client_bedrock:

    cd mcp_client_bedrock
  2. Instalar dependencias:

    uv pip install -e .
  3. Ejecute el cliente:

    python main.py

Configuración

El cliente está configurado para utilizar Claude 3.7 Sonnet de Anthropic de forma predeterminada, pero puede modificar model_id en main.py para utilizar otros modelos Bedrock:

# Examples of supported models:
model_id = "us.anthropic.claude-3-7-sonnet-20250219-v1:0"
#model_id = "us.amazon.nova-pro-v1:0"

También puedes personalizar el mensaje del sistema en el mismo archivo para cambiar el comportamiento del modelo.

Uso

  1. Inicie el servidor MCP2Lambda en una terminal:

    cd mcp2lambda
    uv run main.py
  2. Ejecute el cliente Bedrock en otra terminal:

    cd mcp_client_bedrock
    python main.py
  3. Interactúe con el modelo mediante la interfaz de línea de comandos. El modelo tendrá acceso a las funciones Lambda implementadas anteriormente.

Uso con Claude Desktop

Agregue lo siguiente a su archivo de configuración de Claude Desktop:

{
  "mcpServers": {
    "mcp2lambda": {
      "command": "uv",
      "args": [
        "--directory",
        "<full path to the mcp2lambda directory>",
        "run",
        "main.py"
      ]
    }
  }
}

Para ayudar al modelo a utilizar herramientas a través de AWS Lambda, en su perfil de configuración, puede agregar a sus preferencias personales una frase como:

Use the AWS Lambda tools to improve your answers.

Iniciando el servidor MCP

Inicie el servidor MCP localmente:

cd mcp2lambda
uv run main.py

Available Tools

2 tools
invoke_lambda_function_implB

Tool that invokes an AWS Lambda function with a JSON payload. Before using this tool, list the functions available to you.

ParametersJSON Schema
NameRequiredDescriptionDefault
function_nameYes
parametersYes

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool invokes a Lambda function but doesn't mention critical behavioral traits such as authentication requirements, error handling, rate limits, or what happens upon invocation (e.g., synchronous vs. asynchronous execution). This leaves significant gaps for an agent to understand the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise and well-structured with two sentences: the first states the purpose, and the second provides usage guidance. Every sentence earns its place by adding clear value without redundancy, making it front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of invoking a Lambda function, no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on authentication, execution behavior, error responses, and parameter specifics, which are essential for an agent to use this tool effectively in a real-world context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It mentions 'JSON payload' which relates to the 'parameters' parameter, adding some meaning beyond the schema. However, it doesn't explain the 'function_name' parameter or provide details on payload structure, format, or constraints, failing to fully address the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'invokes an AWS Lambda function with a JSON payload.' It specifies the verb ('invokes'), resource ('AWS Lambda function'), and payload type ('JSON payload'), which is specific and actionable. However, it doesn't explicitly differentiate from its sibling 'list_lambda_functions_impl' beyond the implied distinction between invocation and listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: 'Before using this tool, list the functions available to you.' This indicates a prerequisite step involving the sibling tool 'list_lambda_functions_impl', offering clear context for usage. However, it lacks details on when not to use it or alternatives beyond this prerequisite.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_lambda_functions_implC

Tool that lists all AWS Lambda functions that you can call as tools. Use this list to understand what these functions are and what they do. This functions can help you in many different ways.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states the tool lists functions but doesn't disclose behavioral traits such as whether it requires authentication, rate limits, pagination, or what the output format looks like. The description is minimal and lacks critical operational details for a tool that interacts with AWS Lambda.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, but the last two are redundant and vague ('This functions can help you in many different ways'), adding no value. It's front-loaded with the core purpose but wastes space on fluff, reducing overall efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and a simple tool with zero parameters, the description is incomplete. It fails to explain what the list includes (e.g., function names, ARNs, configurations) or how to interpret the results, leaving gaps in understanding the tool's behavior and output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. Baseline is 4 for zero parameters, as the schema fully covers the absence of inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool lists AWS Lambda functions, which is a clear purpose, but it's vague about what 'functions that you can call as tools' means. It doesn't distinguish from the sibling 'invoke_lambda_function_impl' tool, which would handle calling those functions. The description adds generic phrases like 'help you in many different ways' that don't clarify the specific action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions using the list to understand what functions are and what they do, implying it's for discovery, but it doesn't provide explicit guidance on when to use this tool versus the sibling 'invoke_lambda_function_impl'. There's no mention of alternatives, prerequisites, or exclusions, leaving usage context unclear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updates
    • First observedinvoke_lambda_function_impl
    • First observedlist_lambda_functions_impl

TDQS

B3.1/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one lists available Lambda functions, and the other invokes a specific function. There is no overlap or ambiguity between them, as they serve separate steps in a workflow.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern with '_impl' suffix: list_lambda_functions_impl and invoke_lambda_function_impl. This naming convention is predictable and uniform across the tool set.

Tool Count2/5

With only 2 tools, the server feels thin for its apparent scope of interacting with AWS Lambda functions. While it covers listing and invoking, typical Lambda operations like updating, deleting, or configuring functions are missing, making the set under-scoped.

Completeness2/5

The tool set is severely incomplete for AWS Lambda management. It only supports listing and invoking functions, lacking essential CRUD operations such as creating, updating, deleting, or monitoring functions, which limits agent capabilities in this domain.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    Not graded
    maintenance
    Enables MCP clients to interact with any OpenAPI-defined REST API through a serverless AWS Lambda deployment. Supports multiple authentication methods and provides cost-effective, scalable access to third-party APIs through natural language.
    Apache 2.0
  • F
    license
    Not graded
    quality
    D
    maintenance
    An MCP server hosted on AWS Lambda that provides tools for retrieving user profiles and loan details via API Gateway. It enables GPT models to interact with structured user and financial data using the Streamable HTTP transport.
    -
  • F
    license
    Not graded
    quality
    C
    maintenance
    Enables interaction with AWS services (EC2, S3, Lambda, DynamoDB, etc.) through the Model Context Protocol, allowing natural language management of cloud resources.
    2
    -