mcpField
C
Canary

Canary

Local
github.com/mindstoneDeveloper Tools13Updated today

About Canary

Canary is an internal release-pipeline test MCP server from Mindstone, intended for validating release infrastructure rather than real workflows. Its sole `ping` tool returns an echoed message with a versioned prefix.

Key features

  1. 01Single `ping` tool
  2. 02Echoes messages with `pong v3: ` prefix
  3. 03No authentication or external dependencies

Use cases

  1. 01Test an MCP release pipeline end to end
  2. 02Verify a host can launch a stdio MCP server

MCP support

Exposes one `ping` tool to MCP clients, which returns the supplied message with a `pong v3: ` prefix.

Configuration

Local server config is the same for every client. Copy it into your client’s MCP config file.

mcp.json · Universal config
{
"mcpServers": {
"mindstone-mcp-server-canary": {
"command": "npx",
"args": [
"-y",
"@mindstone/mcp-server-canary"
]
}
}
}
Run commandnpx -y @mindstone/mcp-server-canary

Local servers need a runtime on your machine (e.g. Node.js 18+). Config file locations differ by client; see your client’s docs.

Packages
npm@mindstone/mcp-server-canary0.0.4

Tools

1

Saved tool list · updated 2w ago

ParameterTypeRequiredDescription
messagestringYesA short message to echo back. 1-200 chars.

Details

From the project README

@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

Add to Cursor Add to VS Code Add to VS Code Insiders

No required environment variables — the install completes without prompts.

Manual config for Claude Desktop / Claude Code / Goose / Continue.dev (Canary)
{
  "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>.

FieldTypeRequiredDescription
messagestringyesA 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.

Comments

Markdown supported

New to MCP?

From what the protocol is to installing your first server, these answers cover most first questions.

An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.