+ Integration Guide

· Updated August 29, 2026

How to Connect Twitter MCP to KiloCode

Add FetchLayer's Twitter/X MCP server to KiloCode so your AI assistant can search tweets, get profiles, and pull follower data — via Kilo's own settings.

Written by Alex P.

  • MCP
  • KiloCode
  • twitter scraping
  • X scraping
  • AI agent
  • VS Code extension

KiloCode is an AI coding assistant that runs as a VS Code extension and supports the Model Context Protocol (MCP). One thing worth knowing up front: KiloCode manages its own MCP server list, separate from VS Code’s native .vscode/mcp.json used by GitHub Copilot’s agent mode. If you’ve already set up an MCP server for Copilot in the same workspace, that config won’t be visible to KiloCode — you configure the two independently, even though they’re both running inside VS Code.

Once connected, KiloCode gets access to all 10 FetchLayer Twitter/X tools — search, tweet detail, replies, profiles, followers, and more.


Prerequisites


Step 1: Open KiloCode’s MCP settings

You have two ways in:

Via the UI (recommended for a first setup): Open KiloCode’s settings panel, go to MCP, and click Add Server. Choose Remote (HTTP/SSE) as the server type — not Local (stdio), which is for servers KiloCode spawns as a child process on your machine. FetchLayer’s server is remote, so stdio settings (command, args) don’t apply here.

Via the config file directly: KiloCode stores its MCP settings in a JSON file whose path depends on your OS and whether you’re editing the global or project-level config:

ScopePath
Global (all projects), macOS~/Library/Application Support/Code/User/globalStorage/kilocode.kilo-code/settings/mcp_settings.json
Global (all projects), Windows%APPDATA%/Code/User/globalStorage/kilocode.kilo-code/settings/mcp_settings.json
Global (all projects), Linux~/.config/Code/User/globalStorage/kilocode.kilo-code/settings/mcp_settings.json
Project-level.kilo/kilo.jsonc in your workspace root

Project-level config takes precedence over global when both define a server with the same name. For a personal FetchLayer key you use across projects, the global path is usually the simpler choice.


Step 2: Add the FetchLayer server

Whichever path you edit, the entry looks like this:

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

Replace ss-your-api-key with your key from the FetchLayer dashboard. If you’re using the Add Server UI flow instead of editing JSON directly, paste the URL and header into the corresponding fields — KiloCode writes this same structure to the settings file for you.


Step 3: Reload

If you edited the settings file directly, reload the VS Code window (Ctrl+Shift+P → “Reload Window”) so KiloCode picks up the change. If you used the Add Server UI, KiloCode typically connects immediately without a reload — check the MCP panel for a green/connected status next to “fetchlayer”.


Try it out

Open KiloCode’s chat panel and try:

Search X/Twitter for “best VS Code themes 2026” and show me the top results.

KiloCode calls FetchLayer’s twitter_search tool and returns structured data inline in the chat.

More examples:

PromptWhat KiloCode does
”What do people on X/Twitter recommend for ORMs?”Searches recent tweets on the topic
”Get the latest tweets from @rauchg about Next.js”Fetches a user’s recent tweet history
”Find verified followers of @levelsio”Returns verified accounts following that user
”Pull the replies on this tweet and flag anything negative: [URL]“Fetches replies, then reasons over sentiment

Because KiloCode can chain tool calls with codebase edits in the same session, this is useful mid-task — for example, pulling live user feedback on a feature while you’re actively implementing it, without switching to a browser.


Available Tools

All 10 FetchLayer Twitter/X tools: 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 doesn’t show up after editing the file directly?

  • Double-check you edited the KiloCode-specific mcp_settings.json path above, not VS Code’s own .vscode/mcp.json — the two are unrelated, and it’s an easy mix-up if you’ve configured Copilot’s agent mode in the same workspace before
  • Confirm you’re editing the OS-correct path — a Windows path pasted into a WSL/Linux terminal (or vice versa) resolves to nowhere and fails silently
  • Validate the JSON — trailing commas will break mcp_settings.json even though .kilo/kilo.jsonc (the project-level format) tolerates them

Connected in the UI but no tools listed?

  • Reopen the MCP panel — the tool list sometimes only populates on the first successful handshake after a reload
  • Confirm the server type was set to Remote (HTTP/SSE), not Local (stdio) — a server added as the wrong type won’t be queried correctly

“Not connected” / restart loop on the server entry?

  • This has been reported for other MCP servers when KiloCode misreads non-error output on stderr as a failure — it’s specific to stdio-type local servers, so it shouldn’t affect FetchLayer’s remote HTTP setup, but if you see it, confirm the server type is still Remote and not accidentally switched to Local

Real workflow example

A common use of Twitter/X data inside KiloCode isn’t a one-off lookup — it’s checking live reaction to something you just shipped, without breaking flow to open a browser:

I just pushed a change to how our CLI handles config files. Search X/Twitter for mentions of our project name from the last 48 hours and tell me if anyone’s reporting a problem with it.

KiloCode will call twitter_search, and if it finds relevant posts, follow up with twitter_tweet_replies on the ones with engagement to check whether a thread developed. Because this happens inside the same session as your code changes, you can immediately act on what it finds — for example, asking it to draft a fix for a bug someone just reported on X, in the same conversation.


Global vs. project config: which to pick

If you only work in one or two repos, editing the project-level .kilo/kilo.jsonc is fine and keeps the server definition next to the code that uses it. If you jump between many unrelated projects and want FetchLayer available in all of them without repeating setup, use the global mcp_settings.json path instead. Since project config takes precedence when both define a server with the same name, you can also set a personal key globally and let a specific project override it with a team-shared key — useful if you want your own testing key most of the time but a shared project key when pairing.


What a tool call actually returns

Tools return JSON with the author nested per result:

{
  "results": [
    {
      "id": "1942939879222220800",
      "text": "Swapped to their API last month, no regrets.",
      "author": { "handle": "example_dev", "displayName": "Example Dev", "followersCount": 12400 },
      "likeCount": 284,
      "retweetCount": 41,
      "replyCount": 17,
      "createdAt": "2026-08-18T10:00:00.000Z",
      "url": "https://x.com/example_dev/status/1942939879222220800"
    }
  ]
}

Engagement counts and audience size arriving together mean the agent can rank results meaningfully before spending another request on any of them.


Splitting the work across modes

KiloCode’s modes map neatly onto the two halves of this kind of task, and the split also keeps requests down.

In a research mode, gather:

“Search X for reactions to our v3 launch. Open replies on the two posts with the most discussion and summarize the objections.”

One search, two tweet-replies — three billed requests.

Switch to a code mode and act:

“Turn those objections into a FAQ section in docs/faq.md, linking each answer to the post it came from.”

Zero further requests. The findings are in context; this step only writes files.

Keeping the two apart matters practically: a code-focused mode asked to research tends to interleave fetches with edits, and interleaved runs fetch more, because the agent hits a gap mid-edit and reaches for the tool rather than reasoning from what it already has.


Mode permissions and silent fallbacks

Tool access follows mode permissions. A mode without tool access won’t error — the agent will answer from the model instead, and won’t necessarily say so.

The symptom is a fast, plausible, uncited answer to a question about current activity. Check the transcript for a tool-call block before assuming the config is wrong; more often it’s the mode.


Auto-approve and the paging endpoints

Auto-approving tool calls smooths multi-step work and removes the last checkpoint before a billed request. That’s fine for search and profile lookups, which cost one request each. It matters for user-followers and user-following, which bill per page.

With auto-approve on, always bound graph requests in the prompt:

“First 2 pages of @example’s followers, then stop.”


What’s Next