Support agent fine tuning

[fallow flax]

Hello Krill, running on 2026.5.6; I am building a local OpenClaw support agent called Ditto.

Current setup:

• Ditto is intended to be a support-first troubleshooting agent.
• It uses a local RAG corpus before falling back to other sources.
• The corpus includes official docs and curated solved support cases.
• It can route narrow worker tasks to specialist subagents.
• The goal is for Ditto to give practical support answers while staying grounded and honest about uncertainty.

Question:
How should I design Ditto’s evidence policy so it becomes a stronger support agent?

Please answer at a design level first, not as a long prompt rewrite.

Focus especially on:

1. What evidence should get highest priority?
2. How should Ditto rank evidence from official docs, local RAG, logs, config/schema, source code, solved community cases, and inference?
3. What should Ditto do when evidence conflicts?
4. What should Ditto do when RAG retrieves relevant-but-incomplete evidence?
5. How should Ditto answer low-confidence or partially supported questions?
6. When should Ditto ask a clarification question versus give a bounded practical answer?
7. What should Ditto say when it has no reliable evidence?
8. What minimal instruction changes would improve evidence evaluation without making the prompt noisy?
9. What mistakes should I avoid when writing this evidence policy?

[wet harness]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[faint turret]

I’d design Ditto’s evidence policy around one simple idea: support answers should be grounded in the most authoritative evidence available for the user’s exact version and environment, and Ditto should say when it’s extrapolating.

1. Highest-priority evidence

Top priority should be user-provided live evidence:

• exact OpenClaw version
• error text / stack trace
• relevant logs
• actual config snippets
• output from openclaw status, doctor, schema, etc.

For troubleshooting, live state beats generic docs because the user’s machine is the source of truth. But Ditto should interpret that state using docs/schema/source, not vibes.

2. Evidence ranking

I’d use roughly this order:

1. Actual user environment evidence: logs, error messages, config, command output, version.
2. Config/schema/runtime introspection: schema docs, generated config reference, CLI help, actual installed behavior.
3. Official docs for the matching version: especially setup, FAQ, troubleshooting, config docs.
4. Source code for the matching version/commit: strongest when docs are vague or stale.
5. Curated solved support cases: useful for patterns and known pain points, but not universal truth.
6. Official docs for nearby versions: useful with a version caveat.
7. Community discussion / Answer Overflow / Discord history: helpful, but treat as anecdotal unless repeated or confirmed.
8. Inference / general reasoning: allowed for next-step troubleshooting, but clearly label it as a hypothesis.

Important nuance: source code is not always “higher” than docs for user-facing behavior, because docs may describe intended supported usage. But if the question is “what actually happens?” source/schema/logs win.

3. When evidence conflicts

Ditto should not average conflicting evidence. It should resolve by:

• version match first
• runtime/schema/source over stale prose
• official docs over community claims for intended behavior

• repeated solved cases over one-off anecdotes
• current user evidence over generic examples

And it should say the conflict plainly: “The docs say X, but the 2026.5.6 schema/source appears to do Y, so for your version I’d trust Y.”

4. Relevant-but-incomplete RAG

RAG retrieval should be treated as a lead, not a verdict. If retrieved evidence is relevant but incomplete, Ditto should:

• answer only the supported part
• identify the missing piece
• run a targeted follow-up lookup if possible
• otherwise give a bounded next step

Example posture: “I found evidence that this error often comes from auth resolution, but not enough to identify which provider path is failing. Next check gateway logs around the failed request.”

5. Low-confidence / partially supported answers

Use confidence tiers, not fake certainty:

• Confirmed: supported by live evidence + docs/schema/source.
• Likely: matches known pattern and evidence points that way.
• Hypothesis: plausible next diagnostic step, not a claimed cause.
• Unknown: no reliable evidence.

For support, “likely” is fine if Ditto gives safe, reversible next steps.

6. Clarification vs bounded answer

Ask a clarification question when the missing info changes the recommendation or could make the advice risky. Examples:

• version unknown
• OS/install method unknown
• destructive command might be suggested
• multiple providers/channels/config paths possible

Give a bounded practical answer when the next step is safe and useful regardless. Example: “Please run openclaw --version and check the gateway logs; if you’re on 2026.5.x, I’d first verify…”

Good support agents do not block on perfect info when a safe diagnostic step exists.

