fix: provider-agnostic tool schema for Bedrock/Gemini MCP tools (#4472)

[joaquinhuigomez]

Summary

Fixes #4472 — MCP tools break with Bedrock and Gemini because extract_tool_info() uses generate_model_description(), which applies OpenAI-specific JSON schema transformations that these providers reject:

• additionalProperties: false — rejected by Bedrock
• All properties forced into required — breaks optional field semantics on Gemini/Bedrock
• title on nested objects — rejected by Gemini

What this PR does

• Adds generate_tool_parameters_schema() in pydantic_schema_utils.py — a clean, provider-agnostic alternative to generate_model_description() that:
  • Resolves $ref / $defs inline
  • Strips null from optional field types (preserving the fix: preserve null types in tool parameter schemas for LLM #4579 partial fix)
  • Recursively removes title, default, and additionalProperties
  • Preserves the original required array (does NOT force all fields required)
• Updates extract_tool_info() in common.py to use the new function for the args_schema path, which flows through safe_tool_conversion() to all providers (Bedrock, Gemini, Anthropic, OpenAI, Azure)
• Adds 8 targeted tests covering: no additionalProperties, optional fields not forced required, no title on nested objects, refs resolved, null stripped, defaults stripped, descriptions preserved, types preserved

Context

• PR fix: preserve null types in tool parameter schemas for LLM #4579 (merged) partially fixed this by stripping null types for optional fields
• PR fix: use provider-agnostic schema for non-OpenAI tool conversion (#4472) #4473 had the right approach (provider-agnostic schema generation) but was closed after the partial fix
• PR Lorenze/fix/issue 4472 #4601 was also closed without merge
• The root cause remained: generate_model_description() is designed for OpenAI structured outputs (strict mode) and should not be used for the shared tool-parameter extraction path

Why this approach

The generate_model_description() function is correct for OpenAI structured outputs — it needs additionalProperties: false, all-required, and strict mode. The problem is that extract_tool_info() (shared across providers) was reusing it for tool parameter schemas. This PR separates the two concerns with a dedicated function.

Test plan

• All 8 new TestGenerateToolParametersSchema tests pass
• All 81 existing test_pydantic_schema_utils.py tests pass (no regressions)
• All 59 existing test_agent_utils.py tests pass (no regressions)
• Manual verification with Bedrock/Gemini MCP tool calls (needs contributor with access)

---

Note

Medium Risk
Changes how tool args_schema is converted into JSON Schema for all providers, which can affect tool-calling payload validation and optional/required semantics. Mitigated by focused unit tests, but still touches a cross-provider integration surface.

Overview
Fixes MCP tool failures on Bedrock/Gemini by separating provider-agnostic tool parameter schema generation from OpenAI strict-mode schemas.

extract_tool_info() now uses a new generate_tool_parameters_schema() for Pydantic args_schema, producing a cleaned schema (refs inlined, null stripped, and removing title/default/additionalProperties) without forcing all fields required. OpenAI tool conversion keeps (and strengthens) its strict-mode pipeline by explicitly applying strip_unsupported_formats, ensure_type_in_schemas, convert_oneof_to_anyof, ensure_all_properties_required, and force_additional_properties_false.

Adds comprehensive tests for the new provider-agnostic schema output and a few strict-mode transform assertions.

^{Written by Cursor Bugbot for commit e0a819a. This will update automatically on new commits. Configure here.}

[joaquinhuigomez]

Addressed the Cursor Bugbot issue:

Bug: _strip_schema_metadata was popping title, default, and additionalProperties from the properties mapping dict itself, not just from schema nodes. A tool model with a field named title would have its entire property definition silently removed — breaking the schema while required still referenced it.

Fix: Added a _is_properties flag. When True (i.e. we're iterating a properties mapping where keys are field names), metadata stripping is skipped for that dict. Recursion into each property's schema still strips correctly.

Latest commit: a99502cac

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[joaquinhuigomez]

Addressed all three Cursor Bugbot findings:

High — OpenAI strict mode missing ensure_all_properties_required
Already added in the previous commit. Confirmed present.

Medium — Missing strip_unsupported_formats, ensure_type_in_schemas, convert_oneof_to_anyof
Fixed in latest commit. _convert_tools_for_interference now applies the full 5-transform pipeline in the same order as generate_model_description previously did:

1. strip_unsupported_formats — removes unsupported format annotations (uri, email, uuid)
2. ensure_type_in_schemas — converts empty {} to {"type": "object"} in anyOf/oneOf
3. convert_oneof_to_anyof — normalises oneOf → anyOf for strict mode
4. ensure_all_properties_required
5. force_additional_properties_false

Low — Field named properties incorrectly treated as a properties map
Reviewed the implementation: this is not a bug. When _is_properties_map=True, the code iterates for v in d.values() — keys (field names) are never inspected, so a field named properties is correctly processed as a schema node with _is_properties_map=False. Added a regression test (test_field_named_properties_not_treated_as_properties_map) to lock this in.

All 88 schema utils tests pass.

[joaquinhuigomez]

Addressed the review comments — let me know if you need anything else.

[joaquinhuigomez]

Closing this from my side — it's gone stale and the underlying schema work has likely shifted. Happy to revisit later if there's still interest.