Which integrations are available for this server?

Integrates with JetBrains IDEs to post tweets and generate suggestions based on coding activity.

How do I use Build in Public MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Build in Public MCP Server Post to Twitter: Just shipped the new API integration!" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Build in Public MCP Server

by lucianfialho

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Build in Public MCP Server

v0.5.0

MCP (Model Context Protocol) server for Build in Public - share your dev progress on Twitter directly from Claude Code, Cursor, VS Code, JetBrains IDEs, and more.

What is this?

If Claude Code is already helping you build, why not use it to document the journey too?

This MCP server analyzes your coding sessions and generates tweet suggestions about what you accomplished.

Related MCP server: X (Twitter) MCP

Prerequisites: Twitter API Setup

You need a Twitter Developer account with API credentials. Here's how to get them:

Step 1: Create a Twitter Developer Account

Go to developer.x.com
Sign in with your Twitter account
Apply for a developer account (Free tier works)

Step 2: Create a Project and App

In the Developer Portal, click "Create Project"
Give it a name (e.g., "Build in Public")
Select use case: "Making a bot" or "Exploring the API"
Give your app a name (e.g., "build-in-public-mcp")

Step 3: Enable OAuth 1.0a with Write Permissions

In your app settings, go to "User authentication settings" → click "Set up"
Enable OAuth 1.0a
Set App permissions to "Read and write"
Set Type of App to "Web App, Automated App or Bot"
Set Callback URL to https://example.com (required but not used)
Set Website URL to https://example.com
Click "Save"

Step 4: Get Your API Keys

Go to "Keys and Tokens" tab
Under "Consumer Keys", click "Regenerate" (you need to regenerate AFTER enabling OAuth 1.0a)
Copy your API Key and API Key Secret

Important: You must regenerate the keys AFTER setting up OAuth 1.0a permissions, otherwise the keys won't have write access.

Installation

Claude Code (Recommended)

claude mcp add --transport stdio \
  -e TWITTER_API_KEY=your_api_key \
  -e TWITTER_API_SECRET=your_api_secret \
  build-in-public npx @lucianfialho/build-in-public-mcp

Cursor

Add to your ~/.cursor/mcp.json:

{
  "mcpServers": {
    "build-in-public": {
      "command": "npx",
      "args": ["@lucianfialho/build-in-public-mcp"],
      "env": {
        "TWITTER_API_KEY": "your_api_key",
        "TWITTER_API_SECRET": "your_api_secret"
      }
    }
  }
}

VS Code

Add to User Settings JSON (Ctrl+Shift+P → "Preferences: Open User Settings (JSON)"):

{
  "mcp.servers": {
    "build-in-public": {
      "command": "npx",
      "args": ["@lucianfialho/build-in-public-mcp"],
      "transport": "stdio",
      "env": {
        "TWITTER_API_KEY": "your_api_key",
        "TWITTER_API_SECRET": "your_api_secret"
      }
    }
  }
}

Claude Desktop

Add to your config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "build-in-public": {
      "command": "npx",
      "args": ["@lucianfialho/build-in-public-mcp"],
      "env": {
        "TWITTER_API_KEY": "your_api_key",
        "TWITTER_API_SECRET": "your_api_secret"
      }
    }
  }
}

Global Install (Alternative)

npm install -g @lucianfialho/build-in-public-mcp
claude mcp add --transport stdio \
  -e TWITTER_API_KEY=your_api_key \
  -e TWITTER_API_SECRET=your_api_secret \
  build-in-public build-in-public-mcp

Quick Start

1. Authenticate with Twitter

After installing and configuring your API keys, authenticate via OAuth:

You: Setup build in public authentication

Claude: Authorization URL opened in your browser!
        After authorizing, Twitter will show you a PIN code.

You: The PIN is 1234567

Claude: Authenticated as: @your_username
        Tokens saved to: ~/.build-in-public/auth.json

The OAuth flow generates access tokens that are saved locally. You only need to do this once.

2. Post Tweets

