Skip to main content
Glama

seodraft

by app.seodraft
OverviewDiscussionsAdmin

Refresh topic metrics

refresh_metrics
Destructive

Re-measure Google volume, AI search volume and intent for topics already in the topic bank. This is the only way to refresh measured metrics, and it is always a batch: three requests total, about USD 0.11 for the whole run whether you pass 1 term or 200. Priced per batch, not per term. Terms beyond 200 are dropped and reported as overflow. refreshed counts the terms DataForSEO actually answered for and unmeasured names the rest. The run is refused before spending, with degraded: true and reason: spend-limit, when its estimate would break the per-run or rolling 24h ceiling; the spend object carries the estimate, the ceiling and what was already spent in the window, and nothing is charged. archived names terms dropped before anything was priced because their topic is retired; they are never re-measured, so no money is spent on them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
termsYes
workspaceIdNoThe workspace this call acts on, as listed by list_workspaces. Left out, the call uses the workspace the account is in right now.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / workspaceId
      Added value: +{
+  "description": "The workspace this call acts on, as listed by list_workspaces. Left out, the call uses the workspace the account is in right now.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations (which only flag destructive/expensive/non-idempotent) by disclosing concrete cost (~USD 0.11 per batch, priced per batch not per term), the 200-term overflow drop, the pre-spend refusal path with degraded:true and reason:spend-limit, and that archived terms are dropped before pricing so nothing is charged. This is exactly the operational context an agent needs before committing spend.

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?

Dense and fairly long, but front-loaded with the action and cost, then layered with constraints; each sentence carries distinct operational information. No filler or repetition, though it could be tightened slightly.

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 no output schema, the description still explains the meaningful return fields (refreshed, unmeasured, archived, spend object, degraded) and the failure semantics. Combined with the cost and cap rules, an agent has everything needed to call this correctly.

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 50% (terms has no schema description), and the description compensates by defining what terms are measured, that the batch is capped at 200 with overflow reported, and how refreshed/unmeasured partition the input. workspaceId is left to the schema, so it isn't fully covered, but the description adds real meaning over the schema.

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

Purpose5/5

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

States a specific verb (re-measure) plus the exact resources measured (Google volume, AI search volume, intent) and the scope (topics already in the topic bank), and explicitly contrasts itself with the sibling family by being 'the only way to refresh measured metrics.' An agent can distinguish this from research_topic/add_topics without opening a schema.

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?

Gives a clear usage condition ('only way to refresh measured metrics') and a hard prerequisite/caveat set: always batch, 200-term cap, spend-ceiling refusal, archived terms never re-measured. It does not name the alternative tool to use for brand-new topics, so the when-not boundary is implied rather than stated.

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

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