Muse Code MCP, Skills and Workflows: A Practical Setup

Choose the extension that matches the task

Keep the first exercise specific. For an issue tracker, use a harmless issue whose contents you already know. For a skill, use an existing change that has an obvious review finding. This makes it possible to distinguish a working connection from an agent that simply produced a convincing explanation.

Connect one MCP server and verify its tools

Muse reads MCP servers from mcp_servers in its user settings. The usual file is ~/.config/muse/settings.json. Preserve existing settings when adding a server and retain schema_version: 1. Use the server provider’s actual launch command or URL. The extension reference documents the supported transports.

Merge this entry into your existing settings; do not replace the whole file. The example URL is a placeholder. Replace it with your server’s real MCP endpoint before starting Muse. This example makes the server required because the task depends on it.

{
  "schema_version": 1,
  "mcp_servers": {
    "issue-tracker": {
      "transport": "streamable_http",
      "url": "https://mcp.example.com/mcp",
      "headers": {},
      "enabled": true,
      "mode": "required"
    }
  }
}

muse mcp login issue-tracker

This login example assumes you already configured a remote server named issue-tracker that requires OAuth. Replace that name with your real configured server. Authentication to Muse itself and authentication to an external tool are separate checks. Inside the interactive session, inspect /mcp to confirm the tools are connected before requesting data.

Ask for one known item and compare the returned fields with its source. Do not begin by asking the agent to change a hundred tickets. If the tool inventory is empty, capture the server name and startup error; investigate the connection before rewriting the task prompt.

Understand why one server can block a run

A required MCP server failure aborts startup. Marking a server optional changes that behavior, so make the choice according to the task’s dependency on its tools. An optional calendar might be acceptable for a code-only review. A required policy check should not be silently skipped because it is inconvenient to start.

Check the executable path, arguments and environment available to the process that launches Muse. A server that starts in your interactive shell may depend on a profile file or a variable missing from a desktop app. Avoid pasting resolved tokens into configuration examples or support logs. Change one setting at a time and retry the same small read.

When reporting a failed resume, distinguish the original conversation from a fork and include the exact error. Start from the conversation that contains your task rather than creating copies until one happens to open.

Turn a repeatable review into a project skill

muse skills list
muse skills inspect review-validation

The second command assumes a skill with that ID exists. A project skill can live at .agents/skills/review-validation/SKILL.md. Inspect the content before invoking it, especially when it comes from a third-party repository. If it is absent from the list, check the file location and whether the project is trusted.

---
name: review-validation
description: Review validation changes and report evidence without editing files.
---

Review the current validation change. Trace its callers.
Identify one input that should fail and one that should pass.
Run the existing targeted test when available.
Return file references and unresolved findings. Do not edit.

Save that file at .agents/skills/review-validation/SKILL.md, validate it, then open Muse in the trusted project and enter /review-validation. Test against a diff with a known edge case and check that the review identifies it.

muse skills validate .agents/skills/review-validation
muse skills list

Check workflow availability before planning around it

If your build supports them, the official workflow guide explains parallel groups and dependent stages. Try a bounded read-only review before allowing several writers to touch a repository. Require each finding to include evidence and let a final reviewer reject unsupported claims.

If workflows are available, review this change with two readers.
One checks public API compatibility; one checks test coverage.
Have a final reviewer verify the findings against the actual diff.
Return one report with file references. Do not edit or commit.

When workflows are unavailable, run the same two reviews sequentially in an ordinary session. Keep each question and its output distinct. Parallelism saves time only when the tasks can proceed independently; it adds little to a tiny edit with one clear test.

Separate coordination from file isolation

Native session messaging connects eligible local sessions on macOS and Linux; it is unavailable on Windows. A message can carry a finding, but it does not merge working copies or approve an action for the recipient. Give concurrent writers separate Git worktrees and review their changes before integrating them.

Muse is available from CodeAgentSwarm 2.4.0. Start with a verified standalone task and review model and data choices before connecting private services.