v5 typesafe tool call issue

[thdxr]

in v5 with the change in how tool call parts look: https://ai-sdk.dev/docs/announcing-ai-sdk-5-beta#type-safe-tool-calls

this has made it massively more complex for us because we use this format in an openapi spec. this list of tools are configured by the end user so we can't really know them ahead of time

this means it's difficult to represent this as zod, as an openapi spec, codegen for a golang client - these are all places where we use the format

to put it another way - making a string template literal part of the top level union means languages that don't have that concept cannot deal with it. it's fine when nested because it can be ignored

i'm assuming it's too late now to change anything (although things were fine in the alpha) but wanted to ask anyway

[lgrammel]

@thdxr can you provide a code example that breaks for you? ideally you would leave it untyped in that case but we need to explore where exactly this breaks down and if it possible to fix.

[tal32123]

Do you know where I can see documentation on frontend tools? I cannot find anything. Thanks in advance!

[lgrammel]

Is the issue only the typing on the frontend? because then you can do something like this in the react code:

if (part.type.startsWith('tool-')) {
  const toolPart: ToolUIPart<UITools> = part as ToolUIPart<UITools>;
  switch (toolPart.state) {
    case 'input-available':
      const input = toolPart.input as any;
      return (
        <div key={index} className="text-gray-500">
          {input.message}
        </div>
      );
    case 'output-available':
      const output = toolPart.output as any;
      return (
        <div key={index} className="text-gray-500">
          Location access allowed: {output}
        </div>
      );
  }

For zod, is it possible to use startsWIth?

Noted on the overall issue thought. Not sure if a good solution for OpenAPI exists since it does not support prefixes.

[thdxr]

for zod it's less about representing the exact field and more about representing the two levels of discriminated union that is happening at the same level

discriminate on type and then also on state

either way sounds like we should move away from the AI sdk message format for our usecase. figured it would have to happen at some point

[khanakia]

@thdxr were you able to fix it ?

[github-actions[bot]]

This discussion was automatically locked because it has not been updated in over 30 days. If you still have questions about this topic, please ask us at community.vercel.com/ai-sdk