How we test

Status definitions

Researched: each tool was confirmed to exist through vendor docs or a public repo. Not tested.
In testing: the protocol below is under way.
Tested (with date): the protocol is complete and the test log is published.
Re-test due: the 90-day re-test (or a re-test after a breaking vendor change) is overdue.
Deprecated: no longer recommended.

Accounts. Vendor sandbox or test accounts where they exist. Never real customer data. A separate test tenant for each stack.
Client matrix. At least one mainstream MCP client, with name and version recorded.
Install check. Time from zero to first successful tool call using only vendor docs; undocumented steps recorded.
Workflow scripts. Each automated workflow gets a written prompt, expected tool calls and expected result, run 3 times and recorded as pass, partial or fail.
Read first, write gated. Read-only scripts first. Writes only in a sandbox with an explicit confirm step; we record whether the server or client enforced it.
Failure modes. A bad input, an expired token and a missing permission; we record whether the error was clear.
Security. We do not run our own audit. We record Canopii and VerifyMCP scores with the date and review permission scopes.
Cost. Plan tier and price from each vendor pricing page, with the date. A stack cost appears only when every tool price is recorded.
Publish. Status becomes Tested and the test log is published.
Re-test. Every 90 days, or within 14 days of a breaking vendor change.

We don't run security audits. For that we link to Canopii and VerifyMCP.