feat(acp): support remote HTTP MCP servers

[custard-pirate]

Summary

• extend the versioned typed MCP document from buzz-acp: add structured MCP server configuration #4164 with a transport: "http" variant
• pass ACP Streamable HTTP MCP servers alongside stdio servers without adding a second configuration surface
• resolve remote URLs and headers from literal values, protected value files, or named entries in protected environment files
• fail before session/new when the selected runtime does not advertise agentCapabilities.mcpCapabilities.http
• redact stdio environment values, HTTP URLs, and HTTP header values from ACP wire logs and observer events, and zeroize serialized credential-bearing buffers after writes

Dependency and scope

This PR is stacked on #4164. That PR owns the versioned document, stdio transport, ordering, validation, redaction foundation, and BUZZ_ACP_MCP_COMMAND compatibility input. This PR adds HTTP to its ConfiguredMcpServer enum and reuses BUZZ_ACP_MCP_CONFIG.

Until #4164 merges, the GitHub diff includes its commits. The HTTP contribution is the final commit in this stack.

Concrete endpoints and credentials remain project-owned configuration and are not added to portable agent templates.

Security and behavior

• public endpoints require HTTPS; plain HTTP is accepted only for literal private IPv4 or unique-local IPv6 addresses
• each URL and header must resolve from exactly one configured source
• header values and URLs can remain in protected files rather than process arguments or ordinary environment values
• credential-bearing values use redacted Debug implementations and are removed from wire logging and observer frames
• runtimes without advertised HTTP MCP support fail closed before receiving server credentials
• existing stdio and legacy command configurations retain their behavior

Validation

• cargo test -p buzz-acp --lib — 703 passed
• cargo clippy -p buzz-acp --all-targets -- -D warnings
• cargo fmt -p buzz-acp -- --check
• git diff --check

The patch contains only generic examples under example.test.

[wolfyy970]

@custard-pirate, I had already built #4164 before I came across this PR. It covers named stdio MCP servers, isolated per-server environments, compatibility with the existing command setting and secret-safe launch configuration. This PR covers remote HTTP transport, so the work is complementary, but both currently define the configuration shape that reaches ACP.

The practical win is one reviewable configuration for both local and hosted tools, with credentials scoped to the individual server. I think the clean merge is a single versioned typed document with stdio and http transports, while BUZZ_ACP_MCP_COMMAND remains a compatibility input rather than a second permanent schema. Projects should own concrete endpoints and credentials; portable agent templates should declare logical tool requirements.

I opened #4301 with the broader product shape and proposed PR split. I would like to align these schemas rather than leave Buzz with two permanent configuration surfaces.

[custard-pirate]

Thanks — agreed. A single versioned, typed MCP configuration with stdio and http transports is a cleaner long-term shape than introducing parallel configuration surfaces. Keeping BUZZ_ACP_MCP_COMMAND as a compatibility input also makes sense.

I’m happy to align #4271 with #4164. I’ll review its configuration model and #4301 in more detail, then we can coordinate the shared types and PR boundary so the two changes remain complementary. In particular, I’d like to preserve per-server credential isolation for HTTP servers without putting concrete endpoints or secrets into portable agent templates.

[wolfyy970]

Thanks. I have rebased #4164 and tagged every config entry with its transport. Version 1 remains stdio-only, so #4271 can add HTTP to the same document. Concrete endpoints and credentials should stay with Project connections, outside portable agent templates.

[custard-pirate]

Thanks — I’ve reviewed the rebased #4164 and I’m aligned with this boundary. The tagged ConfiguredMcpServer enum provides the extension point #4271 needs.

Assuming the maintainers are happy with that division of work, I’ll adapt #4271 to add HTTP as another transport in the same versioned document, reusing the existing config path, ordering, validation, and redaction behavior rather than retaining a separate HTTP configuration surface.

Concrete URLs, headers, and credentials will remain Project-owned and outside portable agent templates. I’ll also ensure HTTP credential values receive the same no-log/no-diagnostics treatment as stdio environment values.

[custard-pirate]

@wolfyy970 I have updated #4271 on top of the current #4164 head and removed the separate HTTP configuration surface.

The HTTP transport now extends the same versioned ConfiguredMcpServer document and reuses its ordering, validation, compatibility, and redaction behavior. The HTTP-specific commit is 981d39a; the PR remains draft while the stack evolves.

The local validation is green: 703 buzz-acp library tests, Clippy with warnings denied, formatting, and diff checks. Please flag any place where this has drifted from the schema or boundary you intend for #4164.

[RowanAldean]

@wpfleger96 @tlongwell-block an open question here is if
buzz-agent is intended to gain HTTP MCP, or is remote MCP deliberately
harness-only? That answer decides whether the client-side work is worth
anyone building (have this done btw, ~150 LoC)

I think it'd be great to configure tools once in Buzz and bind them to a team
instead of hand-wiring each agent's harness config - which I think is the same
direction #4735 is heading 🚀

[wolfyy970]

Not harness-only. buzz-acp should resolve the server list and pass it in session/new; the ACP agent owns the MCP session. buzz-agent already owns the stdio lifecycle, so HTTP belongs beside it there.

I’m retiring #4735 as the implementation branch and restacking the binding work around the relay-canonical agent path in #4940. The useful seam remains: Project setup resolves into the same MCP document for any runtime. If your client work is ready, please put it up against #4271’s HTTP transport.

[wolfyy970]

Thanks for aligning this. I have replaced #4164 with the reviewed four-commit stack on current main. The ConfiguredMcpServer shape and stdio boundary are unchanged; only the commit IDs changed because I removed the repair history.

The stack now includes a real two-server, two-session agent proof. Please rebase your HTTP commit onto the new #4164 head and I will review it against the shared validation and redaction cases.

[custard-pirate]

Rebased onto the replacement #4164 four-commit stack at 780561c. HTTP is now an additional variant of the shared buzz-core MCP launch document; harness-only URL/header credential resolution, ACP capability gating, and wire/observer redaction remain in place. Local validation passed: 713 buzz-acp unit tests, 256 buzz-core unit tests, strict Clippy for both crates with warnings denied, formatting, and diff checks. The HTTP commit is now ddce720 and is ready for the requested review against the shared validation and redaction cases.

[custard-pirate]

@wolfyy970 — #4271 has now been updated and rebased onto the replacement #4164 head at 780561c. The HTTP change is the single child commit ddce720 and extends the shared buzz-core ConfiguredMcpServer document rather than defining a parallel schema. The affected suites are green: 713 buzz-acp tests, 256 buzz-core tests, strict Clippy with warnings denied, formatting, and diff checks. It is ready for your requested review against the shared validation and redaction cases.