docs(agent-workflows): correct the MCP flag name across docs

docs/design/agent-workflows/documentation/adapters/claude-code.md

@@ -50,7 +50,7 @@ capability below — the two toggle separately.)
 
 User-declared `mcp_servers` are a separate thing and effectively off today. They would reach
 Claude through `toAcpMcpServers` as additional ACP stdio servers, but only when
-`AGENTA_AGENT_ENABLE_MCP` is set (off by default), so in practice no user MCP server is
+`AGENTA_AGENT_MCPS_ENABLED` is set (off by default), so in practice no user MCP server is
 attached. See [tools.md](../tools.md#status-and-known-gaps).
 
 ## Permissions

docs/design/agent-workflows/documentation/agent-configuration.md

@@ -217,7 +217,7 @@ Legend: (a) catalog/schema, (b) SDK neutral config, (c) runtime.
 | --- | --- | --- | --- | --- |
 | model / provider | yes, `model: str` | yes, `Optional[str]` | wired to the runner | Loose string. No `ModelRef`, no provider enum. There is no separate provider field. |
 | tools | yes, strict list | yes, lenient coercion | wired, resolved to builtin names + tool specs | Entries strict, list lenient. |
-| mcp_servers | yes, strict list | yes | wired, resolved to runner mcp servers | Strict per entry. Gated by `AGENTA_AGENT_ENABLE_MCP` at the service. |
+| mcp_servers | yes, strict list | yes | wired, resolved to runner mcp servers | Strict per entry. Gated by `AGENTA_AGENT_MCPS_ENABLED` at the service. |
 | skills | yes, embed/inline list | yes | wired | Author-settable (`SkillConfig` inline or `@ag.embed` references). The playground build-kit overlay embeds one skill, the `build-an-agent` playbook; the `pi_agenta` harness additionally force-unions `getting-started`. See below. |
 | persona | no | no | wired but forced only | Not a config field. The Agenta harness hardcodes an append-system preamble. See below. |
 | agents_md | yes, `agents_md: str` | yes, as `instructions` | wired to `agentsMd` | The schema names it `agents_md`. The neutral config names it `instructions`. |

docs/design/agent-workflows/documentation/architecture.md

@@ -112,7 +112,7 @@ Batch `/invoke` follows this path:
    fields `harness` and `sandbox`, plus the permission policy at
    `runner.permissions.default`.
 3. The service resolves three things independently: tools, MCP servers, and provider-key
-   secrets. MCP resolution is gated by `AGENTA_AGENT_ENABLE_MCP`
+   secrets. MCP resolution is gated by `AGENTA_AGENT_MCPS_ENABLED`
    (`services/oss/src/agent/tools/resolver.py:23`, off by default).
 4. The service builds `SessionConfig` and constructs a harness over an `Environment` and
    `SandboxAgentBackend`.

docs/design/agent-workflows/documentation/ground-truth.md

@@ -52,7 +52,7 @@ this page and the referenced code as the source of truth.
   relay.
 - Gateway/code tool delivery to non-Pi harnesses (Claude) exists through the internal MCP
   channel, served over a loopback HTTP MCP endpoint the runner stands up (no runner-host child
-  process). User-declared MCP resolution is feature-gated (`AGENTA_AGENT_ENABLE_MCP`, off by
+  process). User-declared MCP resolution is feature-gated (`AGENTA_AGENT_MCPS_ENABLED`, off by
   default).
 - `client` tools (browser-fulfilled, e.g. `request_connection`) are delivered to Claude too on
   the local path: advertised over the same internal MCP channel and PAUSED in the `tools/call`

docs/design/agent-workflows/documentation/ports-and-adapters.md

@@ -159,6 +159,6 @@ result fields should update both sides and the wire tests in the same PR.
 - Session history is not persisted: the runtime is cold and completed `/messages` turns are
   not stored.
 - `AgentaHarness` policy content is placeholder product copy.
-- MCP server resolution is disabled unless `AGENTA_AGENT_ENABLE_MCP` is truthy.
+- MCP server resolution is disabled unless `AGENTA_AGENT_MCPS_ENABLED` is truthy.
 - The code still has historical WP labels in some comments. Those labels should not guide new
   design decisions.

docs/design/agent-workflows/documentation/tools.md

@@ -162,7 +162,7 @@ invoke immediately instead of failing the model mid-loop, and the agent only eve
 name, a schema, and an opaque slug. The Composio key and the connection's auth never leave the
 service.
 
-MCP servers resolve on the same path but only when `AGENTA_AGENT_ENABLE_MCP` is truthy. The
+MCP servers resolve on the same path but only when `AGENTA_AGENT_MCPS_ENABLED` is truthy. The
 gate lives in `resolve_mcp_servers` (`services/oss/src/agent/tools/resolver.py`): when the
 flag is off it returns an empty list before the SDK `MCPResolver` ever runs. When on, the
 `MCPResolver` injects each server's named secrets into its `env`, the same way code tools get
@@ -356,7 +356,7 @@ daemon launches the server's `command` with the resolved `env`, and the harness
 over the MCP protocol.
 
 In practice user MCP is dead on the default path, and for two reasons that stack. First,
-resolution is gated behind `AGENTA_AGENT_ENABLE_MCP`, which is off by default, so the servers
+resolution is gated behind `AGENTA_AGENT_MCPS_ENABLED`, which is off by default, so the servers
 never reach the wire. Second, even with the flag on, `buildSessionMcpServers` drops user MCP
 for Pi (Pi's ACP adapter does not forward them), so it would reach Claude only. Pi and Agenta
 are the default harnesses, so the `mcp_servers` field is accepted and then silently ignored in
@@ -587,7 +587,7 @@ never drift from the files that exist. The canonical playbook format lives in th
 ## Status and known gaps
 
 - **User MCP is effectively dead on the default path.** Resolution is off unless
-  `AGENTA_AGENT_ENABLE_MCP` is truthy, and even on, the runner drops user MCP for Pi. Pi and
+  `AGENTA_AGENT_MCPS_ENABLED` is truthy, and even on, the runner drops user MCP for Pi. Pi and
   Agenta are the default harnesses, so `mcp_servers` is a silent no-op for most runs. It would
   reach Claude only. Do not confuse this with the `agenta-tools` server, which is an internal
   tool-delivery vehicle for Claude, not a user MCP server.