Provides tools for checking a domain's live Google organic search rankings, including position, ranking URL, and top 10 results for a given keyword and country market.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@io.github.epolat/rankjot-mcp where does example.com rank for best running shoes in the UK?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Real Google rankings as a tool for AI assistants. Ask Claude (or any MCP client) "where does example.com rank for best running shoes in the UK?" and it makes a live lookup instead of guessing.
One tool:
check_rank(domain, keyword, country="us") returns
position: the domain's 1-based Google organic position, or null if it isn't
in the results checked
url: which of the domain's pages ranks
results: the top 10 organic results (position, domain, url, title), so the
assistant can answer "who's above me?" without another call
quota: lookups used and remaining this month
Positions are organic results only (ads, maps and answer boxes aren't counted),
for the Google market you pass as country.
Related MCP server: SE Ranking MCP Server
1. Get an API key. Sign in at rankjot.com, open Account → API access → Generate key. Free accounts include 25 lookups a month; the API plan ($20/mo) includes 5,000.
2. Add the server to your client. It runs with uvx,
so there's nothing to install by hand.
Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"rankjot": {
"command": "uvx",
"args": ["rankjot-mcp"],
"env": { "RANKJOT_API_KEY": "rjk_your_key_here" }
}
}
}Any other client that launches stdio servers takes the same command, uvx rankjot-mcp, with RANKJOT_API_KEY in its environment.
Prefer pip? pip install rankjot-mcp, then use rankjot-mcp as the command.
3. Restart the client and ask a ranking question.
Failures come back as a normal result with an error field, so the assistant can
tell you what happened instead of retrying blindly:
| Meaning |
|
|
| The key is wrong or was revoked |
| This month's included lookups are used up |
| Monthly quota used, or too many calls per minute |
| The lookup couldn't be made; try again |
Every call spends one lookup. Models are happy to call tools in loops, so if you ask about many keywords at once, say how many lookups it may use.
The domain, keyword and country you check are sent to rankjot.com to perform the lookup. See the privacy policy.
API reference: https://rankjot.com/api-docs
How this server was designed: https://rankjot.com/blog/google-rankings-as-an-mcp-tool
MIT
Check where a domain ranks on Google for a keyword.
Args: domain: the site to look up, e.g. "example.com" (scheme/www/path ignored). keyword: the search query to rank for. country: ISO country code for the Google market (default "us"), e.g. "gb", "de". Rankings differ by country, so pass the market the user cares about.
Returns a dict with the 1-based position (null if the domain isn't in the
results checked), the ranking url, the top-10 organic results, and the
remaining quota. Failures come back as a dict with an error field.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| country | No | us | |
| keyword | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and covers key behavior: input normalization ('scheme/www/path ignored'), the exact return shape including 'position', 'url', 'results', and 'quota', and failure behavior via an 'error' field. It does not explicitly state that this is a read-only operation, but 'check' plus the described output strongly implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured: a one-sentence summary, an Args block covering each parameter with examples, and a return-shape paragraph. No sentence is redundant, and the most important scoping facts are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description fully specifies what the tool returns, including the null position case and failure dict. It also states the scope ('top-10 organic results') and quota reporting, so an agent can invoke and interpret the result correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain each parameter, and it does: domain is exemplified and normalized, keyword is defined as the search query, and country is given with ISO format, a default, and market-dependence rationale. All three parameters are meaningfully documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence, 'Check where a domain ranks on Google for a keyword,' uses a specific verb, resource, and search context. It clearly distinguishes the tool's function even without sibling tools to differentiate from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives actionable usage context: 'Rankings differ by country, so pass the market the user cares about,' which tells the agent how to set the country parameter based on user intent. It does not mention alternatives, but no siblings exist, so exclusion guidance is not needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_rankScored across 1 tool
With only a single tool, there is no possibility of overlap or confusion about which tool to invoke. The tool's purpose is well-defined and unambiguous.
The tool name 'check_rank' uses a clear verb_noun snake_case convention. Although there is no comparison set, the naming is internally consistent and predictable.
The server is narrowly scoped to a single rank-checking operation, so one tool is serviceable. However, related features like batch ranking checks or quota status would strengthen the server, making the count slightly thin.
The tool covers the core 'check rank' operation completely and returns relevant data. The lack of batch operations, historical tracking, or multi-keyword support leaves a notable gap for a rank-checking service.
SEO data for Google keywords, domains, backlinks and AI visibility. Pay per lookup, no subscription.
Search Google straight from your AI agent. Web results, images, videos, news, products, scholarly ar
SEO research, audits, backlinks, GSC, and content workflow tools for AI agents.
Real-time web search for AI agents: ranked results, source URLs, and optional AI answers.
