squally-mcp

Official

by squallydev-admin

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Debug a failing test

squally-debug-failure

Read-onlyIdempotent

Retrieve every attempt of a failed test, oldest first, with error, stack, and Copy-for-AI prompt to pinpoint why it failed. Provide filePath when the test name is ambiguous.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`runId`	Yes	A run id from GET /projects/{projectId}/runs - or any shard's id of a sharded run.
`filePath`	No	The spec file of the test, as stored (e.g. tests/checkout.spec.ts); an empty value means a test with no file. Pass it exactly as shown in Squally; do not URL-encode, the server does. Needed only when the name exists in several files - the ambiguous_test error lists them.
`testName`	Yes	The full test name as Squally stores it (the Playwright title path), for example "checkout flow > completes payment". Pass the name exactly as shown in Squally; do not URL-encode, the server does. A name used in several spec files also needs filePath.
`projectId`	Yes	A project id from GET /projects.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`run`	Yes
`test`	Yes
`project`	Yes
`attempts`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 24, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly, idempotent, non-destructive behavior. The description adds genuinely useful behavioral detail: results are grouped by test/run, ordered oldest attempt first, and include the exact Copy-for-AI text a user would see in Squally.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, all earning their place: output detail, use case, and disambiguation hint. It is front-loaded with the most decision-relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a full input schema, output schema, and strong annotations, this is complete. The description covers what the tool returns, the ordering, and the ambiguity handling; nothing needed to call it successfully is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters. The description reinforces the ambiguous testName/filePath relationship, but doesn't add syntax or format details beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a concrete, specific contract: every attempt of one test in one run, oldest first, with error, stack, and Copy-for-AI prompt. The phrase "This is the tool for 'why did this test fail'" nails the purpose and differentiates it from run-level or status siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly states when to use it: when the agent needs to answer why a test failed. It adds a disambiguation rule (pass filePath if the test name is ambiguous), but doesn't explicitly name alternatives or conditions when another sibling would be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server