Consistent Error Response Structure

Tool execution errors now return a standardized response format across all failure types. Previously, the data field was empty on errors—now it always includes status_code and message, matching the structure of successful responses.

What Changed

All error responses from tool execution now include:

data.status_code: HTTP status code (or null for non-HTTP errors)
data.message: Detailed error message
error: Same detailed message at the top level

Before vs After

Previous error response:

{
  "data": {},
  "successfull": false,
  "error": "404 Client Error: Not Found for url: ...",
}

New error response:

{
  "data": {
      "http_error": "404 Client Error: Not Found for url: ...",
      "status_code": 404,
      "message": "Resource not found: The requested item does not exist"
  },
  "successfull": false,
  "error": "Resource not found: The requested item does not exist",
}

Why This Matters

Easier parsing: Agents and code can reliably access error details from data.message without special-casing empty data objects
Better debugging: Detailed error messages replace generic HTTP error strings
Consistent schema: Same response shape whether the tool succeeds or fails

Union Types Preserved in Tool Schemas

Tool schemas now use standard JSON Schema anyOf for union types, providing accurate type information for LLMs and code generators.

What Changed

Two changes affect how types appear in request/response schemas:

Change	Scope	Description
Nullable fields	All toolkits	Fields that accept `null` now use `anyOf: [{type}, {type: "null"}]` instead of `type` + `nullable: true`
Multi-type fields	157 toolkits	Fields accepting multiple value types (e.g., `string \| number`) preserve the full `anyOf` array instead of flattening to the first type

Before vs After

For example, the GOOGLECALENDAR_GET_CURRENT_DATE_TIME request schema changes: Previous (only a single type):

{
  "timezone": {
    "default": 0,
    "description": "Timezone specification...",
    "title": "Timezone",
    "type": "string"
  }
}

Now (Union types preserved):

{
  "timezone": {
    "anyOf": [
      { "type": "string" },
      { "type": "number" }
    ],
    "default": 0,
    "description": "Timezone specification...",
    "title": "Timezone"
  }
}

Similarly, nullable fields like page_token in GOOGLECALENDAR_LIST_CALENDARS:

Previous:

{
  "page_token": {
    "default": null,
    "description": "Token for the page of results to return...",
    "nullable": true,
    "title": "Page Token",
    "type": "string"
  }
}

Now:

{
  "page_token": {
    "anyOf": [
      { "type": "string" },
      { "type": "null" }
    ],
    "default": null,
    "description": "Token for the page of results to return...",
    "title": "Page Token"
  }
}

Why This Matters

Accurate schemas: LLMs and code generators see the full set of allowed types
Better validation: Input validation can now correctly accept all valid types, not just the first one

Jan 7, 2026