squally-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SQUALLY_API_KEY | Yes | Organization read key, sqly_ro_…. Missing or an ingest key by mistake, and the server exits with one line saying so. | |
| SQUALLY_API_URL | No | Base URL. A trailing / or /api/v1 is tolerated. Useful against a local Squally: http://localhost:3000. | https://app.squally.dev |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| squally-list-projectsA | Lists the projects in your Squally organization. Start here: every other tool needs a projectId, and this is the only tool that produces one. |
| squally-find-runA | Finds CI runs of a project - the latest, or filtered by branch, commit SHA or status. One row per logical run: a sharded run is collapsed into a single entry. Returns summary counters only; use squally-get-run for the per-test rows. |
| squally-get-runA | One run with its per-test result rows, across every shard. Use this to find out which test is red in a run; the run list carries only the counters. |
| squally-debug-failureA | Every attempt of one test in one run, oldest first, each with the error, the stack and the Copy-for-AI prompt (the same text the Squally UI puts on the clipboard). This is the tool for 'why did this test fail'. If the test name is ambiguous, pass filePath. |
| squally-get-test-statusA | The stored flakiness status and active signals for ONE test. Cheap - one findUnique. Use this when you are asking about a single test; do not reach for squally-list-flaky-tests, which is expensive. |
| squally-list-flaky-testsA | The project's flaky and broken tests, ranked, with the time each has cost (timeLostMs). Expensive - one engine pass over the project's recent runs. For a single test use squally-get-test-status instead. |
| squally-list-errorsA | The project's error signatures in a period: failures grouped by fingerprint, with how often and how recently each occurred. Answers 'is this failure one instance of something that keeps happening' - a grouping no agent can compute from the repository alone. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool targets a distinct resource and action: project discovery, run search, run detail, failure debugging, single-test status, flaky-test listing, and error-signature aggregation. The descriptions explicitly cross-reference when one tool should be preferred over another, so there is no real ambiguity.
All tools share a consistent 'squally-' prefix and lowercase hyphenated action-object pattern such as list-projects, find-run, get-run, and debug-failure. The verbs are semantically meaningful and consistently used throughout.
Seven tools is a well-scoped size for a CI/test debugging server. Each tool covers a distinct step in the investigation workflow without redundant or bloated additions.
The surface covers the full read-only debugging journey: find a project, locate runs, inspect individual run results, drill into a failing test's attempts, check single-test flakiness, list flaky tests, and aggregate error signatures. There are no obvious dead ends or missing operations for the stated purpose.