Define Neural Link harness tool projection boundary

Context

Grace's A2A dependency finding on #13082 exposed a sharper blocker than the original consumer leaf captured: the Neural Link tier metadata can be consumed only after the harness has an explicit boundary where embedded agents receive a projected tool surface.

Release classification: post-release harness line; this sequencing ticket is not v13 release-gating.

The Problem

#13082 was filed as the consumer of the Neural Link tier contract, but live V-B-A shows there is no projection boundary for that consumer to attach to yet. Without this boundary, implementation choices collapse into speculation:

• filter tools/list at handshake time,
• gate call_tool per request while still listing the full surface,
• generate a derived manifest for embedded agents,
• or add a harness-specific MCP client/server context layer.

Those options imply different signatures and authority contexts. Building the #13082 consumer before deciding the boundary would create another declarative-but-unconsumed function one layer up.

The Architectural Reality

V-B-A before filing:

• ai/mcp/server/neural-link/Server.mjs:48-55 advertises static MCP capabilities with tools: {listChanged: false}; it does not project by agent identity or harness mode.
• ai/mcp/server/BaseServer.mjs:285-305 returns every listed tool from the server tool service; BaseServer.mjs:341-342 dispatches calls without a projection-policy hook.
• ai/mcp/client/Client.mjs:270-279 consumes listTools() as the full dynamic proxy set for a client connection.
• ai/mcp/ToolService.mjs:98-151 parses OpenAPI operations into the MCP tools/list payload, but on current dev it has no projection output mode.
• Local exact source sweep for x-neo-tool-tier, toolProjection, and harness projection terms under ai/ found no existing projection consumer or boundary.
• Knowledge Base semantic check was attempted and failed because the current KB server is unhealthy (knowledgeBase:null; healthcheck details: requested resource not found), so this ticket does not rely on KB silence.
• Memory Core semantic search surfaced the approved #13078 tier-contract review context and no prior implemented boundary.
• Live latest-open GitHub sweep checked the latest 20 open issues at 2026-06-13T09:49Z. No equivalent boundary ticket exists. Closest issues: #13056 parent epic, #13064 tier-contract leaf, #13082 consumer leaf.
• A2A in-flight sweep checked the latest 30 messages at 2026-06-13T09:49Z. The only overlapping signal was Grace's dependency finding; no competing [lane-claim] or [lane-intent] exists for the boundary ticket.
• Local synced issue/discussion exact sweep for projection-boundary terms returned no existing issue or Discussion duplicate.

The Fix

Define and implement the Neural Link harness projection boundary before #13082 consumes the tier contract.

Expected shape:

1. Add a single source-of-authority boundary where an embedded harness agent asks for or receives a Neural Link tool projection.
2. Make that boundary explicit enough that #13082 can mechanically derive default visibility from x-neo-harness-tool-projection / x-neo-tool-tier without choosing the embedding interface itself.
3. Preserve the fail-closed sequence: default embedded agents never receive write/admin tools by accident; full developer surfaces remain available only through the existing developer/operator path.
4. Document whether projection happens at tools/list, call_tool, a generated manifest, or a named hybrid, with the authority context passed through the boundary.
5. Keep the implementation on existing MCP surfaces if possible (ToolService, BaseServer, or Client) rather than adding a parallel allowlist subsystem.

Contract Ledger Matrix

Decision Record Impact

Aligned-with ADR 0020. This ticket implements one of the #13056 curated tool-surface prerequisites and does not amend the harness concept. It should not redefine Topological Locking, Bridge-token auth, or admin authority; those remain separate leaves under #13056.

Acceptance Criteria

• A named Neural Link harness projection boundary exists and is documented in code.
• The boundary exposes an explicit authority/context input for embedded harness agents, rather than relying on implicit client naming or private per-harness allowlists.
• Default embedded-agent projection is fail-closed and narrower than the full developer/operator Neural Link tool surface.
• The full existing developer/operator Neural Link path remains available outside the embedded-agent projection path.
• Tests or static validation prove the selected boundary is where #13082 can consume x-neo-harness-tool-projection / x-neo-tool-tier after #13064 lands.
• PR body states the selected projection point (tools/list, call_tool, generated manifest, or hybrid) and why the rejected shapes were not chosen.

Out of Scope

• Implementing the tier-map consumer itself; that remains #13082.
• Changing the tier taxonomy from #13064 / PR #13078.
• Implementing Topological Locking.
• Implementing identity-bound Bridge-token auth.
• Granting admin authority to embedded agents.
• Changing the full local developer Neural Link MCP surface by default.

Avoided Traps

• Speculative consumer first — rejected because no receiving boundary exists for #13082 yet.
• Private allowlist drift — rejected unless generated from the OpenAPI source-of-authority and validated.
• Full surface then call-time denial only — must be defended if chosen, because tools/list visibility itself is part of the harness agent contract.
• Bundling auth/locking/admin policy — rejected; this ticket defines the projection boundary and fails closed until sibling authorities exist.

Related

Parent: #13056 Blocks #13082 Blocked by #13064 Refs #13078

Retrieval Hint: "Neural Link harness tool projection boundary embedded agents tools/list call_tool generated manifest x-neo-tool-tier"