tool execution hangs indefinitely when using the SDK in cloudflare agents-starter template

[unique1o1]

Vercel AI SDK tools execution gets stuck on await when using cloudflare/agents-starter template

I'm encountering an issue where tool execution gets stuck on await when using the Cloudflare agents-starter template with Vercel's AI SDK.

Issue Description

When attempting to execute a tool using the AI SDK's tool execution functionality, the code hangs indefinitely on the await call. Interestingly, the tool executing works perfectly fine in fetch function call.

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const mcpClient = await createMCPClient({
      transport: {
        type: "sse",
        url: "http://localhost:50729/sse",
      },
    });

    const tools = await mcpClient.tools();
    result = await  tools.add.execute(
        { a: 12, b: 233 },
        { messages: [], toolCallId: "xxxx" }
      )
    console.log(result);
      
      return new Response("hello world", { status: 200 });
}

Reproduction

I'm using code based on the Cloudflare agents-starter template with Vercel's AI SDK.

Here's the relevant part of my code that I added in the above codebase here:

// This gets stuck and never resolves
console.log(
  "result: ",
  await env.tools.add.execute(
    { a: 102, b: 23 },
    { messages: [], toolCallId: "43" }
  )
);
console.log("waiting...."); // This line is never reached


I'm currently running this locally using `wrangler dev`.

[leomercier]

I had an issue using Bun with Vercel AI as no errors show - and just hangs. Using ts-node instead works and at least shows errors to debug.

[iteratetograceness]

@unique1o1 @leomercier are you both using processToolCalls from agents-starter/src/utils.ts? From a quick glance, it seems tools in that function is only being used for type inference, and execution is happening after checking for human approval by looking for the tool in executions:

const toolInstance = executions[toolName];
if (toolInstance) {
  result = await toolInstance(toolInvocation.args, {
    messages: convertToCoreMessages(messages),
    toolCallId: toolInvocation.toolCallId,
  });

Could you provide more context on:

• Whether you're initializing a client via our createMCPClient within processToolCalls
• If not, where then env (in env.tools.add.execute()) is initialized

[unique1o1]

@iteratetograceness Yes, i'm using processToolCalls from agents-starter/src/utils.ts.

• Currently I'm initializing the client in the fetch function since global declaration is not allowed in cloudlfare workers. If I do so I get the following error.

Uncaught Error: Disallowed operation called within global scope. Asynchronous I/O (ex: fetch() or connect()), s etting a timeout, and generating random values are not allowed within global s cope

• so I'm using a hacky sortof approach to get access to tools by passing tools from fetch function tosetEnv({...env,tools}). And using global_env to get access to the tools else-where.

Here is the setEnv function

//env.ts
import type { AgentNamespace } from "agents";
import type { Neo4jCacheDO } from "./do";
import type { Chat } from "./chatagent";

// Environment variables type definition
export type Env = {
  OPENAI_API_KEY: string;
  CLOUDFLARE_AI_GATEWAY_API_KEY: string;
  Chat: AgentNamespace<Chat>;
  NEO4J_CACHE: DurableObjectNamespace<Neo4jCacheDO>;
  tools: any;
};
export let global_env: Env = undefined as any;

export function setEnv(env: Env) {
  global_env = env;
}

and I'm using global_env to get access to tools.

 await global_env.tools.add.execute(
    { a: 102, b: 23 },
    { messages: [], toolCallId: "43" }
  )
);

[iteratetograceness]

@unique1o1 I see! Instead of storing tools in global env, you can use the executions argument in processToolCalls to call tools in the agents-starter template.

[unique1o1]

Yeah, I'm using the executions argument in processToolCalls now, but I'm still unclear as to why the global_env approach was not working.

[iteratetograceness]

I can't confidently say I know why, but seems likely that it's a limitation in dynamically setting global env vars in CF Workers. Will close this discussion for now!