Skip to main content
Glama
CorgiCorner

Bisibility

by CorgiCorner
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get cost estimate

get_cost_estimate
Read-only

Estimate monthly rank-check volumes, result pages, and provider costs for a keyword portfolio by specifying keywords, markets, devices, depth, and frequency.

Instructions

Estimate rank checks, result pages, and monthly provider cost for a keyword portfolio. Provide keywords, markets (locations), devices (1-2), and depth (10, 20, 50, or 100; default 100). Frequency supports daily, weekly, monthly, manual, paused, and custom_cron with cron_expression. Missing or invalid custom cron leaves monthly quantities and costs unknown. Pick a provider (default dataforseo) and optionally an option or plan key; see get_provider_rates. Anonymous endpoint.

Input Schema

NameRequiredDescriptionDefault
planNoPlan-model provider plan key; unknown values use auto selection.
depthNoOrganic result depth. Defaults to Top 100.
optionNoFlat-rate provider option key, for example "standard", "priority", or "live".
devicesNoDevice count per keyword (1 or 2). Defaults to 1.
keywordsYesKeyword count to estimate for.
providerNoProvider rate card to use. Defaults to "dataforseo".
frequencyNoRank-check frequency used to estimate monthly checks. Defaults to daily.
locationsNoMarket count per keyword; each market combines a location and language. Defaults to 1.
cron_expressionNoCron expression for custom_cron; missing or invalid values leave monthly estimates unknown.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.17.1
    • addedInput schema / properties / cron_expression
      Added value: +{
+  "description": "Cron expression for custom_cron; missing or invalid values leave monthly estimates unknown.",
+  "maxLength": 120,
+  "type": "string"
+}
    • addedInput schema / properties / depth
      Added value: +{
+  "description": "Organic result depth. Defaults to Top 100.",
+  "enum": [
+    10,
+    20,
+    50,
+    100
+  ],
+  "type": "integer"
+}
    • changedInput schema / properties / frequency / enum
      Previous value: -[
-  "daily",
-  "weekly",
-  "monthly"
-]New value: +[
+  "daily",
+  "weekly",
+  "monthly",
+  "manual",
+  "paused",
+  "custom_cron"
+]
    • changedInput schema / properties / locations / description
      Previous value: -"Location count per keyword. Defaults to 1."New value: +"Market count per keyword; each market combines a location and language. Defaults to 1."
  2. First observedv0.6.1

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: it is an 'Anonymous endpoint' (no auth needed) and that a missing/invalid custom cron 'leaves monthly quantities and costs unknown', which tells the agent how failure degrades the response.

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 but front-loaded: purpose first, then inputs/defaults, then provider selection, then the anonymity note. It is close to the minimum length for a nine-parameter tool, with only mild redundancy against the schema.

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?

No output schema exists, yet the description names what is estimated (rank checks, result pages, monthly cost), the failure mode that leaves costs unknown, the default provider, and the companion tool for rate lookup. For a read-only anonymous estimator this is enough for an agent to call it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter is already documented. The description largely restates those facts (depth values, device limits, frequency enum, defaults) rather than adding new semantics, so the baseline 3 is appropriate; the only added nuance is the consequence of an invalid cron_expression, which the schema also states.

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?

Opens with a specific verb+resource+outcome: 'Estimate rank checks, result pages, and monthly provider cost for a keyword portfolio.' That distinguishes it in substance from siblings like estimate_keyword_research_cost or estimate_backlinks_cost, though it never names those siblings explicitly so an agent must infer the boundary from the resource named.

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?

It gives concrete required inputs and defaults and routes the agent to get_provider_rates for provider option/plan keys, which is genuine usage guidance. However, with four sibling 'estimate_*' tools in the list, it never states when to choose this estimator over the others, which is the main routing decision an agent faces.

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