Skip to main content
Unlisted page
This page is unlisted. Search engines will not index it, and only users having a direct link can access it.

How we test these guides

Each guide that has code has an example folder at docs/guides-examples/<slug>/. A test.sh script in that folder builds the example, starts it, and checks it with the MCP Inspector CLI. Most of the code shown on a guide page is embedded directly from those files, so the page shows what the test ran.

MCPBundles publishes these guides.

What a test checks​

Every test.sh runs the MCP Inspector CLI in --cli mode, pinned to version 2.11.0. It does not start the Inspector web UI.

Each test lists the server's tools twice:

  • --protocol-era modern uses the 2026-07-28 revision of the MCP spec.
  • --protocol-era legacy uses the 2025-era initialize handshake, which older clients still send.

When an SDK does not support the 2026-07-28 revision yet, the guide says so and its test runs the legacy era only. The expected tool names must appear in every list. Then at least one tool is called and its output is checked with grep. The test fails if the expected text is missing.

The checks go further in some examples:

  • build-mcp-server builds the Python and TypeScript servers and runs them over stdio. It saves a bookmark, then searches for it.
  • deploy-remote-mcp-server starts each server on localhost over Streamable HTTP. It checks the /health endpoint, checks that a request with an unknown Host header is rejected, then runs the same tool list and tool call checks.
  • sandbox-local-servers builds the server into a container that runs with no network, a read-only root filesystem, all Linux capabilities dropped, and memory, CPU and process limits. The test checks that the server runs as uid 10001, holds no capabilities, cannot write to the root filesystem, and has no network interface.
  • package-mcpb validates, packs and unpacks an .mcpb bundle. It checks that the unpacked bundle contains the manifest and server entry point, then runs the server from the unpacked files.
  • codex parses each example Codex config as TOML. It checks that every server table has exactly one of command (stdio) or url (Streamable HTTP).

A test passes only when every step in its script succeeds.

Versions on each guide​

Each guide lists the versions it was tested with under the "Tested with" line, along with the date it was last checked. We record a version only if we ran it or confirmed it in an official source on that date.

Example dependencies are pinned in each example's package.json or pyproject.toml, and the Inspector version is pinned in each test.sh.

Sources​

Each guide's frontmatter lists the official pages its claims come from: the MCP spec and modelcontextprotocol.io, SDK documentation and package registries, and the AI app's own docs. When two sources disagree, the newer official source is used.

When tests run​

The tests run when a guide is written and again whenever its example or the guide is updated. When a guide is re-checked, its last-checked date is updated.

What the tests do not cover​

  • Config-only guides. Guides for AI apps such as Cursor, Claude Desktop and VS Code save their config files in the example folder. The tests check that those files parse, where a test exists, but do not open the apps.
  • Desktop app screens. Steps inside desktop apps are described from each app's own documentation. We do not test those screens.