Skip to content

Add a supported Toolcraft HTTP MCP adapter using tiny-http-mcp-server #516

Description

@kamilio

Summary

Add a supported Toolcraft adapter for tiny-http-mcp-server so a Toolcraft command tree can expose the same generated MCP tools over Streamable HTTP without downstream projects hand-writing transport glue or duplicating tool registration.

tiny-http-mcp-server@0.1.0 is now published. Toolcraft currently exposes createMCPServer and runMCP from toolcraft/mcp, but its public runner is stdio-oriented. Downstream applications can see that the underlying server and HTTP transport are structurally related, but composing them manually would rely on implementation details and would leave lifecycle, security defaults, request context, error handling, and bundling behavior outside Toolcraft's supported contract.

Baby Daybook currently stays on stdio MCP rather than adding such an unsupported bridge.

Proposed API

A dedicated public subpath, for example toolcraft/http, with supported functions such as:

import { createHTTPMCPServer, runHTTPMCP } from "toolcraft/http";

const handle = await runHTTPMCP(commands, {
  name: "baby-daybook",
  version: "0.1.0",
  hostname: "127.0.0.1",
  port: 0,
  path: "/mcp",
});

The exact names are open to design, but the adapter should be owned by Toolcraft rather than reimplemented by each consumer.

Required behavior

  • Generate tools from the same defineCommand / defineGroup tree used by CLI, stdio MCP, and SDK.
  • Preserve identical tool names, schemas, secret resolution, service injection, confirmations, human-in-loop behavior, logging, error reports, stream behavior, and result serialization.
  • Use tiny-http-mcp-server as the supported Streamable HTTP transport rather than copying its implementation.
  • Expose the useful HTTP controls supported upstream, including hostname, port, path, stateless/session behavior, JSON responses, allowed hosts/origins, request limits, concurrency limits, timeouts, observability, and OAuth configuration.
  • Default to a safe local binding and fail closed for unsafe host/origin configurations.
  • Return a documented handle with URL, selected port, and graceful close behavior.
  • Preserve request-scoped authentication/context in a documented way without changing existing handler behavior for CLI, stdio MCP, or SDK.
  • Keep HTTP code out of stdio-only bundles through a dedicated subpath and tree shaking.

Bundling requirement

tiny-http-mcp-server is published, but Toolcraft should bundle it as part of the HTTP adapter's supported standalone artifact composition. Downstream generated applications should not need to declare Toolcraft internals or maintain a separate transport compatibility matrix.

The package should appear in Toolcraft's composition/license metadata and follow the same deterministic standalone-bundle guarantees as the existing CLI, SDK, and stdio MCP entry points.

Acceptance criteria

  1. Publish a documented Toolcraft HTTP adapter using tiny-http-mcp-server.
  2. Build one command tree and verify that stdio and HTTP advertise the same tool names and JSON schemas.
  3. Call representative read, write, secret-backed, confirmed, streaming, and erroring commands through both transports and compare normalized results.
  4. Test stateful and stateless Streamable HTTP modes with the official MCP SDK client and tiny-mcp-client.
  5. Verify secure defaults for loopback binding, allowed hosts/origins, request-size limits, concurrency, timeout, session cleanup, and graceful shutdown.
  6. Verify optional OAuth configuration and request-scoped auth context.
  7. Pack a standalone ESM application importing only the new HTTP subpath, install it in a clean consumer, and start/call it on Node.js 20, 22, and 24 without external Toolcraft or transport runtime packages.
  8. Verify stdio-only Toolcraft bundles do not include HTTP/Express/OAuth transport code.
  9. Include the HTTP transport and all incorporated package identities in Toolcraft's composition and third-party-license contract.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions