`FunctionToolset` and `FastMCPToolset` defaulted `max_retries=1`,
ignoring the agent's `retries` setting. Changed default to `None`
(inherit from agent) and resolve via `ToolManager` at runtime.

Resolution chain: Tool → Toolset → Agent (via ToolManager.default_max_retries)

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

…_retries as int

- Propagate default_max_retries onto RunContext in for_run_step() so
  prepare functions see the agent's retry count, not the RunContext default
- Resolve None→agent default in FunctionToolset/FastMCPToolset.get_tools()
  so ToolsetTool.max_retries is always int (remove _resolve_max_retries)
- Update docstrings to document None = inherit from agent at runtime
- Add test_prepare_function_sees_agent_max_retries covering ctx propagation

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

…ries

# Conflicts:
#	pydantic_ai_slim/pydantic_ai/tool_manager.py
#	pydantic_ai_slim/pydantic_ai/toolsets/fastmcp.py
#	tests/test_toolsets.py

… output-retry fix

The `ctx = replace(ctx, max_retries=self.default_max_retries)` line in
`ToolManager.for_run_step` was overriding the `max_result_retries` value
set by `_agent_graph.py` before each `for_run_step` call. This caused
output validators to see `max_retries=1` (the tool default) instead of the
correct `output_retries` value when `output_retries != retries`.

Upstream PR pydantic#4956 already propagates `ctx.max_retries=max_result_retries`
at all three `for_run_step` call sites in `_agent_graph.py`, so the
override in `ToolManager` is now both redundant and harmful on the output
path.

Also update `build_run_context` in tests to accept a `max_retries` param
so unit tests can simulate realistic agent contexts (where `_agent_graph.py`
sets `ctx.max_retries` before calling `for_run_step`).

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

… in ToolManager

- ToolsetTool.max_retries widened to int|None; ToolManager resolves None to
  ctx.max_retries at execution time via new _resolve_max_retries helper,
  applied at _build_tool_context, _run_execute_hooks, _raw_execute,
  validate_tool_call
- FunctionToolset.get_tools passes unresolved value to FunctionToolsetTool;
  keeps local resolution only for the prepare_tool_def ctx so prepare
  functions still see the resolved agent-default
- FastMCPToolset.get_tools and tool_for_tool_def pass self.max_retries
  directly, dropping the hardcoded 1 fallback so durable execution paths
  inherit the agent's retries via ToolManager
- _AgentFunctionToolset: widen max_retries to int | None = None for
  parent-class consistency
- temporal _ToolInfo.max_retries mirrors ToolsetTool to int | None
- tests: new test_toolset_tool_max_retries_none_resolved_by_tool_manager
  and test_fastmcp_tool_for_tool_def_uses_toolset_max_retries; rewrite
  test_fastmcp.py::test_get_tools snapshot with direct field assertions

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

`ToolManager._resolve_max_retries` and `FunctionToolset.get_tools` were
falling back to `ctx.max_retries`, but `RunContext.max_retries` is populated
from `max_result_retries` (the output-validation retry count), not the tool
retry count. When a toolset/tool has no explicit `max_retries` and the agent
is built with `Agent(retries=..., output_retries=...)` (divergent values),
tools and prepare functions saw the output retry count instead of the tool
retry count.

- ToolManager._resolve_max_retries falls back to self.default_max_retries,
  which holds _max_tool_retries (set by Agent at construction)
- FunctionToolset.get_tools resolves the prepare ctx max_retries from
  ctx.tool_manager.default_max_retries (propagated via build_run_context),
  with ctx.max_retries as the fallback for standalone toolset use
- tests: new regression tests exercise the divergent retries/output_retries
  scenario for both the execute path and the prepare path

Addresses devin r3076977400, r3076977506, r3076977694.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

Root cause of prior workarounds: the graph set `ctx.max_retries =
max_result_retries` before calling `for_run_step`, so regular toolsets'
`get_tools` saw the output retry count. Fix at the source: pass
`tool_manager.default_max_retries`; have `OutputToolset.for_run_step`
snapshot from `self.max_retries` instead of `ctx.max_retries`.

Consequences:
- Revert `ToolsetTool.max_retries` to `int`; each toolset resolves
  `None` at `get_tools` time (tool override ?? toolset default ??
  ctx.max_retries).
- Drop `ToolManager._resolve_max_retries` and the patch-and-restore
  in `for_run_step`; use `tool.max_retries` directly.
- `CombinedToolset._output_prep_ctx` now handles only the one case
  the graph fix can't: output-tool `prepare_output_tools` needs
  `ctx.max_retries` = output retries.
- Collapse `FunctionToolset.get_tools` three-level fallback to two.
- Strengthen new tests with tool-call attempt counts.

…n tests

Addresses auto-review feedback on pydantic#4745.

- Introduce `AbstractToolset._adjusted_ctx_for_get_tools(ctx)` so each
  toolset can customize its own `get_tools` context instead of
  `CombinedToolset` hard-coding knowledge of `OutputToolset` and
  manually unwrapping `WrapperToolset` layers.
  - `OutputToolset` overrides to inject `self.max_retries` into
    `ctx.max_retries` for `prepare_output_tools`.
  - `WrapperToolset` delegates to the wrapped toolset.
- Drop the `else 1` fallbacks in `OutputToolset.for_run_step` /
  `get_tools`: Agent always sets `max_retries` before the run, so
  assert that invariant instead of masking it.
- Strengthen new max_retries tests with `capture_run_messages()` +
  message-trace snapshots per the testing guidelines.

Known follow-up tracked in pydantic#5180 (FastMCP `tool_for_tool_def` fallback).

…d_ctx_for_get_tools

Agent always sets `OutputToolset.max_retries` before the run, so the
`return ctx` branch is unreachable — coverage failed on it. Replace
the guard with the same `assert self.max_retries is not None` used
in `for_run_step` and `get_tools`, and unconditionally `replace(ctx)`.

…ction

Replaces the `_adjusted_ctx_for_get_tools` hook on `AbstractToolset`
(and its `WrapperToolset`/`OutputToolset` participants) with an optional
`PreparedToolset.max_retries` kwarg set at agent wiring time.

Addresses @DouweM's review of the prior refactor: don't pollute the
abstract toolset hierarchy with a hook that exists solely for one caller
(`prepare_output_tools`); decide at construction time where both the
wrapper and the retry limit are known.

Changes:

- `AbstractToolset`, `WrapperToolset`, `CombinedToolset`: reverted to
  upstream — no hook, no delegation, `CombinedToolset.get_tools` passes
  `ctx` through to children.
- `PreparedToolset`: new optional `max_retries: int | None = None` field.
  When set, `ctx.max_retries` is overridden for the `prepare_func` call
  only. Default `None` preserves existing behavior.
- `OutputToolset`: removed the hook override.
- `Agent._get_toolset`: when wrapping an `OutputToolset` with
  `prepare_output_tools`, pass `max_retries=output_toolset.max_retries`
  so the callback observes the output retry limit.

Semantically matches pydantic#5075's direction of "ctx.max_retries always
reflects the enforcement scope" — inside `prepare_output_tools` that
scope is the output toolset, whose `max_retries` is the per-tool default.