# Quick MCP Integration Bug Report
**Bug ID**: QS-MCP-ARRAY-DESERIALIZE-001
**Date**: November 28, 2025
**Severity**: High
**Component**: Quick MCP Client Integration Layer
## Executive Summary
Quick’s Model Context Protocol (MCP) client fails to properly parse Server-Sent Events (SSE) responses from MCP servers when the response contains arrays in the result field. This affects all MCP integrations that return collection data, making many third-party tools unusable.
## Technical Details
### Error Message
```
Cannot deserialize value of type `com.amazon.mcpV2.spec.McpSchema$CallToolResult`
from Array value (token `JsonToken.START_ARRAY`)
at [Source: UNKNOWN; byte offset: #UNKNOWN]
```
### Root Cause Analysis
1. **SSE Parsing Failure**: Quick’s MCP client does not properly handle the `data:` prefix standard in Server-Sent Events
2. **Schema Rigidity**: The deserialization logic expects single objects but cannot handle arrays
3. **JSON-RPC Wrapper Handling**: The client fails to properly extract the result field from valid JSON-RPC 2.0 responses
### Technical Root Cause - Schema Design Flaw
Quick’s Java implementation uses a rigid schema (`McpSchema$CallToolResult`) that only accepts object types. The MCP specification allows `result` to be any valid JSON type (object, array, string, number, boolean, null).
This is not a parsing bug - it’s a **fundamental schema design flaw** that makes Quick incompatible with the MCP specification.
**Fix Required**: Update `McpSchema$CallToolResult` to accept `JsonNode` or `Object` type instead of a specific POJO, allowing flexible deserialization of any valid JSON structure.
## Evidence from Production Logs
### Request Format (Correct)
```json
{
“jsonrpc”: “2.0”,
“method”: “tools/call”,
“id”: “request-123”,
“params”: {
"name": "example_list_items",
"arguments": {
"filter": "active",
"limit": 10
}
}
}
```
### Server Response (Valid MCP Protocol)
```
data: {“jsonrpc”: “2.0”, “id”: “request-123”, “result”: [{“id”: 1, “name”: “Item 1”}, {“id”: 2, “name”: “Item 2”}]}
```
### Response Validation
Valid SSE format with `data:` prefix
Valid JSON-RPC 2.0 structure
Proper content structure
Correct SSE termination (`\n\n`)
## Affected vs. Working Tools
### 
Failing Tools (Array Responses)
- `list_devices` - Returns device array
- `list_applications` - Returns application array
- `list_alerts` - Returns alert array
- All other `list_*` operations across MCP integrations
### Working Tools (Object Responses)
- `get_device` - Returns single device object
- `get_application` - Returns single application object
- All `get_*` operations that return single objects
## Impact Assessment
### Immediate Impact
- 60-70% of MCP tools unusable
- All list/collection operations fail across MCP integrations
- User workflows requiring bulk data retrieval blocked
### Broader Impact
- Affects ANY MCP server integration returning arrays
- Limits third-party MCP tool ecosystem adoption
- Reduces Quick’s enterprise integration capabilities
## Reproduction Steps
1. Load any MCP integration with array-returning tools
2. Call a `list_*` operation (e.g., `list_devices`)
3. Observe deserialization error
4. Call equivalent `get_*` operation with single object response
5. Observe successful parsing
## Expected vs. Actual Behavior
### Expected
- Quick should parse SSE responses by stripping `data:` prefix
- Should handle both array and object responses in result field
- Should provide meaningful error messages for actual failures
### Actual
- Fails to parse valid SSE responses with arrays
- Throws generic deserialization errors
- Inconsistent behavior between array and object responses
## Testing Requirements
### Unit Tests
- SSE parsing with various prefixes and formats
- Array vs. object deserialization
- Error handling for malformed responses
### Integration Tests
- End-to-end MCP tool workflows
- Multiple third-party MCP server compatibility
- Performance under load
### Regression Tests
- Ensure existing single-object tools continue working
- Validate backward compatibility
## Business Justification
### Customer Impact
- Enterprise customers cannot fully utilize MCP integrations
- Workflow automation blocked for operations requiring bulk data
- Reduced ROI on Quick enterprise features
### Competitive Risk
- Other AI platforms with working MCP support gain advantage
- Customer churn risk for enterprise use cases
- Delayed adoption of new MCP-based integrations
## Priority Recommendation
**HIGH PRIORITY** - This bug blocks core enterprise integration functionality and affects the entire MCP ecosystem within Quick.
## Additional Context
### MCP Protocol Compliance
The Model Context Protocol specification clearly defines SSE as a valid transport mechanism and allows `result` to be any valid JSON type. Quick’s implementation must fully support the standard to ensure compatibility with the growing MCP ecosystem.
### Example Working Implementation
```python
# Correct SSE parsing
response_text = response.text # “data: {…}\n\n”
if response_text.startswith('data: '):
json_str = response_text.replace('data: ', '').strip()
data = json.loads(json_str)
result = data\['result'\] # Can be array, object, or any JSON type
```
### Timeline Impact
Each day this bug remains unfixed reduces customer confidence in Quick’s enterprise integration capabilities and delays adoption of new MCP-based tools.
## References
- [MCP Specification](https://spec.modelcontextprotocol.io/)
- [JSON-RPC 2.0 Specification]( JSON-RPC 2.0 Specification )
- [Server-Sent Events (SSE) Standard](HTML Standard)
Many of our community Experts and folks from our team are on holiday right now. I asked “My Assistant” (universal chat) in Quick, and got this back.