@mindstone/mcp-server-canary

Mindstone's internal release-pipeline test connector — not for use. It exists only to validate the rebel-oss release pipeline end-to-end. Single ping tool; no external dependencies, no auth, no bridge.

One-click install

No required environment variables — the install completes without prompts.

{
  "mcpServers": {
    "Canary": {
      "command": "npx",
      "args": [
        "-y",
        "@mindstone/mcp-server-canary"
      ],
      "env": {}
    }
  }
}

Why this exists

Releasing a real connector for the first time through a brand-new pipeline (Trusted Publishing, GitHub Actions, mcp-publisher, registry sync, host-app catalog) couples two unknowns: the pipeline correctness AND the connector correctness. The canary decouples them — it exercises every step of the pipeline with a tool whose only behaviour is ping → pong v3: <message>.

Once the pipeline has proven itself stable on the canary, real connectors can adopt the same path without piggy-backing on infrastructure debugging.

See docs/plans/260525_oss_release_automation.md (Mindstone-internal) for the full design.

Tools

ping

Echo a message back wrapped as pong v3: <message>.

| Field | Type | Required | Description | |---|---|:---:|---| | message | string | yes | A short message to echo back. 1-200 chars. |

Example:

{
  "tool": "ping",
  "arguments": { "message": "hello" }
}

Response:

pong v3: hello

Use locally

npx -y @mindstone/mcp-server-canary

This starts the server on stdio. Most MCP hosts will spawn this for you when you add @mindstone/mcp-server-canary as a stdio MCP server.

Status

Pre-1.0 — this is the canary. Versions are stamped 0.0.x deliberately. Do not depend on this connector for any real workflow; its only purpose is to exercise the release machinery.