Cookbook
Recipes for the jobs people bring to the MCP server - each one a tool order that works, and the reading it depends on.
Most tools carry their own instructions about what to call next, and an assistant following them will usually get the sequence right on its own. These recipes are the paths worth knowing anyway, so you can tell whether yours is on track - and, where the order matters for a reason the tool cannot state on its own page, why it is that order.
Each recipe names the job, the sequence, and the way it is most often misread. Nothing here is required: they compose, and a session usually walks two or three of them.
Search performance
Read a site's search performance
The baseline read - what a site is doing now, and against what.
Diagnose a traffic drop
From 'clicks are down' to a cause, and the action each cause implies.
Turn findings into one work queue
Answer 'what should I work on' with everything priced in clicks.
Decide what to write next
Demand you are visible for and losing, versus demand you have no page for.
Brand & competitors
Reporting
Read this before any of them
A missing row is not always a zero
Google compacts each single-dimension breakdown to roughly the top 5,000
rows per day once a day is a few days old, and Bing's traffic feeds are
top-N by nature. Above those ceilings a query's absence stops being evidence
that it got no traffic. The tools detect this per request and report it in
unsupportedInputs rather than quietly returning a short list - read that
field before treating an empty result as a finding.
Two more habits that save a wrong answer later:
- Call
get_server_statusonce at the start of a session. It reports the tools schema version, so a client holding a stale tool list finds out before it builds arguments against it. - Check the connection before concluding a site is quiet.
get_connection_statussays whether Google and Bing are actually attached and how fresh each one is. An unsynced engine and a dead engine look identical in every number downstream.