NodeLLM 1.17: Amostragem MCP, Execução Concorrente de Ferramentas e Controle de ORM Mais Inteligente

Quando introduzimos o suporte ao MCP, terminamos com um teaser: a Fase 3 abordaria Sampling—permitindo que servidores solicitassem completions do host em vez de apenas expor ferramentas e recursos a ele. O NodeLLM 1.17 entrega isso e o combina com uma segunda melhoria, não relacionada, mas atrasada: controle preciso sobre como as chamadas de ferramentas são executadas, agora disponível de forma consistente tanto no núcleo quanto na camada de persistência do ORM.

🔄 MCP Sampling: Fechando o Ciclo

O Sampling inverte a direção usual do MCP. Em vez de o cliente pedir ao servidor por ferramentas, o servidor pede ao cliente para executar uma conclusão LLM em seu nome. Isso permite que um servidor MCP ofereça capacidades impulsionadas por LLM—resumos, classificações, redações—sem precisar de sua própria chave de API ou integração de provedor.

createLLMSamplingHandler responde a essas solicitações usando uma instância real do NodeLLM, então a ferramenta de um servidor acaba sendo alimentada por qualquer modelo que você configurar do lado do cliente:

import { createLLM } from "@node-llm/core";
import { MCP, createLLMSamplingHandler } from "@node-llm/mcp";

const llm = createLLM({ provider: "openai" });

const mcp = await MCP.connect(
  { command: "node", args: ["./sampling-server.mjs"] },
  { sampling: createLLMSamplingHandler(llm, "gpt-4o-mini") }
);

const tools = await mcp.discoverTools();
// O servidor só anuncia ferramentas suportadas por sampling uma vez que vê
// que o cliente declarou suporte a sampling durante o handshake.

Se você precisar de controle total sobre como uma solicitação de sampling é respondida—roteando por dica de modelo, injetando suas próprias barreiras—passe uma função de manipulador simples em vez de { llm, model }. Ela recebe os parâmetros brutos de sampling/createMessage e retorna um CreateMessageResult, então você decide exatamente como (ou se) responder.

⚡ Execução Concorrente de Ferramentas

Quando um modelo retorna várias chamadas de ferramentas independentes na mesma vez, o NodeLLM sempre as executou uma de cada vez. Isso é seguro por padrão, mas desperdiça tempo quando as chamadas não dependem uma da outra—três consultas de clima para três cidades diferentes, por exemplo. toolConcurrency torna isso paralelo opt-in:

const chat = llm.chat("gpt-4o-mini").withTool(WeatherTool).withToolConcurrency(true);

await chat.ask("Qual é o clima em Tóquio, Londres e Nova York?");

A mesma flag funciona em stream() e no modo Agent, então loops agenticos obtêm a mesma redução de latência sem qualquer alteração na forma como as ferramentas são definidas.

🧩 Empilhamento Aditivo de Callbacks

Chamar um on*(), beforeRequest(), ou afterResponse() um segundo vez costumava substituir silenciosamente o primeiro manipulador—uma borda afiada se duas preocupações independentes (registro e uma atualização de UI, por exemplo) tentassem registrar seu próprio callback. Agora, cada manipulador registrado é executado, em ordem:

chat
  .onEndMessage((msg) => audit.log(msg))
  .onEndMessage(() => ui.refresh());

chat
  .beforeRequest(redactPII)
  .beforeRequest(logOutboundPrompt);

Nada muda para o caso comum de um único manipulador; isso só importa uma vez que você começa a compor um comportamento semelhante a middleware a partir de múltiplos pontos de chamada independentes.

🗄️ ORM 0.8.0: O Mesmo Controle de Ferramentas, Persistido

@node-llm/orm agora expõe a mesma superfície de execução de ferramentas que o núcleo, então chats suportados pelo Prisma obtêm controle preciso sem precisar descer para a API bruta do núcleo:

import { createChat } from "@node-llm/orm/prisma";
import { ToolExecutionMode } from "@node-llm/core";

const chat = await createChat(prisma, { model: