### Problem/Motivation `ToolsFunctionInput::renderFunctionArray()` renders `'parameters' => NULL` when a function declares no properties: ```php // src/OperationType/Chat/Tools/ToolsFunctionInput.php $function = [ 'name' => $this->name, 'description' => $this->description, 'parameters' => NULL, ]; if (!empty($properties)) { $function['parameters'] = [ /* … */ ]; } ``` `OpenAiBasedProviderClientBase::chat()` puts that straight into the payload, so a no-argument tool goes on the wire as: ```json {"type": "function", "function": {"name": "list_pages", "description": "…", "parameters": null, "strict": false}} ``` OpenAI's own endpoint tolerates `parameters: null`, so this is invisible there. An OpenAI-*compatible* endpoint need not. Sending it through a LiteLLM proxy in front of an Anthropic model fails the **entire request** — not just the offending tool: ``` litellm.APIConnectionError: 'NoneType' object has no attribute 'get' File ".../litellm/llms/anthropic/chat/transformation.py", line 659, in _map_tool_helper if _input_schema.get("type") != "object": ^^^^^^^^^^^^^^^^^ File ".../litellm/llms/anthropic/chat/transformation.py", line 907, in _map_tools new_tool, mcp_server_tool = self._map_tool_helper(tool) File ".../litellm/utils.py", line 4110, in get_optional_params optional_params = litellm.AnthropicConfig().map_openai_params(…) ``` LiteLLM does try to default the schema, but with `.get()` and a default — which still returns `None` when the key is *present and null*: ```python _input_schema = tool["function"].get("parameters", {"type": "object", "properties": {}}) ``` So the default never applies. This is the same in `v1.79`, `v1.80` and current `main`. Notes on scope: - It affects every provider built on `OpenAiBasedProviderClientBase` (the payload is assembled there), plus `ai_provider_openrouter`, `ai_provider_openai` and `ai_provider_mistral`, which call `renderToolsArray()` directly. - One no-argument tool anywhere in the set breaks every request that offers tools. A tool that takes no arguments is a legitimate thing to have (`list_current_items`, `reset_state`, …). - Anthropic-family models only. The same proxy with a Mistral model is unaffected, because its transform doesn't dereference the schema this way — which makes this easy to misattribute to the proxy or the key. - `ToolsPropertyInput::renderPropertyArray()` derives an array property's `items` from this method's `parameters`, so an empty child object also yields `items: null`. ### Steps to reproduce 1. Install and configure `ai_provider_litellm` against a LiteLLM proxy. 2. Bind a chat operation to an **Anthropic** model on that proxy (e.g. `anthropic/claude-haiku-4-5`). 3. Issue a chat request whose tool set includes at least one function with no properties: ```php $tools = new ToolsInput([ new ToolsFunctionInput('list_pages', ['description' => 'List pages.']), ]); ``` 4. The request fails with the `'NoneType' object has no attribute 'get'` error above. Every request that offers tools fails; the same tool set against an OpenAI model, or the same model with only argument-taking tools, succeeds. ### Proposed resolution Always render a valid JSON Schema object, even for a no-argument function: ```php $function = [ 'name' => $this->name, 'description' => $this->description, 'parameters' => [ 'type' => 'object', ], ]; if (!empty($properties)) { $function['parameters']['properties'] = $properties; foreach ($this->getRequiredProperties() as $property) { $function['parameters']['required'][] = $property->getName(); } } ``` `properties` is deliberately **omitted** rather than emitted empty: an empty PHP array JSON-encodes as `[]`, not the `{}` a schema calls for. Both the OpenAI and Anthropic schemas treat `properties` as optional, and LiteLLM fills it in (`if "properties" not in normalized: normalized["properties"] = {}` in `sanitize_input_schema_for_anthropic`). Emitting `{"type": "object"}` verified as accepted by LiteLLM `v1.79`, `v1.80` and `main`. The payload for functions that *do* declare properties is byte-identical to before. ### Remaining tasks - Review — in particular whether any provider relies on `parameters === NULL` to detect a no-argument tool. Grepping 1.4.4 I found none: every consumer is `isset()`/`is_array()`-guarded. - Optionally extend `ToolsInputTest::testConstructor()`, which currently only covers the with-properties case, so the no-argument shape is asserted. ### User interface changes None. ### API changes `ToolsFunctionInputInterface::renderFunctionArray()` no longer returns `'parameters' => NULL`; it returns at minimum `['type' => 'object']`. Callers inspecting the rendered array for NULL to mean "no arguments" should check for an empty/absent `properties` instead. ### Data model changes None.