mcp-waggle
Allows publishing full test results from Vitest runs, including per-test names, statuses, durations, failure messages, and console logs via a custom reporter.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mcp-waggleRecord a research on improving BFS performance"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Waggle (mcp-waggle)
An MCP server for planning and overseeing the tecture-graph project from the outside. It gives coding agents a persistent, queryable place to:
Log tecture-graph researches — what is being investigated, why, and what came of it
Log development activities — each step performed, linked to a research or directly on the code
Publish test results — one record per test run, optionally linked to a research
Write and read overall project progress — an append-only journal of where the project stands
Waggle owns its own SQLite database and knows nothing about the project it tracks; the tracked project registers Waggle as just another MCP server. (Named after the waggle dance — how bees report their findings back to the hive. Sibling of mcp-bumble, whose architecture — including the OAuth 2.1 HTTP transport — it follows.)
Tools
Tool | Purpose |
| Record a tecture-graph research with its goal (optionally results/status/tags) |
| Update a research's results and/or status |
| List researches, newest first; filter by status or free-text query |
| Fetch one research, including linked test runs + activities |
| Record a development activity — research-linked ( |
| List activities; filter by researchId, scope ( |
| Record a test run with its full per-test report ( |
| List runs, newest first, without per-test reports; filter by suite/status |
| Fetch one run including its full per-test report and run-level output |
| Append a project progress entry (summary + optional details) |
| Read the latest progress entry plus recent history |
The research tools carry the tecture_ prefix deliberately, so they don't collide with other
research-log connectors in the same Claude workspace.
Publishing full Vitest reports (with per-test console logs)
Vitest's built-in JSON reporter (--reporter=json) includes per-test names, statuses, durations
and failure messages — but no console output. To capture logs per test, use the bundled
custom reporter, which listens to onUserConsoleLog (its taskId matches TestCase.id) and
writes a payload that can be passed to publish_test_results verbatim:
npm run test:report # = vitest run --reporter=default --reporter=./scripts/vitest-waggle-reporter.mjs
# → waggle-report.json: { suite, durationMs, tests: [{ name, file, status, durationMs, error?, logs? }] }WAGGLE_SUITE and WAGGLE_REPORT_FILE override the suite name and output path. The reporter is
self-contained — copy scripts/vitest-waggle-reporter.mjs into any Vitest project that publishes
to Waggle.
Related MCP server: Graph
Dashboard
A read-only web interface over the same database — browse researches, activities, test runs and the progress journal without going through MCP:
OAUTH_ADMIN_PASSWORD=... npm run ui # http://127.0.0.1:3204It is protected by the same admin password as the MCP server (OAUTH_ADMIN_PASSWORD, the one
the OAuth consent page uses) and refuses to start without it. Logging in sets an HttpOnly
session cookie (7 days, kept in memory — a restart signs everyone out). The dashboard never
mutates data.
In HTTP mode (WAGGLE_TRANSPORT=http) the dashboard is also served from the MCP server's own
origin — every path the MCP/OAuth routes don't claim — so the hosted instance's dashboard lives
at https://waggle.heycasper.uk/ behind the same login. No separate process or port needed.
Env var | Default | Purpose |
| — (required) | Same password that gates the OAuth consent page |
|
| Dashboard port |
|
| Bind host |
|
| Same database the MCP server uses |
Transports
STDIO (default) — for local Claude Code / Claude Desktop:
{
"mcpServers": {
"waggle": { "command": "node", "args": ["/path/to/mcp-waggle/dist/index.js"] }
}
}HTTP + OAuth 2.1 (WAGGLE_TRANSPORT=http) — for use as a claude.ai custom connector.
Streamable HTTP at /mcp, OAuth 2.1 with dynamic client registration, PKCE, a password-gated
consent page, opaque 15-minute access tokens and rotated 90-day refresh tokens (stored hashed in
a JSON file), and RFC 8707 resource binding. Same design as mcp-bumble v1.1.
Env var | Default | Purpose |
|
| SQLite database file (created + migrated on startup) |
|
| Set to |
| — (required for http) | Canonical public URL, e.g. |
| — (required for http) | Password for the consent page |
| in-memory | JSON file for OAuth clients/tokens |
|
| Local port to bind |
|
| Bind host |
| — | Allowed |
Setup
npm ci
npm run build # bundles to dist/ and copies migrations
npm run smoke # end-to-end STDIO smoke test of the built servernode dist/index.js migrate applies migrations and exits (they also run automatically on
startup).
Deploy
The hosted instance runs on the Raspberry Pi as mcp-waggle.service (checkout at
/home/pi/mcp-waggle, config in /etc/mcp-waggle.env, deployed from origin/main):
npm run deploy # = ./scripts/deploy-pi.shThe script verifies the local tree is clean and pushed, runs the test suite (skip with
SKIP_TESTS=1), then over SSH: syncs the Pi checkout to origin/main, npm ci, builds,
restarts the service, and health-checks it locally and via https://waggle.heycasper.uk.
Override PI_HOST, PI_DIR, SERVICE, BRANCH, or PUBLIC_URL via env if the setup moves. npm run db:seed (= node dist/index.js seed) inserts a snapshot of real
tecture-graph tracking data (captured 2026-07-09 from the live Waggle instance: the CodeGraph
DB-survey research with its linked activities and test run, plus the progress journal) into
DB_PATH; it is idempotent, so re-running never duplicates rows.
Development
Stack: TypeScript, Node ≥ 20,
@modelcontextprotocol/sdk, Express 5 (HTTP transport), SQLite viabetter-sqlite3, Drizzle ORM with committed migrations,tsup, Vitest, ESLint.Layout:
src/index.ts(entry/dispatch) →src/transport/{stdio,http}.ts→src/server.ts(tool registration) →src/tools/*(pure functions + thin MCP wrappers) →src/oauth/*(provider, JSON-file token store, consent page) →src/ui/*(read-only local dashboard: Express routes + server-rendered HTML) →src/db/*(schema, connection + migration runner, seed fixtures) →src/lib/ids.ts(nanoid prefixes:res_,act_,run_,prog_).
npm test # all Vitest suites (fresh in-memory SQLite per test)
npm run test:coverage # v8 coverage, 80% thresholds enforced
npm run lint
npm run typecheck
npm run db:generate # regenerate migrations after editing src/db/schema.tsThis server cannot be deployed
Maintenance
Related MCP Connectors
MCP server for generating rough-draft project plans from natural-language prompts.
A MCP server built for developers enabling Git based project management with project and personal…
An MCP server for deep research or task groups
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceAn MCP server that lets coding agents build and query a persistent knowledge graph of concepts, architecture, and decisions, enabling them to remember across sessions.194 npm564MIT
- AlicenseNot gradedqualityCmaintenanceAn MCP server that gives your agent a persistent project brain: vision, architecture decisions, conventions, roadmaps, and automatic session handoff.3 npm6MIT
- AlicenseNot gradedqualityAmaintenanceLocal-first MCP server that provides project context, verification gates, and structured tools for coding agents to discover knowledge, run diagnostics, and execute allowlisted commands within a repository.23 npmMIT
- AlicenseNot gradedqualityCmaintenanceAn MCP server that gives AI coding agents structured access to a project's architecture, rules, modules, and technical decisions.MIT