mcp-website-traffic-rank-estimator

Estimate Website Traffic Rank

estimate_website_traffic_rank

Read-onlyIdempotent

Return a research-grade Tranco popularity rank for a company domain, with date, band, and rising/falling/stable trend, not traffic visits or visit counts.

Instructions

Return a research grade popularity RANK for a company domain from the public Tranco list, with the date of that rank, an honest band (top_1k through beyond_1m) and a rising, falling or stable trend over roughly forty daily observations. Returns one flat Clay ready row. THESE ARE RANKS, NOT TRAFFIC: a rank does not convert to visits and this tool will never return a visit count. A lower rank number is better, so the trend is given in words rather than as a signed number. Most B2B domains are not on the list at all and return not_found, which is normal rather than disqualifying. Read only; requires an APIFY_TOKEN and consumes Apify credits per call.

Input Schema

Name	Required	Description
`minRank`	No	Sets rank_meets_threshold on the row, so you can filter a list to established sites without writing the comparison yourself. It never drops a row and never changes the rank returned. Sent as a string for Clay compatibility.
`sources`	No	Which rank sources to query. Tranco is free and needs no key. Cloudflare Radar and Chrome UX Report each need your own free key, and a source you did not supply a key for reports "skipped" rather than "not found", because we did not look. Sent as a string for Clay compatibility.
`skipCache`	No	When "false" (default) a successful lookup is cached for seven days and reused, which costs you nothing on a repeated run. Set "true" to force a fresh fetch. Sent as a string for Clay compatibility.
`cruxApiKey`	No	YOUR OWN Google API key with the Chrome UX Report API enabled, free at console.cloud.google.com. OPTIONAL and only used when sources includes CrUX. Marked secret, so the value never renders on this page.
`company_name`	No	Optional. Carried through to the output row for joining. Rank lookup is keyed on the domain alone, so the name does not change the answer.
`includeTrend`	No	When "true" (default) the rank history Tranco already returns is used to say whether the domain is rising, falling or stable. It costs nothing extra: the history arrives in the same response. Sent as a string for Clay compatibility.
`company_domain`	No	Bare company domain, for example stripe.com. This is the only required input and it is the join key for every other actor in the fleet.
`cloudflareApiToken`	No	YOUR OWN Cloudflare API token, free to create at dash.cloudflare.com. OPTIONAL and only used when sources includes Radar. Marked secret, so the value never renders on this page.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.1.1Oct 14, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / minRank / enum

Previous value: -[
-  "none",
-  "1000",
-  "10000",
-  "100000",
-  "1000000"
-]New value: +[
+  "1000",
+  "10000",
+  "100000",
+  "1000000",
+  "none"
+]

First observedv1.0.0Sep 8, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing credit consumption per call, seven-day caching behavior, that unsupplied sources report 'skipped' rather than 'not_found', and that the trend is rendered in words because a lower rank number is better. These are exactly the non-obvious behaviors an agent needs.

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?

The core deliverable and its key caveat (ranks, not traffic) are front-loaded, and nearly every sentence carries information an agent could not infer. It is dense and slightly repetitive in restating the Clay compatibility and caching themes already covered in the schema, which keeps it short of a 5.

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 an eight-parameter tool with no output schema, the description fully specifies the return shape (one flat Clay-ready row with rank, date, band, and trend), the not_found outcome, and the auth/credit requirements. An agent can call and interpret this correctly with no further information.

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 the schema already carries full parameter semantics, including the minRank threshold, source skipping, and caching flags. The description adds interpretive context (rank is not traffic, lower is better, not_found is normal) but no per-parameter detail beyond the schema, so the baseline 3 applies.

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 ('Return a research grade popularity RANK for a company domain from the public Tranco list') and explicitly delimits scope by declaring what it is not ('THESE ARE RANKS, NOT TRAFFIC... will never return a visit count'). An agent knows exactly what this tool produces without opening the 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 clear operating context: read only, requires APIFY_TOKEN, consumes credits per call, and that most B2B domains legitimately return not_found rather than indicating an error. There are no sibling tools to route against, so no explicit alternatives are needed, but it stops short of stating when a caller should prefer this over simply skipping the check.

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

estimate_website_traffic_rankA