PR #68948: fix: enable MCP tools in Pi runtime for coding/messaging profiles (#68875)

• Repository: openclaw/openclaw
• Author: SARAMALI15792
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/68948

Description (problem / solution / changelog)

Summary

Fixes #68875 - MCP servers registered via openclaw mcp set now expose tools to Pi runtime sessions (isolated, cron, main).

Changes:

• Attach pluginId: "bundle-mcp" metadata to MCP tools during materialization
• Add "bundle-mcp" to coding/messaging profile allowlists in CORE_TOOL_PROFILES
• Add graceful degradation logging when MCP tools filtered by policy
• Export setPluginToolMeta function for metadata attachment

Root cause: MCP tools lacked plugin metadata → treated as unknown tools → filtered by profile allowlists.

Fix: Two-part solution:

1. Tag MCP tools with plugin metadata so policy system recognizes them
2. Include "bundle-mcp" in coding/messaging profiles by default

Test Plan

• Unit tests added for metadata attachment
• Unit tests added for profile allowlist inclusion
• Unit tests added for policy filtering with metadata
• Unit tests added for deny list override
• E2E tests added for coding profile (MCP tools pass through)
• E2E tests added for minimal profile (MCP tools filtered)
• All tests passing during implementation
• TypeScript compilation verified
• Follows conventional commit format

Manual verification steps:

1. Register MCP server: `openclaw mcp set testserver '{"command":"npx","args":["-y","@modelcontextprotocol/server-everything"]}'`
2. Set coding profile in config
3. Start session: `openclaw agent --agent main -m "List your tools"`
4. Verify MCP tools appear with `testserver__` prefix
5. Test deny override: Add `tools.deny: ["bundle-mcp"]` to config
6. Verify MCP tools blocked

AI-Assisted Development

• AI-assisted: Built with Claude Code (Sonnet 4)
• Testing degree: Fully tested (unit + E2E tests, all passing)
• Code understanding: Confirmed - fix attaches plugin metadata and updates profile allowlists
• Session logs: Available if needed

Files Changed

• `src/plugins/tools.ts` - Export setPluginToolMeta
• `src/agents/pi-bundle-mcp-materialize.ts` - Attach metadata to MCP tools
• `src/agents/tool-catalog.ts` - Add bundle-mcp to coding/messaging profiles
• `src/agents/pi-embedded-runner/effective-tool-policy.ts` - Add degradation logging
• Test files: Added comprehensive unit and E2E tests

Impact

Before: Users with `tools.profile = "coding"` couldn't use MCP tools (filtered out) After: MCP tools available automatically in coding/messaging profiles Breaking: None - additive change only Migration: Automatic - users get MCP tools on upgrade

Changed files

• src/agents/pi-bundle-mcp-materialize.ts (modified, +7/-1)
• src/agents/pi-bundle-mcp-tools.materialize.test.ts (modified, +14/-0)
• src/agents/pi-embedded-runner.bundle-mcp.e2e.test.ts (modified, +69/-0)
• src/agents/pi-embedded-runner/effective-tool-policy.test.ts (modified, +27/-0)
• src/agents/pi-embedded-runner/effective-tool-policy.ts (modified, +8/-0)
• src/agents/tool-catalog.test.ts (modified, +19/-0)
• src/agents/tool-catalog.ts (modified, +2/-2)
• src/plugins/tools.ts (modified, +4/-0)

PR #68949: fix: enable MCP tools in Pi runtime for coding/messaging profiles (#68875)

• Repository: openclaw/openclaw
• Author: SARAMALI15792
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/68949

Description (problem / solution / changelog)

Summary

• Problem: MCP servers registered via openclaw mcp set did not expose tools in Pi runtime sessions when tools.profile was set to coding or messaging. The tools were silently filtered out of the agent's tool surface.
• Why it matters: Users configuring profile-based tool policies lost access to all bundled MCP tooling, breaking a documented integration path and forcing them to fall back to profile-less configurations.
• What changed: MCP tools are now tagged with pluginId: "bundle-mcp" at materialization time, and the coding and messaging profiles' allowlists explicitly include bundle-mcp. A graceful-degradation log line surfaces any MCP tool that still lacks metadata at policy time.
• What did NOT change (scope boundary): No change to MCP server launch, tool registration, core tool policy engine, or any other profile. The minimal profile continues to exclude MCP tools.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #68875
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: Materialized MCP tools carried no plugin metadata. applyToolPolicyPipeline classified them as "unknown" entries, and the coding / messaging profile allowlists included neither the tool names nor a bundle-mcp plugin key. The policy filter therefore dropped them before they reached the agent.
• Missing detection / guardrail: No test asserted that MCP tools survive profile filtering, and no log fired when a plugin-backed tool was stripped, so the regression was silent.
• Contributing context (if known): Plugin metadata (setPluginToolMeta) was already the mechanism used for every other plugin-sourced tool; the bundle-MCP materializer was introduced without wiring it up.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/agents/pi-bundle-mcp-tools.materialize.test.ts, src/agents/tool-catalog.test.ts, src/agents/pi-embedded-runner.bundle-mcp.e2e.test.ts, src/agents/pi-embedded-runner/effective-tool-policy.test.ts.
• Scenario the test should lock in: With tools.profile = "coding" (or "messaging") and a registered MCP server, materialized MCP tools must remain in the effective tool set after policy evaluation; with tools.profile = "minimal" they must be filtered; and tools.deny: ["bundle-mcp"] must still override.
• Why this is the smallest reliable guardrail: Unit tests pin the metadata-attachment contract and the profile allowlist contents; the E2E test pins the end-to-end behavior a user actually observes in a session.
• Existing test that already covers this (if any): None — the prior suite exercised tool policy without plugin-tagged MCP tools.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

• tools.profile = "coding" and tools.profile = "messaging" now expose bundled MCP tools by default. Users who previously added tools.allow: ["bundle-mcp"] as a workaround can remove it.
• tools.deny entries still take precedence, so operators who explicitly deny bundle-mcp see no change.
• No default changes for the minimal profile.

Diagram (if applicable)

Before:
[mcp server registered] -> [tools materialized without pluginId]
                        -> [profile filter treats tools as unknown]
                        -> [tools dropped, agent sees none]

After:
[mcp server registered] -> [tools materialized, tagged pluginId=bundle-mcp]
                        -> [profile allowlist includes "bundle-mcp"]
                        -> [tools retained, agent sees them]

Security Impact (required)

• New permissions/capabilities? No — this PR restores an intended capability that was already gated behind user opt-in (registering an MCP server and selecting a profile).
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? Yes — MCP tools are reachable under coding and messaging profiles. Mitigation: users who want to block them can still do so via tools.deny: ["bundle-mcp"]; the behavior is additive and matches the documented intent of those profiles.
• Data access scope changed? No

Repro + Verification

Environment

• OS: Linux / macOS / Windows (platform-agnostic)
• Runtime/container: Pi embedded runtime
• Model/provider: Any supported provider (verified with the OpenAI-compatible embedded runner)
• Integration/channel (if any): Bundled MCP via openclaw mcp set
• Relevant config (redacted): tools.profile: coding, one or more registered MCP servers

Steps

1. Register an MCP server: openclaw mcp set testserver '{"command":"npx","args":["-y","@modelcontextprotocol/server-everything"]}'
2. Set tools.profile: coding in the OpenClaw config.
3. Start a session: openclaw agent --agent main -m "List your tools".
4. Confirm the agent enumerates MCP tools with the testserver__ name prefix.
5. Add tools.deny: ["bundle-mcp"] and re-run step 3; confirm MCP tools are gone.

Expected

• Step 4 lists the bundled MCP tools; step 5 excludes them.

Actual

• Matches expected on this branch. On main before the fix, step 4 lists no MCP tools.

Evidence

• Failing test/log before + passing after — the newly added unit and E2E tests fail on main and pass on this branch.
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: coding profile with a registered MCP server exposes tools; minimal profile continues to filter them; tools.deny: ["bundle-mcp"] overrides the profile allowlist.
• Edge cases checked: MCP server returning zero tools (agent tool list unchanged); tool-name collision between MCP tool and a core tool (existing collision-suffix logic retained and exercised).
• What I did not verify: Non-OpenAI providers end-to-end; those share the same tool-policy pipeline, but only the OpenAI-compatible runner was exercised live.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes — additive change; no config schema updates.
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A.

Risks and Mitigations

• Risk: Operators relying on the previous (buggy) behavior of coding/messaging implicitly hiding MCP tools may see tools surface unexpectedly after upgrade.
  • Mitigation: Documented in this PR's user-visible changes; operators can opt out with tools.deny: ["bundle-mcp"].
• Risk: Future plugin-backed tool sources could reintroduce the same metadata-missing gap.
  • Mitigation: The new graceful-degradation log in effective-tool-policy.ts surfaces any plugin tool that reaches policy evaluation without metadata, giving operators and maintainers a clear signal.

Changed files

• src/agents/pi-bundle-mcp-materialize.ts (modified, +8/-1)
• src/agents/pi-bundle-mcp-tools.materialize.test.ts (modified, +14/-0)
• src/agents/pi-embedded-runner.bundle-mcp.e2e.test.ts (modified, +82/-18)
• src/agents/pi-embedded-runner/effective-tool-policy.test.ts (modified, +27/-0)
• src/agents/pi-embedded-runner/effective-tool-policy.ts (modified, +8/-0)
• src/agents/tool-catalog.test.ts (modified, +19/-0)
• src/agents/tool-catalog.ts (modified, +2/-2)
• src/agents/tool-policy-pipeline.test.ts (modified, +3/-2)
• src/plugins/tools.ts (modified, +4/-0)