Skip to content
Skillpedia
Agents40k · #5226

mcp-release-qa

Lets your agent test an MCP server before it's released. It checks if everything works as expected and documents the results.

What it does

Checks if an AI server (called MCP) is ready for public use. It tests if the server works as expected, if its information is accurate, and if it handles errors gracefully.

When to use it

  • ✓When you are about to release a new AI server.
  • ✓When reviewing an existing AI server.
  • ✓To ensure an AI server's documentation matches its actual behavior.

Example of what to ask your AI

“Verify that the 'my-cool-server' AI server is working correctly before release.”

Want more? Open the sections below.

How to use

The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.

Skill link

https://github.com/github/awesome-copilot/blob/main/skills/mcp-release-qa/SKILL.md

Ready-to-paste message

Use this skill to help me: https://github.com/github/awesome-copilot/blob/main/skills/mcp-release-qa/SKILL.md Read the SKILL.md file at that link and follow its instructions for my task.
How it works

The system runs the AI server, interacts with it as a user would, checks if it responds correctly, and verifies that its documentation (like what it does and how to use it) is accurate.

Installation

Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.

In the terminal (Claude Code, Codex, Cursor), in your project folder:

npx skills add github/awesome-copilot --skill mcp-release-qa

Or download just the file:

curl -L https://raw.githubusercontent.com/github/awesome-copilot/main/skills/mcp-release-qa/SKILL.md -o SKILL.md
Technical content (original SKILL.md)

Original text by the author, straight from GitHub.

MCP Release QA

Test the server that users will run. A schema review or a passing unit test is not runtime evidence.

This skill complements security review. It focuses on protocol behavior, published-contract drift, transport correctness, and reproducible release evidence.

Rules

  • Run checks against a fresh server process built from the candidate revision.
  • Keep initialize, notifications/initialized, discovery, and invocation in the same session. A new process is a new STDIO session.
  • Treat source registrations as implementation truth and public documentation as a contract that must match it.
  • Record exact commands and raw responses. Do not replace missing evidence with "looks correct."
  • Do not invoke mutation-capable tools against production data. Use fixtures, a sandbox, or stop and name the missing safe test environment.
  • Derive the expected capability inventory from the candidate source on every run.

1. Establish the release surface

Identify:

  • candidate commit and build command;
  • server entry point and transport: STDIO, Streamable HTTP, or SSE;
  • supported MCP protocol versions;
  • source files that register tools, resources, resource templates, and prompts;
  • generated catalogs, manifests, README tables, and install instructions;
  • existing protocol, integration, and smoke-test commands.

Prefer repository-native commands. Inspect package.json, pyproject.toml, Makefile, CI workflows, and contributor instructions before inventing a test harness.

2. Start a clean server

Build the candidate and start the documented entry point with test-safe configuration. Capture:

  • the exact command;
  • commit SHA;
  • environment variable names, with values redacted;
  • stdout, stderr, and exit status;
  • the endpoint or child-process transport used by the client.

For STDIO, stdout is protocol-only. Logs, banners, and stack traces belong on stderr. For HTTP transports, record the status, relevant MCP headers, and session identifier handling without printing credentials.

If the server cannot start from its documented instructions, report that as a release failure and preserve the startup error verbatim.

3. Exercise one complete session

Run this sequence through a real MCP client or the repository's integration harness:

  1. initialize with a protocol version the server claims to support.
  2. Confirm the negotiated version and advertised capabilities.
  3. Send notifications/initialized.
  4. Call ping.
  5. Call each supported discovery method:
    • tools/list
    • resources/list
    • resources/templates/list
    • prompts/list
  6. Exercise at least one representative read-only item from every advertised capability class.
  7. Follow pagination until no cursor remains when a list method is paginated.

Do not send post-initialization requests through separate one-shot processes. That accidentally tests several incomplete sessions instead of one valid session.

4. Prove inventory parity

Build four inventories from current evidence:

Surface Evidence
Source Registered tool, resource, template, and prompt definitions
Runtime Results from the live discovery methods
Generated metadata Catalogs, manifests, or generated indexes
Documentation README, reference pages, and install output

Compare by stable identifier. Report:

  • source entries missing at runtime;
  • runtime entries absent from metadata or documentation;
  • stale names, descriptions, arguments, URIs, or prompt parameters;
  • documented install commands that do not start the candidate server.

Regenerate derived files with the repository's own build command, then fail if the working tree still contains unexplained generated changes.

5. Check published contracts

For every discovered item, verify the runtime definition against its source:

Tools

  • Name and description are stable and specific.
  • inputSchema defines types, required fields, enums, and bounds where needed.
  • Unknown properties are rejected when the tool contract is closed.
  • Mutation, idempotence, read-only, and open-world annotations match behavior.
  • Successful calls conform to outputSchema when one is published.
  • Errors are protocol errors or structured tool failures, not leaked stack traces.

Resources and templates

  • URIs and MIME types match the registered definitions.
  • Static resources are readable.
  • Template parameters are validated before resolution.

…

FAQ

Why isn't just testing the code enough?

Testing code (unit tests) is important, but it doesn't guarantee the server will work correctly when real users interact with it. This test checks the server's actual behavior.

What is 'MCP'?

MCP is a type of protocol, a set of rules for communication between computer programs. In this context, it refers to an AI server using that protocol.

What are 'failure paths'?

These are situations where something goes wrong, like an incorrect command or an internal error. Testing these paths ensures the server handles errors properly and informs the user clearly.

Details

Original description by the author

Verify an MCP server before release by exercising a real protocol session, comparing runtime capabilities with source and documentation, testing failure paths, and recording reproducible evidence. Use when shipping or reviewing an MCP server, tool, resource, prompt, catalog, or install path.

repo: github/awesome-copilot

Popularity

GitHub stars
40k
Ranking position
#5226
License
MIT
Updated
10/15/2026

Is this skill useful?

0

Sign in to vote.

Comments

  • …

More skills from this repository

Similar skills