[FEATURE] Strands MCP client should support retrieving Output Schema & other Data Types

[jkwening]

Problem Statement

I would like strands to support MCP output schema tool specs feature: https://modelcontextprotocol.io/specification/2025-06-18/server/tools#data-types

A tool definition includes:
- name: Unique identifier for the tool
- title: Optional human-readable name of the tool for display purposes.
- description: Human-readable description of functionality
- inputSchema: JSON Schema defining expected parameters
- outputSchema: Optional JSON Schema defining expected output structure
- annotations: optional properties describing tool behavior

Proposed Solution

Running the most latest version of python MCP SDK (v1.13.1), I was able to connect and fetch output schema from remote MCP server with the following change to MCPAgentTool tool spec function:

def tool_spec(self) -> ToolSpec:
  """Get the specification of the tool.
  
  This method converts the MCP tool specification to the agent framework's
  ToolSpec format, including the input schema and description.
  
  Returns:
      ToolSpec: The tool specification in the agent framework format
  """
  description: str = self.mcp_tool.description or f"Tool which performs {self.mcp_tool.name}"
  return {
      "inputSchema": {"json": self.mcp_tool.inputSchema},
      "outputSchema": {"json": self.mcp_tool.outputSchema},
      "name": self.mcp_tool.name,
      "description": description,
  }

Use Case

It will allow LLM agents to incorporate enhanced context from MCP servers that have implemented the new MCP data types. I'm working on a use case where an Agent is having issues determine which tool to use and providing the context of the output schema has shown to facilitate discerning the nuances between different tools.

Alternatives Solutions

No response

Additional Context

No response

[dbschmigelski]

Hi, thanks for raising this. I am curious about the use case for outputSchema. Bedrock for example does not accept outputSchema as field in the ToolSpecification https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_ToolSpecification.html

Is there a model you have been testing on which would benefit from the addition property.

Generally, I think the concept of providing outputSchema to be used throughout the application could be useful. But specifically for passing to the LLM I'm curious about the benefits.

Thanks

[mxie-extreme]

We have the similar use case where outputSchema is required. For example, a query parser identify a list of tools to accomplish the query intent. Based on the inputSchame and outputSchema, we can generate the execution plan (i.e. execution sequence, one tool's output is another tool's input) and prepare tool parameter values based on previous tool output. Thus, outputSchema is required.

[jkwening]

I haven't looked at LLM directly using this information via tool calls yet, as you noted regarding Bedrock's specification, it is currently lagging behind MCP features. I'm currently focused on the application layer to effectively manage access to a remote MCP server that provides access to all of our internal APIs; 100s of tools via a single remote server interface. So to mitigate the risk of selecting an incorrect or suboptimal tool, I'm building a router/classifier that can be used by agents to identify only the relevant tools for the context or task, thereby actively setting an upper bound of tools it should consider for tool calls and injecting that in the prompt as additional context and directions. I have limited control on what, when, and which tools will be available, so it needs to be dynamic, adjusting based on the current availability of tools in the remote server. The experiments I've recently ran by mocking the remote server to include context about each API tool response schema was very positive, so I'm now in the process of directly accessing the outputSchema from the remote server now that we have several tools that include that metadata for additional testing and benchmarking. Hopefully, the next iterations of LLM will soon include the outputSchema as a field in the Tool Specs but until then, I will manage in the application layer.

…

On Wed, Sep 3, 2025 at 3:06 PM Dean Schmigelski ***@***.***> wrote: *dbschmigelski* left a comment (strands-agents/sdk-python#787) <#787 (comment)> Hi, thanks for raising this. I am curious about the use case for outputSchema. Bedrock for example does not accept outputSchema as field in the ToolSpecification https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_ToolSpecification.html Is there a model you have been testing on which would benefit from the addition property. Generally, I think the concept of providing outputSchema to be used throughout the application could be useful. But specifically for passing to the LLM I'm curious about the benefits. Thanks — Reply to this email directly, view it on GitHub <#787 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABELKKHQXVXLH3F34VRHB633Q433HAVCNFSM6AAAAACFRQDYV6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENJQGQZTCOJQGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[dbschmigelski]

Gotcha, thanks this makes sense to me. We'll most likely explore adding the outputSchema just for MCP to start. Then, we'll create a follow up ticket to try to automatically generate the schema for things like our decorated tools.

[jkwening-extnet]

@dbschmigelski - I'm happy to take a crack at submitting a PR for this. Is my proposed solution sufficient? Can you expand further on: "try to automatically generate the schema for things like our decorated tools"?

[dbschmigelski]

@jkwening, if you take a look at the Tool Decorator, we generate the ToolSpec from the input parameters. So by "try to automatically generate the schema for things like our decorated tools" I mean that suppose a decorated tool is a complex object. We could convert that complex object into an output schema automatically.

I think lets leave that off for now. It can be a future enhancement.

I am aligned with the proposal to add the outputSchema on the ToolSpec dictionary. Adding this as optional should not be difficult. Where you'll have to be careful is to not break any of the models. For example, Bedrock does not ignore extra keys and will fail with a validation exception if we were to just accidentally send outputSchema in the ToolSpec.

[vamgan]

Hi @dbschmigelski, could you please clarify the scope of this task? I'm a bit unclear on the exact requirements. From what I understand, the goal is to have the model config determine whether outputSchema is supported or not. Let me know if I'm missing anything. Thanks!