+ Integration Guide

· Updated August 29, 2026

Connect Twitter MCP to VS Code

Add FetchLayer's Twitter/X MCP server to VS Code so GitHub Copilot's agent mode can search tweets, get profiles, and pull follower data.

Written by Alex P.

  • MCP
  • VS Code
  • GitHub Copilot
  • twitter scraping
  • X scraping
  • AI agent

VS Code supports MCP servers through GitHub Copilot’s agent mode. You can add FetchLayer’s Twitter/X MCP server to give Copilot access to tweet search, profile lookup, follower graphs, and more.


Prerequisites

  • VS Code with GitHub Copilot extension installed
  • GitHub Copilot agent mode enabled
  • A FetchLayer API key — get one free (no credit card)

Step 1: Create the MCP config

VS Code reads MCP configurations from .vscode/mcp.json in your workspace root.

Create the file .vscode/mcp.json:

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

Replace ss-your-api-key with your actual key from the FetchLayer dashboard. Note the top-level key here is servers, not mcpServers — VS Code’s own MCP config shape differs slightly from Claude Desktop’s and Cursor’s, even though the per-server fields (url, headers) are the same.

Prefer not to create a workspace file? Open the Command Palette and run MCP: Open User Configuration instead — this opens a user-level mcp.json that applies across every workspace you open, rather than being scoped to one project. Use the workspace .vscode/mcp.json when you want the server checked into a specific repo (e.g., for a team), and the user-level config for a personal key you want everywhere.


Step 2: Reload VS Code

Reload the window (Ctrl+Shift+P → “Reload Window”) to pick up the new MCP config.


Step 3: Switch to Agent mode

This is the step people most often miss: MCP tools are invisible in Ask mode and Edit mode. Open Copilot Chat, click the mode dropdown at the top of the chat panel, and select Agent. Only in Agent mode does Copilot see and call MCP-provided tools like FetchLayer’s — in Ask or Edit mode, the server can be perfectly configured and still never get used.


Step 4: Use it in Copilot Chat

With Agent mode selected, try:

Search X/Twitter for “VS Code extensions for Python” and show me the most recommended ones.

Copilot calls the FetchLayer search tool and returns structured results inline in the chat, the same way it would call any built-in tool — there’s no special syntax to invoke it by name.

More examples:

PromptWhat Copilot does
”What are people saying about GitHub Copilot on X/Twitter?”Searches recent discussion on the topic
”Get tweets from @rauchg about Next.js”Fetches a user’s recent tweet history
”Get the profile and follower count for @openai”Returns profile + extended metadata
”Find verified followers of @levelsio”Returns verified accounts following that user
”Summarize the replies to this tweet and flag any bug reports: [URL]“Pulls replies, filters by relevance

Because Copilot’s agent mode can combine MCP tool calls with your open workspace context, this is most useful mid-task — pulling live user sentiment on a library you’re about to adopt without leaving the editor to check X manually.


All available tools

All 10 FetchLayer Twitter/X endpoints are available: 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. See the full endpoint list.


Troubleshooting

Tools not appearing in chat?

  • Confirm you’re in Agent mode, not Ask or Edit — this is the single most common miss
  • Validate the JSON in mcp.json (no trailing commas)
  • Confirm the top-level key is servers, not mcpServers — copying a config block from a different client’s docs is the second most common miss

Server configured but Copilot ignores it?

  • Reload the window (Ctrl+Shift+P → “Reload Window”) — mcp.json changes aren’t always picked up live
  • If you added it via workspace config, confirm you actually have that workspace open — a user-level config change won’t retroactively appear if you meant to edit the workspace file instead

401 errors in the tool output?

  • Confirm the key starts with ss- and includes the Bearer prefix in the header value

Real workflow example

A practical way this gets used inside VS Code: validating a technical decision against live opinion before you commit to it.

I’m deciding between two state management libraries for a React project. Search X/Twitter for recent discussion comparing them and summarize the main tradeoffs people are actually running into in production.

Copilot’s agent mode calls twitter_search, reads through the results, and can follow up with twitter_tweet_replies on threads with active debate to get both sides rather than just the original post. Because this runs inside Agent mode alongside your normal file-editing tools, you can ask it to act on the findings immediately — for example, scaffolding a small proof-of-concept with whichever library the discussion favors, in the same session.


Workspace vs. user config, revisited

If .vscode/mcp.json lives in a shared repo, don’t commit a real API key in the Authorization header. VS Code supports an inputs array for exactly this case — define a masked prompt and reference it instead of a literal string:

{
  "inputs": [
    { "type": "promptString", "id": "fetchlayer-key", "description": "FetchLayer API Key", "password": true }
  ],
  "servers": {
    "fetchlayer": {
      "url": "https://mcp.fetchlayer.dev",
      "headers": { "Authorization": "Bearer ${input:fetchlayer-key}" }
    }
  }
}

Each teammate is prompted for their own key the first time the workspace loads, and VS Code stores it encrypted locally rather than in the committed file. For a solo project or personal experimentation, the user-level config from Step 1 avoids the question entirely since nothing workspace-specific gets committed at all.


What a tool call actually returns

Copilot receives structured JSON rather than a rendered timeline. A search response looks roughly like:

{
  "results": [
    {
      "id": "1942939879222220800",
      "text": "Shipped the new parser today. 3x faster on large files.",
      "author": {
        "handle": "example_dev",
        "displayName": "Example Dev",
        "followersCount": 12400,
        "verified": false
      },
      "likeCount": 284,
      "retweetCount": 41,
      "replyCount": 17,
      "createdAt": "2026-08-18T10:00:00.000Z",
      "url": "https://x.com/example_dev/status/1942939879222220800"
    }
  ]
}

The nested author object with followersCount on every result is the useful part: the agent can compute engagement rate — likes relative to audience size — without a second lookup per author. A tweet with 284 likes from a 12k account is a different signal than the same number from a 2M account, and both numbers are already in the one response.


Real tweets as test fixtures

The most practical in-editor use is generating fixtures from live data. With a test file open:

“Search X for posts about our library, take 10, and write them as fixture data for the text-parsing tests here.”

Real tweets bring the cases nobody invents by hand: emoji mid-sentence, RTL text, zero-width joiners in usernames, URLs that eat the character budget, and replyCount present but retweetCount missing. If your parser handles ten real tweets it will survive production far better than one that handles ten tidy invented strings.

The same applies to display components — real displayName values include emoji and 40-character names that break layouts that were only ever tested with “Jane Smith”.


Follower lookups are the expensive ones

Search and profile lookups are a single request each. Follower and following lists paginate, and each page is billed separately — so an offhand prompt like:

“Get all of @bigaccount’s followers”

against an account with 500,000 followers is not one request. It’s however many pages the agent decides to fetch, and an agent trying to be complete will keep going.

Always state a bound:

“Get the first 2 pages of @bigaccount’s followers and summarize who they are.”

For nearly every question people actually ask — is this audience technical, do these two accounts overlap, who are the notable followers — a sample answers it. Full enumeration almost never adds anything the sample didn’t already show.


Agent mode is required

Copilot only calls tools in agent mode. In Ask mode it answers from the model, which for a question about current X activity means confidently reconstructing something from training data.

The tell is speed: a real search takes a moment and produces a tool-call block in the transcript. An instant answer with no block means no request was made and no live data was involved.


What’s Next