Skip to main content
Glama

ExtensionDash

by io.github.tonic20
OverviewDiscussionsAdmin

Get keyword ranks

get_keyword_ranks
Read-onlyIdempotent

Daily search position history for an extension's tracked keywords, one series per term per store.

Every point carries the depth it was scanned to, because a position only means something against the size of the pool it came from: #1 of 9 and #1 of 50 are different results. A null position means we searched that deep and this extension was not in the results.

A term tracked in more than one store language comes back as one series per language — the same term is a different SERP in each.

Each series has a source. "store" is the store's own search. "google" is where the listing page ranks in Google: organic results only (ads and other blocks are not counted), top 50, desktop, in the keyword language's country (English: the United States). A null Google position means Google was searched 50 deep and the listing was not there.

Needs an ExtensionDash account: sign in from your app, e.g. claude mcp login extensions-dashboard or codex mcp login extensions-dashboard.

Input Schema

NameRequiredDescriptionDefault
daysNoHow far back to look. Defaults to 30.
termNoOne term. Omit for all of them.
storeNo
localeNoStore language, e.g. "de". Omit for every language. Canonicalised before use, so "DE" and "de" are one keyword and "pt-br" comes back as "pt-BR".
sourceNoStore search or Google. Omit for both.
extension_idYesFrom list_extensions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / source
      Added value: +{
+  "description": "Store search or Google. Omit for both.",
+  "enum": [
+    "store",
+    "google"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, and the description goes well beyond them: it explains that every point carries its scan depth, what a null position means for both store and Google sources, the exact Google ranking methodology (organic only, top 50, desktop, keyword-language country), and the multi-language series split. It also discloses the auth prerequisite with concrete login commands, which no annotation provides.

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?

Front-loaded with the core purpose in the first sentence, then organized into logical paragraphs covering depth/null, language, source, and auth. Slightly long and the paragraphs are not labeled, but nearly every sentence adds information an agent needs to interpret results correctly.

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 six parameters, no output schema, and a data model involving series, depth, nulls, languages, and two sources, the description carries exactly the burden it needs to: it describes the shape of the result, the meaning of missing values, and how to authenticate. Nothing an agent needs in order to call and interpret this correctly appears to be missing.

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

Parameters4/5

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

Schema coverage is 83%, so the baseline is 3, and the description adds real value on top: it defines what the 'source' enum values actually measure, explains that a term spanning multiple store languages yields one series per language (the semantics behind term/locale), and clarifies null-vs-depth semantics for the returned points. It leaves 'days' and 'store' to the schema, but those are already well documented there.

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 sentence states a specific verb and resource (daily search position history for tracked keywords) plus the cardinality of the result (one series per term per store). It is clear what the tool returns, but it never contrasts itself with the closely related siblings get_keyword_serp and get_metrics_history, so the agent must infer which one is the historical-rank tool.

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?

Usage is implied rather than stated: 'tracked keywords' hints that list_keywords/add_keyword are prerequisites, and the per-source explanation implies when the 'google' source is relevant. There is no explicit 'use this when... vs. use get_keyword_serp when...' routing, and no stated exclusions or prerequisites beyond the account requirement.

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

All ExtensionDash 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