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 decoded execution log tail in one call, eliminating separate log retrieval steps.

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. Functions on Lambda Managed Instances do not support the log tail; read their logs with aws_logs_tail. 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. The invoke is sent AT MOST ONCE: the AWS CLI's automatic retries are turned off here, because a retried invoke runs the function again. A TooManyRequestsException, or a connection that could not be opened, means nothing ran, so retrying is safe. On errorKind 'timeout' the error says whether the invoke was sent; if it was, or after a dropped connection or a 5xx, the function may have run and may still be running -- check its logs before invoking again.

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'. Omit for the service default: $LATEST for a standard function, $LATEST.PUBLISHED for one on Lambda Managed Instances. Durable functions need an explicit qualifier (a version, an alias, or $LATEST).
timeoutMsNoHow long to wait for the function to respond, in milliseconds. Default 60000. Set it to at least the function's own configured timeout; a synchronous invoke runs at most 15 minutes, so values above 900000 are treated as 900000. The AWS CLI is allowed 10 s beyond this to cover a cold start, so a function that hits its own timeout still returns as a functionError with its log tail; a call that gets no answer at all fails with errorKind 'timeout' after at most timeoutMs + 15 s.
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 a pre-flight permission check, aws_iam_simulate evaluates the caller's identity policies but not the function's resource-based policy.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.5.0
    • changedInput schema / properties / invocationType / description
      Previous value: -"Only '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."New value: +"Only '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 a pre-flight permission check, aws_iam_simulate evaluates the caller's identity policies but not the function's resource-based policy."
    • changedInput schema / properties / qualifier / description
      Previous value: -"Version number or alias to invoke, e.g. '3' or 'PROD'. Defaults to $LATEST."New value: +"Version number or alias to invoke, e.g. '3' or 'PROD'. Omit for the service default: $LATEST for a standard function, $LATEST.PUBLISHED for one on Lambda Managed Instances. Durable functions need an explicit qualifier (a version, an alias, or $LATEST)."
    • changedInput schema / properties / timeoutMs / description
      Previous value: -"Timeout in milliseconds. Default 60000 (60s). Raise it for a function whose own timeout is longer — a Lambda may run up to 15 minutes."New value: +"How long to wait for the function to respond, in milliseconds. Default 60000. Set it to at least the function's own configured timeout; a synchronous invoke runs at most 15 minutes, so values above 900000 are treated as 900000. The AWS CLI is allowed 10 s beyond this to cover a cold start, so a function that hits its own timeout still returns as a functionError with its log tail; a call that gets no answer at all fails with errorKind 'timeout' after at most timeoutMs + 15 s."
  2. Addedv2.2.2

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only carry hint flags (destructiveHint=true, idempotentHint=false), so the description carries the burden — and it is exceptional. It discloses that the CLI's automatic retries are disabled ('The invoke is sent AT MOST ONCE'), that a non-empty functionError still means ok is true, and the dangerous middle case where 'the function may have run and may still be running — check its logs before invoking again.' This is exactly the information an agent needs to avoid double-invoking a non-idempotent function.

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

Conciseness4/5

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

Dense, front-loaded guidance: the core behavior and aws_call substitution come in the first two sentences. Each subsequent sentence earns its place by covering retry safety or error semantics, though there is minor redundancy with the timeoutMs parameter description's cold-start discussion.

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?

There is no output schema, so the description must explain return semantics — and it does, covering logTail (last ~4 KB, base64-decoded), functionError (handler threw, ok still true, error in payload), and the three distinct failure classes with retry guidance. For a complex, non-idempotent invocation tool, nothing an agent needs to invoke correctly and avoid duplicate runs is missing.

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%, and parameter descriptions are already rich (payload encoding, qualifier defaults, timeout cap at 900000 ms, invocationType rationale), so the baseline 3 applies. The main description adds tool-level semantics (logTail, functionError, retry safety) rather than per-parameter detail, which is the correct division of labor.

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?

States a specific verb and resource: 'Invoke a Lambda function synchronously (RequestResponse)' and adds a differentiating outcome — 'return its response payload plus the DECODED tail of its execution log in one call.' It names the sibling it replaces ('Use this instead of aws_call') and the one for the Managed-Instances edge case (aws_logs_tail), so an agent can pick this tool without opening schemas.

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?

Explicitly routes around aws_call ('Use this instead of aws_call for Lambda invokes') and explains why: 'aws lambda invoke needs a positional output file and rejects --cli-input-json, so aws_call structurally cannot reach it.' It also directs Managed-Instances users to aws_logs_tail and, for pre-flight permission checks, to aws_iam_simulate.

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