Quick tweet:

"Post to Twitter: Just launched my new feature!"

AI-powered retro (analyzes your whole coding session):

"Analyze my session and help me share what I accomplished on Twitter"

Get suggestions:

"Give me tweet suggestions based on what I've been working on"

Environment Variables

Variable	Required	Description
`TWITTER_API_KEY`	Yes	Twitter API Key (Consumer Key)
`TWITTER_API_SECRET`	Yes	Twitter API Secret (Consumer Secret)
`TWITTER_ACCESS_TOKEN`	No	Skip OAuth - use access token directly
`TWITTER_ACCESS_SECRET`	No	Skip OAuth - use access secret directly

If you provide all 4 variables, the OAuth flow is skipped entirely.

Available Tools

Tool	Description
`setup_auth`	OAuth PIN-based authentication flow
`status`	Check auth status and configuration
`tweet`	Post a single tweet (max 280 chars)
`thread`	Create a Twitter thread from multiple messages
`suggest`	Generate tweet suggestions from session context
`save_context`	Save coding session context for suggestions
`get_context`	Retrieve current session context

Architecture

AI IDE/Editor -> STDIO -> MCP Server (local) -> Twitter API
                              |
                   ~/.build-in-public/
                   - auth.json (OAuth tokens)
                   - context.json (Session context)
                   - history.json (Tweet history)

100% local, zero external infrastructure.

Privacy & Security

OAuth tokens stored locally in ~/.build-in-public/auth.json with 0600 permissions
Never sent to external servers (except Twitter API)
No analytics, no tracking, no telemetry
Open source

Contributing

Contributions, issues, and feedback welcome.

Repository: github.com/lucianfialho/build-in-public-mcp

License

MIT

Available Tools

8 tools

get_contextC

Retrieve current session context

ParametersJSON Schema

Name	Required	Description	Default
`contextId`	No	Optional context ID (uses current session if not provided)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It does not disclose whether the call mutates state, requires authentication, or has rate limits. The reader only knows it retrieves context, nothing else.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no extraneous words. It front-loads the action and resource effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one optional parameter, but it lacks any detail about what data is returned. Since there is no output schema, the description should at least hint at the structure or content of the context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single optional parameter. The description adds no additional semantics beyond the schema's description. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Retrieve') and resource ('current session context'). It is specific enough to distinguish from parameterless tools like 'status', but not from 'save_context' which is its counterpart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'save_context'. There is no indication of prerequisites or when retrieval is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp__bip__configureB

Configure user preferences for Build in Public (language and features)

ParametersJSON Schema

Name	Required	Description	Default
`features`	No	Feature flags to enable/disable specific tweet types
`language`	No	Preferred language for tweets and messages

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description bears full transparency burden. It fails to disclose that this is a mutation operation, whether changes are persisted, or any side effects like requiring authentication. The description only states the purpose, not the behavioral impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence of 10 words, no redundancy. Purpose is front-loaded, and every word contributes meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a configuration tool that mutates user preferences, the description is too minimal. It does not explain that all parameters are optional, what default values are, or if the changes are applied immediately. Given no output schema or annotations, more context is needed for agent decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with detailed descriptions for each parameter. The tool description adds no additional meaning beyond parsing the schema. Hence baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Configure' and resource 'user preferences' with specific scope 'language and features'. It is distinct from sibling tools like get_context or suggest, which are retrieval or action tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. It does not mention prerequisites, default states, or when configuration changes take effect. Sibling tools like setup_auth might be relevant pre-requisites but are not referenced.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

save_contextB

Save session context for later analysis and suggestions

ParametersJSON Schema

