Ataccama ONE Agentic ONE Desktop ONE DQ&C ONE MDM ONE RDM ONE Runtime Server
latest (17.1.0) 17.0.0 16.3.x 16.2.0 16.1.0 16.0.0 15.4.0 15.3.0 15.2.0 15.1.0 14.5.x 13.9.x 13.8.x 13.7.x 13.6.x 13.5.0 13.4.x 13.3.x 13.2.x
Downloads

Connect Amazon Bedrock AgentCore to the DQ&C MCP Server

Amazon Bedrock AgentCore Gateway lets agents running in Amazon Bedrock use the Data Quality & Catalog (DQ&C) Model Context Protocol (MCP) server as a tool source. Unlike Claude, Gemini CLI, or Codex CLI, a Gateway has no browser and cannot sign in interactively. Instead, it authenticates with a client ID and client secret (machine-to-machine, or M2M) and calls the MCP server as a service account.

This page is for administrators who manage both the Ataccama identity provider (IDP) and your AWS account. For an overview of the MCP server and how to connect interactive AI clients, see Data Quality & Catalog MCP Server.

How Amazon Bedrock authenticates to the MCP server

By default, the MCP server accepts only tokens issued after an interactive browser sign-in. For Amazon Bedrock, the server can also accept tokens issued directly by Keycloak, as long as the token carries the scope that the server is configured to trust. Both modes work at the same time on the same endpoint, so enabling Amazon Bedrock support does not affect users of Claude, Gemini CLI, or Codex CLI.

A request from an agent passes through the following layers:

  1. The agent obtains a token from Keycloak through an AgentCore credential provider and calls the Gateway.

  2. The Gateway validates the token against Keycloak and obtains a service-account token from Keycloak using the client credentials you stored in AWS.

  3. The Gateway forwards the MCP request with the service-account token to the DQ&C MCP server.

  4. The MCP server checks the issuer, audience, and required scope of the token, and forwards the token to Ataccama ONE.

  5. Ataccama ONE authorizes the request based on the roles assigned to the service account and returns the result through the Gateway to the agent.

Because the same token is forwarded to ONE, permissions and the audit trail belong to the service account, not to the person or agent that triggered the request. See Security considerations for the Amazon Bedrock connection before you use this setup in production.

The setup requires configuring the following:

  • Ataccama identity provider (Keycloak): A dedicated client with a service account that can obtain tokens and is authorized in ONE.

  • DQ&C MCP server: The setting that lets the server accept those tokens.

  • AWS: A credential provider, a Gateway, a Gateway target, and the AWS Identity and Access Management (IAM) permissions that connect them.

A mistake in one part usually shows up as an unclear error in another part. Follow the steps in order and verify each step before you move on to the next. If something fails, see Troubleshooting the Amazon Bedrock connection to trace the symptom back to its cause.

Prerequisites

Before you start, make sure you have:

  • Ataccama ONE 17.1.0-patch11 or later. Amazon Bedrock support is not available in earlier versions.

  • Administrator access to the Keycloak Admin Console for your ONE environment.

  • An AWS account where you can create IAM roles and Amazon Bedrock AgentCore resources, with the AWS CLI configured for that account.

  • An AgentCore agent that you want to connect to the MCP server.

  • Network access from AWS to the MCP server. The MCP server hostname must resolve to a public address. Hostnames that resolve only to private addresses are not reachable from AWS.

    To check, run:

    dig +short mcp-<your-hostname> @1.1.1.1

  • curl and jq installed locally for the verification steps.

Throughout this page, replace the following placeholders:

Placeholder Description

<your-hostname>

The hostname where you access Ataccama ONE, for example one.example.com. The MCP server URL is https://mcp-<your-hostname>, and Keycloak is available at <your-hostname>/auth.

<AWS_ACCOUNT_ID>

Your 12-digit AWS account ID.

<AWS_REGION>

The AWS Region where you create the AgentCore resources, for example eu-central-1.

<CLIENT_SECRET>

The client secret of the dedicated Keycloak client you create in Create a dedicated client for Amazon Bedrock.

<CREDENTIAL_PROVIDER_ARN>

The Amazon Resource Name (ARN) of the credential provider, returned by the command in Create the OAuth 2.0 credential provider.

<GATEWAY_ID>

The ID of the Gateway, returned as gatewayId by the command in Create the Gateway.

<GATEWAY_URL>

The URL of the Gateway, returned as gatewayUrl by the command in Create the Gateway. The URL ends in /mcp.

<AGENT_EXECUTION_ROLE_NAME>

The name of the execution role of your AgentCore agent, for example AmazonBedrockAgentCoreHarnessDefaultServiceRole-XXXXX.

Step 1: Configure the identity provider

All steps in this section take place in the Keycloak Admin Console, in the ataccamaone realm.

The examples use mcp-dqc:direct as the scope name and mcp-dqc-agentcore as the client ID. Keep mcp-dqc:direct as the scope name, because it is the value the MCP server expects by default. If you use a different name, the MCP server setting must be changed to match, as described in Step 2: Check the scope configured on the MCP server.

Create a client scope for direct tokens

The MCP server accepts a directly presented token only if its scope claim contains the scope that the server is configured to trust (mcp-dqc:direct by default).

The scope does not exist in the realm until you create it. Create it once per realm:

  1. Go to Client scopes and select Create client scope.

  2. Configure the scope:

    • Name: mcp-dqc:direct.

    • Type: Default.

    • Include in token scope: On. Without this option, the scope is not added to the scope claim and the MCP server rejects the token.

  3. Select Save.

Do not reuse the existing mcp client scope for this purpose. That scope is available to a public client that uses the standard login flow, so any signed-in user could obtain a token that carries it, and the scope check would no longer limit who can call the MCP server directly.

Create a dedicated client for Amazon Bedrock

Create a separate client for Amazon Bedrock. Never enable service accounts on the interactive MCP client (mcp-dqc-openid), and never grant it the scope you created in the previous section. See Security considerations for the Amazon Bedrock connection for details.

  1. Go to Clients and select Create client.

  2. Enter the Client ID, for example mcp-dqc-agentcore, and select Next.

  3. In Capability config, set the following:

    • Client authentication: On.

    • Authentication flow: Select Service accounts roles only. Clear Standard flow and Direct access grants. This client should never perform an interactive login.

  4. Select Save.

  5. On the Credentials tab, copy the Client secret. You need it when you create the AWS credential provider and for the verification steps.

  6. On the Client scopes tab, select Add client scope.

  7. Select mcp-dqc:direct and add it as Default. A default scope is included in every token the client obtains, without any extra request parameters. If you add the scope as Optional instead, every token request must explicitly ask for it, which is easy to omit in a caller’s configuration.

Saving the client creates a user named service-account-mcp-dqc-agentcore in the realm.

Add an audience mapper

The MCP server also checks that the aud claim of the token contains its own client ID, which is the ID of the interactive MCP client, mcp-dqc-openid. Tokens issued to your dedicated client do not contain this audience by default, so you need to add a mapper:

  1. On the Client scopes tab of the mcp-dqc-agentcore client, select the mcp-dqc-agentcore-dedicated scope. Keycloak creates this scope automatically when you create the client.

  2. Select Configure a new mapper and choose Audience. If the scope already has mappers, select Add mapper > By configuration instead.

  3. Configure the mapper:

    • Name: mcp-dqc-audience.

    • Included Client Audience: mcp-dqc-openid.

    • Add to access token: On.

  4. Select Save.

The audience check runs before the scope check. If the mapper is missing, the MCP server rejects the token with a plain 401 even though the token looks correct when decoded.

Assign roles to the service account

