L3 construct missing `bedrock:CountTokens` permission + MCP client sends GET instead of POST

[dmahapatro]

Description

Two issues found when creating a new AgentCore CLI project (reproducible on a fresh agentcore create app):

1. Missing bedrock:CountTokens in agent execution role
2. MCP client sends HTTP GET instead of POST to MCP server

Steps to Reproduce

1. Create a new AgentCore CLI project: agentcore create
2. Deploy and invoke the agent (the scaffolded app already includes the Exa MCP client by default)
3. Observe traces for both errors

Expected Behavior

1. The L3 construct should include bedrock:CountTokens in the IAM policy attached to the agent's execution role.
2. The MCP client should send a POST request to the MCP server endpoint, not GET.

Actual Behavior

Issue 1: Missing bedrock:CountTokens in agent execution role

The L3 construct does not include the bedrock:CountTokens action in the agent's execution role policy. This causes an AccessDeniedException at runtime. The error is non-blocking but shows up in traces.

Error:

AccessDeniedException: An error occurred (AccessDeniedException) when calling the CountTokens operation: 
User: arn:aws:sts::XXXXXXXXXXXX:assumed-role/AgentCore-CustomerSupport-ApplicationAgentCustomerS-6nuOb33W09pv/BedrockAgentCore-ac1c86c3-de93-43fb-8557-8646329aabe6 
is not authorized to perform: bedrock:CountTokens on resource: 
arn:aws:bedrock:us-east-1:XXXXXXXXXXXX:inference-profile/global.anthropic.claude-sonnet-4-5-20250929-v1:0 
because no identity-based policy allows the bedrock:CountTokens action

---

Issue 2: MCP client sends HTTP GET instead of POST to MCP server

The scaffolded app includes the Exa MCP client by default. At runtime, the MCP client sends an HTTP GET request to the MCP server endpoint instead of POST. MCP servers expect POST requests per the MCP protocol spec, so the server returns HTTP 405 (Method Not Allowed).

Full trace:

{
  "traceId": "69fd18744fbeee504b14eb996038f3d8",
  "spanId": "579b45dbae3c2ce1",
  "flags": 256,
  "name": "GET",
  "kind": "CLIENT",
  "startTimeUnixNano": 1778194554918856200,
  "endTimeUnixNano": 1778194554963947800,
  "durationNano": 45091588,
  "attributes": {
    "aws.local.service": "CountTokens_CountAgent.DEFAULT",
    "telemetry.extended": true,
    "http.url": "https://mcp.exa.ai/mcp",
    "aws.remote.service": "mcp.exa.ai",
    "aws.local.environment": "bedrock-agentcore:default",
    "aws.remote.operation": "GET /mcp",
    "http.status_code": 405,
    "aws.local.operation": "UnmappedOperation",
    "aws.span.kind": "CLIENT",
    "PlatformType": "AWS::BedrockAgentCore",
    "http.method": "GET",
    "http.response.status_code": 405,
    "session.id": "a8a4b0a7-ef2f-426f-a4c0-b5292914c2f7"
  },
  "status": {
    "code": "ERROR"
  },
  "resource": {
    "attributes": {
      "deployment.environment.name": "bedrock-agentcore:default",
      "aws.local.service": "CountTokens_CountAgent.DEFAULT",
      "service.name": "CountTokens_CountAgent.DEFAULT",
      "cloud.region": "us-east-1",
      "aws.log.stream.names": "otel-rt-logs",
      "telemetry.sdk.name": "opentelemetry",
      "aws.service.type": "gen_ai_agent",
      "telemetry.sdk.language": "python",
      "cloud.provider": "aws",
      "cloud.resource_id": "arn:aws:bedrock-agentcore:us-east-1:XXXXXXXXXXXX:runtime/CountTokens_CountAgent-IJDCzB41oz/runtime-endpoint/DEFAULT:DEFAULT",
      "aws.log.group.names": "/aws/bedrock-agentcore/runtimes/CountTokens_CountAgent-IJDCzB41oz-DEFAULT",
      "telemetry.sdk.version": "1.40.0",
      "cloud.platform": "aws_bedrock_agentcore",
      "telemetry.auto.version": "0.17.0-aws"
    }
  },
  "scope": {
    "name": "opentelemetry.instrumentation.httpx",
    "version": "0.61b0"
  },
  "parentSpanId": "11ca449276d6e017"
}

CLI Version

0.13.1

Operating System

macOS

Additional Context

• Region: us-east-1

[tejaskash]

Traced the issue to strands
strands-agents/sdk-python@a49dc33

[Hweinstock]

Thanks for reporting the issues!

Issue 1: To provide additional context, the strands team made a change (linked above) that now leverages additional functionality and permissions that the CLI had not yet updated our permissions to match. We've added the permission and will include it in the next release.

Issue 2: I believe this is expected behavior in the MCP protocol on initialization. My understanding is that the client will "probe" the server to see if it supports SSE:

The client MAY issue an HTTP GET to the MCP endpoint. This can be used to open an SSE stream, allowing the server to communicate to the client, without the client first sending data via HTTP POST.
The client MUST include an Accept header, listing text/event-stream as a supported content type.
The server MUST either return Content-Type: text/event-stream in response to this HTTP GET, or else return HTTP 405 Method Not Allowed, indicating that the server does not offer an SSE stream at this endpoint.

https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#listening-for-messages-from-the-server

In other words, the exa mcp client likely doesn't support SSE, so it responds with a 405. OTEL is then picking up this 405 as an error in its trace.