How to test an MCP server before you rely on it
To test an MCP server, check four layers in order: the connection, each tool with good and bad input, the error paths and limits, and a live run against the real service. Wield's server, wield-mcp, has five tools, so the list is short. Start with npx -y wield-mcp doctor, then call each tool once. A failed live run is a finding to read, not a reason to guess.
What to test
The Model Context Protocol specification defines how a client discovers a server's tools and calls them. Each tool has a name, an input schema and a result. Test all five Wield tools:
| Tool | Input to test | A good result |
|---|---|---|
find_recipe | task of 1 to 300 characters, optional site, limit from 1 to 10 | Ranked results with recipe_id, params_schema and effect. A hint when nothing matches |
run | recipe_id, params that match params_schema, optional version | ok: true with output, or an error with a code and a hint |
list_sites | none | Sites and recipes, with logged_in set to true, false or null |
status | none | executor online, registry reachable, telemetry state, signatures verified |
request_recipe | site, task up to 300 characters, mode set to request or record | A request logged, or a recipe_id in record mode |
Layer 1: the connection
Run the doctor first. It checks Node, the bridge, each browser's registration, the extension's connection and version, recipes, signatures, your account and your AI apps. It prints a fix for each problem it finds.
Then call status. You want executor online and signatures verified. If executor is offline, the browser is closed or the extension is not running.
Layer 2: good and bad input
Test each tool with input that should work and input that should fail:
find_recipewith an empty task, a 301-character task andlimit: 11. Each should fail before any search runs.runwith a missing required param, and with a param of the wrong type. The result should beinvalid_params, and nothing should be sent to the site.runwith a validrecipe_idand params. Check that the defaults from the schema were filled in.
Layer 3: errors and limits
Each error has a code and a hint. Check that the hint tells the agent what to do next:
| Code | How to trigger it | Expected behavior |
|---|---|---|
login_required | Run a login recipe while logged out | The result carries a login_url. The agent asks you to log in |
confirmation_denied | Run a write recipe and deny its Allow window | Nothing is sent. Use a test account for write tests |
origin_blocked | Not reproducible by hand; check the logs | Nothing is sent, and the agent does not retry |
recipe_unsigned | Not reproducible by hand | Nothing is sent. The agent reports it and does not retry |
limit_exceeded | Run a site more often than its hourly pacing allows | The message gives the wait time |
Limits to confirm: 12 steps, 40 requests, 5 MB per response and 60 seconds per run. Time you spend on an Allow window does not count toward the 60 seconds.
Layer 4: a live check
Run npx -y wield-mcp check. It makes one live, read-only sample through your browser and ends with "Wield is ready" when it works. Then run npx -y wield-mcp speed --runs 10, which times find_recipe and run the way an agent calls them, with p50 and p90 for read recipes.
Open the executor log after a test. It lives at ~/.wield/logs/executor-YYYY-MM-DD.ndjson. It shows each request's method, host, path, status and time. It holds no bodies, no query values and no results, so you can confirm what was sent.
Testing a recipe
Recipe authors add a verify block to each recipe, with example_params and checks written as JMESPath expressions over the output. Run the recipe with its example params before you publish it. See the recipe format.
FAQ
Can I test without a live site?
Use the schema checks in layer 2 and the error table in layer 3. Live behavior needs a live site, and public recipes change when sites change.
Can I test without an AI app?
Yes. npx -y wield-mcp demo runs three sites from the terminal and prints every host your computer contacted. Any MCP client or SDK can call the five tools directly.
Should I test write recipes on a real account?
Test writes only on an account you can afford to change, and deny the Allow window when you test the denial path. Every write needs your click.
Sources
- Model Context Protocol specificationmodelcontextprotocol.io