Feature Request: Parse output schema in smolagents adapter

[duguyue100]

Hi, I was trying to understand how smolagents package manages MCP tools. And found out that here

https://github.com/grll/mcpadapt/blob/main/src/mcpadapt/smolagents_adapter.py#L128-L133

        tool = MCPAdaptTool(
            name=mcp_tool.name,
            description=mcp_tool.description or "",
            inputs=input_schema["properties"],
            output_type="string",
        )

The output type is manually set as string. As I understand, official MCP's tool definition has an output schema.
Supporting output schema correctly would be a very nice addition for tool use.

[chahn]

This would be a great addition, as I understand that a CodeAct agent could generate optimal code to handle the tool’s output effectively?

I've been working extensively with smolagents and MCP tools, and the lack of outputSchema support creates a significant inefficiency in agent workflows, particularly with CodeAgent.

Current Problem: Inefficient Print-and-Inspect Pattern

Without outputSchema, agents must use this workflow:

# Step 1: Call tool blindly
raw_data = list_app_records(app_id="123", filter_param="")

# Step 2: Parse and print to see structure (wasted LLM step!)
data = json.loads(raw_data)
print(data)  # Agent needs to "see" what it got

# Step 3: In next iteration, finally work with the data
# Now the LLM can see the structure and write proper code

Critical Problem: Context Window Bloat

When tools return large JSON responses (which is common with data APIs), printing them to "inspect" the structure can severely bloat the context window. For example, a tool returning hundreds of records forces the entire JSON payload into the context just so the LLM can understand the structure. This:

• Wastes tokens on redundant data display
• Reduces available context for actual reasoning
• Increases costs for token-based models
• Slows down processing due to larger context

With OutputSchema: Direct, Intelligent Usage + Lean Context

The LLM would know the structure upfront and could write efficient code immediately without ever needing to see sample data:

# LLM already knows the tool returns:
# {
#   "app_id_1": {
#     "id": "string",
#     "name": "string", 
#     "fields": {...}
#   }
# }

# So it writes optimal code from the start:
raw_data = list_app_records(app_id="123", filter_param="")
data = json.loads(raw_data)
app_names = [record["name"] for record in data.values()]  # Direct access
# No printing needed = clean context

Technical Implementation?

The MCP specification already supports outputSchema in tool definitions:

{
  name: string;
  description?: string;
  inputSchema: { ... },
  outputSchema?: { ... },  // ← This exists but is ignored!
  annotations?: { ... }
}

The change would involve:

1. Preserve outputSchema in mcpadapt: Instead of hardcoding output_type="string", extract and pass through the MCP tool's outputSchema
2. Extend smolagents Tool class: Add output_schema attribute alongside existing output_type
3. Enhance tool descriptions for LLM: Include output structure info in the tool descriptions sent to the model

Benefits

This would eliminate both the "call → print → inspect → actually use" pattern AND the context bloat that comes with it. The agent would become significantly more efficient and direct in its tool usage while maintaining a lean context window.

[grll]

Nice I have seen the discussions to add structured output and I see now it's part of the MCP spec. I imagine usage by MCP server will still remain pretty low for now. But indeed would be a great feature to add. If you want to make a PR go for it otherwise I will see if I find some time.

[chahn]

@grll Thanks a lot for your support and openness to this feature!

I can give it a try and see how far I get, though I'm not really familiar with the internals of mcpadapt yet. If I manage to get a working implementation, perhaps we could polish it up together afterwards to make sure it's done properly.

[grll]

For sure, mcpadapt is quite small and easy happy to support in any case!

…

On Wed, Jul 2, 2025 at 6:01 PM Christian Hahn ***@***.***> wrote: *chahn* left a comment (grll/mcpadapt#62) <#62 (comment)> @grll <https://github.com/grll> Thanks a lot for your support and openness to this feature! I can give it a try and see how far I get, though I'm not really familiar with the internals of mcpadapt yet. If I manage to get a working implementation, perhaps we could polish it up together afterwards to make sure it's done properly. — Reply to this email directly, view it on GitHub <#62 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANIKTF2LFAGWXJQ6HQIDND3GP65HAVCNFSM6AAAAACAGKHE76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMRYGQYTOMRTG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[chahn]

@grll I tried an implementation of the feature we discussed and opened a PR with my changes.
Since I’m still new to mcpadapt, I’d really appreciate your feedback—especially on whether this is the most appropriate approach.
Thanks a lot in advance!