Extend the internal MCP with trusted Project/Wiki capabilities

[LanicBlue]

Context

T3 already attaches one product-owned t3-code MCP server to provider sessions. Extend that existing seam with Project/Wiki providers instead of creating service-specific adapter protocols.

Dependencies:

• Project Service authenticated Agent binding: https://github.com/LanicBlue/project-service/issues/14
• Stable Project Consumer/SDK artifact: https://github.com/LanicBlue/project-service/issues/12

Trusted execution context

Every MCP request must resolve a server-created context, conceptually:

interface ToolExecutionContext {
  environmentId: string
  threadId: string
  providerSessionId: string
  providerInstanceId: string
  logicalAgentId: string
  t3ProjectId: string
  projectServiceProjectId?: string
  capabilities: ReadonlySet<string>
}

The Agent must not provide or override:

• clientId / consumerId;
• agentId;
• projectId;
• executorRef;
• Wiki root/subtree identity;
• Session/Thread identity;
• service credentials.

Project/Wiki integrations derive those values from the trusted Session and add them to SDK calls behind the MCP boundary.

Capabilities

Decouple MCP attachment from the Browser setting. Model independent capabilities such as:

preview
project.work.read
project.work.write
wiki.read
wiki.write

Disabling Browser access must not disable Project/Wiki. Agent settings changes should refresh/revoke the relevant MCP credential scope without deleting the Session.

Provider adapters

Reuse the generic T3 MCP attachment for:

• Codex;
• Claude;
• Cursor;
• Grok;
• locally managed OpenCode.

Externally managed OpenCode servers are explicitly unsupported in this phase. Do not add Project/Wiki-specific code to every adapter.

Project MCP v1

Prefer context-bound tools such as:

project_work_list()
project_work_get(runId)
project_work_submit(runId, revisions, result)
project_operation_get(operationId)

No tool accepts Agent/Project/Client/executor identity. T3 adds agentId + projectId; Project Service derives the authenticated Client half and canonical executorRef.

Expose only an explicit allowlist; do not publish a generic Project HTTP facet to the Agent.

Error boundary

Map Service SDK errors into structured MCP errors, including:

• authentication invalid/disabled;
• incompatible SDK/API/protocol;
• stale assignment/revision;
• uncertain mutation with operation recovery;
• integration disabled/unavailable.

Authentication errors leave the Session intact.

Acceptance criteria

• Project/Wiki tools are registered on the existing internal MCP server.
• Browser, Project, and Wiki capabilities are independent.
• MCP context contains the authoritative logical Agent and Project binding.
• Agent tool inputs cannot select Agent, Project, Client, executorRef, or Wiki root/subtree.
• Raw service credentials never enter provider-visible environment, prompts, or tool arguments.
• Supported adapters reuse the same generic MCP surface.
• External OpenCode server mode is explicitly skipped.
• Project MCP uses the supported SDK and an explicit tool allowlist.
• Structured errors preserve authentication/revision/uncertain semantics.
• Tests cover identity spoof attempts and capability changes.
• Adding a Project/Wiki operation does not require editing every provider adapter.

Non-goals

• Do not expose Project/Wiki Services as direct Agent-facing MCP servers.
• Do not implement a second service-specific tool transport.
• Do not expose generic admin/maintenance facets to Agents.

[LanicBlue]

Completed in 4b4929a (Project-only scope per #1 phasing).

Delivered

• Vendored SDK: @lanicblue/project-consumer 0.4.0 as file: tarball + sha256 sidecar (vendor/consumer-sdk/), digest from the PS release manifest; verifier script + suite-enforced integrity test.
• Four trusted tools (project_work_list/get/submit, project_operation_get): all identity — projectId, agentId, projectGeneration, Bearer credential, operation/idempotency handles — resolved server-side from session + live settings; arguments carry business data only. Outputs re-projected field-by-field so PS-side identity (projectId, executorRef, workspaceRef) never reaches the agent.
• Capability family project.work.{read,write} derived live per call (independent of the browser preview scope); refresh on an attached session takes effect without deletion.
• Error boundary: structured auth/conflict/uncertain(+operationId recovery hint)/not-found(kind by service code)/unavailable/incompatible/rejected; no session teardown on any service failure.

Adversarial review (2 HIGH + 4 LOW, all confirmed) — fixed in the same commit

• HIGH client layer never provided to the runtime (toolkit requirements erased) → provided at the toolkit registration + end-to-end wiring test.
• HIGH committed-operation revision decoded as Number while the service/SDK deliver "run:4" → String + fixtures carrying the real shape.
• LOW: sidecar enforcement, transport ok computed, NOT_FOUND kind from code, UncertainError omits empty operationId, duplicate bindings → binding-ambiguous.

Gates

root typecheck 15/15 zero errors · apps/server 244 files / 2642 tests passed (baseline 238/2606 + 6 files / 36 tests) · vendored-sdk verifier ok · lint/format clean.

Next: #4 (Consumer runtime wiring + notice routing/coalescing), then E2E (needs an operator client for the PS WebUI + an ordinary client for T3, both created in the PS WebUI).