The request signature we calculated does not match the signature you provided

If the signing happens in Python — aws_iam_streamablehttp_client, streamablehttp_client_with_sigv4, or your own SigV4Auth

1. 1 Check the body reached the signer before anything else. SigV4Auth.payload() hashes request.body, and with no body it returns botocore's EMPTY_SHA256_HASH — e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. Build an AWSRequest without data=, sign it, then POST the JSON-RPC message with requests or httpx, and the canonical request you signed claims an empty payload while AWS hashes the message. Every MCP call is a POST with a body, so this fails on the very first request and never works once.
2. 2 Copy the whole signed header set onto the outgoing request, not just Authorization. botocore's _modify_request_before_signing adds X-Amz-Security-Token itself when the credentials carry a session token, and that header is part of the canonical request — cherry-pick Authorization out of the signed AWSRequest and the token is silently dropped. AWS's own signing reference is explicit that temporary credentials need it: "When you use temporary security credentials, you must add X-Amz-Security-Token to the Authorization header or include it in the query string to hold the session token."
3. 3 Pass the service name rather than letting it be inferred. aws_iam_streamablehttp_client takes aws_service and aws_region explicitly; AWS's proxy in front of it does infer, and its own troubleshooting entry for this error explains why to override that: "We try to autodetect the service from the url, sometimes this fails, ensure that --service is set correctly to the service you are attempting to connect to. Otherwise the SigV4 signing will not be able to be verified by the service you connect to, resulting in this error."
4. 4 Do not hand botocore headers that change in flight. Its SIGNED_HEADERS_BLACKLIST already skips connection, expect, keep-alive, proxy-authenticate, proxy-authorization, te, trailer, transfer-encoding, upgrade, user-agent and x-amzn-trace-id, and AWS's signing reference says why: "Do not include hop-by-hop headers that are frequently altered during transit across a complex system." AWS's proxy strips one by hand for exactly this reason — its comment reads "Header 'connection' = 'keep-alive' is not used in calculating the request signature on the server-side, and results in a signature mismatch if included".
5. 5 If you are on streamablehttp_client_with_sigv4, know what you are debugging: its own module docstring calls it a "Backwards compatibility wrapper" that forwards to aws_iam_streamablehttp_client from mcp-proxy-for-aws. Both take the same three inputs — endpoint, service, region — so a mismatch is in one of those three and not in the transport.

import boto3
from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest

body = '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

request = AWSRequest(
    method="POST",
    url="https://url-id-12345.lambda-url.us-west-2.on.aws/mcp",
    # Omit data= and the payload hash is the empty-string SHA-256 while
    # AWS hashes the body you actually send. This is the usual cause.
    data=body,
    headers={
        "Content-Type": "application/json",
        "Accept": "application/json, text/event-stream",
    },
)

# "lambda" here, "execute-api" for API Gateway, "bedrock-agentcore" for
# AgentCore Runtime. Never "mcp".
SigV4Auth(boto3.Session().get_credentials(), "lambda", "us-west-2").add_auth(request)

# dict(request.headers), not just the Authorization value: botocore also
# set x-amz-date and, for session credentials, X-Amz-Security-Token.
headers = dict(request.headers)

If your agent uses StreamableHTTPClientWithSigV4Transport or createSigV4Fetch

1. 1 Two options decide the credential scope and nothing else does: region and service. The transport's own comment names the values it expects — "AWS service name for signing requests (e.g., 'lambda', 'execute-api')" — and AgentCore adds bedrock-agentcore. Get either wrong and AWS answers with the element it wanted rather than a bare mismatch: Credential should be scoped to correct service: '<service>', or Credential should be scoped to a valid Region, not <region-code>.
2. 2 The signer takes the signed host from the URL you construct it with — it seeds the header map with host: urlObj.hostname — and host is required in every canonical request. So if the URL your client dials is a custom domain, a load balancer or a CDN that forwards to a different origin host, you have signed the wrong host. AWS documents this exact failure for a function URL behind CloudFront: "Lambda will validate the signature against the host of the Lambda URL domain. If the signature isn't based on the Lambda URL domain, the host in the signature won't match the host used by the Lambda URL origin. This means the request will fail, resulting in a signature validation error."
3. 3 Unlike botocore, this path publishes the payload hash on the wire. @smithy/signature-v4 sets x-amz-content-sha256 when the header is absent and applyChecksum is on, and applyChecksum is on by default — the source comment is "default to true if applyChecksum isn't set". The header is then itself signed, so anything that rewrites the body after signing breaks the hash and the header together.
4. 4 Every header you put on the transport is signed unless the signer considers it unsignable, and the exempt list is fixed: ALWAYS_UNSIGNABLE_HEADERS covers authorization, cache-control, connection, expect, from, keep-alive, max-forwards, pragma, referer, te, trailer, transfer-encoding, upgrade, user-agent and x-amzn-trace-id, plus anything matching /^proxy-/i or /^sec-/i. mcp-session-id and mcp-protocol-version are not on it, so a hop that adds or rewrites either after signing is a mismatch.
5. 5 Re-signing a request has to start from a clean header set. smithy's prepareRequest deletes authorization, x-amz-date and date before it signs, and a caller that restores its own saved headers afterwards puts the previous signature back over the new body. LiteLLM shipped a fix for precisely that shape: a retry re-signed a modified body, the first attempt's Authorization and X-Amz-Date were restored on top, and AWS returned 403 SignatureDoesNotMatch.