A service account with no roles can obtain a token, but ONE does not let it see or do anything. Assign the realm roles that match what the agent should be allowed to do:

  1. Go to Users and open service-account-mcp-dqc-agentcore.

  2. On the Role mapping tab, select Assign role.

  3. Select the roles the agent needs and select Assign. For a description of the roles, see Identity Provider Roles.

For testing only, you can mirror a full administrator by assigning the same realm roles as the admin user. On a standard ataccamaone realm, these are admin, MMM_export, default, and default-roles-ataccamaone. Because admin is a composite role, the resulting token carries the full administrator role set, including ONE_ADMIN, MMM_admin, and MMM_user. Before you use the setup in production, replace these with only the roles the agent needs. See Apply least privilege to the service account.

Verify the service-account token

Request a token with the client credentials and inspect its claims:

Request a token and decode its claims
KC=https://<your-hostname>/auth/realms/ataccamaone

curl -s -X POST "$KC/protocol/openid-connect/token" \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode grant_type=client_credentials \
  --data-urlencode client_id=mcp-dqc-agentcore \
  --data-urlencode "client_secret=<CLIENT_SECRET>" \
  | jq -r .access_token | cut -d. -f2 | base64 -d 2>/dev/null | jq '{azp, aud, preferred_username, scope}'

The output should look like this:

Expected token claims
{
  "azp": "mcp-dqc-agentcore",
  "aud": ["mcp-dqc-openid", "account"],
  "preferred_username": "service-account-mcp-dqc-agentcore",
  "scope": "mcp-dqc:direct profile email"
}

Check that:

  • scope contains the scope name you created (mcp-dqc:direct).

  • aud contains the interactive MCP client ID (mcp-dqc-openid).

If either value is missing, revisit Create a dedicated client for Amazon Bedrock and Add an audience mapper.

Step 2: Check the scope configured on the MCP server

The MCP server accepts directly presented Keycloak tokens only if they carry the scope set in its TRUSTED_TOKEN_SCOPE environment variable. In Ataccama Cloud, the MCP server is deployed with this variable set to mcp-dqc:direct.

If you used mcp-dqc:direct as the scope name in Create a client scope for direct tokens, no change on the MCP server is needed. If you chose a different scope name, contact Ataccama Support and provide the name so that the variable can be updated to match.

The interactive sign-in path is always tried first, so this setting does not change anything for existing interactive clients.

Step 3: Verify the MCP server accepts the token

Before you create any AWS resources, confirm that the MCP server accepts the service-account token directly. This separates the Keycloak and MCP server configuration from the AWS configuration.

Run the following commands:

Initialize an MCP session and call a tool with the service-account token
MCP=https://mcp-<your-hostname>
TOKEN=<ACCESS_TOKEN>   # the token from the previous verification step

# initialize; capture the session id
curl -sS -D headers.txt -o /dev/null -X POST "$MCP" \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"probe","version":"1"}}}'
SID=$(grep -i '^mcp-session-id:' headers.txt | awk '{print $2}' | tr -d '\r')

curl -sS -o /dev/null -X POST "$MCP" \
  -H "Authorization: Bearer $TOKEN" -H "mcp-session-id: $SID" \
  -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","method":"notifications/initialized"}'

# a real tool call proves that ONE authorized the service account
curl -sS -X POST "$MCP" \
  -H "Authorization: Bearer $TOKEN" -H "mcp-session-id: $SID" \
  -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"search_catalog_items","arguments":{"query":"customer"}}}'

Expected results:

  • The initialize request returns HTTP 200 and an mcp-session-id header.

  • The tool call returns catalog items with isError: false.

  • Repeating the requests with an invalid token returns HTTP 401.

Step 4: Create the AWS resources

Create the following resources in order, all in the same AWS Region.

Create the Gateway execution role

The Gateway needs an IAM role that AgentCore can assume to read the stored client credentials and write logs.

Run the following commands:

