Skip to main content
Glama
Sign In

pageaudit

by online.pageaudit
OverviewDiscussionsAdmin

Search console

search_console
Read-onlyIdempotent

Read own-site keywords, opportunities at average positions 4–20, up to 20 tracked queries and daily history. Check dates, partial coverage and collection failure before proposing edits. These are not market search volumes. The sample covers 28 days, at most 50 queries and 50 pages. Use queries for keyword research and opportunities for average positions 4–20. The terms array adds daily history and 7-day comparisons for up to 20 selected queries. Coverage is partial: impressions are for this property, not market search volume. Positions are impression-weighted averages, not fixed SERP ranks. Credentials and raw provider responses are not returned. Returns: { available, connected, property, last_attempt_at, last_success_at, next_run_at, error, stale, snapshot{property,period,checked_at,queries,pages,coverage}, opportunities[{query,clicks,impressions,ctr,position}], terms[{query,last_alert_at,analysis,series}] } Example: await fetch("$ORIGIN/api/sites/SITE_ID/search-console").then(r => r.json()); Errors: 401: account_required or session_ended; 403: account_required or invalid_csrf; 404: site_not_found; 503: sites_unavailable

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "search_console"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesSite ID from list_sites or add_site.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Added

TDQS

A4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly/idempotent/closed-world, and the description still adds substantial context: the 28-day window with 50-query/50-page caps, partial coverage, impression-weighted rather than fixed positions, exclusion of credentials and raw provider responses, staleness fields (last_attempt_at, stale, error), and a full error-code table. This is well beyond what the annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Information is front-loaded with what you get and the sampling limits before the return shape and errors. Some material is repeated ('not market search volume' appears twice, 'positions 4–20' twice) and the inline fetch example adds noise for an agent that only needs the parameter and semantics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one parameter and no output schema, the description compensates fully by enumerating the return object's fields, the sampling window, staleness signals, and 401/403/404/503 failure modes. An agent has everything needed to call it and interpret the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single 'id' parameter is documented in-schema as coming from list_sites or add_site. The description says nothing further about the identifier, so the baseline 3 applies when the schema carries the full parameter burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause names a specific resource (own-site keywords, opportunities at positions 4–20, tracked queries, daily history) and the scoping limits (28 days, 50 queries/pages) make clear this is a read of the property's Search Console data. It is distinct in substance from sync_search_console or connect_search_console, but it never names a sibling to contrast with, so differentiation must be inferred from the verb alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives conditional guidance: check dates, partial coverage and collection failure before proposing edits, and use 'queries' for keyword research versus 'opportunities' for positions 4–20. However, those two names refer to response arrays rather than sibling tools, and there is no guidance on when to call sync_search_console first or when another tool (e.g. track_search_queries) is the better choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All pageaudit toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources