Bedrock Runtime: raise the 64-character tool-name limit for MCP interoperability

No SDK file or test is identified because the report describes a Bedrock Runtime service-side constraint rather than a Python serialization issue. Reproduce the request using Converse with a 65-character toolSpec.name, then review the linked ToolSpecification API documentation; done means the service supports the requested longer names or documents a supported aliasing mechanism.

Summary

Amazon Bedrock Runtime Converse limits toolConfig.tools[].toolSpec.name to 64 characters. Modern MCP clients qualify tool names with a server or application namespace, which can make otherwise valid tool names exceed this limit and cause Bedrock to reject the entire request before inference.

Please consider raising the Bedrock Runtime tool-name limit to at least 128 characters, or providing another service-supported mechanism for stable long-name aliases.

This is a Bedrock Runtime service API compatibility request rather than an SDK serialization bug. It is being filed here because the AWS SDK for Python currently targets Bedrock Runtime and provides a public AWS-owned feedback tracker.

Use case: Codex Apps over Bedrock

OpenAI Codex exposes app tools through MCP using model-visible names shaped like:

mcp__codex_apps__<tool_name>

The namespace consumes 17 characters, leaving only 47 characters for the individual tool name under the Bedrock limit.

Codex originally normalized MCP names to 64 bytes. OpenAI PR #39594 raised that limit to 128 bytes to match the OpenAI Responses API. Consequently, names between 65 and 128 characters are valid in Codex but fail when an OpenAI-compatible gateway forwards the request to Bedrock Runtime.

The Codex regression and reproduction details are tracked here:
https://github.com/openai/codex/issues/46188

Original Codex name-length issue and changes:

• https://github.com/openai/codex/issues/1289
• https://github.com/openai/codex/pull/1571
• https://github.com/openai/codex/pull/39594

Reproduction

1. Invoke Bedrock Runtime Converse with a model that supports tool use.
2. Include a toolSpec.name containing 65 valid ASCII characters.
3. Bedrock rejects the request with a ValidationException indicating that the member length must be less than or equal to 64.

The same failure occurs when one codex_apps MCP name exceeds the limit because Bedrock validates the complete tool configuration before model execution.

API constraint:
https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_ToolSpecification.html

Expected behavior

Ideally, Bedrock Runtime would accept tool names of at least 128 characters consistently across:

• ToolSpecification.name
• SpecificToolChoice.name
• returned toolUse.name values
• tool names replayed in conversation history

If the runtime limit cannot be raised, a documented service-supported aliasing or capability-negotiation mechanism would help clients avoid provider-specific request failures.

Current workaround

A proxy deterministically shortens names to 64 characters, preserves uniqueness with a hash suffix, and reverse-maps returned tool calls to their original MCP names. This works but requires every client or gateway to implement its own bidirectional mapping.

Related AWS-owned reports currently work around the same constraint by shortening names rather than changing the Runtime limit:

• https://github.com/aws/bedrock-agentcore-starter-toolkit/issues/308
• https://github.com/awslabs/mcp/issues/2395

Environment

• Client: OpenAI Codex CLI 0.153.2 / Codex Apps MCP tools
• Backend: Amazon Bedrock Runtime through an OpenAI-compatible gateway
• Platform: macOS
• SDK applicability: service-side constraint; reproducible through any AWS SDK exposing Converse