7. No reliable evidence

Ditto should say something like:

“I don’t have reliable evidence for that in the docs/source/corpus I checked. I don’t want to guess. The safest next step is X; if this looks like a bug or missing docs, file it here: https://github.com/openclaw/openclaw/issues.”

No confident folklore. No invented config keys. No “probably” masquerading as fact.

8. Minimal instruction changes

I’d add a short evidence policy block, not a huge prompt rewrite:

• Prefer live user evidence, matching-version docs/schema/source, then curated solved cases, then inference.
• Treat RAG hits as candidates; verify against version, schema, source, or logs before presenting as fact.
• If evidence conflicts, state the conflict and trust matching-version runtime/schema/source over stale docs or anecdotes.

• Separate confirmed facts from hypotheses and next diagnostic steps.
• When incomplete, give the safest bounded next step and ask only the clarification that changes the answer.
• Never invent commands, config keys, defaults, file paths, or provider behavior.

That’s enough. The key is consistency, not prompt mass.

9. Mistakes to avoid

• Treating RAG similarity as authority.
• Letting old solved cases override current docs/source.
• Collapsing “I found a similar issue” into “this is the cause.”
• Asking for clarification too early when a safe diagnostic step exists.
• Asking too late when advice depends on version/install method/provider.
• Hiding uncertainty behind confident wording.
• Making source code the only truth and ignoring supported/documented user flows.
• Writing a giant evidence rubric the model won’t actually follow.
• Failing to cite or name the evidence type behind the answer.

My recommendation: make Ditto very strict about evidence labels. Every serious support answer should internally know whether it is based on logs, config/schema, docs, source, solved cases, or inference. The visible answer can stay natural, but the reasoning discipline should be that crisp. 🦞

[fallow flax]

I want to create a new OpenClaw support agent, separate from Ditto, focused only on diagnosis.

Goal: behave more like Krill using an Agentic RAG loop:

1. Classify the question.
2. Use local support-RAG first.
3. Evaluate evidence type/quality/version fit.
4. Inspect logs/config/schema/source only if needed.
5. Rewrite/search again if evidence is incomplete.
6. Decide posture: confirmed / likely / hypothesis / unknown.
7. Answer with grounded advice, safe next step, or one needed clarification.

Evidence priority:
live user evidence > runtime/config/schema > matching-version docs > matching source > curated solved cases > nearby/community evidence > labeled inference.

How should I implement this in OpenClaw? Please cover:

• files to create/edit
• AGENTS.md and TOOLS.md structure
• openclaw.json config
• support-RAG/local read-only tool access
• what to avoid giving it
• tests to verify the 7-step loop
• OpenClaw gotchas: workspace, agentDir, tools, model, context files

[faint turret]

For a diagnosis-only OpenClaw agent, I’d build it as a separate agent with its own workspace, agentDir, corpus, and constrained tool surface. Keep Ditto broad; make this one deliberately boring and evidence-obsessed.

First: since you’re on 2026.5.6, validate exact keys against your live schema before applying this:

openclaw config schema
openclaw doctor
openclaw agents list --bindings

Docs worth keeping open:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/concepts/multi-agent
https://docs.openclaw.ai/gateway/config-agents
https://docs.openclaw.ai/gateway/config-tools
https://docs.openclaw.ai/reference/memory-config

1. Files to create

Recommended layout:

~/.openclaw/workspace-diagnosis/
  AGENTS.md
  SOUL.md
  IDENTITY.md
  USER.md          optional / short
  TOOLS.md
  HEARTBEAT.md     empty or disabled
  support-rag/
    docs/
    solved-cases/
    notes/

    index-notes.md

And a separate agent state dir:

~/.openclaw/agents/diagnosis/agent/

Do not reuse Ditto’s agentDir. That causes auth/session collisions.

You can start with:

openclaw agents add diagnosis

Then edit the generated workspace files.

2. AGENTS.md structure

Make AGENTS.md procedural, not poetic. Something like:

# Diagnosis Agent

You are a diagnosis-only OpenClaw support agent.
Your job is to identify likely causes, evidence quality, and safe next steps.
Do not implement fixes, mutate user files, send external messages, or claim certainty without evidence.

## Diagnostic loop
For support questions:
1. Classify the issue: setup, config, auth, channel, model, tools, sandbox, memory, runtime, networking, unknown.

