What is the problem this feature would solve?
I wrote a transform function that converts ACP (agent client protocol) SessionUpdate stream into Response.StreamPartEncoded stream, and then sends it to the frontend via SSE for UI display.
However, I ran into trouble when I needed to decode the data into Response.StreamPart, because the toolkit parameter is mandatory.
The ACP protocol does not report the tools the agent uses, nor the corresponding input/output schemas.
In fact, in the ACP stream, tool names and input/output data appear dynamically and no dedicated schema is ever provided, which makes it impossible to define a toolkit.
On the other hand, I don't actually need a strict schema to decode the inputs and outputs of these tools, because for UI display I only need to treat them as ordinary JSON objects.
I noticed that Tool.dynamic is provided in ai/Tool.ts to represent scenarios where the schema is determined at runtime.
But this design cannot solve the case where even the tool name is unknown, because in ai/Response.ts the Schema generated by ToolCallPart() is:
Schema.Struct({
name: Schema.Literal(name),
params: someParametersSchema,
});
This means it will always reject dynamic tool names.
What is the feature you are proposing to solve the problem?
Specifically, this problem shows up when the toolset of an AI system that uses the current effect ai message model cannot be predetermined. This can happen in cases such as:
- Merely using the effect ai message model as an intermediate layer for external message models, as in the case I described above;
- Currently effect only ships providers for OpenAI, Anthropic, and OpenRouter; if more providers are supported in the future, the situation where the toolset cannot be predetermined will become more common;
- Tools are not defined on the client, but are implicitly provided to the AI system, such as server-side executed tools like the OpenAI Response
computer-use;
For these cases, I think a loose Schema that does not require a specific toolkit would be very convenient and also acceptable in terms of real usage:
// tool call part schema that will accept any tool
const AnyToolCallPart = Schema.Struct({
name: Schema.String,
params: Schema.Json,
});
What alternatives have you considered?
Build toolkit on the fly
I came up with a hacky way to read the tool name of the encoded tool-call part, and then build a toolkit on the fly with a dynamic tool definition. Can work but not ideal:
const toolkitFor = (name: string): Toolkit.Any =>
Toolkit.make(
Tool.make(name, {
parameters: Schema.Unknown,
success: Schema.Unknown,
failure: Schema.Unknown,
}),
);
ai SDK
The AI SDK also keeps a strict schema-based path for registered tools, but keeps an escape hatch for tools that were not registered. It falls back to a bare JSON parse with no validation.
// ...
} catch (error) {
const parsedInput = await safeParseJSON({ text: toolCall.input }); // just json parse, no schema validation
return { type: 'tool-call', toolCallId, toolName, input, dynamic: true, invalid: true, error };
}
AI SDK community provider: acp-ai-provider
The tool-call emitted in the stream of acp-ai-provider never uses the agent's real tool name; instead it uniformly uses a placeholder Provider tool:
import { tool, jsonSchema } from "ai";
export const ACP_PROVIDER_AGENT_DYNAMIC_TOOL_NAME = "acp.acp_provider_agent_dynamic_tool";
export function getACPDynamicTool() {
return {
[ACP_PROVIDER_AGENT_DYNAMIC_TOOL_NAME]: tool({
type: "provider",
id: ACP_PROVIDER_AGENT_DYNAMIC_TOOL_NAME,
args: {},
inputSchema: jsonSchema({}),
}),
};
}
The real information is packed into a wrapper object:
import { z } from "zod";
export type ProviderAgentDynamicToolInput = {
toolCallId: string;
toolName: string;
args: Record<string, unknown>;
};
export const providerAgentDynamicToolSchema = z.object({
toolCallId: z.string(),
toolName: z.string(),
args: z.record(z.unknown()),
});
What is the problem this feature would solve?
I wrote a transform function that converts ACP (agent client protocol)
SessionUpdatestream intoResponse.StreamPartEncodedstream, and then sends it to the frontend via SSE for UI display.However, I ran into trouble when I needed to decode the data into
Response.StreamPart, because thetoolkitparameter is mandatory.The ACP protocol does not report the tools the agent uses, nor the corresponding input/output schemas.
In fact, in the ACP stream, tool names and input/output data appear dynamically and no dedicated schema is ever provided, which makes it impossible to define a toolkit.
On the other hand, I don't actually need a strict schema to decode the inputs and outputs of these tools, because for UI display I only need to treat them as ordinary JSON objects.
I noticed that
Tool.dynamicis provided inai/Tool.tsto represent scenarios where the schema is determined at runtime.But this design cannot solve the case where even the tool name is unknown, because in
ai/Response.tsthe Schema generated byToolCallPart()is:This means it will always reject dynamic tool names.
What is the feature you are proposing to solve the problem?
Specifically, this problem shows up when the toolset of an AI system that uses the current effect ai message model cannot be predetermined. This can happen in cases such as:
computer-use;For these cases, I think a loose Schema that does not require a specific toolkit would be very convenient and also acceptable in terms of real usage:
What alternatives have you considered?
Build toolkit on the fly
I came up with a hacky way to read the tool name of the encoded
tool-callpart, and then build a toolkit on the fly with a dynamic tool definition. Can work but not ideal:aiSDKThe AI SDK also keeps a strict schema-based path for registered tools, but keeps an escape hatch for tools that were not registered. It falls back to a bare JSON parse with no validation.
AI SDK community provider:
acp-ai-providerThe
tool-callemitted in the stream ofacp-ai-providernever uses the agent's real tool name; instead it uniformly uses a placeholder Provider tool:The real information is packed into a wrapper object: