Evidence and safety

Search Console MCP keeps provider semantics and evidence states explicit. Use these boundaries before turning a result into a recommendation or a write action.

The loop returns to observation. Confirmation permits one bounded request, not unrestricted automation.

Evidence states

• Observed: an API response or fetched public-page value returned for the stated target and window.
• Derived: a calculation based on observed values, with its input window and method attached.
• Requested: a provider accepted a submission request.
• Crawled: the provider later reports a fetch or crawl event.
• Indexed: the provider later reports the URL in its searchable index.

Requested, crawled, and indexed are different states. A successful submission is never reported as proof of indexation.

Provider boundaries

Google and Bing expose different metrics, scopes, delays, and position semantics. Compare directional evidence, not superficially similar field names. Keep the provider and observed window attached to every conclusion.

Guarded actions

Read tools can inspect verified properties and public pages. Write tools require an explicit target and bounded action. Before submitting anything, confirm the provider, site, URL set, action, and expected blast radius.

1. ReadCollect provider responses and public-page facts.
2. CompareKeep provider semantics and observed windows separate.
3. ExplainExpose limits, derived values, and remaining uncertainty.
4. ConfirmName one provider, target, action, and blast radius.
5. SubmitRecord the response, then measure later states separately.

Secrets

Keep credentials in the MCP server environment or the client configuration. Do not paste service-account JSON, OAuth tokens, Bing API keys, or IndexNow keys into prompts or public issue reports.

Continue with the installation guide or run a quick audit.