Agent skill · every-app
verify-local-mcp
Verify the OpenSEO MCP server end-to-end on a local dev server — protocol-level correctness against real DataForSEO, then a headless-agent consumer probe that tests tool ergonomics (descriptions, schemas, output size, errors, async flows) without the maintainer manually driving an MCP client. Use after adding or changing MCP tools, or when asked to check that the MCP "works" or "is ergonomic".
What it needs
About 3k tokens when loaded.
What this skill does
Verify local MCP Two layers, in order. The protocol layer proves the server and provider behave; the consumer layer proves an agent that has never seen the code can use the tools well. They catch different bugs — protocol testing found DataForSEO quirks (zoom-dependent empty SERPs), the consumer probe found ergonomics failures (9KB provider rows overflowing client token budgets, fractional inputs rejected upstream with raw provider errors). Do both. 1. Boot .env.local needs AUTHMODE=localnoauth and DATAFORSEOAPIKEY (base64 of login:password). Never print the key. Start pnpm dev:agents in the background. The server URL is branch-prefixed: http://<branch-suffix>.open-seo.localhost:1355 (the exact URL is printed on boot; logs tee to .logs/dev-server.log). With localnoauth, /mcp needs no token. Vite hot-reloads server code, so fix → re-call without restarting. 2. Protocol smoke (cheap, deterministic) Raw JSON-RPC against /mcp — the layer for asserting exact shapes and driving edge cases (resume taskIds, empty results, invalid inputs): Bootstrap: listprojects, then createproject if empty — most tools need a projectId. Test the happy path AND at least one edge per changed tool: an empty result (obscure query), an invalid identifier, and for queued tools the full lifecycle including resuming with the returned taskId. These are real, billed DataForSEO calls (metering itself short-circuits in localnoauth — billing needs unit tests, not this). Keep depths 10–20. 3. Consumer probe (the ergonomics test) Spawn a headless Claude subprocess connected as a real MCP client. Write a config: Then run a NATURAL task — never name the tools; whether the model finds them from descriptions alone is the test: Use --model sonnet as the typical-client proxy — if sonnet navigates it cold, weaker clients likely can too. Read FINDINGS for correctness (did it get real, sensible data?) and MCP FEEDBACK for the rubric below. 4. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills every-app/verify-local-mcp