Multi-tool source structure for delegate-ai-mcp #4

Closed
opened 2026-09-06 14:41:53 +00:00 by haylan · 1 comment
Owner

Part of TypeScript project conventions for delegate-ai-mcp

Question

Today src/qwen-delegate.ts (core logic) + src/qwen-delegate-server.ts (MCP wiring, one registerTool call) is the whole project. When a second delegate tool (different AI backend) is added, decide the pattern: one MCP server process registering multiple tools (one entrypoint, src/tools/.ts per tool, each exporting its core logic + a register() function) vs. separate server processes/binaries per backend. Also decide the shared-code boundary (e.g. a common spawn/timeout helper if multiple tools shell out to CLIs).

Part of [TypeScript project conventions for delegate-ai-mcp](https://git.arthurerlich.de/haylan/delegate-ai-mcp/issues/1) ## Question Today src/qwen-delegate.ts (core logic) + src/qwen-delegate-server.ts (MCP wiring, one registerTool call) is the whole project. When a second delegate tool (different AI backend) is added, decide the pattern: one MCP server process registering multiple tools (one entrypoint, src/tools/<name>.ts per tool, each exporting its core logic + a register() function) vs. separate server processes/binaries per backend. Also decide the shared-code boundary (e.g. a common spawn/timeout helper if multiple tools shell out to CLIs).
haylan added the wayfinder:grilling label 2026-09-06 14:41:53 +00:00
haylan self-assigned this 2026-09-06 15:56:09 +00:00
Author
Owner

Resolved:

  1. Separate process per backend — each delegate tool (qwen, and whatever comes next) is its own MCP server process with its own claude mcp add --scope user registration. Not one process registering multiple tools.
  2. Flat naming, extending the existing convention: src/-delegate-server.ts (MCP wiring) + src/-delegate.ts (core logic) per backend, all directly in src/ — no subfolders.
  3. Extract a generic shared helper now: src/lib/spawn-cli.ts, exporting spawnCli(command, args, opts) -> {ok, output}, with an injectable spawnFn (same shape src/qwen-delegate.ts already uses). Each backend's -delegate.ts becomes a thin wrapper supplying its own command/args/default timeout.
  4. Split tests to match: test/spawn-cli.test.ts covers the generic spawn/timeout/error logic once; each backend gets its own test/-delegate.test.ts for its specific defaults.

Not yet done: implementation (extracting src/lib/spawn-cli.ts out of src/qwen-delegate.ts, splitting the test file) — that's follow-up work, not part of this decision ticket.

Resolved: 1. Separate process per backend — each delegate tool (qwen, and whatever comes next) is its own MCP server process with its own `claude mcp add --scope user` registration. Not one process registering multiple tools. 2. Flat naming, extending the existing convention: src/<backend>-delegate-server.ts (MCP wiring) + src/<backend>-delegate.ts (core logic) per backend, all directly in src/ — no subfolders. 3. Extract a generic shared helper now: src/lib/spawn-cli.ts, exporting spawnCli(command, args, opts) -> {ok, output}, with an injectable spawnFn (same shape src/qwen-delegate.ts already uses). Each backend's -delegate.ts becomes a thin wrapper supplying its own command/args/default timeout. 4. Split tests to match: test/spawn-cli.test.ts covers the generic spawn/timeout/error logic once; each backend gets its own test/<backend>-delegate.test.ts for its specific defaults. Not yet done: implementation (extracting src/lib/spawn-cli.ts out of src/qwen-delegate.ts, splitting the test file) — that's follow-up work, not part of this decision ticket.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: haylan/delegate-ai-mcp#4