Name	Required	Description	Default
`context`	Yes	Session context data

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description bears full burden. It discloses the purpose but omits behavioral details such as idempotency, persistence guarantees, overwrite behavior, authentication needs, or side effects. For a mutation tool, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the verb and resource, and contains no unnecessary words. However, it is too terse and sacrifices completeness for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has a single complex parameter (nested object), no output schema, and no annotations, the description is incomplete. It does not explain return values, success indicators, failure modes, or how this interacts with sibling tools like 'suggest' or 'get_context'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a generic description for the context parameter. The tool description adds purpose (saving for analysis) but no additional structure or constraints for the object. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool saves session context for later analysis and suggestions, using a specific verb ('save') and resource ('session context'). It implicitly distinguishes from sibling 'get_context' which retrieves context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the usage scenario (saving for later analysis) but does not explicitly state when to use this tool versus alternatives like 'get_context' or 'suggest'. No exclusions or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

setup_authA

Setup Twitter authentication via OAuth 1.0a (PIN-based flow). Call without PIN to get authorization URL, then call again with PIN to complete.

ParametersJSON Schema

Name	Required	Description	Default
`pin`	No	PIN code from Twitter (leave empty to start OAuth flow)

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the two-step OAuth flow, a key behavioral trait, but does not detail potential side effects, error conditions, or state persistence beyond the flow. This is adequate but leaves gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the core purpose, and contains no superfluous text. Every sentence is essential for understanding the tool's operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (two-step OAuth), one parameter, and no output schema, the description adequately explains the overall flow. However, it omits details about expected outputs (authorization URL format) and error handling, which would be helpful for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (the 'pin' parameter is well-documented). The description adds value by explaining the two-step usage pattern (first call empty, second call with PIN), which is not fully captured in the schema's 'leave empty to start OAuth flow'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sets up Twitter authentication via OAuth 1.0a PIN-based flow, specifying the two-step process. This verb-resource pair distinguishes it from sibling tools (e.g., tweet, thread) which are unrelated to authentication.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit instructions on when to call without PIN (to get authorization URL) and when to call with PIN (to complete), establishing a clear usage context. However, it does not include exclusions or alternative tools for authentication.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

statusB

Check authentication status and storage location

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior. It states a read check but does not explain side effects, required prior setup, or what happens on failure. The word 'Check' implies non-destructive behavior, but this is implicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence. It is front-loaded and contains no fluff. However, it could be slightly more informative without sacrificing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 params, no output schema), the description covers the core purpose. However, it does not explain the output format or what 'storage location' refers to, leaving some ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are 0 parameters and 100% schema description coverage. The baseline for 0 params is 4, and the description adds no parameter info because none exist. No additional meaning needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: checking authentication status and storage location. It uses a specific verb ('Check') and resource ('authentication status and storage location'), and the purpose is distinct from sibling tools like 'setup_auth' or 'get_context'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description only states what it does, without mentioning prerequisites, preferred scenarios, or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

suggestC

Generate intelligent tweet suggestions based on session context

ParametersJSON Schema

Name	Required	Description	Default
`contextId`	No	Optional context ID (uses current session if not provided)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries full burden. It only states the tool generates suggestions based on session context, but does not disclose side effects, authentication requirements, rate limits, or behavior when contextId is invalid. This is insufficient for a tool with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that conveys the core purpose. It is appropriately brief with no wasted words, though it could benefit from additional detail without sacrificing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only one optional parameter and no output schema, the description is minimally adequate. However, it does not explain the format or quantity of suggestions, nor how they are returned, leaving some gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single parameter 'contextId', which is already described in the schema as optional. The description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates tweet suggestions based on session context. It uses a specific verb and resource, distinguishing it from siblings like 'tweet' (which posts tweets) and 'get_context' (which retrieves context). However, it could be more specific about what 'intelligent' entails.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'tweet' or 'get_context'. The description implies use when generating suggestions from context, but does not explicitly state when to avoid it or provide comparisons with siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

threadA

Create a Twitter thread from multiple messages. Posts tweets in reply chain.

ParametersJSON Schema