2. Search local support RAG first.
3. Evaluate evidence by type, quality, version fit, and recency.
4. Inspect logs/config/schema/source only when RAG and user evidence are insufficient.
5. If evidence is relevant but incomplete, rewrite the query and search once more before answering.
6. Choose posture: confirmed / likely / hypothesis / unknown.
7. Answer with grounded advice, a safe next step, or one needed clarification.

## Evidence priority
live user evidence > runtime/config/schema > matching-version docs > matching source > curated solved cases > nearby/community evidence > labeled inference.

## Answer rules
- Separate confirmed facts from hypotheses.
- Prefer safe read-only diagnostics.
- Ask one clarification only when it changes the recommendation.
- If a safe diagnostic step exists, give it instead of blocking.

- Never invent commands, config keys, defaults, paths, or provider behavior.
- If evidence conflicts, state the conflict and trust matching-version runtime/schema/source over stale docs or anecdotes.

That’s enough. Don’t bury the agent under a 900-line rubric.

3. TOOLS.md structure

Use TOOLS.md for local corpus/tool conventions, not general behavior:

# Local Diagnosis Tools

## Support corpus
- Local RAG corpus lives at `support-rag/` in this workspace.

- Prefer local solved cases and official docs before web search.
- Treat solved cases as pattern evidence, not authoritative truth.

## Read-only boundaries
- Use read/search/log inspection only.
- Do not write, edit, patch, delete, move, install, restart services, or change config.
- If a fix requires mutation, explain the fix and ask the user to apply it.

## Source/doc lookup
- Prefer matching-version docs/source when available.
- If version is unknown, ask for `openclaw --version` unless a safe generic diagnostic step exists.

Keep SOUL.md short: “calm, precise, support-first, no drama.” If you want it Krill-like, copy the principles, not the whole personality.

4. openclaw.json shape

Minimal sketch:

{
  agents: {
    list: [
      {
        id: "diagnosis",
        name: "Diagnosis Agent",
        workspace: "~/.openclaw/workspace-diagnosis",
        agentDir: "~/.openclaw/agents/diagnosis/agent",
        model: "provider/model",
        identity: {
          name: "Diagnosis",
          emoji: "🔎"
        },

        tools: {
          profile: "minimal",
          allow: [
            "read",
            "memory_search",
            "memory_get",
            "web_search",
            "web_fetch",
            "exec",
            "process",
            "session_status"
          ],
          deny: [
            "write",
            "edit",

            "apply_patch",
            "browser",
            "canvas",
            "message",
            "tts",
            "image_generate"
          ],
          elevated: { enabled: false }
        },
        subagents: {
          allowAgents: ["diagnosis-rag-worker", "diagnosis-source-worker"],
          requireAgentId: true
        }
      }
    ]

  }
}

Use an actual configured provider/model; don’t rely on stale model examples. For this agent, I’d choose a tool-reliable model over the cheapest one. Diagnosis quality depends heavily on following the loop.

If you want specialist workers, add separate agents like:

{
  id: "diagnosis-rag-worker",
  workspace: "~/.openclaw/workspace-diagnosis-rag-worker",
  agentDir: "~/.openclaw/agents/diagnosis-rag-worker/agent",
  tools: {
    profile: "minimal",

    allow: ["read", "memory_search", "memory_get"],
    deny: ["write", "edit", "apply_patch", "exec", "message"]
  }
}

Only give exec to a worker if it truly needs rg, openclaw config, or log inspection.

5. support-RAG / local read-only access

Best pattern:

• Put official docs snapshots and curated solved cases under support-rag/.
• Store solved cases with metadata:
  • OpenClaw version
  • OS

• install method
  • symptom/error
  • root cause
  • fix
  • source link/thread id
  • confidence
• Use OpenClaw memory/QMD or a custom skill/plugin as a search-only retrieval surface.
• Let the agent use read for local snippets and memory_search / memory_get for indexed recall.

If you use QMD, configure extra collections per agent rather than globally when this corpus is only for diagnosis. The memory docs call out agents.list[].memorySearch.qmd.extraCollections for agent-scoped extra collections.

The important design rule: RAG returns candidate evidence, not truth. The agent still has to grade the evidence.

6. What not to give it

Avoid:

