FetchLayer fetchlayer.dev Get started

+ Integration Guide

· Updated August 29, 2026

How to Connect Twitter MCP to OpenClaw

Add FetchLayer's Twitter/X MCP server to OpenClaw's self-hosted Gateway so every agent session can search tweets, get profiles, and pull follower data.

Written by Alex P.

  • MCP
  • OpenClaw
  • twitter scraping
  • X scraping
  • AI agent
  • self-hosted

OpenClaw is a self-hosted Gateway for running and coordinating coding-agent sessions — closer to infrastructure you deploy than a single-machine editor extension. It sits between multiple communication channels and your agents, and doubles as an MCP client-side registry: you configure MCP servers once at the Gateway level, then route them to specific agents rather than reconfiguring each session individually.

That architecture matters for setup: unlike a desktop app, there’s a running Gateway process (local or remote) whose config file you’re editing, and a separate step to confirm it actually reached mcp.fetchlayer.dev from wherever it’s deployed.

Prerequisites

  • An OpenClaw Gateway running — local mode (on your own machine) or remote mode (a Gateway instance you connect to)
  • A FetchLayer API key — get one free (no credit card)

Step 1: Open the Gateway config

OpenClaw’s config lives at:

~/.openclaw/openclaw.json

It’s written in JSON5 — a relaxed JSON dialect that allows comments and trailing commas, so you can annotate your config without breaking the parser. The mcp.servers block sits at the root of the file, alongside the Gateway’s other top-level sections (channels, agents, models, skills, plugins, browser, gateway, and so on).

Step 2: Add the FetchLayer server

Add an entry under mcp.servers:

{
  mcp: {
    servers: {
      fetchlayer: {
        url: "https://mcp.fetchlayer.dev",
        transport: "streamable-http",
        headers: {
          Authorization: "Bearer ss-your-api-key",
        },
        requestTimeoutMs: 20000,
        connectionTimeoutMs: 5000,
      },
    },
  },
}

Replace ss-your-api-key with your key from the FetchLayer dashboard. The explicit transport: "streamable-http" matters here — OpenClaw supports multiple MCP transports, and FetchLayer’s server speaks streamable HTTP, not stdio, so leaving this unset can cause OpenClaw to try the wrong connection method.

Prefer the CLI? The same server can be added without hand-editing JSON:

openclaw mcp add fetchlayer \
  --url https://mcp.fetchlayer.dev \
  --transport streamable-http \
  --header "Authorization: Bearer ss-your-api-key"

By default, a server added to mcp.servers is available Gateway-wide. If you’re running multiple agents through OpenClaw and only want some of them touching Twitter/X data, scope it explicitly under agents.<name>.mcpServers in the same config file, listing only fetchlayer for the agents that need it. This keeps agents that don’t need social data from carrying the extra tools in their context.

Step 4: Verify the connection

Because OpenClaw runs as a persistent Gateway rather than a GUI you glance at, it ships CLI diagnostics instead of a status icon:

# Lists configured servers without connecting — a quick config sanity check
openclaw mcp status --verbose

# Opens a live connection and lists the tools it actually returns
openclaw mcp probe fetchlayer --json

# Runs static checks, then verifies connectivity end-to-end
openclaw mcp doctor fetchlayer --probe

If you have Control UI access, the same inventory is browsable at /settings/mcp in your browser, with per-server transport and connection details.

JSON5, not plain JSON

One more small but real difference from other MCP clients: OpenClaw’s config format is JSON5, which tolerates trailing commas and inline comments that would break a strict JSON parser. That’s convenient for documenting why a particular timeout value or transport was chosen directly in the file — but it also means copying an openclaw.json snippet into a strict-JSON validator (or a client that expects plain JSON, like most of the others in this series) will report false errors on syntax JSON5 explicitly allows. If you’re troubleshooting with an external JSON linter, make sure it’s JSON5-aware before trusting its output.

Try it out

Once connected, ask your OpenClaw-managed agent:

Search X/Twitter for posts about “self-hosted alternatives to Notion” and show me the top results.

The agent calls FetchLayer’s twitter_search tool through the Gateway and returns structured data.

