Dynamoi vs Submit Map

A side-by-side look at the Dynamoi and Submit Map MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.

Dynamoi logoDynamoiMarketing · Remote HTTP/SSEPromote music on Spotify and grow YouTube channels through AI-powered Meta and Google ad campaigns.60GoodAuth: oauth 2.0Submit Map logoSubmit MapMarketing · Remote HTTP/SSEA directory of product launch platforms: where your product qualifies and how each form is filled.64GoodAuth: api key required

Verdict: choose Dynamoi 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.

Which MCP server should you choose?

Dynamoi logoChoose Dynamoi 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 dynamoi_open_workspace, dynamoi_about, dynamoi_get_account_overview.
Explore Dynamoi

Submit Map logoChoose Submit Map when

  • You need dedicated capabilities in the Marketing domain.
  • You prefer a remote HTTP/SSE transport.
  • Its auth model fits you: API key required.
  • You want tools like search_platforms, get_platform, qualify_project.
Explore Submit Map

Feature & specification comparison

Rows where the two servers differ are marked.

SpecDynamoi logoDynamoiSubmit Map logoSubmit Map
CategoryMarketingMarketing
Quality signal60/100 · Good64/100 · Good
Install commandConfirmedConfirmed
TransportRemote HTTP/SSERemote HTTP/SSE
AuthOAuth 2.0API key required
PricingNot declaredFree
Required env varsNone listedNone listed
Verified ownerCommunity listingCommunity listing
GitHub stars3265
Directory activity 0 views 0 installs 0 upvotes 4 views 0 installs 1 upvotes
Tools2411

Tools & capabilities

Dynamoi tools 24

  • dynamoi_open_workspaceOpen the read-only Dynamoi workspace when the user wants to browse their existing artists, campaigns, Smart Links and observed results in ChatGPT. Returns an authorized artist roster or an honest empty account state. Does not create links, change campaigns, start purchases or connect accounts. Use individual read tools for follow-up details.
  • dynamoi_aboutUse this when the user asks what Dynamoi is, who it is for, or what it offers — including before sign-in or before choosing a tool. Returns the canonical About Dynamoi text plus a short structured summary covering free Smart Links, managed Smart Campaigns, YouTube campaigns, distribution, company facts, support, and getting started. This is read-only product information, not account data.
  • dynamoi_get_account_overviewUse this when the user explicitly asks about the signed-in Dynamoi account itself, such as who is logged in, how many organizations or artists it can access, or whether account-level platform connections exist. Pass intent to match that explicit account question; it defaults to account_overview. Do not use this to confirm a specific Meta or YouTube onboarding attempt because this account-level state can span multiple artists; use dynamoi_get_platform_status for the target artist instead. Do not use this to enumerate artists one by one; use dynamoi_list_artists for that. Never use this to 'check context' before answering generic Instagram, lyrics, songwriting, or marketing-advice questions, even if Dynamoi is attached.
  • dynamoi_list_artistsUse this when the user wants to see which artists or YouTube channels they manage, along with billing status, active campaign count, and their role. Pass artistId when you need the full profile/readiness details for one artist instead of a roster page. Do not use this for campaign details; use dynamoi_list_campaigns or dynamoi_get_campaign. Never use this for generic social-media or marketing advice, including Instagram follower-growth questions, unless the user explicitly asked about their Dynamoi roster. If the result is empty, the user is brand-new — do not stop with 'no records found'; route through dynamoi_get_account_overview.recommendedNextActions.
  • dynamoi_searchUse this when the user mentions an artist, release, campaign, or smart link but you do not yet know the exact record to inspect. Do not use this for analytics summaries or billing questions once you already know the target record. If the result is empty for a brand-new user (no artists yet), do not respond 'no records found' as a terminal answer — instead suggest creating their first artist hub via dynamoi_create_smart_links_from_spotify_artist.
  • searchOpenAI ChatGPT Deep Research / Connectors search contract. Returns matching Dynamoi artists, campaigns, and Smart Links so they can be cited in a deep-research session. For regular ChatGPT chat use dynamoi_search instead.
  • fetchOpenAI ChatGPT Deep Research / Connectors fetch contract. Given an id returned by `search` (formatted as 'artist:<uuid>', 'campaign:<uuid>', or 'smartlink:<uuid>'), returns the full record for citation.
  • dynamoi_list_campaignsUse this when the user wants to browse campaigns for one artist, optionally filtered by type or status. Do not use this for a single campaign deep dive; use dynamoi_get_campaign for that. Never use this to personalize generic marketing advice. If the user has no artists yet, do not call this — route via dynamoi_get_account_overview first.
  • dynamoi_get_campaignUse this when the user wants full details for one campaign, including budget, targeting, platform status, and next actions. YouTube campaigns return youtubeStrategy and strategyGuide: read the guide's goal and judgeBy before interpreting results. Set includeAnalytics=true for paid delivery, includeChannelResults=true for observed YouTube channel results with paid and organic views (never attributed to the campaign), includeDeploymentStatus=true for delivery/deployment blockers, and includeCountries=true only when the full country list is needed. Do not use this for a campaign list; use dynamoi_list_campaigns instead. After a successful launch or campaign mutation, prefer format=summary when you need a follow-up read to relay the final answer.
  • dynamoi_get_artist_analyticsUse this when the user wants artist-level performance across all campaigns, including 30-day rollups or daily breakdowns. Pass granularity=DAILY when the user asks for a daily breakdown. Pass format=summary when the user wants a written rollup, a strongest-campaign verdict, or a direct answer you can relay immediately. If this tool already returned the requested strongest-campaign comparison, stop and answer instead of calling more analytics tools. For one campaign's metrics, use dynamoi_get_campaign with includeAnalytics=true.
  • dynamoi_get_growth_auditUse this when the user asks for an artist's Spotify monthly listeners, listener growth over time, growth audit or score, playlist reach, or growth recommendations. The response carries its status, coverage dates, and limitations; preserve unavailable or stale status and do not treat a missing metric as zero. This is Spotify and market insight data, not paid campaign performance.
  • dynamoi_get_playlist_analyticsUse this when the user asks about an artist's tracked playlist placements, reach, or playlist movement. The response includes freshness and snapshot dates with the playlist and movement rows. These observed placements are not attributed to a paid campaign.
  • +12 more on the listing page

Submit Map 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.

Dynamoi

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "dynamoi": {
      "url": "https://dynamoi.com/mcp"
    }
  }
}

Submit Map

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "directory-3": {
      "url": "https://submitmap.com/api/mcp"
    }
  }
}

Frequently asked questions

Dynamoi is categorized under Marketing and uses a remote HTTP/SSE transport. Submit Map belongs to Marketing and uses a remote HTTP/SSE transport. Pick Dynamoi for marketing work and Submit Map 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.

Dynamoi has no declared pricing — check the project's own site. Auth: oauth 2.0. Submit Map is listed as free. Auth: api key required. 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 dynamoi and directory-3 as separate keys in the same mcpServers object, and your assistant will call tools from either one.

On AllMCPs, Dynamoi has a quality signal of 60/100 (Good) with 0 views, 0 installs and 3 GitHub stars. Submit Map has 64/100 (Good) with 4 views, 0 installs and 265 GitHub stars.