Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Feature Request: decode `Response.StreamPart` without toolkit provided

Cerrado
  • ¿Algo no está bien?
#7,152 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@observerw ya está trabajando en esto.

Desde el 20/9/2026.

  • #9674 de @effect-bot — fusionado

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
api, backend-api-design

Línea de trabajo

Start by reading ai/Response.ts, especially ToolCallPart(), and compare its required toolkit and literal tool-name schema with the dynamic-tool model in ai/Tool.ts. The work is complete when encoded stream parts can be decoded without a toolkit, accepting dynamically named tools and JSON parameters while preserving the existing strict path.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement
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()),
});
Lenguaje dominante
TypeScript
Estrellas
16.7k
Forks
808
Merge medio
10 h 33 min
PR fusionados (30 d)
830

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Effect-TS/effect

Todos los issues de Effect-TS/effect

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.