Mismatch between ToolCallContent TypeScript types and Zod validation

[lewis617]

Description

There is a mismatch between the TypeScript type definitions and the runtime Zod validation for ToolCallContent in the @agentclientprotocol/sdk (v0.17.0).

Details

In schema/types.gen.d.ts, ToolCallContent is defined as:

export type ToolCallContent = (Content & {
    type: "content";
}) | (Diff & {
    type: "diff";
}) | (Terminal & {
    type: "terminal";
});

Where Content is:

export type Content = {
    _meta?: { [key: string]: unknown; } | null;
    content: ContentBlock;
};

This implies that to send text content in a tool call update, the structure should be:

{
  "type": "content",
  "content": {
    "type": "text",
    "text": "some result"
  }
}

However, when an agent sends this exact structure, the ClientSideConnection (via its internal Zod validator) throws a JSON-RPC -32603 Internal error with invalid_union.

Observed Behavior

When the agent sends a session/update with tool_call_update:

{
  "jsonrpc": "2.0",
  "method": "session/update",
  "params": {
    "sessionId": "...",
    "update": {
      "sessionUpdate": "tool_call_update",
      "toolCallId": "...",
      "status": "completed",
      "content": [
        {
          "type": "content",
          "content": { "type": "text", "text": "Task created with ID: 1" }
        }
      ],
      ...
    }
  }
}

The SDK logs:

Error handling notification { ... } {
  code: -32603,
  message: 'Internal error',
  data: [
    {
      code: 'invalid_union',
      errors: [...],
      path: ['params', 'update', 'content', 0],
      message: 'Invalid input'
    }
  ]
}

Expected Behavior

The Zod schema should be synchronized with the TypeScript types. If the types require the content wrapper, the validator should accept it. If the protocol intended for ContentBlock to be top-level (e.g., { type: "text", text: "..." }), then the TypeScript types for ToolCallContent should be updated to reflect that.

[benbrandt]

Thanks for reporting! I am not able to reproduce.. . but also realized you all were on zod 3 and I think we didn't have a properly specified import here that might be causing the issue: #99

[lewis617]

We found that the invalid_union error was actually caused by passing undefined to the text field in our code, which triggered the Zod validation failure. After ensuring that the text field is always a valid string (e.g., by adding a typeof ... === 'string' check), the validation works as expected in both 0.17.0 and 0.17.1. This was an error in our implementation, not a bug in the SDK. Closing this issue.