Add ClientSession/Client opt-out for automatic tool-result validation

[pujitha24]

Fixes #3513

Add a validate_tool_results: bool = True constructor parameter to ClientSession and the high-level Client. When set to False, call_tool skips the automatic validate_tool_result() call it otherwise runs after every successful result.

Motivation and Context

call_tool() revalidates a successful CallToolResult's structured_content against the tool's declared output_schema after every call. When the session's output-schema cache is empty — which it always is on a short-lived session, the pattern stateless gateways and proxies use (one ClientSession per call) — that revalidation triggers a tools/list request to discover the schema. This doubles round-trips on every call_tool, and when the server behind the session is itself an aggregator, it adds that aggregator's slowest-backend tools/list latency to every single call. There was previously no way to opt out short of subclassing ClientSession.

This is the "constructor opt-out" shape from the three options the issue proposed. The alternative (skip the refresh only when the cache is wholly empty) would have changed default behavior on a fresh session — several existing tests (test_validate_tool_result_passes_a_conforming_result and others in tests/client/test_session_promotions.py) deliberately lock in today's auto-discover-and-validate behavior on a first call, so changing that default felt like a maintainer design call rather than an obvious bug fix. The opt-out is purely additive: the default (True) preserves existing behavior exactly.

How Has This Been Tested?

• uv run --frozen pytest tests/client/ — 782 passed, 1 skipped, 1 xfailed
• uv run --frozen ruff format --check . / uv run --frozen ruff check . — clean
• uv run --frozen pyright on changed files — 0 errors
• ./scripts/test (full coverage-gated suite) — 5970 passed, 100.00% coverage, strict-no-cover clean
• uv run --frozen pre-commit run --files <changed> — markdownlint and ruff hooks pass. The pyright hook's only failure (tests/transports/stdio/test_lifecycle.py:190, os.waitid) is confirmed pre-existing on a clean main via git stash, unrelated to this change.
• Two new regression tests cover both call_tool paths that revalidate: the direct path (tests/client/test_session_promotions.py) and the SEP-2133 claimed-extension-result path (tests/client/test_client_extensions.py), each asserting that with the flag off, a schema-violating result passes through unraised and (for the direct path) that no tools/list request is issued — the test server has no on_list_tools handler at all, so such a request would raise METHOD_NOT_FOUND.
• Base branch CI (gh run list --branch main --event push) is green as of the last push.

Breaking Changes

None. The new parameter defaults to True, matching current behavior exactly; all existing tests pass unmodified.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I am assigned to the linked issue (or it is labeled help wanted, or I'm a maintainer)
• I have disclosed any AI assistance and can explain the change in my own words
• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

This PR was developed with AI assistance (Claude). I reviewed the change and can explain the approach and trade-offs described above.

Docs: added a short paragraph to docs/advanced/low-level-server.md right after the section that already describes the Client's automatic structured_content/output_schema revalidation, explaining the tools/list round-trip cost and the new escape hatch.

---

AI assistance: this change was drafted with Claude Code.

[github-actions]

This PR has been closed automatically. This repo only keeps pull requests open when they come from a maintainer, or from a contributor a maintainer has assigned to the linked issue, and you aren't currently assigned to #3513.

If a maintainer assigns you to #3513, this PR reopens on its own and there's nothing more you need to do here. Assignment is a maintainer call based on capacity; comments that only ask to be assigned don't factor in. What does help is engaging on the issue itself by confirming the repro, explaining why it matters for your use case, or describing the approach you'd take.

You're welcome to keep pushing commits here (just avoid force-pushing, since GitHub can't reopen a rewritten branch), but that on its own won't get the PR reviewed or the issue assigned, and realistically most auto-closed PRs stay closed. There's no need to open a new PR either way.

CONTRIBUTING.md has the full reasoning, but in short:

• We're a small team with very little capacity to review community PRs right now.
• Many recent PRs are AI-generated with little human review, and reviewing one carefully still costs a maintainer as much time as it ever did. A well-described issue is usually more useful to us than the code.

Maintainers: reopen, remove missing-issue-link, or add bypass-issue-check to override.