Skip to main content
Glama
search-console-mcp

search-console-mcp

by makashibk

query_segments

Read-only

Segment Google Search Console query data into branded vs non-branded, multilingual questions, query length, results-page, and chat-style groups to analyze search performance.

Instructions

Queries split into branded vs non-branded, questions (EN/NL/SV/PT/FR/DE), query length, results page, and chat-style fragments.

Input Schema

NameRequiredDescriptionDefault
daysNoDays ending yesterday (PT); ignored if start_date is given
siteYesProperty: 'sc-domain:example.com', 'https://www.example.com/' or 'example.com'
top_nNo
end_dateNoYYYY-MM-DD (Pacific Time)
start_dateNoYYYY-MM-DD (Pacific Time)
brand_termsNoBrand names/spellings; default = the property's brand_terms note
search_typeNoweb

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by disclosing the segmentation dimensions the tool computes, which is real behavioral context. However, it says nothing about aggregation, result limits (top_n), time-zone handling, or the brand_terms fallback to property notes.

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?

A single front-loaded sentence with no filler, and the segment list is the most information-dense part. The opening 'Queries split into' is slightly awkward phrasing but wastes no words.

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

Completeness2/5

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

With seven parameters, no output schema, and a multi-dimensional aggregation result, the description should explain the return shape and how the dimensions are grouped. It also omits date-range behavior (days vs start_date/end_date, Pacific Time) and the brand_terms default, leaving the agent under-informed about a non-trivial report tool.

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

Parameters2/5

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

Schema description coverage is 71%, with top_n and search_type carrying no description at all. The description mentions no parameter by name — not brand_terms (which drives the branded/non-branded split), not search_type, not top_n — so it adds essentially no meaning beyond the schema and leaves the undocumented parameters doubly unexplained.

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 names a concrete analysis ('Queries split into...') and enumerates the actual segment dimensions: branded vs non-branded, question queries with specific languages, query length, results page, and chat-style fragments. An agent can tell this is a query-segmentation report rather than a raw performance pull. It stops short of naming a sibling such as performance_query as the alternative, so it doesn't reach 5.

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

Usage Guidelines2/5

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

There is no when-to-use or when-not-to-use guidance and no mention of alternative tools. The agent must infer from the segment list that this is for query-intent analysis, but nothing says when to pick it over performance_query or find_opportunities.

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