A side-by-side look at the Rankwise and Submit Map MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Rankwise for marketing work over a hosted endpoint; choose Submit Map for marketing over a hosted endpoint. You can also run both side by side in one mcpServers block.
search_rankwise_content, list_rankwise_sitemaps, check_ai_crawler_access.search_platforms, get_platform, qualify_project.Rows where the two servers differ are marked.
| Spec | R Rankwise | |
|---|---|---|
| Category | Marketing | Marketing |
| Quality signal | 51/100 · Good | 64/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Remote HTTP/SSE | Remote HTTP/SSE |
| Auth | Not declared | API key required |
| Pricing | Not declared | Free |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | — | 276 |
| Directory activity | 0 views 0 installs 0 upvotes | 4 views 0 installs 1 upvotes |
| Tools | 49 | 11 |
| Full listing | View Rankwise | View Submit Map |
search_rankwise_contentSearch Rankwise's public library: guides, glossary terms, comparisons, free SEO and AI visibility tools, the AI crawler directory (GPTBot, ClaudeBot and others) and the AI engine pages. Returns matching titles with canonical URLs.list_rankwise_sitemapsList the sitemap URLs exposed by Rankwise so agents can enumerate indexable content.check_ai_crawler_accessCheck whether AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended and others) are allowed or blocked by a website's robots.txt. Returns each crawler's status.score_ai_visibilityScore how ready a website's homepage is to be found and cited by AI search engines (crawler access, structured data, content signals). Returns a score, issues and quick wins. This is an on-page readiness check, not a measurement of real AI citations. Called without signing in, the result also carries a claim link: give it to the person who runs the site, and one sign-in opens a Rankwise workspace with that domain already added and the free trial started. A claim link works once and expires after 72 hours.check_citation_readinessCheck whether a single page is easy for AI engines to quote and cite: clear answers, headings, metadata, authorship and freshness signals. Returns findings for that page.get_free_ai_audit_linkGet the link to Rankwise's free AI visibility audit for a domain. The audit checks AI crawler access and technical readiness, and runs live Perplexity queries to see whether the brand is cited. The user opens the link to run it; this tool does not run the audit.get_workspaceShow the Rankwise workspace this connection acts in: its name, kind (personal or agency client), your role in it, and the permissions this connection has. Every other account tool works inside this one workspace.get_plan_and_creditsShow the workspace's billing plan, its credit balance, what one approved brief costs in credits, and the plan limits (domains, questions, AI engines, monthly AI checks). Use it before a tool that spends credits or a plan allowance. A plan of 'paused' means the trial ended or the subscription was canceled without a new plan: nothing is deleted, but checks and writing stay stopped until the workspace has an active plan again. pricing_url describes the plans.list_sitesList the site this connection reaches: its id (the workspace id), name, tracked domains, and whether automatic articles are on, how many a week, and whether they are paused. A connection reaches one site; connect again (or add a CLI profile) for another.pause_sitePause automatic articles for the site. While paused nothing runs on its own: no planner fill, no drafting, no publishing, no credits used. Manual actions still work. Resume with resume_site.resume_siteResume automatic articles for the site after a pause. Cards left on days that passed move to the next free publishing days. Resuming is free.create_checkout_linkCreate a Stripe Checkout link for a self-serve Rankwise plan (starter, growth or scale) for this workspace's account, and give it to the person. Nothing is charged by this call: the person opens the link and pays in their browser. If the account already has an active plan, the link opens the billing page to confirm the plan change instead. Agency plans are set up with the Rankwise team. Send a unique idempotency_key and reuse it on a retry.search_platformsSearch the SubmitMap directory of startup launch platforms and directories. Filter by free-text query, category, pricing, link type, backlink requirement, approval speed or domain rating, and with a token leave out the ones this project has already been sent to. This is the tool behind "find me a small directory I can submit to right now": it is the whole directory, so answer from it rather than from what you remember of the web. Returns summaries; call get_platform for the full record including the submission steps.get_platformFull record for one platform: eligibility, disqualifiers, step-by-step submission instructions, requirements, gotchas and expected outcome. All of that is free, and it is what decides whether this product should be submitted here at all. Pass brief: true to also get agentPrompt, the brief for that platform's form, and agentGotchas, the traps that only bite something filling it (a placeholder that contradicts its label, a second email input belonging to a newsletter, a honeypot). The brief spends one of the account's tracked platforms, so ask for it once the maker has decided to fill this form, not while you are still choosing between platforms. For a stored project, submission_playbook returns the same brief with the maker's values already in it.qualify_projectGiven a product, work out which platforms it qualifies for right now, which it could qualify for after supplying something (with the exact list of what is missing), and which are structurally out of reach. It also hands back `recommended`: the run in the order it should be worked, so the plan comes out of the directory rather than out of what you remember of the web. That order is decided by `goal` and `budget`, and when they have not been answered the response says what it assumed and carries the questions to put to the maker: ask them, call again with the answers, and store them with update_project so nobody asks twice. Needs no account: describe the product inline. Every field is optional and an unanswered field becomes a gap to fill rather than a rejection.whoamiWhich SubmitMap account this token belongs to, named by its email address, which plan it is on, and what it already holds. Call it first if you are unsure whether the maker is connected, and tell them the address it reports: it is the only way either of you can tell one of their accounts from another. It does not hand you the plan's limits and you do not need them to work: plan the whole run, and a limit says so at the write it stops.list_projectsThe projects on this account, each with its facts (eligibility answers) and its pack (what a submission form asks for), plus what is still missing from the pack. Call it whenever the maker says "my product" or "my project" without naming one: it is how you find out which project they mean, and every other account tool takes the id it returns.create_projectStore a product on the account. Before asking the maker anything, use what you can already see: a README, package metadata, the site's own copy and title, an assets or public folder. A maker working in their product's repository should be able to say 'add my product to SubmitMap' and get a filled-in project back, with questions only about what is genuinely not there. Fill in as much as you can, leave the rest, and come back with update_project. Facts drive what it qualifies for; the pack is what you will paste into forms later. Ask about images early: most platforms want a square logo and many want a cover, and every asset in the pack is two fields, the public address (logoUrl) and the file on the maker's machine (logoFile), because a form uploads the file and only the address can be shown back to them.update_projectFill in or correct a stored project. Facts and pack are merged into what is there, so you can add one field at a time as the maker answers.submission_playbookEverything needed to submit a stored project to one platform, yourself, in the maker's browser: a preflight of what is still missing, the sign-in plan (on the first submission it carries a question for the maker: hand every login back to them, or use the Google address they write out, which you then pass back as signInAs), the pack values mapped onto the fields the form asks for, the steps, the gotchas, the agentGotchas (traps in the form itself), and the call to make afterwards. Read the preflight before opening a tab. One brief is out at a time per project: ask for the next platform only after record_submission has answered this one, because until then this tool refuses the next brief and names the one still open. Do not fetch briefs ahead or in parallel. This is the tool the free plan meters: it covers the same submissions the dashboard tracks, plus any platform the account has already sent to, and past that it says so and points at the upgrade rather than answering.record_submissionLog what happened to the dashboard: the listing URL, when it was sent, when it goes live. Call it as soon as a submission lands, before you ask for the next brief, including when it is only queued for review, and including when you are not sure it landed: that is what `attempted` is for. The next brief on this project is refused until this call is made. A platform that needs the maker (a captcha, a login, a payment, a file, an address to confirm) is recorded as `planned` with a note saying what you need from them: that hands it back without claiming an outcome, and frees the run to carry on. If the live platform did not match what the brief said, put the difference in `differsFromRecord`. This costs nothing on any plan and no status costs more than another, so record what actually happened: the brief was what spent the tracked platform, and leaving the row wrong now only makes the run harder to follow.plan_submissionsWrite the run order for a project: which platforms, in what sequence, and why each one is where it is. Anything already submitted to is dropped from the plan and named back to you in `alreadySubmitted`, because a plan is what is still ahead. Pass the platforms in the order they should be worked, with a short reason on each, plus a summary of the strategy. The plan appears on the maker's dashboard as a checklist that ticks itself off as submissions land. Anything already tracked is reordered rather than reset. Call it after qualify_project, using the `recommended` list it hands back, and if that response carried `questions`, put them to the maker before you plan: the order depends on the answers, and a plan written on an assumption is one they have to undo by hand. A plan costs nothing on any plan, so plan the whole run the product deserves rather than a short one sized to a guess about what the account can track.list_submissionsWhere every submission for a project stands: what went out, when, what came back, and what is still waiting. This is the tool behind "check my submissions", "what did I submit", "did I ever submit to that one" and "how is my launch going", so answer those from here instead of asking the maker to remember. Start with list_projects if they have not named a project.Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
{
"mcpServers": {
"rankwise": {
"command": "npx",
"args": [
"-y",
"rankwise"
]
}
}
}
{
"mcpServers": {
"directory-3": {
"url": "https://submitmap.com/api/mcp"
}
}
}