### Summary:
This enables users to **use** MCP inside the SDK.
1. You add a list of MCP servers to `Agent`, via `mcp_server=[...]`
2. When an agent runs, we look up its MCP tools and add them to the list
of tools.
3. When a tool call occurs, we call the relevant MCP server.
Notes:
1. There's some refactoring to make sure we send the full list of tools
to the Runner/Model etc.
2. Right now, you could have a locally defined tool that conflicts with
an MCP defined tool. I didn't add errors for that, will do in a
followup.
### Test Plan:
See unit tests. Also has an end to end example next PR.
---
[//]: # (BEGIN SAPLING FOOTER)
* #324
* #322
* __->__ #321
* #320
### Summary:
1. Add the MCP dep for python 3.10, since it doesn't support 3.9 and below
2. Create MCPServer, which is the agents SDK representation of an MCP server
3. Create implementations for HTTP-SSE and StdIO servers, directly copying the [MCP SDK example](https://github.com/modelcontextprotocol/python-sdk/blob/main/examples/clients/simple-chatbot/mcp_simple_chatbot/main.py)
4. Add a util to transform MCP tools into Agent SDK tools
Note: I added optional caching support to the servers. That way, if you happen to know a server's tools don't change, you can just cache them.
### Test Plan:
Checks pass. I added tests at the end of the stack.
Currently, when we set `parallel_tool_calls=False` in the
`model_settings`, the responses API is called with `parallel_tool_calls
== NotGiven`, which defaults to true on the Response API side
(https://platform.openai.com/docs/api-reference/responses/create#responses-create-parallel_tool_calls).
This PR attempts to fix that.
```
agent = Agent(
...,
model_settings=ModelSettings(
parallel_tool_calls=False,
),
)
```
# Fix potential infinite tool call loop by resetting tool_choice after
tool execution
## Summary
This PR fixes an issue where setting `tool_choice` to "required" or a
specific function name could cause models to get stuck in an infinite
tool call loop.
When `tool_choice` is set to force tool usage, this setting persists
across model invocations. This PR automatically resets `tool_choice` to
"auto" after tool execution, allowing the model to decide whether to
make additional tool calls in subsequent turns.
Unlike using `tool_use_behavior="stop_on_first_tool"`, this approach
lets the model continue processing tool results while preventing forced
repeated tool calls.
## Test plan
- Added tests to verify tool_choice reset behavior for both agent and
run_config settings
- Added integration test to verify the solution prevents infinite loops
- All tests pass
## Checks
- [x] I've added new tests for the fix
- [x] I've updated the relevant documentation (added comment in code)
- [x] I've run `make lint` and `make format`
- [x] I've made sure tests pass
### Summary:
This enables users to **use** MCP inside the SDK.
1. You add a list of MCP servers to `Agent`, via `mcp_server=[...]`
2. When an agent runs, we look up its MCP tools and add them to the list of tools.
3. When a tool call occurs, we call the relevant MCP server.
Notes:
1. There's some refactoring to make sure we send the full list of tools to the Runner/Model etc.
2. Right now, you could have a locally defined tool that conflicts with an MCP defined tool. I didn't add errors for that, will do in a followup.
### Test Plan:
See unit tests. Also has an end to end example next PR.
### Summary:
1. Add the MCP dep for python 3.10, since it doesn't support 3.9 and below
2. Create MCPServer, which is the agents SDK representation of an MCP server
3. Create implementations for HTTP-SSE and StdIO servers, directly copying the [MCP SDK example](https://github.com/modelcontextprotocol/python-sdk/blob/main/examples/clients/simple-chatbot/mcp_simple_chatbot/main.py)
4. Add a util to transform MCP tools into Agent SDK tools
Note: I added optional caching support to the servers. That way, if you happen to know a server's tools don't change, you can just cache them.
### Test Plan:
Checks pass. I added tests at the end of the stack.
This update moves the tool_choice reset logic to a more appropriate location within the RunImpl class, ensuring that the original agent's model_settings remains unmodified during the reset process. The logic now checks for problematic scenarios before creating a modified copy of the agent's settings, maintaining expected behavior across sequential runs. This change enhances clarity and efficiency in handling tool choices.
Addresses previous feedback regarding the modification of the agent instance and improves the overall structure of the reset logic.
This fixes the issue where the original agent's model_settings was being directly modified during the tool choice reset process. The original implementation caused the agent's tool_choice to unintentionally reset to "auto" for subsequent runs, which could be unexpected behavior.
The fix creates new copies of the agent and model settings objects using dataclasses.replace() instead of modifying the original objects. This ensures that the tool choice reset is limited to the current run only, maintaining the expected behavior for sequential runs with the same agent.
Addresses feedback from @baderalfahad about the agent instance being modified when it should maintain its original state between runs.
- Refactor tool_choice reset to target only problematic edge cases
- Replace manual ModelSettings recreation with dataclasses.replace
- Fix line length and error handling lint issues in tests
# Summary
This adds the missing TracingProcessor export to __init__.py.
# Behavior
When trying to add a custom tracing processor, the TracingProcessor
importing fails with not found error when trying the example usage
proposed in issue #164
Specifically this line throws the error:
`add_trace_processor(MyTracingProcessor("output"))`
# Expected Behavior
Inspecting the init file, simply the import/export was missing. Adding
these made the example code work for me
# Test plan
Local dev of example code in #164
# Issue number
#164
# Checks
None
This PR introduces a `strict_mode: bool = True` option to
`@function_tool`, allowing optional parameters when set to False. This
change enables more flexibility while maintaining strict JSON schema
validation by default.
resolves#43
## Changes:
- Added `strict_mode` parameter to `@function_tool` and passed it to
`function_schema` and `FunctionTool`.
- Updated `function_schema.py` to respect `strict_mode` and allow
optional parameters when set to False.
- Added unit tests to verify optional parameters work correctly,
including multiple optional params with different types.
## Tests:
- Verified function calls with missing optional parameters behave as
expected.
- Added async tests to validate behavior under different configurations.
Martín Bravo
Rohan Mehta
apeccaud
xianghuijin
Raduan77
Richie Caputo
Kazuhiro Sera
Dominik Kundel
Carlos Souza
Vincenzo Domina
MartinEBravo
Carlos Souza