• write, edit, apply_patch — diagnosis-only means no mutation.
• elevated exec.
• broad shell with full security if exposed to public users.
• browser/canvas unless you really need UI inspection.
• proactive message tool unless this agent must send messages itself.
• GitHub issue/PR creation tools.
• secrets, personal workspaces, or raw unrestricted session transcripts.
• unrestricted subagent spawning.
• access to Ditto’s full workspace unless intentionally shared.

Also avoid giving it “fix it automatically” instructions. That will fight the diagnosis-only identity.

7. Tests for the 7-step loop

Create a small test set of prompts and expected behavior:

1. Known solved case

• Ask about an error that exists in curated cases.
  • Expected: cites/uses solved-case pattern, labels as likely unless live logs confirm.

2. Version conflict

   • Give a 2026.5.6 question where old docs/cases say one thing and current schema/source says another.
   • Expected: trusts matching-version schema/source and states the conflict.

3. Incomplete RAG hit

   • Ask with only a vague symptom.
   • Expected: searches RAG, sees incomplete evidence, rewrites/searches again, then asks one targeted clarification or gives safe diagnostics.

4. Live log beats docs

   • Provide a log line contradicting a generic docs path.
   • Expected: uses the log as primary evidence.

5. No evidence

   • Ask about a nonexistent config key.

• Expected: says no reliable evidence; does not invent a key.

6. Risky fix request

   • “Just change my config / restart / delete sessions.”
   • Expected: refuses mutation, gives read-only diagnosis and asks user confirmation or hands off to a fixer agent.

7. Clarification gate

   • Omit version/install method for a version-sensitive issue.
   • Expected: asks for openclaw --version only if the answer depends on it; otherwise gives a safe first check.

Also test tool behavior with /tools from that agent’s session. Confirm mutation tools are absent/blocked.

8. OpenClaw gotchas

Big ones:

• workspace is default cwd/context, not a security sandbox. Absolute paths can still reach host files unless sandbox/tool policy blocks it.

• agentDir must be unique per agent.
• Context files are injected into the agent prompt; keep AGENTS.md and TOOLS.md tight.
• Large RAG files in the workspace can bloat context if you paste them into bootstrap files. Store corpus as files/indexes, not giant instructions.
• agents.list[].skills replaces defaults; it does not merge.
• tools.allow entries must be real tool names/groups like read, memory_search, group:web; not made-up names like web.fetch.
• systemPromptOverride replaces OpenClaw’s assembled prompt. Avoid it unless you really want to own the whole prompt stack.
• Tool profile, allow/deny, provider policy, sandbox policy, and elevated mode all interact. Use the docs’ mental model: sandbox decides where tools run; tool policy decides what tools exist; elevated decides exec escape.
• Local models may be weaker at tool calling. For a diagnosis agent, tool reliability matters more than raw benchmark vibes.

My recommended implementation: make the diagnosis agent read-only + RAG-first + schema/source-capable, and route actual repairs to a separate fixer agent or the human. That separation will make it much more trustworthy.

[fallow flax]

The agent should autonomously diagnose support issues using this loop:
classify → retrieve → evaluate evidence → inspect more if needed → refine/search again → decide confidence → answer/ask/stop.

It should be allowed to inspect read-only evidence such as RAG, logs, config, schema, local docs/source, session files, and curated solved cases. It should stop before mutation: no config edits, restarts, commits, ingestion, deletes, or fixes unless explicitly moved to a separate fixer flow.

We already discussed evidence priority:
live user evidence > runtime/config/schema > matching-version docs > matching source > curated solved cases > nearby/community evidence > labeled inference.

Follow-up question:
How should we design the agent’s loop-control policy?

Specifically:

1. When should it continue inspecting instead of answering?
2. When should it rewrite/retry a RAG query?
3. When should it ask the user for missing external input?
4. When should it stop with “unknown / insufficient evidence”?
5. How many retrieval/inspection iterations are reasonable before stopping?
6. What are good stopping states for a diagnosis-only support agent?
7. How do we prevent both premature answers and endless investigation?
8. What minimal wording should go into AGENTS.md to enforce this behavior?

[faint turret]

I’d make the loop-control policy explicit and mechanical. The agent should not “research until satisfied”; it should move through bounded gates.

Core rule

The diagnosis agent continues inspecting only while another read-only check is likely to change one of these:

• the issue classification
• the suspected cause
• the confidence posture
• the safe next step
• whether it needs user input

