Loading ToolBench
Zero-dependency TypeScript client for OpenAI, Anthropic, Gemini, Ollama, LM Studio, Groq, OpenRouter, DeepSeek, Mistral, xAI, Together and any OpenAI-compatible API. Real streaming, tool calling, structured output, images, typed provider errors with hints, retries with backoff, static model routing. Agents, MCP client, sessions, embeddings.
llmwire exposes 9 utility functions as MCP tools, but they are internal LLM-client helpers, not domain tools. Tool names lack action verbs (openaiTools, parseArgs, stringifyArgs, recoverLeakedToolCalls, canRun, runTools, toolResultContent, nextStepRequest). Descriptions are present but generic (34 - 194 chars). Input schemas visible but minimal: most parameters lack type constraints, enums, or validation guidance. No output schemas documented. These tools are designed for internal SDK use, not agent-facing operations. No error handling, recovery guidance, or security considerations. This is a library, not an agent-ready tool server.
Determines whether every call names a tool that has `execute`, so the loop can run them.
Creates the request for the next step: the conversation so far, the assistant turn that made the calls, and one tool message per result.
Converts a tool choice specification to OpenAI format.
Converts tools[] to OpenAI-format function definitions (Ollama and every compatible host take the same shape).
Parses a tool call's arguments: parsed when the provider sent JSON text, the raw string when that text is not JSON.
Weak local models print `<function=name>{json}</function>` as text instead of a real tool call. Recovers those (first occurrence per tool wins) and strips the markup from the shown text. Only tools in `tools` are recovered; anything else is left as written.
Runs the calls in parallel. A throwing tool becomes an `error` result the model sees; the request does not fail.
Tool names do not start with action verbs. Names like 'openaiTools', 'parseArgs', 'stringifyArgs' are noun-heavy and do not convey intent. LLMs cannot infer what action to take from these names alone.
Input schemas lack type constraints, enums, and validation rules. Parameter 'choice' in openaiToolChoice accepts 'string|object' but no enum values or format guidance. Parameter 'raw' in parseArgs is typed 'unknown' with no constraints.
No output schemas documented. Tools return unstructured results with no field definitions. LLMs cannot plan downstream calls or extract typed data.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | <=2025-11-25 | v2 |
Converts a tool's arguments to the text format a provider expects.
Formats what goes back to the model for one tool result.
No error handling or recovery guidance. Tools provide no actionable error messages, categorization (retryable vs fatal), or next-step hints for LLMs.
These are internal SDK utilities, not domain-specific agent tools. They expose LLM-client implementation details (tool format conversion, argument parsing) rather than user-facing operations. Not suitable for general agent use.