Last updated: August 2026

Is it safe to connect an MCP server to my X account?

It depends on the server, not on MCP. The real risks are prompt injection from content the agent reads, a local server running arbitrary code on your machine, and a write scope nobody audited. Reduce them: pin versions, prefer hosted servers over npx, use a revocable key, and have the agent schedule rather than publish.

MCP is a protocol. It does not make anything safe or unsafe on its own. What matters is who wrote the server, where it runs, and what its tools can do to an account you care about.

Four risks, and what actually reduces each

1

Prompt injection through content the agent reads

Your agent reads a timeline, a webpage, an issue, or an email. Any of that text can contain instructions. If the agent also holds a publish tool, the person who wrote that text is one step from your account.

Reduce it: Keep a human between the draft and the timeline. Prefer scheduling to publishing so there is a queue to inspect. Do not connect a write tool to an agent whose whole job is reading untrusted input.

2

Arbitrary code execution from a local server

A stdio MCP server launched with npx downloads a package and runs it as you, with your environment variables and your filesystem. That is not an API call, it is software installation with no review step.

Reduce it: Prefer a hosted HTTP server, which cannot touch your machine. If you do run local, pin an exact version rather than latest, and read the package before you run it.

3

A write capability nobody audited

Tool lists are easy to skim past. A server may be able to delete posts, read your analytics, or send DMs, and you approved all of it by pasting one URL.

Reduce it: List the tools before you trust the server, and know which of them are destructive. Ask what happens if this key leaks, and prefer a key that can be revoked without touching your X login.

4

The key sitting in a config file

MCP config is plaintext JSON on disk. A workspace file like .vscode/mcp.json lives in a repository, and a bearer token in it gets committed and pushed.

Reduce it: Use the input or environment variable mechanism your client provides instead of inlining the token. Add the config to .gitignore. Rotate anything that has ever been in a commit.

Prompt injection is the one people underrate

The mental model that gets this wrong is treating the agent as an employee who might make a mistake. The better model is that everything the agent reads is potentially an instruction, because a language model does not reliably distinguish content from commands.

So a coding agent that reads GitHub issues, a research agent that reads webpages, and an inbox agent that reads email are all processing text written by strangers. Give any of them a tool that publishes to your account and you have connected a stranger's text to your timeline with one hop in between.

Better prompting does not fix this, and neither does asking the model to ignore instructions in content. What fixes it is architecture: reduce what the tool can do, and keep a step where a person sees the result before it becomes public.

Scheduling is the cheapest safety control you have

Publishing is irreversible in the way that matters: people see it, screenshot it, and quote it before you delete it. Scheduling turns the same action into a row in a queue that you can read and delete. If the agent schedules for two hours out, an injection attempt becomes something you notice rather than something you find out about.

Local servers are software installs, hosted servers are API calls

This distinction gets lost because both are one line of config. They are not the same thing at all.

two-very-different-lines.json
// Local: downloads a package and runs it as you.
// Full filesystem access, your environment variables, no sandbox.
{ "command": "npx", "args": ["-y", "some-mcp-server"] }

// Pinned local: same power, but you know exactly what version ran.
{ "command": "npx", "args": ["-y", "some-mcp-server@1.4.2"] }

// Hosted: an HTTPS request. It cannot touch your machine.
{ "type": "streamable-http",
  "url": "https://mcp.opentweet.io/mcp",
  "headers": { "Authorization": "Bearer ot_your_key" } }

The -y flag on npx suppresses the install prompt, and latest means the code that runs today is not the code you reviewed last month. For anything holding a credential to an account you care about, a hosted endpoint removes an entire category of risk, because the worst a compromised hosted server can do is misuse the tools it publishes. A compromised local package can read every secret on your machine.

Know both revocation paths before you need them

There are two independent levers and they do different things. Learn which is which now, not during an incident.

  • Rotate the API key. In your OpenTweet dashboard, delete the ot_ key. Every client configured with it stops working immediately. Your X connection is untouched, so you can issue a new key and carry on. This is the fast lever and it is the right first move.
  • Revoke the app on X. In X settings under Security and account access, Apps and sessions, Connected apps. This cuts the X side entirely and requires reconnecting afterwards. Use it when you want the account fully detached rather than the credential rotated.