If the next lookup would only add color, stop and answer.

1. Continue inspecting instead of answering when

Continue if any of these are true:

• The evidence is relevant but does not identify a cause or next diagnostic step.
• The version/install method/provider/channel matters and is not yet resolved, but can be inferred from available logs/config.
• RAG found a pattern, but live evidence has not confirmed whether it applies.
• Evidence conflicts and a higher-priority source is available to check.
• The proposed advice would be risky, version-sensitive, or likely wrong without one more read-only check.
• The answer would otherwise depend mainly on inference.

Stop inspecting if you already have enough to give a safe bounded next step.

2. Rewrite/retry RAG when

Retry RAG once when the first retrieval is:

• semantically close but missing the exact error string
• too broad, e.g. “auth issue” but not the provider/channel
• version-mismatched
• mostly community anecdotes with no docs/source support

• contradicted by live evidence
• missing the known terms from logs/config

Good rewrite pattern:

1. first query: user language
2. second query: normalized diagnostic language using exact error terms, version, provider, command, file path, or config key

Example:

• user query: “Discord bot says pairing required”
• retry query: discord disconnected 1008 pairing required device scope operator.write 2026.5

Do not keep paraphrasing forever. One focused retry is usually enough; two only for complex multi-symptom cases.

3. Ask user for missing external input when

Ask when the missing input is not available to the agent and materially changes the answer.

Common gates:

• exact openclaw --version
• OS / install method
• full error text or log excerpt
• relevant config snippet, with secrets redacted
• which channel/provider/model/account is failing
• whether the issue happens after restart, upgrade, first install, or only one session

But don’t ask if a safe universal diagnostic exists. Prefer:

“First run openclaw status --all; if it shows X, do Y. If not, paste the relevant log section.”

over:

“What version are you on?”

unless version truly blocks the next step.

4. Stop with unknown / insufficient evidence when

Stop when:

• RAG has no relevant hit after one rewrite.
• Docs/schema/source do not mention the claimed key/behavior.
• Live evidence is absent and the question is too environment-specific.
• Evidence conflicts and no higher-priority source is available.
• Further inspection would require mutation, secrets, private data, or external action.
• The agent has hit its iteration budget.

The answer should be blunt but useful:

“I don’t have enough reliable evidence to identify the cause. I found no matching docs/source/case for this exact error. The safest next step is to collect openclaw status --all and the gateway log around the failure.”

5. Reasonable iteration budget

I’d use a small budget:

• Default: 2 inspection rounds after initial retrieval.
• Max: 3 rounds for complex issues with logs/config/source available.
• RAG retries: 1 rewrite by default, 2 max.
• Source/log/schema inspections: only when they can resolve a specific uncertainty.

A good loop shape:

1. classify + initial RAG
2. evaluate + inspect one higher-priority source if needed
3. refine query or inspect one more targeted source
4. decide posture and answer/ask/stop

If it needs more than that, it probably needs user input or a human/fixer flow.

6. Good stopping states

Use explicit stopping states:

• Confirmed cause — live evidence plus docs/schema/source align.
• Likely cause — strong pattern match, but missing one confirming live signal.
• Hypothesis — plausible and safe to test, but not proven.
• Need user input — one specific missing fact blocks progress.
• Insufficient evidence — searched reasonable sources; no reliable basis.
• Blocked by boundary — next step would require mutation, restart, secrets, or external action.
• Escalate/report — likely bug or docs gap; point to GitHub issue.

These states prevent mushy “maybe try this” answers.

7. Prevent premature answers and endless investigation

Use two guardrails:

Anti-premature-answer gate: before answering, the agent must be able to state:

• what evidence it used
• what confidence posture it chose
• why the next step is safe

If it can’t, inspect once more or ask.

Anti-endless-loop gate: before any additional lookup, the agent must state internally:

• what uncertainty this lookup resolves
• which source it will check
• how the result would change the answer

If it cannot answer those, stop.

That one rule is the claw. 🦞

8. Minimal AGENTS.md wording

I’d add this, compactly:

## Loop-control policy

For support diagnosis, follow a bounded loop:
classify → retrieve → evaluate evidence → inspect more if needed → refine/search again → decide confidence → answer/ask/stop.

Continue inspecting only if the next read-only lookup is likely to change the classification, suspected cause, confidence posture, safe next step, or need for user input.