Create the Gateway execution role
cat > trust.json <<'JSON'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "bedrock-agentcore.amazonaws.com" },
    "Action": ["sts:AssumeRole", "sts:SetContext"],
    "Condition": { "StringEquals": { "aws:SourceAccount": "<AWS_ACCOUNT_ID>" } }
  }]
}
JSON

cat > gw-policy.json <<'JSON'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "TokenVaultAndWorkloadIdentity",
      "Effect": "Allow",
      "Action": [
        "bedrock-agentcore:GetResourceOauth2Token",
        "bedrock-agentcore:GetWorkloadAccessToken",
        "bedrock-agentcore:GetWorkloadAccessTokenForJWT",
        "bedrock-agentcore:GetWorkloadAccessTokenForUserId"
      ],
      "Resource": [
        "arn:aws:bedrock-agentcore:<AWS_REGION>:<AWS_ACCOUNT_ID>:token-vault/default",
        "arn:aws:bedrock-agentcore:<AWS_REGION>:<AWS_ACCOUNT_ID>:token-vault/default/*",
        "arn:aws:bedrock-agentcore:<AWS_REGION>:<AWS_ACCOUNT_ID>:workload-identity-directory/default",
        "arn:aws:bedrock-agentcore:<AWS_REGION>:<AWS_ACCOUNT_ID>:workload-identity-directory/default/workload-identity/*"
      ]
    },
    {
      "Sid": "ReadProviderSecret",
      "Effect": "Allow",
      "Action": ["secretsmanager:GetSecretValue"],
      "Resource": "arn:aws:secretsmanager:<AWS_REGION>:<AWS_ACCOUNT_ID>:secret:bedrock-agentcore-identity*"
    },
    {
      "Sid": "Observability",
      "Effect": "Allow",
      "Action": ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"],
      "Resource": "arn:aws:logs:<AWS_REGION>:<AWS_ACCOUNT_ID>:log-group:/aws/bedrock-agentcore/*"
    }
  ]
}
JSON

aws iam create-role --role-name AtaccamaMcpGatewayRole \
  --assume-role-policy-document file://trust.json
aws iam put-role-policy --role-name AtaccamaMcpGatewayRole \
  --policy-name AgentCoreGatewayAccess --policy-document file://gw-policy.json

Create the OAuth 2.0 credential provider

The credential provider stores the client ID and client secret of your dedicated Keycloak client. AgentCore uses it to obtain service-account tokens with the client credentials grant.

Run the following commands:

Create the credential provider
KC=https://<your-hostname>/auth/realms/ataccamaone

aws bedrock-agentcore-control create-oauth2-credential-provider \
  --region <AWS_REGION> \
  --name ataccama-mcp-sa \
  --credential-provider-vendor CustomOauth2 \
  --oauth2-provider-config-input "{
    \"customOauth2ProviderConfig\": {
      \"oauthDiscovery\": { \"discoveryUrl\": \"$KC/.well-known/openid-configuration\" },
      \"clientId\": \"mcp-dqc-agentcore\",
      \"clientSecret\": \"<CLIENT_SECRET>\",
      \"clientAuthenticationMethod\": \"CLIENT_SECRET_POST\"
    }
  }"

Copy the ARN of the credential provider from the output. You need it in the following steps.

The command returns status: READY and stores the secret in AWS Secrets Manager under a name starting with bedrock-agentcore-identity!default/oauth2/ataccama-mcp-sa-.

The discovery URL must include the /auth path prefix, as shown. Without it, Keycloak returns a 404 page that AgentCore reports as Error parsing ClientCredentials response.

Create the Gateway

Run the following commands:

Create the Gateway
KC=https://<your-hostname>/auth/realms/ataccamaone