More examples:

  • “What’s @levelsio tweeting about this week?”
  • “Get replies to this tweet: [URL] and summarize the disagreement”
  • “Find verified accounts following @openai”
  • “Get the profile and recent tweet history for @rauchg”

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

openclaw mcp status shows the server, but probe times out?

  • Confirm the Gateway host itself has outbound network access to mcp.fetchlayer.dev — this is a common miss in remote/containerized Gateway deployments with restrictive egress rules
  • Check connectionTimeoutMs isn’t set unrealistically low if you’re on a higher-latency network path

“Unknown transport” or connection immediately drops?

  • Make sure transport: "streamable-http" is present — omitting it can cause OpenClaw to assume a stdio-based local process instead

Agent doesn’t call the tool even though probe succeeds?

  • If you scoped the server under agents.<name>.mcpServers, confirm the agent you’re actually talking to is in that list
  • JSON5 is forgiving about commas, but a genuinely malformed brace/bracket will still fail — run openclaw mcp doctor fetchlayer --probe for a targeted diagnosis rather than re-reading the whole config file by eye

Why the Gateway model matters for a monitoring setup

If you’re using OpenClaw to run several agent sessions continuously — say, one watching a support channel, another triaging issues — configuring FetchLayer once at the Gateway level and routing it to specific agents is the point of this architecture. You’re not re-pasting an API key into N different config files or restarting N different local apps every time the key rotates; you update ~/.openclaw/openclaw.json once, and every routed agent picks up the change on its next Gateway restart. That’s a meaningfully different operating model from a single-user desktop client, and it’s worth setting up the agents.<name>.mcpServers scoping from Step 3 even if you only have one agent today — it’s much less friction to add a second agent later if the routing structure already exists.

Keep your key out of the committed config

Because openclaw.json lives on the Gateway host rather than a per-user machine, treat it like any server-side secrets file: don’t check it into a repo with the key inline, and restrict file permissions on the host so only the Gateway process (and you) can read it. If you’re running the Gateway across a team, consider a per-agent or per-environment key from your FetchLayer dashboard rather than sharing one key across every routed agent — it makes revoking access to a single misbehaving agent possible without rotating the key everyone else depends on.

What a tool call actually returns

Structured JSON, author nested per result:

{
  "results": [
    {
      "id": "1942939879222220800",
      "text": "Anyone else seeing timeouts since yesterday?",
      "author": { "handle": "example_dev", "displayName": "Example Dev", "followersCount": 12400 },
      "likeCount": 284,
      "retweetCount": 41,
      "replyCount": 63,
      "createdAt": "2026-08-18T10:00:00.000Z",
      "url": "https://x.com/example_dev/status/1942939879222220800"
    }
  ]
}

For a monitoring agent the useful part is that one search call yields enough to triage — engagement counts, audience size, timestamps, and URLs — so the agent can decide what merits a deeper call without making one.

A bounded autonomous run

Autonomous agents take an objective, so the objective has to carry the limits:

“Monitor X for mentions of our product over the last 24 hours. Open replies on at most three posts. Report any complaint that appears more than once, with the post URL. Stop after that.”

A sane run:

  1. search for the product, product: "Latest" — 1 request
  2. Rank by replyCount from data already returned — 0
  3. tweet-replies on three posts — 3 requests
  4. Report recurring complaints with URLs — 0

Four requests, terminating. Without “at most three” and “stop after that”, an agent optimizing for completeness will keep going — and unattended is exactly where nobody notices.

Never leave graph endpoints unbounded

user-followers and user-following bill per page. An autonomous agent asked to “understand who follows this account” has no reason to stop, and a large account can generate an enormous number of pages before it decides it’s finished.

Treat any prompt touching the follower graph as requiring an explicit page limit:

❌ “Analyze @bigaccount’s followers”

✅ “Fetch 2 pages of @bigaccount’s followers and describe the pattern”

This is the single most important guardrail for an unattended agent with these tools. Everything else is one request per call.

Verifying the output

Since every post carries a url, require citations and you get a free audit trail:

“Every claim must include the post URL it came from.”

Claims without URLs came from the model rather than from X. For a run nobody supervised, that’s the most practical check available.

What’s Next