Before any extra lookup, identify the specific uncertainty it will resolve. If no specific uncertainty exists, stop and answer.

Retry RAG at most once by rewriting the query with exact error text, version, provider/channel, command, config key, or file path. Use a second retry only for complex multi-symptom cases.

Ask the user for one missing external input only when it materially changes the recommendation and cannot be obtained from available read-only evidence. If a safe diagnostic step exists, give that step instead of blocking.

Default budget: initial retrieval plus up to 2 targeted inspection rounds. Maximum: 3 rounds. Stop earlier when evidence supports a safe bounded answer.

Every answer must choose one posture: confirmed, likely, hypothesis, need-user-input, insufficient-evidence, blocked-by-boundary, or escalate/report.

Stop before mutation. Do not edit config, restart services, delete files, commit code, ingest data, or apply fixes unless explicitly moved into a separate fixer flow.

That’s the policy I’d use. Small enough to follow, strict enough to stop both guessing and spelunking forever.

[fallow flax]

We are considering replacing the shell-backed support-RAG workflow with a narrow MCP tool so the support agent can use support-RAG without general exec.

Proposed shape:

• local MCP server exposes one tool: support_rag_search
• input: { "query": string, "limit"?: number }
• output: structured RAG results with evidence_decision_hint, source, score, chunk_index, preview, evidence_type
• no ingestion, no writes, no Qdrant admin, no shell passthrough
• Ditto2 tool policy would allow this MCP tool and deny exec

Questions:

1. Does this installed OpenClaw version support registering a local MCP server/tool from config?
2. What is the exact config shape for adding a local MCP server?
3. Once registered, what exact tool name appears in agents.list[].tools.allow?
4. Can an agent allowlist that MCP tool while denying exec?
5. Does OpenClaw support per-agent MCP tool exposure, or are MCP tools global and then filtered by agent tool policy?
6. What validation/listing command shows the registered MCP tool name?
7. Any known caveat with Node-based local MCP servers inside the gateway container?
8. Evidence sources used.

currently using 2026.5.6 version.

[faint turret]

I checked this against the v2026.5.6 tag + current installed docs/source. Short version: yes, the shape is viable, but treat the MCP registry as global config and use per-agent tool policy to narrow exposure.

1. Yes — 2026.5.6 supports configured MCP servers under mcp.servers. The docs describe this as OpenClaw’s MCP client-side registry, consumed by runtimes such as embedded Pi. Configured MCP tools are exposed in normal coding / messaging profiles; minimal hides them.

2. Local stdio MCP config shape:

{
  mcp: {
    servers: {
      support_rag: {
        command: "node",
        args: ["/app/support-rag-mcp/dist/server.js"],
        cwd: "/app/support-rag-mcp",
        env: {
          // ordinary app env is ok
          QDRANT_URL: "http://qdrant:6333"

        },
        connectionTimeoutMs: 30000
      }
    }
  }
}

Equivalent CLI write:

openclaw mcp set support_rag '{"command":"node","args":["/app/support-rag-mcp/dist/server.js"],"cwd":"/app/support-rag-mcp"}'

3. Tool naming: OpenClaw materializes MCP tools as:

<sanitized-server-name>__<sanitized-mcp-tool-name>

So if the server key is support_rag and the MCP server exposes support_rag_search, the agent tool name should be:

support_rag__support_rag_search

If you name the server support-rag, it will be:

support-rag__support_rag_search

In 2026.5.6, valid chars are basically A-Z a-z 0-9 _ -; other chars become -; server prefix max is 30 chars; full tool name max is 64 chars; collisions get suffixes.

4. Yes, an agent can allowlist that MCP tool and deny shell tools. I’d use a normal profile, then narrow with allow:

{
  agents: {
    list: [
      {

        id: "ditto2",
        tools: {
          profile: "messaging",
          allow: ["support_rag__support_rag_search"],
          deny: ["exec", "process", "apply_patch"]
        }
      }
    ]
  }
}

The restrictive allow is the real control; the deny entries are belt-and-suspenders. Avoid allow: ["bundle-mcp"] unless you want all configured MCP tools exposed.

5. MCP server definitions are global under mcp.servers. Exposure is then filtered by runtime/profile/tool policy (agents.list[].tools, group policy, etc.). I did not find a per-agent mcp.servers config surface in 2026.5.6.

6. Config/listing commands: