Use two MCP servers in Claude: Snapchat Ads and video generation
Add the Snapchat Ads MCP and Sume MCP to one Claude Code session under different names: read ad data from one, generate video with the other. Commands inside.
Yes, Claude Code can use both at once: register each server under its own name, log in to each separately, and let the agent call whichever tool fits. Snapchat Ads MCP reads your ad data; Sume MCP can generate video or images. The two do not talk to each other, so Claude is the go-between.
The Snap commands come from Snap's connect an agent page and the Sume ones from the MCP quickstart, both read 2026-09-29.
What are the two setup commands?
Use distinct server names, here snap-ads and sume, so tool lists and logins never mix. Sume's quickstart adds a plain HTTP server; Snap's adds a client id.
claude mcp add --transport http --client-id claude-snap-ads snap-ads https://mcp.snapchat.com/ads
claude mcp login snap-ads
claude mcp add --transport http sume https://mcp.sume.com/mcp
claude mcp login sumeWhat can each server do?
Sume's tools and gates list generate_video among the image, video and audio generation tools. With OAuth mcp:read only, mutating and paid tools are hidden, so grant Write at consent if you want Claude to generate. Paid submits still need an idempotency_key.
| Server | Endpoint | What the docs say |
|---|---|---|
| Snapchat Ads MCP | https://mcp.snapchat.com/ads | Read-only: cannot create, update or delete anything |
| Sume MCP | https://mcp.sume.com/mcp | OAuth defaults to mcp:read; write and paid tools need mcp:write or an API key |
What is a good prompt that uses both?
Ask for a chain the agent can do without leaving its lane: read the ad account data through Snap's server, then write a short brief, then use Sume's tools to generate the creative. Ending the request with a review step matters, because Snap's server cannot upload the result for you. A person adds the finished clip in Snapchat.
Use dry_run=true first if you want a cost preview before the agent submits a paid Sume call; the docs describe it as an admission and cost preview only.
What can go wrong with two logins?
The two servers authorize separately, and the approvals are different in kind. On the Snap side an Admin or Business Admin must approve the agent for the organization before other members can connect, and each member only reaches ad accounts their Snapchat permissions allow. On the Sume side the consent screen is where you choose whether the session may write.
So if one server works and the other does not, check that server's login and approval on its own. Do not paste API keys into chat: Sume's quickstart says to prefer the OAuth connector flow for interactive clients. And because Snap's server is read-only, a failed attempt to change an ad is expected behavior, not a bug in your Sume setup.
Does the order of the servers matter?
Not for correctness. Each server has its own endpoint and login, and Claude sees tools from both. Keep the names short and unlike each other, since tool names show up in the agent's prompts. To share the pair with a team, see Claude Code MCP project scope.
Sources
Related posts
More in Integrations
- Spring Retry and @Retryable for a paid API call in Spring 7
Spring Retry is archived; Spring Framework 7 has @Retryable in core. For a paid API call, narrow the exceptions, back off, and pass one idempotency key in.
- Stripe checkout webhook: start a paid job once per payment
Listen for checkout.session.completed, verify the signature on the raw body, answer 2xx fast, then start the job keyed by the Checkout Session id.
- Suno MCP: making music from Claude, and what Sume's MCP has
No Suno MCP server is in Sume's docs. Sume's hosted MCP does expose a music_create tool for Lyria-based music, and paid calls need an idempotency_key.
- Tenacity retry in Python: safe settings for a paid API POST
Bare @retry in tenacity retries forever with no wait. For a paid POST, cap attempts, add jittered backoff, retry only transient errors, and reuse one key.
Written by Sume