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 "Install 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: MegaMemory
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 installed
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Latest Blog Posts
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/shanika/mcp-waggle'
If you have feedback or need assistance with the MCP directory API, please join our Discord server