Is your feature request related to a problem? Please describe.
The current implementation uses associative array for the decoding the JSON-RPC message. Which will break the Opis\JsonSchema\Validator since it needs the stdClass for a object as described in the docs. Currently the empty array/object ambiguity exists and the validation fails.
Describe the solution you'd like
Preserve JSON object/array semantics on inbound MCP messages and set associative parameter to false. Update all internal methods to work with stdClass objects instead of associative arrays.
json_decode($input, false, JSON_THROW_ON_ERROR)
Additional context
This feature would allow to work with fully validated object structures with #Schema attribute on input parameters in tool calls. Here is an example how a tool call failed and the model confusion about the parameter typing. The tool method is using this signature: McpServer::updateDocument(array $document) So i asked the model why did it fail, this is the answer:
The document parameter type should be object (not array), and the description should clarify the expected root structure:
{
"document": {
"type": "object",
"description": "Complete document (root object with type, name, version properties)",
"properties": {
"type": { "type": "string" },
"name": { "type": "string" },
"version": { "type": "string" },
},
"required": ["type", "name", "version"]
}
}
The key fix: changing "type": "array" to "type": "object" and adding a required array so it's explicit what the root document needs.
Is your feature request related to a problem? Please describe.
The current implementation uses associative array for the decoding the JSON-RPC message. Which will break the
Opis\JsonSchema\Validatorsince it needs thestdClassfor a object as described in the docs. Currently the empty array/object ambiguity exists and the validation fails.Describe the solution you'd like
Preserve JSON object/array semantics on inbound MCP messages and set
associativeparameter tofalse. Update all internal methods to work withstdClassobjects instead of associative arrays.Additional context
This feature would allow to work with fully validated object structures with
#Schemaattribute on input parameters in tool calls. Here is an example how a tool call failed and the model confusion about the parameter typing. The tool method is using this signature:McpServer::updateDocument(array $document)So i asked the model why did it fail, this is the answer:The document parameter type should be object (not array), and the description should clarify the expected root structure:
{ "document": { "type": "object", "description": "Complete document (root object with type, name, version properties)", "properties": { "type": { "type": "string" }, "name": { "type": "string" }, "version": { "type": "string" }, }, "required": ["type", "name", "version"] } }The key fix: changing "type": "array" to "type": "object" and adding a required array so it's explicit what the root document needs.