New issue?
Bug
The Okta MCP server returns inconsistent response formats that make it difficult for clients to parse responses reliably. Currently, responses are returned as:
- Python dict strings instead of JSON strings (most common)
- Enum objects embedded in the response strings instead of their string values
- Unparseable object string representations for some tools (e.g.,
get_user)
- Tuples in list responses instead of proper dictionaries
- Mixed formats across different tools
This inconsistency forces clients to implement complex parsing logic with multiple fallback strategies, which is error-prone and not maintainable.
Expected behavior
All MCP server responses should follow the MCP protocol standard and return JSON strings in the content[].text field:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [
{
"type": "text",
"text": "{\"id\": \"0oa123\", \"name\": \"My App\", \"status\": \"ACTIVE\", \"sign_on_mode\": \"SAML_2_0\"}"
}
],
"isError": false
}
}
Key requirements:
- JSON format: All responses should be valid JSON strings (not Python dict strings)
- Enum values: Enum objects should be serialized to their string values (e.g.,
"SAML_2_0" instead of <ApplicationSignOnMode.SAML_2_0: 'SAML_2_0'>)
- Proper serialization: Objects like
OktaAPIResponse should be serialized to JSON, not converted to string representations
- Consistent structure: List responses should return arrays of objects, not tuples
- Standard types: All values should be JSON-serializable (strings, numbers, booleans, null, objects, arrays)
Observed behavior
Current Behavior
Example 1: Python Dict String with Enum Objects
Tool: get_application or list_applications
Response:
"{'id': '0oa123', 'name': 'My App', 'status': 'ACTIVE', 'sign_on_mode': <ApplicationSignOnMode.SAML_2_0: 'SAML_2_0'>}"
Issues:
- Python dict string format (not JSON)
- Enum object (
<ApplicationSignOnMode.SAML_2_0: 'SAML_2_0'>) cannot be parsed by standard JSON parsers
- Requires
ast.literal_eval() and custom enum handling
Example 2: Unparseable Object String
Tool: get_user
Response:
"<okta.api_response.OktaAPIResponse object at 0xffff8132b770>"
Issues:
- Completely unparseable - no data can be extracted
- This appears to be a serialization bug where the object is converted to its string representation instead of being properly serialized
Example 3: Tuples in List Responses
Tool: list_users
Response:
{
"items": [
("{'email': 'user@example.com', 'firstName': 'John', ...}", "00u123"),
("{'email': 'user2@example.com', 'firstName': 'Jane', ...}", "00u456")
],
"total_fetched": 2
}
Issues:
- Items are tuples instead of dictionaries
- First element of tuple is a Python dict string, not JSON
- Requires special handling for tuple unpacking
Relevant log output
Additional information
Affected Tools
Based on testing, the following tools are affected:
get_application - Returns Python dict string with enum objects
list_applications - Returns Python dict string with enum objects
get_user - Returns unparseable object string representation
list_users - Returns tuples instead of objects
get_group - Returns Python dict string
list_groups - Returns Python dict strings in items array
- Likely affects all 40+ tools in the server
MCP Protocol Compliance
The Model Context Protocol specification expects responses to be JSON-serializable. The current implementation violates this expectation by returning Python-specific formats (dict strings, enum objects, tuples).
Requested Action
Please standardize all MCP server responses to:
- Return valid JSON strings in the
content[].text field
- Serialize enum objects to their string values
- Fix object serialization issues (especially
get_user)
- Ensure consistent format across all tools
- Add validation to prevent regression
This will make the Okta MCP server compliant with MCP standards and much easier for clients to integrate.
Additional Context
- MCP Protocol: https://modelcontextprotocol.io
- Current workaround: Clients must implement multi-strategy parsing with
ast.literal_eval() and custom enum handling
- Impact: Affects all clients integrating with the Okta MCP server
New issue?
Bug
The Okta MCP server returns inconsistent response formats that make it difficult for clients to parse responses reliably. Currently, responses are returned as:
get_user)This inconsistency forces clients to implement complex parsing logic with multiple fallback strategies, which is error-prone and not maintainable.
Expected behavior
All MCP server responses should follow the MCP protocol standard and return JSON strings in the
content[].textfield:{ "jsonrpc": "2.0", "id": 1, "result": { "content": [ { "type": "text", "text": "{\"id\": \"0oa123\", \"name\": \"My App\", \"status\": \"ACTIVE\", \"sign_on_mode\": \"SAML_2_0\"}" } ], "isError": false } }Key requirements:
"SAML_2_0"instead of<ApplicationSignOnMode.SAML_2_0: 'SAML_2_0'>)OktaAPIResponseshould be serialized to JSON, not converted to string representationsObserved behavior
Current Behavior
Example 1: Python Dict String with Enum Objects
Tool:
get_applicationorlist_applicationsResponse:
Issues:
<ApplicationSignOnMode.SAML_2_0: 'SAML_2_0'>) cannot be parsed by standard JSON parsersast.literal_eval()and custom enum handlingExample 2: Unparseable Object String
Tool:
get_userResponse:
Issues:
Example 3: Tuples in List Responses
Tool:
list_usersResponse:
Issues:
Relevant log output
Additional information
Affected Tools
Based on testing, the following tools are affected:
get_application- Returns Python dict string with enum objectslist_applications- Returns Python dict string with enum objectsget_user- Returns unparseable object string representationlist_users- Returns tuples instead of objectsget_group- Returns Python dict stringlist_groups- Returns Python dict strings in items arrayMCP Protocol Compliance
The Model Context Protocol specification expects responses to be JSON-serializable. The current implementation violates this expectation by returning Python-specific formats (dict strings, enum objects, tuples).
Requested Action
Please standardize all MCP server responses to:
content[].textfieldget_user)This will make the Okta MCP server compliant with MCP standards and much easier for clients to integrate.
Additional Context
ast.literal_eval()and custom enum handling