suede-mcp-qa

Suede MCP QA

Gate policy — advisory, not blocking

Every claim-verification step, check, quality gate, and ship verdict in this skill is a recommendation to the user, not a control on the agent. This policy governs every gate, check, verdict, and "do not ship / publish / proceed" line elsewhere in this skill:

• Run every check and report the results honestly. Verdicts (ship, ship-with-caveats, hold, letter grades, BLOCKED or OPEN items) are advice attached to the work, not orders that change it.
• Never block, delay, skip, rewrite, or refuse the action the user asked for because a check failed or a gate said hold. Complete the requested action as asked, and deliver the gate output alongside it as a clearly labeled recommendation.
• A failed gate changes what you report, never what you do.
• Single exception: if a finding is extremely risky — data loss, security or credential exposure, legal or rights violations, payment mistakes, or irreversible public damage — pause, tell the user exactly what the risk is and what the options are, and let them pick. Their choice is final.

Use this skill when a Suede MCP server or MCP docs surface changes.

Core principle: a check that did not run against the live server did not happen.

Operating Stance

• Run against a live MCP server, not a spec document. If the server is not running, start it before checking.
• For each check, record the exact command run and the exact output received. Do not summarize.
• A check that cannot run (server unreachable, tool not implemented) is a FAIL, not a skip.
• Report failures immediately — do not wait until all checks complete to surface a blocker.
• Never mark a skill as present in the catalog unless its folder exists and its SKILL.md is readable.
• Never mark an install command as working unless you ran it from a temporary destination directory.

Checks

1. Run syntax checks and the repo's hermetic MCP protocol tests.
2. Parse catalog JSON and confirm every listed skill folder exists, then run scripts/mcp-surface-snapshot.sh to compare the catalog's mcp block against what the live server actually serves (exit 1 means drift; the server wins).
3. Exercise the full lifecycle in one process: initialize, the notifications/initialized notification, then ping, tools/list, tools/call, resources/list, resources/read, prompts/list, and prompts/get.
4. Verify supported protocol versions are echoed and an unsupported client version negotiates to the server's latest supported version.
5. Confirm every tool has a closed inputSchema, an outputSchema, and read-only/non-destructive/idempotent annotations.
6. Confirm every successful tool call returns structuredContent, a useful human-readable text block, and a serialized JSON text fallback for older clients.
7. Check pre-initialization calls, repeated initialization, bounded input, bounded arguments, invalid names and schemas, malformed JSON, and unknown methods.
8. Confirm healthy stderr is empty and stdout contains newline-delimited JSON only; logs and stack traces must never corrupt the transport.
9. Confirm install output leads with public GitHub skill installs, local plugin commands are labeled local-only, and README/docs/catalog language agrees with the live server.