Agent integrations and MCP servers
MCP integrations that expose product, database, browser, developer-tool, automation, design, and business-system capabilities to agents.
32%
Best tweets about Model Context Protocol
50 Best Tweets About Model Context Protocol (2026)
Read the best tweets about Model Context Protocol, including MCP servers, clients, tools, security, integrations, and implementation lessons. Updated weekly.
Technical MCP implementations and ecosystem analysis, with bare and unrelated uses of the acronym excluded.
- Creators
- 44
- Updated
Original Xholic analysis
What 50 top Model Context Protocol posts reveal
The supplied corpus is implementation-heavy: posts describe MCP connections to databases, design workflows, browser-page information, simulators, and other product capabilities. Tool-surface design and governance are recurring themes, with posts discussing scoped discovery, code-mode approaches, OAuth, allowlists, and enterprise authorization. [2042486942802321552, 2065449153014939755, 2067959080606700005]
- Dominant tone
- Positive
- Median score
- 11.3
- Leading format
- Announcement
- Recent posts
- 46%
62% of posts
All-time engagement
46% of posts
Published in 90 days
Conversation map
The themes creators return to
Ecosystem evolution and architectural strategy
Ecosystem adoption, platform positioning, registries/gateways, specification evolution, and debate over MCP versus CLIs, skills, or direct integrations.
28%
Tool discovery, design, and context efficiency
Managing tool sprawl and context overhead through filtering, scoped toolsets, progressive discovery, code mode, composite workflows, and server design patterns.
28%
Implementation and integration patterns
Hands-on MCP server and client implementations, including local/remote deployment, transports, SDKs, OAuth setup, and cross-language development.
20%
Security, authorization, and governance
Security, authorization, governance, and operational controls for MCP servers, including tool poisoning, prompt injection, OAuth, enterprise identity, policy, and observability.
20%
Knowledge, retrieval, and memory
MCP for agent knowledge access: RAG, codebase retrieval, private data, memory, documentation, and domain-specific context.
14%
Protocol architecture and concepts
Protocol fundamentals: host-client-server architecture, JSON-RPC, tools, resources, prompts, and how MCP differs from REST APIs and native function calling.
12%
MCP Apps and interactive UI
MCP Apps and interactive agent interfaces, including server-provided UI widgets, bidirectional app workflows, and generative UI in conversational clients.
10%
Tone and stance
Sentiment Positive leads
Author posture Supportive leads
Performance benchmark
- Median likes
- 27
- Median reposts
- 4
- Median replies
- 4
- Median views
- 2.4K
Posts with media make up 58% of this collection. Their median all-time score is 18.2, compared with 1.19 for text-only posts.
Format mix
- Announcement 46% · score 16.1
- Tutorial 20% · score 19.8
- Opinion 16% · score 3.45
- Case Study 14% · score 8.42
Consensus and debate
Where creators agree, and where they do not
Shared view
MCP is used as an integration surface
Posts showcase MCP servers exposing database access, bidirectional design workflows, browser-page interaction, and simulator interaction to agent clients.
Shared view
Tool-surface discipline is a recurring implementation concern
Tool sprawl and context overhead recur in implementation posts. Proposed approaches include scoped toolsets, progressive discovery, composite tools, and code-mode interfaces that avoid loading broad schemas upfront.
Shared view
Security appears in implementation guidance
Security-oriented implementation posts cover OAuth, tool allowlists, enterprise-managed authorization, local or private-data access, policy hardening, and operational logging.
Open debate
MCP is not presented as a universal abstraction
Posts debate when MCP is the appropriate abstraction. They distinguish MCP from skills and native function calling, and one architectural view positions MCP alongside skills and CLIs rather than as the only connectivity mechanism.
Open debate
Raw tool exposure has competing design approaches
Several posts criticize large tool schemas and broad tool lists. Code mode, smaller discovery interfaces, and workflow-oriented tools are proposed as alternatives or mitigations; the posts do not identify a single settled pattern.
Open debate
Governance concerns accompany adoption
Security posts range from warnings about tool poisoning, tool shadowing, mutation, and prompt injection to operational controls such as allowlists and enterprise-managed authorization.
What performs
Patterns behind standout posts
Top outliers center on concrete implementations and product releases
The five supplied benchmark outliers cover an X/OpenClaw setup tutorial and announcements involving Google’s database toolbox, Figma’s bidirectional server, n8n support, and Playwright MCP. Their all-time scores range from 417.63 to 1718.91.
Integration content is the largest theme
“Agent integrations and MCP servers” is the largest theme, representing 32% of tweets (16 tweets), with a median all-time score of 26.02.
Context efficiency is a substantial editorial thread
“Tool discovery, design, and context efficiency” represents 28% of tweets (14 tweets), tying “Ecosystem evolution and architectural strategy” as the second-largest theme. Its median all-time score is 4.81.
Statistical standouts
- View standout post 1 Score 1718.9 · 152.52× median
- View standout post 2 Score 787.2 · 69.85× median
- View standout post 3 Score 566.4 · 50.26× median
- View standout post 4 Score 464.4 · 41.21× median
- View standout post 5 Score 417.6 · 37.06× median
Creator landscape
Who shapes this conversation
The five most represented creators account for 20% of the selected posts.
-
1. Avi Chawla
@_avichawla
2 posts
-
2. Vaishnavi
@_vmlops
2 posts
-
3. Aurimas Griciūnas
@Aurimas_Gr
2 posts
-
4. Paul Iusztin
@pauliusztin_
2 posts
-
5. Sagar Batchu
@sagar_batchu
2 posts
-
6. DEV Community
@ThePracticalDev
2 posts
Avi Chawla connects MCP, skills, and interactive UI
Avi Chawla distinguishes MCP’s connectivity role from skills as procedural guidance. A separate post demonstrates an MCP Apps workflow that associates tools with interactive UI components.
Aurimas Griciūnas argues for selective adoption
Aurimas Griciūnas presents MCP as a way to standardize access to retrieval domains, while arguing that teams should use native function calling when MCP standardization is unnecessary.
Vaishnavi spotlights agent-facing infrastructure
Vaishnavi’s two cited posts highlight database-toolbox and Playwright MCP announcements aimed at giving agents structured access to databases and browser-page information.
How this analysis was made
Themes, sentiment, stance, and post format are classified per tweet. All counts, shares, medians, creator concentration, freshness, and performance comparisons are then calculated directly from the published snapshot.
Xholic's all-time score compares engagement while accounting for reach, post age, and creator consistency. It is used for relative comparisons within this collection.
This report analyzes the exact 50-post snapshot shown below. AI identifies editorial categories and drafts explanations; all statistics are calculated from the snapshot, and every narrative claim is checked against cited posts before publication.
Best Model Context Protocol tweets
Top Model Context Protocol tweets from 44 creators
Ranked 01–50
- 01
@jonoringer ·
This is huge : @X released an MCP server today.. How to Connect X to your 🦞 : **Step 1: Run the XMCP Server** git clone https://t.co/28snn6oaEa cd xmcp cp env.example .env Edit the .env file with your X OAuth consumer key and secret. Set the callback URL to http://127.0.0.1:8976/oauth/callback in your X Developer app. For safety, add an allowlist such as: X_API_TOOL_ALLOWLIST=searchPostsRecent,createPosts,getUsersMe,getPostsById,likePost,repostPost Then run: python -m venv .venv && source .venv/bin/activate pip install -r requirements.txt python https://t.co/yO2ogIBpks The server will be available at http://127.0.0.1:8000/mcp. Complete the OAuth flow on first run and keep this process active. **Step 2: Add XMCP in @OpenClaw** Use the following command: openclaw mcp set x '{ "url": "http://127.0.0.1:8000/mcp" }' Verify with: openclaw mcp list openclaw mcp show x **Step 3: Test the Integration** Restart the OpenClaw agent or reload MCP configuration if required. Test by sending these prompts to OpenClaw in your chat app: - Search recent posts about MCP on X and summarize the top trends - Draft and post this thread on X - Get my X profile information - Like the latest post from @xdevplatform OpenClaw will use the XMCP tools automatically when relevant. **Key Benefits** - OpenClaw provides persistent memory and works across multiple messaging platforms. - XMCP delivers standardized access to X API functionality. - Combined, they enable an agent that can research trends, post content, engage with posts, and report results within your existing chat workflows. **Safety and Configuration Notes** Start with a minimal tool allowlist in the XMCP .env file. Expand gradually after testing. The allowlist can be updated and requires restarting the XMCP server. Monitor logs in both the XMCP server and OpenClaw for troubleshooting. X actions performed by the agent are public. XMCP repository: https://t.co/fIxYHLI33T OpenClaw MCP documentation: https://t.co/15Rod9Q4QG
- 02
@_vmlops ·
GOOGLE JUST MADE IT DEAD SIMPLE TO CONNECT AI AGENTS TO ANY DATABASE postgres, mysql, mongodb, bigquery, redis, elasticsearch, spanner, snowflake. 20+ databases supported mcp toolbox is an open source...mcp server that gives your ai agents direct access to your enterprise databases in plain english no custom connectors, no boilerplate, built-in connection pooling, auth, and opentelemetry out of the box works with langchain, llamaindex, genkit, and any mcp-compatible client less than 10 lines of code to plug it into your agent https://t.co/6e4EY2gIfo this is google making database access the easy part of building ai agents
- 03
@mariorod1 ·
Design → code → canvas → feedback → repeat. The @figma MCP server is now bidirectional. @GitHub Copilot users can pull design context into code and push working UI back to the Figma canvas, all from @code . No handoffs or context switching. Just flow. https://t.co/FbDcp7kboG
Watch video
- 04
@EXM7777 ·
n8n shipped native MCP support and nobody's connecting what this actually means... your AI agents can now CREATE and MODIFY n8n automations programmatically the setup: > install the n8n-mcp server > add it to your Claude Code config > Claude now has access to all 1,396 n8n nodes (812 core + 584 community) what used to happen: > open n8n dashboard > manually drag nodes > configure each one > test, debug, repeat > 45 minutes per workflow what happens now: > "build me an automation that monitors my competitors' pricing pages every 6 hours and sends a Slack alert when anything changes" > Claude builds the entire n8n workflow > 3 minutes, zero mistakes the real implication: your agents can now build their own automations not "trigger existing workflows"... literally construct new ones from scratch based on what they need this is the beginning of self-automating systems
- 05
@_vmlops ·
MICROSOFT BUILT AN MCP SERVER FOR PLAYWRIGHT and it changes how ai agents interact with the web most browser agents rely on screenshots + vision models to "see" the page playwright-mcp skips all that it reads the accessibility tree instead structured, clean, zero ambiguity your llm knows exactly what's on the page & what to do with it no hallucinated clicks no broken selectors works with cursor, vs code, claude desktop https://t.co/wWDkXlEUA4
- 06
- 07
@pontusab ·
The best foundation to position your product right now: - MCP server with OAuth - Claude and ChatGPT connectors - APIs and SDKs - Chat interfaces like iMessage and WhatsApp - A dashboard that uses the same MCP layer - Open source
Watch video
- 08
@betomoedano ·
Xcode 27 ships with the xcode-tools MCP server which allows your agent to interact with the simulator. This helps agents validate that the feature actually works (video is at 4x speed)
Watch video
- 09
@_avichawla ·
MCP & Skills for AI agents, clearly explained! Devs treat MCP and Skills like they're the same thing. They're not. Conflating them is one of the most common mistakes I see when people start building AI agents seriously. So let's break both down from scratch. Before MCP existed, connecting an AI model to an external tool meant writing custom integration code every single time. For instance, 10 models and 100 tools led to 1,000 unique connectors to build and maintain. MCP fixed this with a shared communication standard. Tools became a part of a “server” that exposed its capabilities. Every AI agent became a “client” that knew how to ask. They talked through structured JSON messages over a clean, well-defined interface. For instance, one could build a GitHub MCP server once, and it worked with Claude, ChatGPT, Cursor, or any other agent that spoke MCP. That’s the core value: write the integration once, use it everywhere. MCP solved the connection problem. But it did not solve the usage problem. This means you can hand an agent 50 perfectly wired MCP tools, and it can still underperform if it doesn’t know when to call which tool, in what order, and with what context. That’s the gap Skill intends to fill. A Skill is a portable bundle of procedural knowledge. Think of a SKILL(.)md file that tells an agent not just “here are your tools” but “here’s how to use them for this specific task.” - A writing skill could bundle tone guidelines and output templates. - A code review skill can bundle patterns to check and rules to follow. MCP gives the agent a hand. Skills give it muscle memory. Together, they form the full capability stack for a production AI agent: - MCP handles tool connectivity (the wiring layer) - Skills handle task execution (the knowledge layer) - The agent orchestrates both using its context and reasoning This is why advanced agent setups increasingly ship both: MCP servers for integrations and SKILL(.)md files for domain expertise. ____ Find me → @_avichawla Every day, I share tutorials and insights on DS, ML, LLMs, and RAGs.
Watch video
- 10
@srishticodes ·
🚨Breaking: Someone just open sourced a knowledge graph engine for your codebase and it's terrifying how good it is. It's called Repowise. And it's not another "generate docs and forget" tool. 500+ stars on github in just 2 days. It's a self-hosted codebase documentation engine that builds confidence-scored docs from your actual code, tracks git drift in real time, and serves everything through an MCP server your AI agent can query mid-task. Here's what this thing does: → Parses your entire repo and generates documentation with per-section confidence scores → Watches every commit. When code changes, confidence scores degrade automatically → Runs fully local. Your code never leaves your machine. Ever. → Ships 8 MCP tools that plug directly into Cursor, Claude Code, and Windsurf → Supports local models. Ollama, LM Studio, whatever you're running → Regenerates stale sections on demand when confidence drops below your threshold → Lets your AI agent ask "what does this service do" and get an answer it can actually trust Here's the wildest part: Your AI agent reads autogenerated docs from 3 weeks ago. The auth module got refactored twice since then. Agent hallucinates a function signature that hasn't existed for 11 days. Broken code ships. Repowise would have flagged that doc section at 23% confidence before your agent ever touched it. Every other tool generates docs once and walks away. Repowise treats documentation as a living system with a trust score attached to every paragraph. One command to set it up: npx repowise init MCP server starts automatically. Your AI agent stops hallucinating about your codebase. Self-hosted. Confidence-scored. Git-aware. 8 MCP tools out of the box. Your AI agent has been reading dead documentation. This fixes that. 100% Open Source. Link: https://t.co/Jwy4I4ueoV
Watch video
- 11
@chadwahl ·
Because I get asked a lot Ontology-MCP (O-MCP): I want dynamic interactions at runtime with my favorite MCP client agents/frameworks. Think runtime. Palantir-MCP (P-MCP): I want to build pipelines, objects, generally do anything builders do in the platform. Think development. Ontology SDK (OSDK): I am building apps/integrations backed by the Ontology. Think design time. data, logic, action
- 12
@pauliusztin_ ·
There is a new way of building software powered by AI. Here is the architecture: Most teams are building AI applications by taking existing frontend/backend architectures and stitching agents and MCP servers into the backend. Which makes sense. Every new paradigm starts by adapting the old one. But as David Soria Parra (@AnthropicAI, co-creator of MCP) put it: "Connectivity is not one thing. The best agents use all of it - skills, CLI, MCP - together." This idea changed how I think about agent architecture... Browsers remain the primary interface. But we're moving toward a world where a single chat interface can render whatever the agent returns. The browser was built to navigate websites. AI-native interfaces are being built to generate them on demand. The architecture I see emerging across serious AI applications looks like this: 1/ Presentation The thin renderer. Today, this means: TUI (Claude Code) IDE extensions (Cursor, VS Code) Web applications Desktop applications (ChatGPT, Gemini) With MCP Apps, clients can render server-shipped UIs directly from the harness. The same MCP App can run across Claude, ChatGPT, and Cursor without rewriting the UI. 2/ Harness + Runtime The brain of the system. This is where: The LLM ↔ tool loop lives Memory lives • Permissions live Orchestration lives Agents are becoming long-running systems rather than single inference calls. Which means they need: Durable execution Retries Checkpoints Human approvals Observability This is why I increasingly think of tools like @PrefectIO as part of the runtime itself. 3/ Connectivity The right tool for the right job. Skills → reusable user domain knowledge CLIs → local host capabilities MCP Clients → auth, resources, tasks, and UI Modern agents use all three. Single-mechanism agents underperform. 4/ MCP Servers Where business logic and private data live. A modern MCP server ships: Tools Resources Prompts Skills MCP Apps Tasks + elicitation In Python, @fastmcp (by @PrefectIO) has effectively become the practical default. Even David Soria Parra said: "It’s just way better than our Python SDK that we shipped." The MCP ecosystem recently crossed 110M monthly downloads. React took roughly twice as long to get there. This is what "full connectivity" looks like. Four layers. Each independently decomposable. MCP acts as the connective tissue between them. P.S. Do you think browsers become obsolete once chat interfaces can render any application on demand?
- 13
@Aurimas_Gr ·
Integrating 𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗥𝗔𝗚 Systems via 𝗠𝗖𝗣 👇 If you are building RAG systems and packing many data sources for retrieval, most likely there is some agency present at least at the data source selection for retrieval stage. This is how MCP enriches the evolution of your Agentic RAG systems in such case (𝘱𝘰𝘪𝘯𝘵 2.): 𝟭. Analysis of the user query: we pass the original user query to a LLM based Agent for analysis. This is where: ➡️ The original query can be rewritten, sometimes multiple times to create either a single or multiple queries to be passed down the pipeline. ➡️ The agent decides if additional data sources are required to answer the query. 𝟮. If additional data is required, the Retrieval step is triggered. We could tap into variety of data types, few examples: ➡️ Real time user data. ➡️ Internal documents that a user might be interested in. ➡️ Data available on the web. ➡️ … 𝗧𝗵𝗶𝘀 𝗶𝘀 𝘄𝗵𝗲𝗿𝗲 𝗠𝗖𝗣 𝗰𝗼𝗺𝗲𝘀 𝗶𝗻: ✅ Each data domain can manage their own MCP Servers. Exposing specific rules of how the data should be used. ✅ Security and compliance can be ensured on the Servel level for each domain. ✅ New data domains can be easily added to the MCP server pool in a standardised way with no Agent rewrite needed enabling decoupled evolution of the system in terms of 𝗣𝗿𝗼𝗰𝗲𝗱𝘂𝗿𝗮𝗹, 𝗘𝗽𝗶𝘀𝗼𝗱𝗶𝗰 𝗮𝗻𝗱 𝗦𝗲𝗺𝗮𝗻𝘁𝗶𝗰 𝗠𝗲𝗺𝗼𝗿𝘆. ✅ Platform builders can expose their data in a standardised way to external consumers. Enabling easy access to data on the web. ✅ AI Engineers can continue to focus on the topology of the Agent. 𝟯. Retrieved data is consolidated and Reranked by a more powerful model compared to regular embedder. Data points are significantly narrowed down. 𝟰. If there is no need for additional data, we try to compose the answer (or multiple answers or a set of actions) straight via an LLM. 𝟱. The answer gets analyzed, summarized and evaluated for correctness and relevance: ➡️ If the Agent decides that the answer is good enough, it gets returned to the user. ➡️ If the Agent decides that the answer needs improvement, we try to rewrite the user query and repeat the generation loop. Are you using MCP in your Agentic RAG systems? Let me know about your experience in the comment section 👇
- 14
@techNmak ·
Finally, a 100% open-source MCP-Apps infrastructure. With just a few lines of code, CopilotKit now lets you bring MCP-Apps into your copilot via AG-UI. Agents can return interactive mini-apps inside your copilot, not just text. > It works with any agent framework (ADK, LangChain, Mastra, Strands, Pydantic, etc). > Your app and MCP server communicate bidirectionally. > AG-UI middleware lets you connect to different types of apps. > MCP-Apps are treated as frontend tools the agent can invoke. This brings OpenAI-style MCP-Apps into your own product, without being locked to a single model, platform, or provider. For context: CopilotKit is an open-source framework for building in-app AI copilots and the team behind the AG-UI protocol. If you’re building agentic apps, this adds a real UI interaction layer inside your copilot. Bringing MCP-Apps into copilots is quickly becoming a standard across the ecosystem. This is part of the agentic future, and where generative UI is headed. Definitely worth checking out. All open source ↓
Watch video
- 15
@IntuitMachine ·
What if the reason your LLM agent feels "dumb" has nothing to do with the model—and everything to do with how you structured your MCP server? Here's what 15 production deployments teaches us about why agents succeed or fail. 🧵 2/ We keep hitting the same wall: an agent that was brilliant with 5 tools would completely fall apart at 15. Not slightly worse. Completely unusable. Same model. Same prompts. The only difference? How many tools we exposed. 3/ Turns out LLMs select tools by reading descriptions, not by browsing schemas like a human engineer would. That simple fact changes everything about how you should design an MCP server. 4/ Researchers analyzed 15 independently built MCP servers—5 from production voice AI deployments, 10 from the public registry. Five recurring patterns emerged. Each addresses a different way the LLM-client constraint breaks naive designs. 5/ Pattern 1: Resource Gateway Expose backend data as stable URIs with sanitization layers. Why it matters: user-generated content like "Ignore previous instructions…" will be processed as instruction, not data. Gateway pattern puts sanitization in one place. 6/ Pattern 2: Tool Orchestrator Collapse multi-system workflows into single composite tools. The LLM sees "create_and_notify_ticket" instead of juggling 3 separate APIs. Accuracy jumps. But there's a catch… 7/ Pattern 3: Stateful Session Server Manage conversational state server-side behind an opaque session ID. The killer feature: multi-turn "open file → edit → save" workflows become natural. The hidden trap: memory leaks if you don't reap sessions. We learned this the hard way. 8/ Pattern 4: Proxy Aggregator (the scoped variant) Route 50+ upstream MCP servers behind one endpoint but only expose the subset relevant to the current task. Static merging makes the problem worse. Scoped filtering is the only escape hatch. 9/ Pattern 5: Domain-Specific Adapter Wrap hostile APIs with human-readable descriptions, fuzzy input normalization, and plain-English errors. Example: accept "next Tuesday" instead of ISO-8601. The LLM succeeds; your API doesn't change. [The Actionable Bridge: Making It Real] 10/ Here's the part that surprised us most: Tool selection accuracy collapses between 10 and 15 tools for Haiku-class models. At 20 tools, Sonnet 4 drops below 90%. At 30, both models are guessing. [mini chart or screenshot of Fig. 2] 11/ So the tool-count budget is now a first-class architectural constraint. If you're building an MCP server that exposes more than ~12 tools, you must use the scoped Proxy Aggregator pattern or your agent will fail in ways that feel random but are actually structural. 12/ Quick audit: How many of your MCP tools have vague or missing descriptions? We found servers with names like "send_message" and no description. The LLM has no idea when to use it. Fix: write descriptions like you're explaining to someone who's never seen it before. 13/ These aren't MCP-specific hacks. They're classical software patterns—Facade, Adapter, Proxy—applied through the lens of a client that selects operations by reading descriptions instead of consulting docs. The delta is small. The implications are huge. 14/ Three leverage points if you take nothing else: Treat tool descriptions as load-bearing code (review them like schemas) Use scoped aggregation, not static merging Explicit session hygiene or you will leak state 15/ One more thing: The highest-leverage architectural decision is often removing a tool, not adding one. If your agent feels overwhelmed, the fix isn't a better prompt. It's a smaller, clearer tool surface. Less is more. Literally.
- 16
@DivyanshT91162 ·
What if you had access to a global intelligence platform... for free? This open-source project turns any AI agent into a real-time intelligence analyst. Phoenix Intelligence Dashboard is an MCP server with 113 tools across 30+ intelligence domains. It can monitor: • Financial markets & macro signals • Military flights & naval activity • Global conflicts & unrest • Cyber threats & CISA alerts • Earthquakes, wildfires & disasters • Shipping, aviation & infrastructure • SEC filings & company intelligence • AI papers & GitHub trends • Elections, sanctions & prediction markets • Space weather & disease outbreaks The best part? It continuously builds a searchable intelligence database using Qdrant. So instead of querying dozens of APIs, you can simply ask: → "Military activity near the Taiwan Strait" → "Cyber threats targeting healthcare" → "Economic indicators suggesting recession" It searches across accumulated historical intelligence and returns relevant results in seconds. Under the hood: • 113 MCP tools • 30+ intelligence domains • 43+ public data sources • Live operations dashboard • Interactive world map • Semantic vector search • PDF/HTML intelligence reports 100% open source. MIT licensed. Repo👇
- 17
@bibryam ·
Zero-touch OAuth for MCP https://t.co/A3eXRNIiTc TLDR: Standard MCP auth is too high-friction in enterprise: users authorize every server, security can’t centrally enforce policy/audit, and account mixing is easy. Enterprise-Managed Authorization makes the IdP the control plane: admins define group/role/conditional access once, and SSO exchanges an IdP-issued Identity Assertion JWT (ID-JAG) for MCP server tokens without per-server consent screens.
- 18
@smratitiwa86867 ·
Everyone is talking about MCP. Very few can explain how it actually works. Most developers: → Install an MCP server → Connect it to Claude or ChatGPT → See it working But ask what happens behind the scenes... Silence. Here's MCP explained in plain English 👇 ⚡ What is MCP? MCP (Model Context Protocol) is an open standard that lets AI models connect to tools, databases, APIs, and applications through a single protocol. Think of it as: "USB-C for AI" Instead of building custom integrations for every model and every tool, MCP creates one universal language. Before MCP: N Models × M Tools After MCP: N + M A massive simplification. ⚡ The Architecture 3 Core Components: • Host → The AI application (Claude Desktop, IDEs, etc.) • Client → Communicates with MCP servers • Server → Exposes tools and capabilities Everything runs on JSON-RPC 2.0. Simple. Standardized. Extensible. ⚡ The 3 Building Blocks 🛠 Tools AI decides when to use them. 📄 Resources Applications provide context. 📝 Prompts Users trigger predefined workflows. ⚡ The Hidden Costs The demos look magical. Reality is more complicated: • Tool schemas get sent repeatedly • More tools = larger context windows • Token costs increase fast • OAuth and secret management become harder • Schema drift can silently break agents • Tool sprawl becomes the new microservice sprawl ⚡ The Biggest Mistake Treating MCP like a framework. It's not. MCP is a protocol. The right mental model isn't LangChain. It's HTTP. Boring. Foundational. And quietly becoming the standard layer for AI applications. Bookmark this for the next time someone asks: "How does MCP actually work?"
- 19
@socialwithaayan ·
🚨 BREAKING: AI coding agents can finally understand your entire codebase without exploding your token count. Zilliz just dropped Claude Context an open-source MCP server that makes large projects instantly searchable and usable by any coding agent. No more pasting random files. No more “I don’t have that file in context” replies. Just pure, precise code intelligence. Here’s why developers are going crazy over it: → Semantic + BM25 hybrid search that actually gets your code → AST-based smart chunking (not dumb text splitting) → Incremental Merkle-tree indexing — only updates what changed → ~40% token savings with better retrieval quality → Works with Claude Code, Cursor, Windsurf, VS Code, Gemini, and more → Flexible embeddings (OpenAI, Ollama, Voyage, Gemini) → One-command install and you’re done Tell the agent “find the auth logic” or “show me how payments connect to the DB” and it just works. This is the devtool that turns AI from “sometimes helpful” into “actually knows my project.” 6.2k stars and climbing. Built in TypeScript. 100% Open Source. MIT License.
- 20
@tonysimons_ ·
Announcing Hermes Vault 0.3.x ✳️ 0.3.0: shipped MCP support exposed vault capabilities to agents through a standard MCP server made ephemeral env materialization the default access pattern ✳️ 0.3.1: fixed MCP alias handling hardened metadata responses corrected policy docs/examples cleaned up MCP init/logging 193 tests passing. https://t.co/d9BJrZSaAe
- 21
@Aurimas_Gr ·
𝗧𝗼𝗼𝗹 𝗖𝗮𝗹𝗹𝗶𝗻𝗴 𝘃𝗶𝗮 𝗠𝗖𝗣 vs. implementing it 𝗡𝗮𝘁𝗶𝘃𝗲 𝘁𝗼 𝘁𝗵𝗲 𝗔𝗴𝗲𝗻𝘁. What's the difference? Recently there have been many MCP vs. Function Calling articles floating around. Let’s simplify. ❗️ 𝗖𝗹𝗮𝗿𝗶𝗳𝘆𝗶𝗻𝗴 𝗼𝗻𝗲 𝗱𝗲𝘁𝗮𝗶𝗹: Function Calling and Tool Use in Agentic Systems are almost the same thing. You can implement tools via functions, the only difference is that functions are usually used to enforce stricter structure to the input and output schema. 𝘜𝘴𝘪𝘯𝘨 𝘔𝘊𝘗 𝘵𝘰 𝘦𝘹𝘱𝘰𝘴𝘦 𝘵𝘰𝘰𝘭𝘴 𝘵𝘰 𝘺𝘰𝘶𝘳 𝘈𝘨𝘦𝘯𝘵𝘴: ℹ️ In this case your Agent becomes an MCP Host and implements one or more MCP Clients to communicate with MCP Servers. 𝟭. User Query is passed to the Agent (usually a Python application). 𝟮. The application implements MCP Client and via it retrieves all available tools from the MCP servers. 𝟯. The list of available Tools is passed together with the User Query to a LLM via a prompt. The LLM figures out which tools need to be invoked and with what parameters. 𝟰. The Agent application communicates with the MCP server (via MCP Client) again and sends the tool execution request. After execution completes the Agent receives the required data. 𝟱. User Query is sent to the LLM together with the data retrieved by the Tool calls. 𝟲. The answer is constructed and returned to the user via the Agent. 𝘜𝘴𝘪𝘯𝘨 𝘕𝘢𝘵𝘪𝘷𝘦 𝘍𝘶𝘯𝘤𝘵𝘪𝘰𝘯 𝘊𝘢𝘭𝘭𝘪𝘯𝘨: 𝟭. User Query is passed to the Agent (usually a Python application). 𝟮. All of the available Functions/Tools are defined as part of the Agent code (procedural memory). 𝟯. The list of available Tools is passed together with the User Query to a LLM via a prompt. The LLM figures out which functions need to be invoked and with what parameters. 𝟰. The Agent application directly executes the functions. 𝟱. User Query is sent to the LLM together with the data retrieved after function execution. 𝟲. The answer is constructed and returned to the user via the Agent. 𝗠𝘆 𝘁𝗵𝗼𝘂𝗴𝗵𝘁𝘀: ❗️ From the trenches, it looks like we have place for both methods of tool calling, only standardise behind MCP servers if necessary. ❗️ In some cases teams are even abandoning MCP due to the lack of flexibility. Are you using MCP already to expose Tools to your Agents? Let me know in the comments. 👇
- 22
@patilvishi ·
MCP ≠ REST API ≠ Function Calling These three terms are everywhere in AI discussions... Yet they're solving completely different problems. Many developers use them interchangeably. They shouldn't. Here is the easiest way to remember them: MCP (Model Context Protocol) ➜ A standard protocol that lets AI models securely connect to external tools, databases, files, and services. REST API ➜ A standard way for applications to communicate over HTTP. Function Calling ➜ A capability that lets an LLM choose a tool and return structured arguments for your application to execute. Quick memory trick - MCP = Connect AI to Tools - REST API = Connect Applications - Function Calling = Let the AI Use a Tool --- Imagine you're building an AI coding assistant. It needs to: - Read GitHub repositories - Query a PostgreSQL database - Search documentation - Create Jira tickets - Check Slack messages How do these technologies fit together? MCP Instead of writing custom integrations for every tool... The AI connects through MCP Servers. LLM ↓ MCP Client ↓ GitHub Database Slack Filesystem MCP provides a standard way for AI models to discover and use external tools. REST API Your frontend needs customer data. React App ↓ GET /customers ↓ Spring Boot API ↓ Database REST APIs expose services that any client can consume. They are not AI-specific. Function Calling The user asks: Create an invoice for ₹1,200. The LLM decides: createInvoice( amount=1200, currency="INR" ) Your application executes the function... The model never performs the action itself. It simply selects the appropriate tool and supplies structured arguments. --- When should you use each? MCP - AI Agents - Coding assistants - RAG applications - Multi-tool AI workflows - Enterprise AI platforms Purpose: 👉 Give AI standardized access to external systems. REST API - Web applications - Mobile apps - Microservices - Public APIs - Third-party integrations Purpose: 👉 Expose services over HTTP. Function Calling - AI Assistants - Chatbots - Agent workflows - Automation - Tool execution Purpose: 👉 Let the model decide which tool to use and what arguments to pass. --- The biggest misconception Many developers think: MCP replaces REST APIs. It doesn't. In fact... An MCP Server often uses REST APIs internally. A common architecture looks like this: LLM ↓ MCP ↓ REST API ↓ Application MCP standardizes how AI models access tools. REST standardizes how applications expose services. Another misconception People also think: Function Calling is the same as MCP. Not quite. Function Calling tells the model: Choose a tool. MCP tells the application: Here's a standard way to expose many tools. One is an LLM capability. The other is an integration protocol. --- One sentence to remember forever MCP = Connect AI to external tools. REST API = Connect applications. Function Calling = Let the AI choose and invoke a tool. --- The future of AI applications isn't about replacing REST APIs... It's about combining all three: ✔️ REST APIs expose your services. ✔️ MCP makes those services discoverable by AI. ✔️ Function Calling enables the model to use the right tool at the right time. That's how modern AI agents are being built.
- 23
@TheTuringPost ·
An open-source OSINT agent for security research – OpenOSINT It’s like an AI investigation layer that lets you: examine emails, domains, IPs, phone numbers, GitHub profiles, etc. It exposes its OSINT tools through MCP. This agent decides what to run, chains findings, and pivots from one clue to another. Supports: - 18 OSINT tools - REPL, CLI, Web UI, and MCP server - Checks for emails, usernames, breaches, domains, IPs, DNS, GitHub, and infrastructure - Claude, Ollama, or OpenAI-compatible backends - Auto-saved Markdown/PDF reports In general, OpenOSINT issues hard-stop tool calls, and the actual tools return the results. That makes it more like an OSINT workflow engine than just a chatbot for security research.
- 24
- 25
@webmaster ·
Profound's SDK code mode MCP server flipped my negative opinion on MCP What I don't like about MCP is the excessive tool calls, context bloat and LLMs struggling with tool call code due to limited training data Cloudflare and Anthropic recently wrote about their experiments with using MCP to execute code. The idea was that LLMs are great at writing code, so give them a typed SDK and let them write it Anthropic test results using Google Drive and Salesforce examples: - Native MCP: 150k tokens - Code Mode MCP: 2k tokens Cloudflare code mode test results with Cloudflare API in a 200k context: - Raw OpenAPI Spec: ~2M tokens, 977% context - Native MCP (full schemas): 2,594 tools, 1.17M tokens, 585% - Native MCP (req params only): 2,594 tools, 244k tokens, 122% - Code Mode: 2 tools, 1,069 tokens, 0.5% Massive reduction in context use! Profound follows the same approach with 2 tools: - search_docs: Searches documentation to find methods, params and examples - execute: Runs TypeScript to interact with the Profound API Since MCP discovery and configuration is built into most harnesses, agents can discover the MCP tools, reason, determine the optimal query, and learn the SDK in real time I've found that this works better than managing personal docs and scripts because you're leveraging all the things that already exist for SDKs: docs, examples, and types See the example MCP server response from Profound when prompting the LLM with "optimize my content for AEO using Profound API". The search_docs tool will return methods the LLM can use to write TypeScript I've been able to delete agent skills, reduce context, and improve task execution by simply using the MCP. I now want this for all APIs and SDKs!
- 26
@_avichawla ·
Hugging Face meets Claude! I built a @huggingface fine-tuning studio that lets you fine-tune any LLM directly from Claude. The app connects to the HF Hub for model and dataset search. It handles chat template formatting for the training data, and lets you configure LoRA rank, quantization, batch size, and learning rate directly from Claude. Training runs on HF's GPU infra via AutoTrain. Once training finishes, you can also chat with your fine-tuned model (or any other LLM on HF) directly from Claude. The studio's built with @manufact's mcp-use SDK, an open-source full-stack framework to build MCP Apps for Agents. In mcp-use, any MCP tool can be associated with a UI. You define a tool handler, create a React component, and the mcp-use framework handles the tool registration, prop mapping between server and widget, bundling, and hot reload during development. The widgets follow the MCP Apps standard, inspired by OpenAI's Apps SDK. Claude is an example, but you can render them as interactive UI elements in any conversational MCP client that supports it. Similarly, this pattern works for any workflow you want to bring inside a chat, like eval dashboards, dataset explorers, or model comparison tools. I have shared my fine-tuning studio repo in the replies!
Watch video
- 27
@nico_jeannen ·
The MCP server was the best feature I've added to Heyo I think 1) a user report a bug this morning 2) I ask Claude Code to investigate the issue 3) it connect to the MCP, get all the convo + context (user info, messages, screenshots etc) 4) it spawned 3 agents to investigate the issue in codebase 5) found the issue and fixed it in < 5 minutes 6) I checked the code, pushed to prod, and issue was fixed
- 28
@therealdanvega ·
X just dropped their hosted MCP server, so I connected Spring AI to it. A small Spring Boot 4.1 app, one ChatClient, two X MCP servers. Ask questions from the X API docs, and search live posts on X. No Node, no browser login. Read access is just an app-only Bearer token. Code: https://t.co/mCyl53c19D
- 29
@asmah2107 ·
The S in MCP stands for security. (That's a joke. But it shouldn't be.) April 2025 security research found: → Tool poisoning (malicious tool descriptions) → Cross-server tool shadowing (a rogue server intercepts calls) → Silent tool mutation (definitions change after trust is established) → Prompt injection via MCP tool output You just gave your agent access to 10,000 servers. Each server is a trust boundary. Each tool description is a potential attack vector. Each tool call is an unsigned contract. MCP is powerful. It is not safe by default. Treat every MCP server like a third-party API you don't control. Because that's exactly what it is.
- 30
@sagar_batchu ·
The release and near-immediate unrelease of Fable put enterprise AI spend back in the headlines this week. Good moment to resurface something we wrote a while back, because one of the quieter drivers of that spend is MCP. Every tool an MCP server exposes has to be described to the model, and those descriptions are tokens. As servers grow, the tool list alone can eat a serious chunk of context before the agent does real work. We cut it ~100x with dynamic toolsets: instead of loading every tool definition up front, the agent pulls in only the handful it needs via progressive discovery and semantic search. Same capability, a fraction of the context. https://t.co/GW1dIpkc4Y
- 31
@sagar_batchu ·
The official MCP server from @datadoghq exposes 142 tools across 22 toolsets. Connect it to an agent and the context window fills up with tool definitions before the agent does a single useful thing. Beyond the context, every irrelevant tool is one more thing the model has to consider and spend tokens ruling out. An incident-response agent doesn't need dashboard-creation tools in scope; a metrics agent doesn't need log management. This is where every serious MCP server is heading. Tool lists grow as servers add capabilities, and the cost of just listing them grows with it. Datadog's own docs let you request a subset of toolsets instead of all 142. They know the full list is too much to load at once. The MCP spec has open proposals for this around tool groups, namespaces, filtering hints. But they haven't shipped yet so we implemented them ourselves. We shipped tag-based tool filtering for Speakeasy-hosted MCP servers. Tag your tools, and any client can append a tags parameter to the same server URL to get a focused subset. One server, many scoped views. Context stays lean, tool selection improves, and operators decide which client sees what, without running a separate server per use case. It stacks with dynamic toolsets: filtering caps which tools a client can ever see, and progressive discovery trims from that set at runtime. Props to the Datadog team for building the server that made this impossible to ignore. How we did it: https://t.co/gVCsF42QVO
- 32
- 33
- 34
@RoundtableSpace ·
BLENDER BECOMES A PROMPT BOX WITH KIMI K3 AND MCP INTEGRATION Connecting Kimi K3 to Blender using the Model Context Protocol turns text prompts into native 3D scenes complete with terrain, lighting, camera paths, and animation. Kimi inspects its own visual renders and edits the active project file to fix errors without forcing a total restart.
Watch video
- 35
@katibmoe ·
Finally, someone said it. > @garrytan, the president of @ycombinator vibe coded a CLI wrapper in 30 minutes. 100 lines of code. worked 100x better than MCP. > @perplexity_ai just shipped their flagship agent without MCP. > typical MCP server: 13K–18K tokens of context bloat. CLI equivalent: 225 tokens. 80x efficiency > 78% of MCP servers have no proper auth. MCP as a concept is sound. wrapping every API in its own server and calling it an integration strategy is dead.
- 36
@suraj_sharma14 ·
Earlier this year, 🦄 Peter Steinberger posted seven words that became a rallying cry: "mcp were a mistake. bash is better." This week, he announced that the next version of OpenClaw will ship as an MCP server. "I know, this is awkward." Awkward is an understatement. Peter joined OpenAI in February. He publicly called MCP a mistake. And now he's not just adopting Anthropic's protocol, he's using it to build a competing messaging layer that out-scopes Anthropic's own implementation. Think about what that means. The guy who dismissed MCP, who now works at a direct competitor, looked at the landscape and concluded: this is still the right protocol to build on. Even if it means competing with the people who created it, on their own turf, using their own standard. This is what real ecosystem adoption looks like. A skeptic shipping the thing he dismissed.
- 37
- 38
@hackerrank ·
More MCP tools will just make your agent worse. When your MCP has hundreds of tools to choose from it becomes a liability. The model has to read every tool definition. Choose the right one, pass the right inputs, and not blow up the context window before the work even starts. The better pattern isn't giving the agent more choices. It's giving it a cleaner way to find the right one. Instead of giving the agent hundreds of preloaded tools, give it a smaller interface: search what exists, write the code, then execute the right call.
Watch video
- 39
@jumbld ·
We're past the dreary trough of the MCP hype/hate cycle. Was on a discovery call today and they needed a RAG chatbot for employees on their Sharepoint data. On the call, googled that there was a fairly good sharepoint mcp server and connected that into @LibreChatAI and we had an MVP there. (No, didn't need Portkey and I was candid about it) With the MCP spec updates and everything on the roadmap, I am insanely driven by the protocol and what it's adoption means for AI in production. I'm actively building an MCP Gateway in @PortkeyAI , https://t.co/Gqy6k2UElX as a personal hobby project to build a really good MCP client, and constantly having conversations about MCP + Agents. 2026 is going to be even better!
- 40
@ThePracticalDev ·
A minimal Python MCP server, validated locally with Gemini CLI, then deployed to AWS ECS Express in a single step. This dev walks through the incremental approach — from stdio transport to HTTP, from local to remote — without the extra noise. { author: xbill + @GoogleDevExpert } https://t.co/mNMbQHXKzY
- 41
- 42
@DanKornas ·
Running MCP servers, agents, and REST or gRPC APIs separately can leave AI clients without one governed endpoint for discovery and tool calling. ContextForge is an open source registry and proxy that federates tools, agents, and APIs into one clean endpoint for AI clients. It runs as a compliant MCP server that translates and federates supported backends while providing centralized governance, discovery, observability, authentication, retries, and rate limiting. Key features: • Federates MCP servers, A2A servers, and REST or gRPC APIs across multiple services. • Translates gRPC services to MCP through reflection-based service discovery and virtualizes legacy APIs as MCP-compliant tools and servers. • Routes external AI agents through A2A integration with OpenAI-compatible, Anthropic, and custom agent support. • Provides built-in authentication, retries, rate limiting, user-scoped OAuth tokens, and X-Upstream-Authorization header support. • Adds OpenTelemetry tracing across federated gateways and services, with Phoenix, Jaeger, Zipkin, and other OTLP backends. Link in the reply 👇
- 43
- 44
- 45
- 46
@ibuildthecloud ·
@dsp_ I know this has come up before but I think it's super useful for MCP servers to be able to offer skills just like they offer tools because the obvious pattern now is that the top level of everything is a skill. Everything's a skill. And then what does your skill do? It might call a CLI or it might call an MCP server, it might generate code. The issue with it calling a MCP server is the kind of weird backwards nature of that where you load a skill and then you have to load an MCP server. Some agents can do this. They have dynamic lookup discovery, registration of MCP servers, but a lot of them don't. So it makes more sense that you can register or install the MCP server and it comes with the skill. It's kind of like if I wrote a skill that needs, let's say, Chromium, I probably need to install that beforehand or any other system-level dependency that you don't want the agent doing. And again I wouldn't be surprised if you guys are already talking about this and I'm just not involved. But I would like a top-level primitive in MCP for list skills. That skill would have the name, description, the body, plus what I want also is required or optional tools for that skill. Not allowed tools that's slightly different. I want to know what tools have to be pulled in from the MCP server for that skill to work. One paradigm that has worked really well for us is also an MCP server that just contributes skills. Because I could see a behavior where an MCP server can list a skill and then it can put a dependency on another MCP server with its skills. And also a side note. I don't think the direction of search and dynamic dispatch for MCP servers negates the patterns that I'm talking about. I think they're slightly orthogonal. Just fyi. So I really want the next version of MCP to have the headline that "MCP now includes skills" and then it'll just confuse the crap out of everyone.
- 47
- 48
- 49
- 50
@aroussi ·
Weekend = Time to lock in 😁 MUXI Runtime is now ~3x faster overall with... 🪟 8K context window for embedding 🍎 Knowledge ingestion on Apple Silicon: 280s → 38s (7x) 📈 Heavy PDF processing is ~18% faster 🧪 Parallelized and local LLM synthesis 🔥 Hot-reload secrets without restarting 🏁 MCP errors translate into agent-actionable hints 🫗 Filter unused MCP tools to further reduce context ✅ 274 e2e tests green before shipping ...and a lot more (really) https://t.co/Wfors7f0pl
Best Tweets by Topic