Persuasion Taxonomy MCP vs SubmitMap
A side-by-side look at the Persuasion Taxonomy MCP and SubmitMap MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Persuasion Taxonomy MCP for marketing work as a local process; choose SubmitMap for marketing over a hosted endpoint. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Persuasion Taxonomy MCP when
- You need dedicated capabilities in the Marketing domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You want tools like
plan_marketing_copy, diagnose_marketing_copy, explain_why_not_converting.
Choose SubmitMap when
- You need dedicated capabilities in the Marketing domain.
- You prefer a remote HTTP/SSE transport.
- Its auth model fits you: OAuth 2.0.
- You want tools like
search_platforms, get_platform, qualify_project.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Marketing | Marketing |
| Quality signal | 65/100 · Great | 56/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Remote HTTP/SSE |
| Auth | No auth required | OAuth 2.0 |
| Pricing | Free | Freemium |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 1 | — |
| Directory activity | 2 views 0 installs 0 upvotes | 1 views 0 installs 0 upvotes |
| Tools | 9 | 11 |
| Full listing | View Persuasion Taxonomy MCP | View SubmitMap |
Tools & capabilities
Persuasion Taxonomy MCP tools 9
plan_marketing_copyPlan any piece of marketing copy before you write it, whether it's an ad, a landing page, a sales page or sales letter, an email, a subject line, a social post, a headline or a video script. Give it the goal, the reader and the offer, and it tells you which of the nine questions every reader silently asks this piece has to answer, which ones deserve the most words for this reader, and a few ways to answer each one, drawn from real advertising and linked to the Persuasion Taxonomy. One option is always the established move and the rest are less expected, because left to itself a model answers every question with the move everyone else makes, and readers have learned to skim past it. So call it before you draft, even when you're sure you know how to write the piece, and when the draft is done, check it with diagnose_marketing_copy.diagnose_marketing_copyReview, critique or roast any piece of marketing copy, whether it's an ad, a landing page, an email, a sales page, a social post or a script, and find out why it might not persuade. Before you call it, read the copy and label each line with the one reader question it mainly answers, quoting the words exactly. Those labels go in the moves array. You get back which of the nine questions the copy answers for its goal, which it answers weakly and which it skips, along with the biggest gap and what readers do when it is missing. It also checks the order, whether the answers agree with each other, and the craft, pointing to the exact words that read as machine-written, like em dashes, "it's not X, it's Y" lines and sentences that all run the same length. Then it checks the opening line and suggests techniques from the catalog to fill the gap. Use it before you show anyone a draft you wrote, and whenever someone asks "is this good?", "roast this", "what's wrong with this copy?" or "how do I make it better?"explain_why_not_convertingWork out why an ad, a landing page, an email or a whole funnel isn't converting. Start from what you can see. Maybe people don't click (a low CTR), or they click and bounce, or they read and don't buy. Maybe they abandon the checkout or the form, the leads never buy, customers buy once and leave, or emails don't get opened or get opened and nobody clicks. Whatever the symptom, you get back the reader questions most likely going unanswered, what to check in the copy first, and the problems copy can't fix that you should rule out, along with techniques to try and the test that would confirm the diagnosis. So use it whenever someone says their marketing "isn't working", "isn't converting" or "isn't selling", or asks why results dropped.find_persuasion_techniquesSearch the Persuasion Taxonomy, 766 named persuasion techniques documented from real advertising and organized by the nine reader questions they answer. Describe what you want the copy to do, like build trust without testimonials, create urgency without fake scarcity, handle a price objection, make an opening less generic, prove a claim or reframe a problem. It finds the techniques that do it. Each one comes with its name and ID, a one-line definition, a real example, how common it is in a category if you name one, and a link. So reach for it when a draft relies on the obvious move and you want a less expected one, or when someone asks for tactics, angles, hooks or ideas.get_persuasion_techniqueLook up one persuasion technique by its ID (like PT-PRV-10000), its slug or its name. You get the full definition, why it works, when it lands and when it backfires, real examples from advertising, related and opposite techniques, and a link you can cite. Use it before you apply or recommend a technique so you get it right, and whenever someone asks what a tactic is called or how it works.check_headlinesCheck headlines, email subject lines, ad openings, video hooks, social post openings and first lines, and compare options against each other. For each line it tells you whether the line does its job in that spot, meaning which of the nine reader questions it answers, and whether a competitor could send it unchanged. It also shows exactly what a reader sees before the cutoff, flags anything that fails outright, and brings in evidence from thousands of real headline tests. Then it tells you what each option is betting on and which two to test. Before you call it, list the reader questions each line answers and quote the exact words doing the work. Use it whenever you write headlines, hooks or subject lines, whenever you have to choose between them, and whenever someone asks "which one is best?" You won't get a score out of ten. Nobody can predict a winner from the words alone, and that includes this tool.check_marketing_claimsCheck whether marketing claims and calls to action are specific enough to believe. It catches the vague superlative, like "the best" or "#1", that readers discount on sight. It catches promises with no proof behind them and results with no mechanism, and it flags the generic buttons everyone uses, like "Learn more" and "Get started". Then it tells you how to fix each one. Use it when you write or review claims like "results in days", "trusted by thousands" or "the #1 tool", and for any button text. For headlines, check_headlines does the full job.plan_ab_testPlan an A/B test for marketing copy. Give it the current conversion rate, the smallest lift worth detecting and the daily traffic, and it tells you how many visitors each version needs and how many days to run. It also frames the test as two different answers to the same reader question, so the result teaches you something you can reuse, and not just that "B won". Use it when someone asks how long to run a test, how much traffic they need, whether a test is worth running, or what to test next.read_ab_test_resultRead the result of an A/B test. You get each version's conversion rate and lift, whether the difference is statistically significant, the confidence interval, and the chance each version really beats the original. It also warns you about the things that make a test result lie. Those include too few conversions, traffic that didn't split the way it should (a sample ratio mismatch), stopping the moment it looked good, and testing too many versions at once. So use it whenever someone shares test numbers, or asks "did my test win?", "is this significant?", "which version won?" or "should I keep it running?"
SubmitMap tools 11
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.
Ready-to-paste client configs
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.
Persuasion Taxonomy MCP
{
"mcpServers": {
"persuasion-taxonomy-mcp": {
"command": "npx",
"args": [
"-y",
"@coppica/persuasion-mcp"
]
}
}
}
SubmitMap
{
"mcpServers": {
"submitmap": {
"command": "npx",
"args": [
"-y",
"submitmap"
]
}
}
}
Frequently asked questions
Persuasion Taxonomy MCP is categorized under Marketing and uses a local stdio subprocess. SubmitMap belongs to Marketing and uses a remote HTTP/SSE transport. Pick Persuasion Taxonomy MCP for marketing work and SubmitMap for marketing.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Persuasion Taxonomy MCP is listed as free. Auth: no auth required. SubmitMap is listed as freemium — a free tier with paid plans. Auth: oauth 2.0. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add persuasion-taxonomy-mcp and submitmap as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Persuasion Taxonomy MCP has a quality signal of 65/100 (Great) with 2 views, 0 installs and 1 GitHub stars. SubmitMap has 56/100 (Good) with 1 views, 0 installs and 0 GitHub stars.