Name	Required	Description	Default
`messages`	Yes	Array of tweet messages for the thread
`replyToTweetId`	No	Optional: Tweet ID to reply to (creates thread as replies to this tweet)

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description adds behavioral context ('Posts tweets in reply chain') but with no annotations, it lacks details on rate limits, error handling, or success behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with core purpose, each sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Sufficient for a simple 2-parameter tool with no output schema, though misses optional explanation of return value or side effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers both parameters with descriptions (100% coverage). Description adds no additional semantic meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Create a Twitter thread from multiple messages', specifying the verb and resource. It distinguishes from sibling 'tweet' by emphasizing multiple messages in a reply chain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied from purpose but no explicit guidance on when to use this vs alternatives like 'tweet', nor any prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tweetC

Post a tweet immediately for build in public. Requires authentication.

ParametersJSON Schema

Name	Required	Description	Default
`message`	Yes	The tweet message to post (max 280 characters)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It mentions authentication but lacks details on rate limits, whether tweets are public, error handling, or idempotency. The word 'immediately' suggests real-time posting but is vague.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence conveys purpose and a key constraint (authentication). It is concise and front-loaded, though it could benefit from breaking into two sentences for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is adequate but lacks behavioral details and usage guidance that would fully inform an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters with a description for 'message' (max 280 chars). The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Post a tweet immediately for build in public', which directly describes the action and resource. It distinguishes from sibling tools like 'thread' by implying this is for single tweets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'thread' or 'suggest'. It does not mention any prerequisites or context for use beyond authentication.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a distinct purpose: authentication, context management, tweeting, threads, suggestions, and configuration. There is no overlap or ambiguity.

Naming Consistency2/5

Naming patterns are inconsistent: some use verb_noun (get_context, save_context, setup_auth), others are single verbs (suggest, thread, tweet) or nouns (status), and one has a non-standard prefix (mcp__bip__configure).

Tool Count5/5

8 tools is well-scoped for a build-in-public Twitter client, covering authentication, context, posting single tweets, threads, and suggestions without being excessive.

Completeness4/5

Core posting workflow is covered (tweet, thread, auth, context), but lacks tools for deleting tweets, viewing history, or scheduling, which are minor gaps.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

PilotMyX
com.pilotmyx
Stop guessing what works on X/Twitter. Analyze your history, draft in your voice, schedule posts.
Social Media Marketing
1
SocialDataX X / Twitter MCP A
com.52choujiang
X / Twitter public post, comment, reply, user, and search tools.
Social Media Search
161
VibeCom Growth Autopilot
app.vibecom
Marketing autopilot in your IDE. AI turns codebase and context into content for 10+ platforms
Developer Tools Marketing Autonomous Agents
2
twitr.sh A
sh.twitr
X/Twitter reads, search, monitors and posting. Pay-per-call in USDC — no signup, no API keys.
Social Media Communication
1421

Related MCP Servers

Twitter MCP Server
Social Media Search Marketing
vinod827
F
license
Not graded
quality
D
maintenance
Enables LLM agents to interact with Twitter (X) for searching tweets, posting content with images, analyzing engagement, and extracting topics using the Twitter API.
Updated 8 months ago (2025-12-22 14:28 UTC)
X (Twitter) MCP
Social Media Communication
arnaldo-delisio
A
license
Not graded
quality
D
maintenance
Enables interaction with X (Twitter) to post tweets, threads, and replies while retrieving tweet metrics and account information. It supports core management tasks like deleting tweets and verifying authentication through the Twitter API.
Updated 9 months ago (2025-12-09 15:19 UTC)
MIT
TwitterAPI.io MCP Server
Social Media Search
DevRico003
A
license
Not graded
quality
D
maintenance
Provides AI agents and coding assistants with Twitter data access including tweets, user profiles, followers, and search functionality.
Updated a year ago (2025-05-15 19:19 UTC)
MIT
x-mcp-server
MindMadeLab
A
license
Not graded
quality
C
maintenance
Enables AI assistants to interact with X (Twitter) API v2 for posting tweets, searching, liking, retweeting, and more through natural language.
Updated 5 months ago (2026-03-27 12:17 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lucianfialho/build-in-public-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server