Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi everyone,
I am testing the official Qlik Cloud MCP server with several AI clients and have encountered a schema validation issue that appears to affect Gemini Enterprise specifically.
Environment and configuration:
The MCP configuration in Gemini Enterprise completes successfully. The connection test also succeeds, with no warnings or schema validation errors.
However, when I submit a request involving a Qlik application from the Gemini Enterprise web interface, Gemini understands and plans the request but stops before invoking the MCP tool.
The following error is returned:
LLM RPC failed: Unable to submit request because
qlik_create_measure functionDeclaration
parameters.colorSpec.gradient schema didn't specify
the schema type field.
[INVALID_ARGUMENT]The Gemini Enterprise diagnostic information confirms that the failure occurs during a model plan step. For example:
{
"createTime": "2026-07-15T10:15:48.570356021Z",
"planStep": {
"role": "MODEL",
"parts": [
{
"text": "LLM RPC failed: Unable to submit request because qlik_create_measure functionDeclaration parameters.colorSpec..."
}
]
}
}This suggests that Gemini Enterprise performs schema validation when submitting the available MCP tool declarations to the model. It appears to reject the schema because parameters.colorSpec.gradient does not contain an explicit type field.
The same schema validation problem also occurs with qlik_update_measure.
At present, Gemini Enterprise is the only tested client that rejects these tool declarations.
Other MCP clients may accept or normalize the same schema, while Gemini Enterprise appears to require an explicit type for nested schema nodes.
As a workaround, if I disable both qlik_create_measure and qlik_update_measure, the Qlik MCP integration in Gemini Enterprise appears to work correctly.
Has anyone else tested the official Qlik MCP server with Gemini Enterprise and encountered the same issue?
I would also be interested to know whether anyone has found a different workaround.
Thanks in advance for sharing your experience or any possible workaround
Cristian
A little slow coming back to update this thread, but this should now be fixed. Please feel free to reach out to support if issues persist.
Thanks for raising, we'll take a look. Please consider raising a support case for better tracking!
A little slow coming back to update this thread, but this should now be fixed. Please feel free to reach out to support if issues persist.
Hello Dave,
I’ve just checked, and the issue seems to be fixed. I’ll need to run a few more tests, but if everything works as expected, I’ll mark your reply as the accepted solution.
Many thanks!