Skip to main content
Glama
CorgiCorner

Bisibility

by CorgiCorner
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Run rank check

run_rank_check

Run a provider-backed rank check for one keyword to measure search position, with cost caps and immediate or queued results.

Instructions

Run a provider-backed rank check for one keyword. Requires write access and may incur provider cost. Ask for explicit user approval immediately before calling; this server cannot enforce the client's confirmation UI. The deployment selects inline or queued execution. A queued response contains an rcr_ run ID, not a check_ ID. Follow get_rank_history for that run_id until terminal, then use its check_ ID with get_rank_check_result. The async option only requests an early response. Set max_cost_cents to have the server refuse the check when its preflight estimate is higher.

Input Schema

NameRequiredDescriptionDefault
asyncNo
keyword_idYesIdentifier of the tracked keyword to operate on.
project_idNoIdentifier of the bisibility project to operate on; list_projects returns valid project ids.
provider_idNoSERP provider id, validated server-side. Known values: dataforseo and serpapi.
max_cost_centsNoServer-enforced maximum for the preflight cost estimate of this check, in cents.
idempotency_keyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.17.1
    • addedInput schema / properties / max_cost_cents
      Added value: +{
+  "description": "Server-enforced maximum for the preflight cost estimate of this check, in cents.",
+  "exclusiveMinimum": 0,
+  "maximum": 9007199254740991,
+  "type": "integer"
+}
  2. First observedv0.6.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only flag a non-read-only, open-world, non-destructive operation; the description goes well beyond them by disclosing that it incurs provider cost, requires explicit user approval because the server cannot enforce the confirmation UI, that execution mode is deployment-dependent, and that a queued response returns an rcr_ run ID rather than a check_ ID. These are exactly the behavioral traits annotations cannot express.

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 action, then packed with the approval requirement, execution-mode caveat, ID semantics, async caveat, and cost cap. Every sentence carries substantive information and nothing is padding, though the dense run-on paragraph could be broken up for faster scanning.

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?

For a mutating, cost-incurring tool with no output schema, the description covers what an agent needs: authorization requirements, cost containment via max_cost_cents, the shape of the response identifier, and the full downstream workflow. Nothing material is missing for correct invocation and follow-through.

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 67%, so the schema documents several parameters itself, but the description adds real meaning for the two least obvious ones: async 'only requests an early response,' and max_cost_cents causing the server to refuse the check when the preflight estimate exceeds it. The remaining parameters (keyword_id, project_id, provider_id, idempotency_key) get no extra treatment, so this is above the baseline but not exhaustive.

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 precise verb+resource with scope: 'Run a provider-backed rank check for one keyword.' An agent immediately distinguishes this initiation tool from siblings like get_rank_check_result (retrieval) and list_rank_check_runs (listing), and the description reinforces that distinction by naming those tools in the follow-up workflow.

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

Usage Guidelines5/5

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

Explicit about prerequisites (write access, user approval before calling), routing (use get_rank_history for the run_id, then get_rank_check_result with the check_ ID), and the conditional behavior of the async option. It tells the agent both when to call it and how to follow up, with no ambiguity left to inference.

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

Deploy Server

Other Tools