mcp-website-traffic-rank-estimator
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | Your Apify API token. Get it at https://console.apify.com/account/integrations |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| estimate_website_traffic_rankA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
There is only one tool, so no misselection is possible. Its purpose is stated precisely and even disambiguates itself from a common confusion (ranks vs. visit counts).
The single tool uses a clear snake_case verb_noun pattern (estimate_website_traffic_rank) that matches the server name. No competing conventions exist to conflict with it.
One tool is defensible for a deliberately narrow, single-operation microservice (fetch a rank for a domain). It is slightly thin in that there is no batch or multi-domain variant, which would be natural for research use.
The single operation returns everything the stated domain requires: rank, observation date, band, trend, and an explicit not_found outcome, with read-only scope acknowledged. The only gap is bulk/batch lookup for comparing many domains at once.