Webanto

List Search Console keywords

webanto_list_keywords

Read-onlyIdempotent

List the search queries from the organization's newest imported Google Search Console window: clicks, impressions, CTR, impression-weighted average position, movement against the previous window, and the page earning the most impressions. The opportunities view keeps queries averaging positions 8-20. Reads only imported data; no live Google call, no inference credits, no ranking guarantee. Check window.stale before relying on the numbers. Follow keywords.page.next_cursor while retaining the same filters.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

Name	Required	Description	Default
`sort`	No	change sorts the biggest climbers since the previous window first.	impressions
`view`	No	all: every query in the newest window. opportunities: queries averaging positions 8-20 with at least 3 impressions.	all
`cursor`	No	next_cursor from the previous page, retaining the same filters. Omit for the first page.
`search`	No	Case-insensitive substring filter on the query text.
`page_size`	No	Queries returned per page.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4/5.0

Behavior4/5

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the description scores better for adding disclosure beyond them beyond them: 'no live Google call, no inference credits, no ranking guarantee' tells the agent the data is a cached import, which explains staleness risk. The window.stale warning is a genuinely useful operational caveat.

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

Conciseness5/5

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

The description is front-loaded with the core action, then packs metrics, view semantics, data-provenance caveats, and pagination into three tight sentences with no filler. The only redundancy is with the schema, not with itself.

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

Completeness4/5

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

An output schema exists, so the description safely omits return-shape detail, though it still summarizes the metrics. It covers provenance, staleness, and pagination, which are the operational risks for a read of imported data. It is slightly thin on prerequisites, such as what the agent sees when no import exists or how the organization's connection state affects results.

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%, so all five parameters are already documented in the schema, including the enum meanings for view and sort. The description restates the opportunities band (positions 8-20) and the cursor rule ('retaining the same filters') but adds no new syntax, constraints, or edge-case behavior beyond them. This matches the baseline of 3 for a fully documented schema.

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 description opens with a specific verb and resource: 'List the search queries from the organization's newest imported Google Search Console window,' and then names the metrics returned (clicks, impressions, CTR, impression-weighted position, movement, best page). That is far more specific than a restatement of the name. It loses the top score because it never distinguishes itself from the sibling webanto_list_search_console_opportunities; it only explains the 'opportunities' view parameter, which leaves some ambiguity about which tool to choose.

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

Usage Guidelines4/5

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

It gives clear conditions for use: it reads only the newest imported window, the opportunities view filters to queries at positions 8-20, the agent must check window.stale before trusting the numbers, and pagination continues through keywords.page.next_cursor while retaining the same filters. What is missing is explicit routing: no 'use this instead of X' and no stated prerequisite for what happens when no GSC import exists.

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

All Webanto tools Inspect

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

Need Help?