feat: add tool/function calling support

[KochC]

Summary

Closes #50. Adds OpenAI-style function tools, Anthropic tools, and Gemini function declarations across all four API surfaces (/v1/chat/completions, /v1/responses, /v1/messages, /v1beta/models/:model:generateContent), both streaming and non-streaming.

The problem

OpenCode's own agent loop always executes tools itself, server-side, and has no concept of a "client-executed" tool call — the exact thing coding-agent clients need (they run their own file/shell/etc. tools locally and expect the model to propose a call, then wait for an externally-supplied result).

How it works

1. When a request includes tools, the proxy dynamically registers a small local MCP server (mcp-tool-bridge.js) whose tool list is exactly the caller's declared tool schemas — reused from a small fixed-size pool of slot names, since OpenCode's server API (POST /mcp) has no endpoint to deregister an MCP server once added.
2. Only those tools are enabled for that one prompt call via the existing tools enable/disable map ({[id]: boolean}); every built-in OpenCode tool stays disabled, same as before.
3. As soon as the model proposes calling one of the bridge tools, the full call (name + arguments) is already present on OpenCode's event stream — ToolStatePending includes the fully-parsed input even before execution starts. The proxy captures it and immediately calls session.abort() before the bridge's harmless no-op tools/call handler would ever be consulted.
4. The captured call is translated into the caller's expected shape: tool_calls (OpenAI Chat Completions), a function_call output item (OpenAI Responses API), tool_use (Anthropic), or a functionCall part (Gemini).
5. The message normalizers for all four formats now render prior tool calls/results (tool_calls/tool role, tool_use/tool_result, function_call/function_call_output, functionCall/functionResponse) as descriptive text when replaying conversation history, so multi-turn tool use works even though sessions are stateless per-request (this proxy always replays full history into a fresh session).

Changes

• index.js:
  • parseOpenAITools / parseAnthropicTools / parseGeminiTools + applyOpenAIToolChoice / applyAnthropicToolChoice / applyGeminiToolChoice — parse each API's tools/tool_choice/toolConfig into a canonical {name, description, parameters} list.
  • sanitizeToolName, a small bridge-slot pool (acquireBridgeSlot/releaseBridgeSlot), and registerToolBridge — dynamic MCP registration.
  • runAgentTurn — unifies the event-driven turn execution shared by executePrompt and executePromptStreaming when tools are present (both now accept an optional callerTools param; behavior is 100% unchanged when omitted/empty).
  • Tool-call branches added to all four response builders (createChatCompletionResponse, createResponsesApiResponse, createAnthropicResponse, createGeminiResponse) and their SSE/NDJSON streaming emitters.
  • Message normalizers (normalizeMessages, normalizeResponseInput, normalizeAnthropicMessages, normalizeGeminiContents) extended to round-trip tool calls/results in history.
• mcp-tool-bridge.js (new): minimal MCP stdio JSON-RPC server exposing caller-supplied tool schemas. tools/call is a harmless no-op stub since the proxy always aborts the session before it would be consulted.
• index.test.js: unit tests for the new parsing/tool_choice helpers and history round-tripping, plus end-to-end tool-calling tests (stream + non-stream) for all four API formats.
• README.md: documents the new tools/tool_choice/toolConfig request fields, how the bridge mechanism works, current limitations, and the new OPENCODE_LLM_PROXY_TOOL_BRIDGE_POOL_SIZE env var.

Limitations (documented in README)

• One tool call per turn — no parallel/simultaneous tool calls yet.
• Bridge servers are reused from a fixed pool (default 8 slots, configurable) rather than registered fresh per request, since OpenCode has no MCP deregistration endpoint.
• The bridge process is spawned with node, so node must be on PATH wherever OpenCode runs.

Testing

• npm test — 138 passed (116 existing + 22 new)
• npm run lint — clean
• Manually smoke-tested mcp-tool-bridge.js's JSON-RPC handling (initialize, tools/list, tools/call) by piping requests to it directly.

Notes

I don't have a live OpenCode instance handy to run a full end-to-end integration test against the real server, so tests use mock client objects matching the exact shapes documented in OpenCode's server API reference and its generated SDK client (session.abort, mcp.add, mcp.disconnect, ToolPart/ToolStatePending). Would appreciate a maintainer or anyone with a live setup giving this a try against a real OpenCode server before merging.