What does this PR do?

Normalises MCP tool input schemas that declare {"type": "object"} without a properties field before forwarding them to the LLM tool-calling API. This fixes a 400 Bad Request from OpenAI when an MCP server exposes a bare object schema, such as Crawl4AI's ask tool:

Invalid schema for function 'mcp_crawl4ai_ask':
In context=(), object schema missing properties.

The normalisation is applied in both MCP tool discovery/registration and the MCP sampling callback when server-provided tools are forwarded to the model, which are the only two places I could find the MCP tool schema reaching the model.

Regression tests covering both paths included.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• Added _normalize_mcp_input_schema() in tools/mcp_tool.py [used USian spelling for codebase consistency ;p]
• Updated MCP schema conversion in tools/mcp_tool.py to normalise bare object schemas before registration
• Updated the sampling callback in tools/mcp_tool.py to normalise server-provided tool schemas before forwarding them to the model
• Added a regression test in tests/tools/test_mcp_tool.py for MCP tool schemas with {"type": "object"} and no properties
• Added a regression test in tests/tools/test_mcp_tool.py covering the sampling callback path for server-provided tools with the same schema shape

How to Test

1. Run:

   pytest tests/tools/test_mcp_tool.py -q tests/tools/test_mcp_tool_issue_948.py -q

2. Verify the MCP tests pass, including the new regression coverage for object schemas without properties.
3. Reproduce against an MCP server exposing a tool with {"type": "object"} input schema and confirm the gateway no longer sends an OpenAI-invalid function schema for that tool.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: Linux

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A