The workflow

  1. 01What was actually tested?
  2. 02Which configuration should I start with?
  3. 03How can I repeat the example?
  4. 04What should I check when discovery fails?

Muse Code 1.3.0 connected to the published Swift review server using schema_version: 1 and the camel-case mcpServers configuration key. The recorded check discovered 36 tools and executed a Stop hook, but did not verify a model choosing tools or building an app.

What was actually tested?

This walkthrough is deliberately a connection test. The local echo provider exercises initialization without making a model request. That distinction matters: a successful tool list establishes that two programs can communicate, while a completed development task requires evidence from the model, the tool, and the resulting project.

The repository's installation guide and its existing client record describe this boundary. I repeated the discovery harness against an isolated installation of the published ios-agent-mcp@2.7.0 package. The result again contained 36 tool names. Representative entries included review_swift_concurrency, search_local_references, create_app, and simulator_list. A command-based Stop hook also left the expected marker.

The record is available as the complete verification JSON. It identifies the client build, server package, discovered catalog, and the checks that remain false. It contains no account tokens, personal project content, or generated-app claims.

Which configuration should I start with?

For a local installation, this is the configuration shape documented by the project:

{
  "schema_version": 1,
  "mcpServers": {
    "ios-agent": {
      "command": "/absolute/path/to/ios-agent-mcp",
      "args": []
    }
  }
}

Merge that server entry into your existing settings rather than replacing the file. The absolute executable path is a placeholder: obtain the real location from your installation. The harness used an absolute Node executable and the server's JavaScript entry point, rather than relying on shell startup files to add a command to PATH.

The repository's configuration note records camel-case mcpServers as the tested key. It does not establish that the snake-case alternative mcp_servers works, and this article makes no such claim. Likewise, the schema version belongs to Muse's configuration format; it is not the npm package version and should not be changed to match a release number.

Meta's configuration documentation is the vendor reference. That page did not expose readable content to the unauthenticated research tool during this review. The compatibility statement here therefore rests on the executable record and repository documentation, not an invented quotation from Meta.

How can I repeat the example?

Use the verification harness from a source checkout and point it at the Muse executable and the installed server entry point:

node scripts/verify-muse.mjs \
  /absolute/path/to/muse \
  /absolute/path/to/ios-agent-mcp/dist/unified.js

Both paths must exist. The harness prepares temporary configuration and a temporary workspace, places the existing skill in that workspace, starts Muse with the echo provider, and records MCP discovery. It checks several representative tools rather than accepting any nonempty response. Finally it checks the Stop marker and removes its temporary files.

For this article, the server came from a separate installation pinned to 2.7.0. A first run against the working checkout exposed 37 tools, including an unpublished feedback tool. That was useful development evidence but unsuitable as a description of the npm release. Repeating the check against the released artifact resolved the mismatch. This is why a package version string alone is insufficient when testing uncommitted builds.

A compact reading of the published-package result is:

{
  "serverVersion": "2.7.0",
  "toolCount": 36,
  "stopHookExecuted": true,
  "provider": "echo",
  "modelSessionVerified": false
}

What should I check when discovery fails?

First confirm the executable path outside the agent. Then validate the JSON and check that the server is nested under the tested key. Preserve unrelated settings when correcting either problem. A missing executable and a valid executable that never completes initialization are different failures, so keep the startup error with the client version.

Next compare the environment used by your shell with the environment the client inherits. This example avoids package fetching during startup; it does not prove an npx download will succeed under every network policy. A global installation may be convenient, but the sandboxed download workaround has not been verified by this article.

Finally, do not paste private settings into a public issue. A synthetic configuration with executable placeholders, the versions, and the failure category is usually enough to begin diagnosis.

Limits

Tool discovery does not verify tool invocation, simulator permissions, model quality, skill selection, or app completion. The Stop test does not verify PreToolUse, PostToolUse, or an observer feature. No claim about HTTP transport, pricing tiers, or training policy follows from this stdio test. Recheck compatibility after either program changes.

Last verified

September 16, 2026, America/Chicago; the JSON timestamp is September 17 in UTC. Muse Code 1.3.0 build 1.3.0-R3233.1, published MCP package 2.7.0, Node.js 24.15.0. Repository sources: docs/mcp/installation.md and examples/client-verification/muse-1.3.0.json.

Example project: ios-agent-skill.