aws bedrock-agentcore-control create-gateway --region <AWS_REGION> \
  --name ataccama-mcp-sa-gw \
  --role-arn arn:aws:iam::<AWS_ACCOUNT_ID>:role/AtaccamaMcpGatewayRole \
  --protocol-type MCP \
  --protocol-configuration '{"mcp":{"supportedVersions":["2025-11-25"]}}' \
  --authorizer-type CUSTOM_JWT \
  --authorizer-configuration "{
    \"customJWTAuthorizer\": {
      \"discoveryUrl\": \"$KC/.well-known/openid-configuration\",
      \"allowedScopes\": [\"email\"]
    }
  }"

Note the gatewayId and gatewayUrl in the output. The Gateway URL ends in /mcp and is the endpoint your agents call.

Two authorizer settings must be set as follows:

  • allowedScopes is required. If you omit it, every request to the Gateway fails with 403 insufficient_scope. Set it to a scope that the caller’s token carries, such as email, which tokens from Keycloak carry by default.

  • Do not set allowedClients. The Gateway matches it against a client_id claim, which Keycloak does not include in its tokens, so every request is rejected.

Create the Gateway target

The target points the Gateway to the DQ&C MCP server and tells it which credential provider to use for outbound calls.

Run the following commands:

Create the Gateway target
GW=<GATEWAY_ID>   # gatewayId from the previous step
MCP=https://mcp-<your-hostname>

aws bedrock-agentcore-control create-gateway-target --region <AWS_REGION> \
  --gateway-identifier $GW \
  --name ataccama-mcp \
  --target-configuration "{
    \"mcp\": { \"mcpServer\": { \"endpoint\": \"$MCP\", \"listingMode\": \"DEFAULT\" } }
  }" \
  --credential-provider-configurations '[{
    "credentialProviderType": "OAUTH",
    "credentialProvider": {
      "oauthCredentialProvider": {
        "providerArn": "<CREDENTIAL_PROVIDER_ARN>",
        "scopes": [],
        "grantType": "CLIENT_CREDENTIALS"
      }
    }
  }]'

Set listingMode to DEFAULT so that the Gateway discovers the available tools when the target is created. With DYNAMIC, the target reaches the READY state but lists no tools, and no requests reach the MCP server.

Step 5: Verify the connection through the Gateway

Call the Gateway directly with a service-account token to confirm that the full chain works:

List and call tools through the Gateway
GWURL=<GATEWAY_URL>   # gatewayUrl from the create-gateway output, ends in /mcp
TOKEN=<ACCESS_TOKEN>   # a client_credentials token from Keycloak

# tools/list
curl -sS -X POST "$GWURL" \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2025-11-25' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}'

# tools/call - tool names are prefixed with the target name
curl -sS -X POST "$GWURL" \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2025-11-25' \
  -d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"ataccama-mcp___search_catalog_items","arguments":{"query":"customer"}}}'

The Gateway is stateless and does not return an mcp-session-id. Every request must carry the MCP-Protocol-Version: 2025-11-25 header explicitly. Otherwise, the Gateway falls back to an older protocol version and returns Unsupported protocol version.

Expected results:

Check Expected result

tools/list through the Gateway

The full list of DQ&C tools, with names prefixed by the target name and three underscores (ataccama-mcp___).

tools/call through the Gateway

isError: false and catalog items in the response.

Request without a token or with an invalid token

401 from both the Gateway and the MCP server.

Step 6: Connect your agent to the Gateway

After you verify the Gateway, connect your AgentCore agent to it. In the AgentCore API, agents are called harnesses.

Grant your agent access to the Gateway

The execution role of your agent needs permissions that it does not have by default. The policies AWS generates for the agent cover only the resources that existed when the agent was first configured, so they do not include the Gateway and credential provider you created in Step 4: Create the AWS resources.

Run the following commands:

Add the required permissions to the agent execution role
HARNESS_ROLE=<AGENT_EXECUTION_ROLE_NAME>   # for example AmazonBedrockAgentCoreHarnessDefaultServiceRole-XXXXX

cat > harness-addon.json <<'JSON'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadProvider",
      "Effect": "Allow",
      "Action": ["bedrock-agentcore:GetResourceOauth2Token"],
      "Resource": [
        "arn:aws:bedrock-agentcore:<AWS_REGION>:<AWS_ACCOUNT_ID>:token-vault/default",
        "<CREDENTIAL_PROVIDER_ARN>"
      ]
    },
    {
      "Sid": "ReadProviderSecret",
      "Effect": "Allow",
      "Action": ["secretsmanager:GetSecretValue"],
      "Resource": "arn:aws:secretsmanager:<AWS_REGION>:<AWS_ACCOUNT_ID>:secret:bedrock-agentcore-identity!default/oauth2/ataccama-mcp-sa-*"
    },
    {
      "Sid": "InvokeGateway",
      "Effect": "Allow",
      "Action": ["bedrock-agentcore:InvokeGateway"],
      "Resource": "arn:aws:bedrock-agentcore:<AWS_REGION>:<AWS_ACCOUNT_ID>:gateway/<GATEWAY_ID>"
    },
    {
      "Sid": "BedrockModelAccess",
      "Effect": "Allow",
      "Action": [
        "aws-marketplace:ViewSubscriptions",
        "aws-marketplace:Subscribe",
        "bedrock:Converse",
        "bedrock:ConverseStream",
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "*"
    }
  ]
}
JSON

aws iam put-role-policy --role-name $HARNESS_ROLE \
  --policy-name AtaccamaMcpGatewayAccess --policy-document file://harness-addon.json

The bedrock:Converse, bedrock:ConverseStream, and aws-marketplace actions are needed for the model call, not for MCP. Without them, the agent fails with an error that model access is denied due to missing AWS Marketplace permissions, often only after one apparently successful run. Because aws-marketplace:Subscribe can incur costs and does not support resource-level scoping, consider restricting it with a condition on aws-marketplace:ProductId.

Add the Gateway as an agent tool

Add the Gateway to the tools of your agent.

The --tools option replaces the full list of tools of the agent but leaves its other settings unchanged. If your agent already has tools, add them to tools.json as well. Otherwise, they are removed from the agent.
Add the Gateway as an agent tool
cat > tools.json <<'JSON'
[{
  "type": "agentcore_gateway",
  "name": "ataccama-mcp",
  "config": {
    "agentCoreGateway": {
      "gatewayArn": "arn:aws:bedrock-agentcore:<AWS_REGION>:<AWS_ACCOUNT_ID>:gateway/<GATEWAY_ID>",
      "outboundAuth": {
        "oauth": {
          "providerArn": "<CREDENTIAL_PROVIDER_ARN>",
          "scopes": []
        }
      }
    }
  }
}]
JSON

aws bedrock-agentcore-control update-harness --region <AWS_REGION> \
  --harness-id <HARNESS_ID> --tools file://tools.json

The command updates an existing harness. Replace <HARNESS_ID> with the ID of the harness of the agent in which you want to use the MCP server.

The providerArn must be the full ARN of the credential provider, not its name. The AWS console shows only the name, so copy the ARN from the output of the create-oauth2-credential-provider command.

Leave scopes empty so that Keycloak returns its default scopes, which include email and therefore satisfy the Gateway’s allowedScopes.

Security considerations for the Amazon Bedrock connection

Review the following points before you use this setup in production.

Use a dedicated client

This page uses a dedicated Keycloak client for Amazon Bedrock and leaves the interactive MCP client (mcp-dqc-openid) unchanged. Keep it that way:

  • Never grant the direct-token scope to the interactive client. The MCP server stores the Keycloak tokens of every interactive user.

    If those tokens carried the scope, a user could present their own stored token straight to the MCP server and bypass the server’s token storage and revocation. They would still get only their own permissions, so this is not a privilege escalation, but it removes a safeguard.

  • Never enable service accounts on the interactive client.

A dedicated client also lets you rotate its secret independently and assign the service account a narrower set of roles.

Apply least privilege to the service account

If you assigned the roles of the admin user for testing, as described in Assign roles to the service account, the service account has full administrator access to ONE. Replace them with only the roles the agent needs. If the agent only reads metadata and data quality results, do not assign roles that allow changes to data quality rules or monitoring projects.

Understand the effects of a shared identity

All requests through the Gateway run under one service account:

  • The audit log in ONE shows a single principal for all activity triggered through Amazon Bedrock.

  • The MCP server rate limit (30 calls per minute by default) is applied per identity, so all agents using the Gateway share one limit. A single multi-step agent run can exhaust it on its own.

    Contact Ataccama Support if you need a higher limit.

Limitations of the Amazon Bedrock connection

Per-user identity through an AgentCore Gateway is not currently supported. The Gateway can forward only a service-account token, so requests are not attributed to the individual user who triggered the agent.

Troubleshooting the Amazon Bedrock connection

Errors in this setup often point at the wrong layer. If the direct test in Step 3: Verify the MCP server accepts the token succeeds, but calls through the Gateway fail, the problem is in the AWS configuration, and changes to the Keycloak or MCP server configuration do not help.

Contact Ataccama Support if you need the MCP server access log for your environment.

403 insufficient_scope on every Gateway call

The allowedScopes setting of the Gateway authorizer is missing, or allowedClients is also set. The Gateway matches allowedClients against a client_id claim, which Keycloak does not include in its tokens. Set allowedScopes to a scope the token carries, such as ["email"], and remove allowedClients.

tools/list returns no tools and the MCP server receives no requests

The Gateway target was created with listingMode: DYNAMIC, which does not work for MCP server targets. Delete the target and recreate it with listingMode: DEFAULT.

tools/call fails with an internal error while tools/list works

The target uses an API_KEY credential provider. Use an OAUTH credential provider with grantType: CLIENT_CREDENTIALS instead.

Unsupported protocol version: 2025-03-26

The MCP-Protocol-Version header is missing. Because the Gateway is stateless, it defaults to an older protocol version when the header is absent. Send MCP-Protocol-Version: 2025-11-25 with every request.

Error parsing ClientCredentials response

The token endpoint returned a non-JSON response, usually because the discovery URL is missing the /auth path prefix. Use <your-hostname>/auth/realms/ataccamaone/.well-known/openid-configuration.

unauthorized_client or Client not enabled to retrieve service account

Service accounts are not enabled on the Keycloak client. See Create a dedicated client for Amazon Bedrock.

Token is rejected with 401 although it carries the scope

The aud claim of the token does not contain the interactive MCP client ID. The audience check runs before the scope check, so a missing audience mapper results in a plain rejection. See Add an audience mapper.

AccessDeniedException on GetResourceOauth2Token

The agent execution role does not cover the newly created credential provider. The policies AWS generates for an agent cover only the resources that existed when the agent was created. See Grant your agent access to the Gateway.

AccessDeniedException on ConverseStream mentioning AWS Marketplace

The agent execution role lacks the aws-marketplace:ViewSubscriptions and aws-marketplace:Subscribe actions, or bedrock:ConverseStream, which is a separate action from bedrock:InvokeModel. This error often appears only after one successful run. See Grant your agent access to the Gateway.

providerArn fails validation when updating the agent

The credential provider name was supplied instead of its full ARN. Use the full arn:aws:bedrock-agentcore:…​ value from the create-oauth2-credential-provider output.

Gateway target is stuck in CREATING

The target combines a TOKEN_EXCHANGE credential provider with listingMode: DEFAULT. There is no caller token available when the target is created, so the exchange cannot happen. Wait for the target to reach the FAILED state, then delete it and recreate it with an OAUTH credential provider and grantType: CLIENT_CREDENTIALS.

See also

Was this page useful?