Skip to main content
Glama
YawLabs

@yawlabs/aws-mcp

Official
by YawLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

aws_lambda_invoke

Destructive

Invoke a Lambda function synchronously and get its response payload plus the decoded tail of its execution log in one call, removing the need to locate and tail logs separately.

Instructions

Invoke a Lambda function synchronously (RequestResponse) and return its response payload plus the DECODED tail of its execution log in one call. Use this instead of aws_call for Lambda invokes: aws lambda invoke needs a positional output file and rejects --cli-input-json, so aws_call structurally cannot reach it. The returned logTail is the last ~4 KB of the function's own log output, already base64-decoded, which removes the usual invoke -> find the log group -> tail it -> hope the window caught it loop. IMPORTANT: a non-empty functionError means the function's HANDLER threw; the invocation itself still succeeded, so ok is true and the thrown error is in payload.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionNoOverride session region for this call.
payloadNoThe event to pass to the function. Any JSON value (usually an object); it is JSON-encoded and sent as the request body. Omit for a function that takes no input — this sends no payload at all rather than an empty object.
profileNoOverride session profile for this call.
qualifierNoVersion number or alias to invoke, e.g. '3' or 'PROD'. Defaults to $LATEST.
timeoutMsNoTimeout in milliseconds. Default 60000 (60s). Raise it for a function whose own timeout is longer — a Lambda may run up to 15 minutes.
functionNameYesFunction name, name:alias, partial ARN ('123456789012:function:my-fn'), or full ARN. E.g. 'my-function', 'my-function:PROD'.
invocationTypeNoOnly 'RequestResponse' (synchronous) is supported. Async 'Event' and permission-check 'DryRun' are deliberately not implemented — 'Event' returns no payload or logs and needs its own result shape; for 'DryRun', use aws_iam_simulate instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.2.2

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark this as non-read-only, destructive, open-world, and non-idempotent. The description adds important behavior beyond those annotations: only synchronous RequestResponse is supported, the returned logTail is the last ~4 KB of the function log already base64-decoded, and a non-empty functionError means the handler threw while the invocation itself still succeeded.

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 front-loaded with the core purpose, then moves efficiently through the aws_call alternative, the logTail return behavior, and the important functionError caveat. Every sentence carries operational value and no sentence is redundant.

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

Completeness5/5

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

For a complex AWS invoke tool with seven parameters, no output schema, and destructive/open-world annotations, the description covers the return shape, logTail behavior, functionError semantics, supported invocation type, and relevant alternatives. It provides enough context for an agent to invoke and interpret the call correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all seven parameters, including payload omission behavior, qualifier format, region/profile overrides, and timeout guidance. The description reinforces synchronous RequestResponse usage but does not add substantial parameter-level meaning beyond the schema, so the baseline 3 is appropriate.

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

Purpose5/5

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

The description states a specific verb and resource: synchronously invoke a Lambda function and return both the response payload and the decoded execution log tail. It explicitly distinguishes this tool from the sibling aws_call by explaining why aws_call cannot reach Lambda invokes, so an agent can select it without opening either schema.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance: use this instead of aws_call for Lambda invokes, with the structural reason that aws lambda invoke requires a positional output file and rejects --cli-input-json. It also names the alternative for DryRun (aws_iam_simulate) and states that async Event and DryRun are deliberately not implemented.

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

Deploy Server

Other Tools