import { StreamableHTTPClientWithSigV4Transport } from "@aws/run-mcp-servers-with-aws-lambda";
import { Client } from "@modelcontextprotocol/sdk/client/index.js";

// The first argument must be a URL object. Its hostname becomes the signed
// `host` header, so it has to be the host the verifying AWS service sees —
// not a custom domain or CDN in front of it.
const transport = new StreamableHTTPClientWithSigV4Transport(
  new URL("https://url-id-12345.lambda-url.us-west-2.on.aws/mcp"),
  // `service` is the SigV4 signing name of the endpoint and `region` has
  // to match the credential scope AWS will recompute.
  { service: "lambda", region: "us-west-2" },
);

const client = new Client({ name: "my-client", version: "0.0.1" });
await client.connect(transport);

If a chat client is the caller and AWS's local signing proxy is doing the signing for it

1. 1 No MCP client signs SigV4, so nothing here is in your server. AWS's answer is mcp-proxy-for-aws, a local stdio process launched by the client that signs from your own credentials — which means every value in this error comes from that process's arguments and environment.
2. 2 Set --service explicitly. The flag's own documentation is "AWS service name for SigV4 signing, if omitted we try to infer this from the url", and the proxy's troubleshooting entry for this error is about that inference failing. A function URL host is <url-id>.lambda-url.<region>.on.aws, which carries no service label to infer from at all.
3. 3 Set the Region the same way. --region "Uses AWS_REGION environment variable if not set", and a process a client spawns does not necessarily inherit your shell's exports — put the value in args, or in the config's env block. A separate symptom to recognise: no Region resolved at all surfaces as NoRegionError, which the proxy's docs note MCP clients show as -32602: Invalid request parameters, not as a signature error.
4. 4 "It worked this morning" is usually not this error. The proxy "reads fresh credentials from disk on every request, so credential refreshes and account switches take effect immediately — no restart or retry required", and expired credentials produce Signature expired: <date> is now earlier than <date> rather than a mismatch. Run aws sso login and retry without restarting anything; if the message is still the mismatch, the service or the Region is wrong.

{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@1.6.0",
        "https://url-id-12345.lambda-url.us-west-2.on.aws/mcp",
        "--service",
        "lambda",
        "--region",
        "us-west-2",
        "--profile",
        "default"
      ]
    }
  }
}

If the MCP route is an API Gateway method whose authorizationType is AWS_IAM

1. 1 The service code is execute-api, not apigateway and not lambda. AWS's permissions model page puts it plainly: the invoking actions are "execute-api:Invoke or execute-api:InvalidateCache, where execute-api designates the underlying API execution component of API Gateway." Sign with the wrong one and the credential-scope check fails before the signature is compared, giving you Credential should be scoped to correct service: '<service>'.
2. 2 The stage is part of the path you sign. AWS's annotated canonical request marks the second line as "Path. For API stage endpoint, it should be /{stage-name}/{resource-path}", against a host of the form <api-id>.execute-api.<region>.amazonaws.com. A client configured with the bare invoke URL and the stage stitched on elsewhere signs a path the gateway never sees.
3. 3 Sign the Region the API lives in, which the host already tells you. Both signature versions are accepted — "API Gateway supports Signature Version 4a (SigV4a) and Signature Version 4 (SigV4) to authenticate the user's credentials" — but the credential scope has to match either way, and with SigV4a the Region moves out of the scope and into an X-Amz-Region-Set header that is signed instead.
4. 4 Separate this from an unsigned request. AWS: "Make sure that the API request is signed with SigV4. If the API request isn't signed, then you might receive the error: Missing Authentication Token." That is a client that never signed at all, which is a different fix from a signature that did not verify.