The reason to prefer a service-issued key over handing raw X tokens to a third party is exactly this: a key you can revoke by itself gives you a small, fast lever. A leaked X OAuth token gives you only the big, slow one.

Check your repository right now

If you ever put a bearer token directly into .vscode/mcp.json or a committed client config, treat it as public and rotate it. Git history keeps it even after you delete the line, and a private repository is one visibility change away from not being private.

The eight question checklist

Run this before you paste any MCP server URL into a client that touches an account you care about. It takes two minutes and it is the whole of the practical advice on this page.

  1. Can I revoke this credential on its own, without changing my X password or disconnecting the account?
  2. Is the server hosted, or does connecting it run code on my machine?
  3. If it runs locally, is the version pinned to an exact number rather than latest?
  4. What is in the tool list, and which of those tools are destructive?
  5. Is the key in a file that could end up in a commit?
  6. Does the agent read content written by other people, and does it also hold a publish tool?
  7. Can the agent schedule instead of publish, so there is a queue I can inspect?
  8. Do I know the two revocation paths, and can I use them in under a minute?

Where OpenTweet lands on each

The MCP server is hosted at https://mcp.opentweet.io/mcp, so connecting it runs nothing on your machine. Keys are ot_ prefixed and revocable from the dashboard on their own. Scheduling is a first-class tool, so an agent can queue rather than publish. Setup details are in the MCP docs, and the full tool list is on the Twitter MCP server page.

7-day free trial. Cancel anytime.

Related decisions

If you are choosing between giving an agent a tool and calling an endpoint from your own code, the trade-off is in API vs MCP for posting. If you are weighing the official X MCP server, note that it publishes immediately with no queue to inspect, covered in can the official X MCP server schedule posts. And if the client in question is ChatGPT, the per-action confirmation modal and the plan gate are in which ChatGPT plans can post via MCP.

Frequently asked questions

Is it safe to connect an MCP server to my X account?

It depends on the server, not on MCP itself. Three risks matter: prompt injection from content the agent reads, a local server executing arbitrary code on your machine, and a write capability nobody audited. All three are reducible. Prefer hosted servers over ones you npx, pin versions if you do run locally, use a key you can revoke on its own, and have the agent schedule rather than publish.

What is prompt injection in the context of a posting tool?

An agent that reads a timeline, a webpage, an email, or a GitHub issue is reading text someone else wrote. If that text contains instructions and the agent holds a publish tool, the attacker is one step from your account. The mitigation is not better prompting, it is limiting what the tool can do and keeping a human between the draft and the timeline.

Are local MCP servers riskier than hosted ones?

Usually yes. A stdio server started with npx downloads a package and runs it on your machine with your user privileges and your environment variables, which is full code execution, not a sandboxed API call. A hosted HTTP server runs on someone else infrastructure and can only do what its published tools do. If you run local servers, pin exact versions and read what you are installing.

Where does my API key live when I configure an MCP server?

In a plaintext config file on your machine, such as .vscode/mcp.json in a repository or the client config in your home directory. The repository case is the dangerous one: a workspace config with a bearer token in it gets committed and pushed. Use your client input or environment variable mechanism, and add the file to .gitignore.

How do I revoke access if something goes wrong?

Two independent levers. Revoke the API key in your OpenTweet dashboard, which instantly stops every client using it without touching your X connection. And revoke the app itself in X settings under Security and account access, Apps and sessions, Connected apps, which cuts the X side. Rotate the key first, since it is the faster of the two.

Should I let an autonomous agent publish without approval?

Rarely. Have it schedule instead. A scheduled post sits in a queue you can inspect and delete before it goes live, which turns an irreversible action into a reversible one, and it costs you nothing in autonomy for anything that was not urgent.

Hosted, revocable, and it can schedule

Nothing runs on your machine, the key rotates on its own, and an agent can queue instead of publish. Flat $11.99 a month.

7-day free trial. Cancel anytime.