How to Connect Twitter MCP to Windsurf

Windsurf is the AI-native IDE originally built by Codeium and now part of Cognition (the makers of Devin) after their 2025 acquisition. Its agent, Cascade, supports the Model Context Protocol (MCP), which lets you connect external data sources as tools Cascade can call mid-conversation. This guide covers connecting FetchLayer’s Twitter/X MCP server — the same steps work whether your Windsurf installation still shows “Windsurf” branding or the newer “Devin Settings → Cascade” naming that’s rolling out post-acquisition.

Once configured, Cascade gets access to all 10 FetchLayer Twitter/X tools — search, tweet detail, replies, profiles, followers, and more — as structured JSON it can reason over directly, without you writing a scraper or handling X’s official API.

Prerequisites

• Windsurf installed
• A FetchLayer API key — get one free (no credit card)

Step 1: Find the MCP config file

Cascade reads its MCP server list from a single JSON file:

~/.codeium/windsurf/mcp_config.json

This path is the same on macOS and Linux; on Windows it’s %USERPROFILE%\.codeium\windsurf\mcp_config.json. Note the directory name — it’s still .codeium, a holdover from before the Cognition acquisition, even on installs that show “Devin” branding elsewhere in the UI. Unlike some editors, Windsurf does not create this file automatically on first launch, so you may need to create the .codeium/windsurf/ directory and the file yourself.

You can also reach it from inside the app: open the Cascade panel, click the MCPs icon in the top-right of the panel (or Devin Settings → Cascade → MCP Servers on newer builds), and use Add Server to have Windsurf create and open the file for you.

Step 2: Add the FetchLayer server

This is the detail that trips people up: Windsurf’s remote-server key is serverUrl, not url. A config copied from another MCP client’s url-style example will fail silently — Cascade won’t error, it just won’t list the server’s tools.

{
  "mcpServers": {
    "fetchlayer": {
      "serverUrl": "https://mcp.fetchlayer.dev",
      "headers": {
        "Authorization": "Bearer ss-your-api-key"
      }
    }
  }
}

Replace ss-your-api-key with your actual key from the FetchLayer dashboard. If you already have other MCP servers configured, add the "fetchlayer" block alongside them inside the same mcpServers object — don’t create a second top-level mcpServers key.

Windsurf also supports ${env:VAR_NAME} interpolation in header values, so if you’d rather not paste your key directly into the file, set FETCHLAYER_API_KEY in your shell environment and reference it as "Bearer ${env:FETCHLAYER_API_KEY}" instead.

Step 3: Refresh Cascade

Save the file, then go back to the MCPs panel and click the refresh icon next to the server list — this reloads config without a full restart. If the server doesn’t show up, restart Windsurf entirely; on some builds config changes are only picked up on launch.

Once connected, “fetchlayer” appears in the MCPs panel with its tool count, and you can toggle individual tools on/off from there.

A budget you need to know about: 100 tools

Cascade enforces a hard limit of 100 total tools across every MCP server you have connected at once. FetchLayer’s Twitter/X server contributes 10 of those. If you’re already running several other MCP servers (filesystem, database, other platform integrations) and Cascade silently isn’t calling FetchLayer tools, check the MCPs panel for a tool-count warning — you may need to disable unused tools from another server to make room, rather than assuming the connection itself failed.

Try it out

Open Cascade and try:

Search X/Twitter for discussions about “best TypeScript ORMs” and summarize the top recommendations.

Cascade will call FetchLayer’s twitter_search tool and incorporate the results into its response.

More examples:

Because Cascade can plan multi-step tool use, it can combine FetchLayer calls with your codebase context — for example, cross-referencing a feature you’re building against live X discussion about the same problem space.

Available Tools

All 10 FetchLayer Twitter/X tools are available once connected: twitter_search, twitter_tweet_detail, twitter_tweet_replies, twitter_user_profile_details, twitter_about_profile, twitter_user_tweets, twitter_user_replies, twitter_following, twitter_followers, and twitter_verified_followers. Full parameter reference: Twitter/X API endpoints.

Troubleshooting

Server not appearing in the MCPs panel?

• Confirm you used serverUrl, not url — this is the single most common mistake migrating a config from another client
• Validate the JSON (no trailing commas, headers nested correctly under the server, not at the top level)
• Confirm the file is actually at ~/.codeium/windsurf/mcp_config.json — a typo’d path fails silently with no error dialog

Tools listed but Cascade never calls them?

• Check the 100-tool budget above — you may be over the limit with other servers active
• Make your prompt explicit about the platform (“search X/Twitter for…”) — Cascade won’t guess which server to route a vague request to

401 or auth errors in the tool call output?

• Confirm the key starts with ss- and was copied in full from the dashboard
• If using ${env:VAR_NAME} interpolation, confirm the environment variable is actually set in the shell Windsurf was launched from — GUI-launched apps don’t always inherit shell profile exports

A realistic Cascade run

Cascade chains steps on its own, so state the outcome and the limits rather than the procedure:

“Work out how our competitor’s launch went on X. Search for mentions of them from the last week, find the three posts with the most replies, read those reply threads, and tell me what people actually objected to.”

The run:

1. search for the competitor, product: "Latest" — one request
2. Sorts the results by replyCount, which came back on every item — no request
3. tweet-replies on the top three — three requests
4. Synthesizes the objections from the reply text — no request

Four billed requests. Step 2 is what keeps it to four: because replyCount, likeCount, and retweetCount all arrive with the search results, Cascade can pick which conversations are worth opening without opening any of them first.

Follow-ups that only reason over what’s already in context are free:

“Which of those objections are about pricing rather than features?”

No new request — Cascade re-reads the replies it already has.

Follower lists will eat your quota

The engagement endpoints are cheap and the graph endpoints are not. search, tweet-detail, and user-profile-details are one request each. user-followers and user-following paginate, and Cascade — which is built to work autonomously until a task looks done — will keep requesting pages if you don’t bound it.

❌ “Analyze @bigaccount’s follower base”

✅ “Pull the first 2 pages of @bigaccount’s followers and characterize who they are”

The second version answers the same practical question. Nobody reading the output can tell the difference between a 200-follower sample and a 500,000-follower enumeration, but your bill can.

Handles, not URLs

The tools expect a bare handle. Pasting a profile URL or an @-prefixed handle is the most common cause of an empty result that looks like a tool failure:

• ✅ rauchg
• ⚠️ @rauchg — usually normalized, but not worth relying on
• ❌ https://x.com/rauchg

If a profile lookup comes back empty for an account you know exists, check what the agent actually passed before assuming the server is broken. Saying “the account rauchg” rather than pasting a link avoids it entirely.

What’s Next

• Twitter/X MCP: All Clients Compared — every supported AI tool in one place
• Twitter MCP + Cursor — a similar setup in a different editor
• Twitter MCP + Claude Desktop — desktop app setup
• Twitter MCP + VS Code — GitHub Copilot’s agent mode
• How to Scrape Twitter/X in 2026 — every method compared, not just MCP
• FetchLayer API Reference — full endpoint docs