GET                                                      -------- HTTP method
/                                                        -------- Path. For API stage endpoint, it should be /{stage-name}/{resource-path}
                                                         -------- Query string key-value pair. Leave it blank if the request doesn't have a query string.
content-type:application/json                            -------- Header key-value pair. One header per line.
host:0123456789.execute-api.us-east-1.amazonaws.com      -------- Host and x-amz-date are required headers for all signed requests.
x-amz-date:20220806T024003Z

content-type;host;x-amz-date                             -------- A list of signed headers
d167e99c53f15b0c105101d468ae35a3dc9187839ca081095e340f3649a04501        -------- Hash of the payload

If anything sits between the code that signs and the AWS service that verifies — a load balancer, a CDN, a service-mesh sidecar, or a gateway re-signing on your behalf

1. 1 Start here when the same request succeeds against the AWS hostname and fails through your own. AWS's troubleshooting note is one sentence and it is the whole diagnosis: "You can also verify that you didn't send the request through a proxy that modifies the headers or the request."
2. 2 host is signed on every request — AWS requires it in the canonical headers — so any hop that presents a different Host to the verifying service breaks the signature by construction, before anything about your payload matters. AWS spells this out for a function URL behind CloudFront: "If the signature isn't based on the Lambda URL domain, the host in the signature won't match the host used by the Lambda URL origin. This means the request will fail, resulting in a signature validation error."
3. 3 The volatile headers are the other half, and AWS names them: "Do not include hop-by-hop headers that are frequently altered during transit across a complex system. This includes all volatile transport headers that are mutated by proxies, load balancers, and the nodes in a distributed system, including connection, x-amzn-trace-id, user-agent, keep-alive, transfer-encoding, TE, trailer, upgrade, proxy-authorization, and proxy-authenticate." A tracing sidecar that stamps x-amzn-trace-id after signing is enough, if your signer included it.
4. 4 Where the hop signs for you, its own configuration owns the service and the Region. AgentCore Gateway is the documented case: for an MCP server or OpenAPI target under IAM outbound authorization you supply an iamCredentialProvider whose service is "The AWS service name used for SigV4 signing. For example, bedrock-agentcore for MCP servers hosted on Amazon Bedrock AgentCore", and whose region is optional — "If you don't specify a Region, the gateway uses its own Region." A target in a different Region from the gateway therefore gets signed for the wrong one by default. Lambda, API Gateway and Smithy targets take no iamCredentialProvider at all.
5. 5 If the hop cannot sign and cannot be taken out of the path, IAM signing is not the method for that route. A PUT or POST through CloudFront's origin access control needs the caller to supply the hash: "your users must compute the SHA256 of the body and include the payload hash value of the request body in the x-amz-content-sha256 header when sending the request to CloudFront. Lambda doesn't support unsigned payloads." Every MCP message is a POST with a body, so that requirement applies to all of them.

# Bisect the hops. Same body, same signer, one URL at a time.
#  1. the AWS hostname directly   -> https://url-id-12345.lambda-url.us-west-2.on.aws/mcp
#  2. through your load balancer  -> https://mcp-internal.example.com/mcp
#  3. through your CDN or domain  -> https://mcp.example.com/mcp
#
# Then read what actually arrived. Every signed name must survive the trip
# with the same value, and `host` must be the host that verifies.
curl -sS -D - -o /dev/null -X POST "$URL" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

# The first URL that fails is the hop that changed the request.

Something else

Whatever the components are, this error has one shape: two canonical requests differ by one field, and only three things can be changed — what you sign, what arrives, or the scope you sign it under. Work it in that order. Read the response body first, because AWS names the service, the Region or the date when one of those is what differed, and a bare mismatch is the only case that needs investigating. Then reproduce with a known-good signer over the same body, since every MCP message is a POST and a signer handed no body signs the empty-string hash. Then bisect the hops: sign for the AWS hostname, then for each proxy, ingress or domain in front of it, and fix the layer where the request stopped matching rather than the signer. Two dead ends worth naming: this is not a permissions problem — a verified signature that IAM then denies is also a 403, and only the body distinguishes them — and it is not something the MCP spec can help with, because request signing sits outside the OAuth profile there, so there is no challenge to read and no discovery to fall back on.