Fix call_workflow tool registration in HTTP safe-outputs MCP server

[Copilot]

The HTTP safe-outputs MCP server silently dropped all generated call_workflow tools at registration time. The compiler and safe_outputs_tools_loader.cjs both handle _call_workflow_name correctly, but safe_outputs_mcp_server_http.cjs only had a special-case branch for _workflow_name (dispatch_workflow). Tools like generic_worker fell through to enabledTools.has(tool.name), which always fails because the config key is call_workflow, not the workflow-specific tool name.

Changes

• safe_outputs_mcp_server_http.cjs: Added isCallWorkflowTool detection and an else if branch gated on safeOutputsConfig.call_workflow, mirroring the existing isDispatchWorkflowTool branch. Updated the fallback skip-log to surface _call_workflow_name metadata.

// Before: only dispatch_workflow was special-cased
if (isDispatchWorkflowTool) { … }
else { if (!enabledTools.has(tool.name)) continue; }  // always skips call_workflow tools

// After: call_workflow gets its own branch
if (isDispatchWorkflowTool) { … }
else if (isCallWorkflowTool) {
  if (!safeOutputsConfig.call_workflow) continue;
  // register tool
}
else { if (!enabledTools.has(tool.name)) continue; }

• safe_outputs_mcp_server_http_call_workflow.test.cjs: Regression tests at two levels:
  • Logic tests (9): Cover registration predicate cases — config present/absent, multiple tools, falsy config, independence from dispatch_workflow, and tools/list inclusion/exclusion.
  • Integration tests (6): Call createMCPServer directly with real temp config and tools files, asserting against the actual server.tools Map. Scenarios include: single and multiple workers, combined call_workflow + regular tools, call_workflow + dispatch_workflow independence, and end-to-end handler invocation verifying the JSONL output written to disk.

---

💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.

[Copilot]

Pull request overview

Fixes a regression/bug where the HTTP safe-outputs MCP server failed to register dynamically generated call_workflow tools (those identified via _call_workflow_name metadata), causing them to be silently skipped during tool registration.

Changes:

• Add isCallWorkflowTool detection and a safeOutputsConfig.call_workflow-gated registration path in safe_outputs_mcp_server_http.cjs.
• Improve the “skipping tool” debug log to include _call_workflow_name metadata when present.
• Add a regression test suite covering call_workflow registration scenarios and inclusion/exclusion behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
actions/setup/js/safe_outputs_mcp_server_http.cjs	Adds explicit call_workflow tool detection/registration logic to prevent generated workflow-specific tools from being dropped.
actions/setup/js/safe_outputs_mcp_server_http_call_workflow.test.cjs	Adds regression tests to ensure call_workflow tools are registered only when config.call_workflow is present/truthy and appear in the effective tool list.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[pelikhan]

@copilot add tests

[Copilot]

@copilot add tests

Added 6 integration tests in commit 1878750 that call createMCPServer directly with real temp config/tools files (same pattern as safe_outputs_bootstrap.test.cjs) and verify the actual server.tools Map:

• registers a call_workflow tool when config.call_workflow is present
• does not register when config.call_workflow is absent
• registers all tools for multiple configured workers
• registers call_workflow and regular tools together
• registers call_workflow and dispatch_workflow tools independently
• registered tool has a callable handler that writes call_workflow entries to the output file

All 15 tests pass (9 logic-level + 6 integration).