Mark

Run Rank Check

run_rank_check

Starts an on-demand rank refresh for tracked keywords, outside the weekly schedule. Checks the Google top 100 for each tracked keyword, 1 check per keyword in the tracker's location and language (scope.summary, like 12 keywords = 12 checks); results can take 20 minutes or more. Pass trackerId from get_rankings, or siteId to use that site's tracker. Related: get_rankings, save_keywords.

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": "run_rank_check"
  }
}

Input Schema

Name	Required	Description	Default
`siteId`	No	Site whose tracker to refresh. Defaults to the primary site.
`trackerId`	No	Rank tracker id from get_rankings.

Output Schema

Name	Required	Description
`run`	No
`scope`	No	What the run checks.
`state`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026

addedOutput schema / properties / scope

Added value: +{
+  "additionalProperties": false,
+  "description": "What the run checks.",
+  "properties": {
+    "summary": {
+      "description": "The same line the app shows beside the button.",
+      "type": "string"
+    },
+    "units": {
+      "description": "How many checks, pages or questions.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "units",
+    "summary"
+  ],
+  "type": "object"
+}

First observedOct 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations, which only cover safety and idempotency: it discloses the cost model (1 check per keyword, '12 keywords = 12 checks'), the scope (Google top 100, tracker's location and language), and the expected latency ('20 minutes or more'). This is exactly the operational context an agent needs before firing a slow, non-idempotent job.

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?

Front-loaded with the action and trigger, then cost/scope, then parameter routing and related tools. Dense but every clause carries information; nothing is padding.

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?

An output schema exists, so return values need not be explained. Combined with the annotations covering the safety profile and the description covering trigger, scope, cost, latency, and parameter routing, an agent has everything required to invoke 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 100%, so both parameters are already documented and the baseline is 3. The description adds real value on top: it explains the relationship between trackerId and siteId, and points to get_rankings as the source of trackerId, which the schema does not say.

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 and resource ('Starts an on-demand rank refresh for tracked keywords') and immediately scopes it against the recurring schedule ('outside the weekly schedule'). An agent can distinguish this from the nearby read tool get_rankings 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?

Clearly defines the trigger context (on-demand, outside the weekly schedule) and routes parameter choice ('Pass trackerId from get_rankings, or siteId to use that site's tracker'). Names related tools, but stops short of an explicit when-not-to-use or a direct 'use get_rankings instead when you only want to read' exclusion.

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

All Mark 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?