Read the best tweets about Model Context Protocol, including MCP servers, clients, tools, security, integrations, and implementation lessons. Updated every two weeks.
Technical MCP implementations and ecosystem analysis, with bare and unrelated uses of the acronym excluded.
Original Xholic analysis
Across 50 posts from 39 creators on Model Context Protocol, the conversation is overwhelmingly constructive: 90% supportive stance, 76% positive sentiment, and 46% tutorial-format content. Engagement is concentrated in first-party vendor server launches, which post the highest theme median (281.561), and three of the five top outliers are launch posts (2111702567449424226, 2040937372909531286, 2105091392011948221) — but the single highest-scoring post overall (3033.86, 120× the overall median) is a Claude Code–TradingView workflow tutorial (2039712499503964298). The security theme has the lowest theme median (3.223), with tool-overload/context-bloat discussion close behind (6.39): both are技术
76% of posts
All-time engagement
46% of posts
Published in 90 days
Conversation map
Educational threads defining MCP (USB-C for AI), the N×M integration problem, host/client/server roles, tools/resources/prompts primitives, JSON-RPC transport, and how MCP differs from REST APIs and function calling.
20%
Critiques of large tool surfaces: context-window bloat from tool definitions, tool-selection accuracy collapse, dynamic/on-demand tool discovery, tag filtering, code-mode/SDK execution instead of tool calls, and the CLI-vs-MCP debate (mcp2,
20%
Announcements and setup guides for first-party servers from major vendors — X/XMCP, Google MCP Toolbox for databases, Playwright MCP, Chrome DevTools MCP, Unreal Engine MCP, Datadog MCP, ChatGPT MCP Events, ProductSpec MCP.
18%
Practical guidance for implementing your own server: tool/schema design for model consumption (human-readable params vs UUIDs), small tool surfaces, wrapping existing APIs, testing with MCP Inspector, and shipping MCP as product feature.
10%
Attack and defense analysis: tool poisoning, cross-server shadowing, rug pulls, prompt injection via tool output, egress proxies, OAuth/enterprise-managed authorization, and fine-grained agent permission boundaries.
10%
Posts distinguishing MCP as the connectivity/wiring layer from Skills as the procedural-knowledge layer (SKILL.md), plus proposals and spec updates for discovering and serving skills through MCP servers.
8%
Hands-on case studies of Claude Code (and similar agents) driving external applications via MCP: TradingView charting/Pine Script, Blender/Unity 3D asset creation, Unreal editor control, browser debugging, and binary vulnerability analysis.
8%
Using MCP to standardize data access in Agentic RAG pipelines, GraphRAG memory servers, natural-language memory query/write tool design, and connecting assistants to enterprise data sources like SharePoint.
6%
Tone and stance
Performance benchmark
Posts with media make up 64% of this collection. Their median all-time score is 21.0, compared with 39.9 for text-only posts.
Format mix
Consensus and debate
Shared view
Multiple creators independently frame MCP as turning N models × M tools into N + M integrations ('USB-C for AI'), with a write-once, use-everywhere value proposition.
Shared view
Repeated finding that big tool lists bloat context and collapse tool-selection accuracy, with converging fixes: on-demand tool loading (2014800390999429334 reports Claude Code tool search cutting MCP tool context from 25% to 14%), tag/scoped filtering for a 142-tool server (2065449153014939755), CLI-based dynamic discovery (2111756983280001388), and code-mode execution (2039499696813822194 reports Anthropic tests at
Shared view
Several posts draw the same boundary: MCP standardizes how AI reaches tools, REST standardizes application APIs (an MCP server often wraps REST internally), and function calling is an LLM capability — the three compose rather than compete.
Shared view
Recurring framing that MCP is the wiring/connectivity layer while Skills (SKILL.md) are the procedural-knowledge layer, including MCP spec support for serving skills via the Resources primitive.
Open debate
2032924771470700969 argues 'CLI > MCP' because MCP servers load all tool definitions every turn, citing 96–99% token savings from converting servers to CLI commands. Counterpoint from Thariq (@trq212) in 2099958388230873165: better tool calling, deferred tools, and stateless MCP now make MCP preferable to CLIs for most integrations. 2078517653530902897 documents a public reversal in the same direction (a prominent 'M
Open debate
2108220903335272689 argues servers should not mirror REST APIs and should collapse ~30 endpoint-shaped tools into 4 general tools (with a cited example dropping a trace from 131,710 to 6,652 tokens), accepting recoverable errors; 2065449153014939755 instead keeps full surfaces but adds tag-based filtering so each client sees a scoped subset of a 142-tool server.
What performs
First-party launch posts occupy three of the top five outlier slots (2111702567449424226 at 2422.61, 2040937372909531286 at 1102.97, 2105091392011948221 at 629.56), and the official-launch theme has the highest median (281.561). By contrast, the ANNOUNCEMENT format overall has a median all-time score of just 9.62 — launch-post traction is concentrated in a handful of high-profile launches rather than announcements in
64% of posts include media, yet text-only posts carry a higher median all-time score (39.87) than posts with media (21.03) — the top performers are long-form tutorials and threads, not image posts.
The security theme has the lowest median (3.223) despite concrete attack/defense content (tool poisoning, cross-server shadowing, rug pulls; enterprise-managed OAuth via ID-JAG). Tool-overload discussion also underperforms its usefulness (6.39). Both are candidate topics for a technically angled report, not evidence the conversation ignores them.
Median post: 48 likes, 3,056 views, 9 replies, 6 reposts; median all-time score 25.25. The top outlier sits at 3033.86 (120× median).
Statistical standouts
Creator landscape
The five most represented creators account for 20% of the selected posts.
1. Vaishnavi
@_vmlops
2 posts
2. Akshay 🚀
@akshay_pachaar
2 posts
3. Ashutosh Maheshwari
@asmah2107
2 posts
4. Aurimas Griciūnas
@Aurimas_Gr
2 posts
5. Jian Wang
@jianw851
2 posts
6. Julian Goldie SEO
@JulianGoldieSEO
2 posts
Vaishnavi (@_vmlops) leads with a median all-time score of 392.56 across 2 posts, both covering first-party servers: Google MCP Toolbox for databases (2042486942802321552, 503.57) and Microsoft's Playwright MCP server (2048971660561445288, 281.56). Akshay (@akshay_pachaar) follows at 343.94 with two MCP-vs-Skills posts (2029534926828388537, 509.62; 2100659094625636526, 178.25).
39 creators across 50 posts, with the top five accounting for 20% of placements; the two highest-scoring posts come from creators outside the top-voice list — a TradingView workflow tutorial from Axel Bitblaze (@Axel_bitblaze69, 3033.86) and an Unreal Engine launch post from @RoundtableSpace (2422.61).
Since the previous snapshot
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
Ranked 01–50
@Axel_bitblaze69 ·
Dear Traders, Claude code can now connect directly to your TradingView charts It reads your charts, indicators, writes Pine Script for your trading strategies, compiles it and fixes errors.. all automatically Not a browser extension.. A direct connection to your live charting platform ▫️Here's how it works and how to set this up: > How it works: TradingView Desktop runs on Electron (Chromium). Chromium has a built in debug interface called Chrome DevTools Protocol. It's off by default. One flag turns it on. That's the door. Claude Code connects through it via an MCP server running locally on your machine. Nothing touches TradingView's servers. No data leaves your machine. Everything runs on localhost. Here's the setup, give Claude code this prompt and it does everything: "Install the TradingView MCP server. Clone and explore https://t.co/4NApHd4Lyx, run npm install, add to my MCP config at ~/.claude/.mcp.json, and launch TradingView with the debug port." Once it's done, verify: "Use tv_health_check to confirm TradingView is connected." Then just try: "What's on my chart right now?" That's the whole setup. Claude installs it. Claude runs it. You just describe what you want. ▫️What Claude can actually see What Claude can read from your charts: > Current symbol and timeframe > Real-time OHLC and volume > Up to 500 price bars > All indicator names, IDs, and values > Pine Script drawings — lines, labels, tables, boxes > Data window values > Order book depth > Strategy tester results and trade list > Screenshots of any chart region The most useful part is it reads protected indicators too. Pass a filter with the indicator name and you get back every price level, every text annotation, full table contents, every drawn zone. "What levels is my NY Sessions indicator showing?" it reads them. "What does the session stats table say?" it reads that too.All of this data is already on your screen. This tool just makes it readable to an AI. ▫️ The Pine Script workflow This is the part that changes everything for traders who code: You describe what you want → Claude writes the Pine Script → injects it into TradingView → compiles it → reads the errors → fixes them → recompiles That loop runs until the script is clean. The whole time Claude has full context of your chart and every indicator on it. No more copy-pasting between VS Code and the Pine editor hunting type mismatches. You can also: → Validate indicators (write it, compile it, read values back, check the math) → Loop through input parameters and test each one → Run the same indicator across multiple symbols and timeframes → Read strategy tester metrics after each compile The actual workflow of verifying your indicators works instead of just assuming they do. sharing the usecases of this workflow in my next post.. like & RT
@RoundtableSpace ·
Epic Games released an official plugin that lets Claude Code control Unreal Engine directly. It connects Claude Code to the Unreal Editor and exposes hundreds of editor tools across 30+ toolsets: → Actors, Blueprints and materials → Niagara effects, Control Rigs and Sequencer → State Trees, widgets and the Gameplay Ability System → Automation testing Install it from Anthropic's official plugin marketplace: /plugin install unreal-engine-skills-for-claude-code@claude-plugins-official In Unreal, enable the ModelContextProtocol and AllToolsets plugins, then start the MCP server with the editor open. Works on Mac, Linux, and Windows through Git Bash or WSL. https://t.co/LYM4whQ8Ev
@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
@mxstbr ·
One more launch today: the new MCP Events spec is now supported in ChatGPT 🎉 MCP servers can now push real-time updates (messages, comments, status changes, whatever) to ChatGPT, triggering automations for your users 🤯 It’s easy to add to your MCP server, too! Just point Codex at the docs and let it rip: https://t.co/9CqX6hfhXC
@trq212 ·
I was not expecting things to go this way, but I think MCPs are better than CLIs for most integrations. The models have gotten much better at tool calling, we can defer tools & MCP is now stateless. If you need to compose/filter data, add params like query to your MCP tools.
@akshay_pachaar ·
MCP vs. Skills for AI agents, clearly explained! People 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. 10 models, 100 tools? That's 1,000 unique connectors to build and maintain. The AI tooling ecosystem was a tangled mess of one-off glue code. MCP (Model Context Protocol) fixes this with a shared communication standard. Every tool becomes a "server" that exposes what it can do. Every AI agent becomes a "client" that knows how to ask. They talk through structured JSON messages over a clean, well-defined interface. Build a GitHub MCP server once, and it works with Claude, ChatGPT, Cursor, or any other agent that speaks MCP. That's the core value: write the integration once, use it everywhere. But here's where most explanations stop short. MCP solves the *connection* problem. It does not solve the *usage* problem. You can hand an agent 50 perfectly wired MCP tools and it'll still underperform if it doesn't know when to call which tool, in what order, and with what context. That's the gap Skills 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 bundles tone guidelines and output templates. A code review skill bundles patterns to check and rules to follow. MCP gives the agent hands. 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. If you're building with agents, I have shared a repository of 85k+ skills that you can use with any agent, link in the next tweet!
Watch video
@_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
@arvidkahl ·
The complexity of adding an MCP to your product (if you already have some sort of API) is a single prompt. Here is precisely what I would dictate into my prompt field today. Maybe this gives you some insight into how I prompt agentic systems: "Add full MCP capabilities to the product, aiming for feature parity with our existing API implementation. For authentication purposes, use the OAuth implementation that is closest to our existing authentication stack. If you have to create authentication confirmation pages, keep the design as close as possible to our login and registration pages as you can. For documentation, create solid, self-contained documentation blocks for every single tool that mirrors the complexity of API docs. Create MCP management, analytics, and log features analogous to our API implementation and draft MCP landing pages that also fit into our existing marketing and customer acquisition scheme. Do extensive web searches around the quirks and expectations of OpenAI and the Anthropic MCP and plugin stores. As we will likely want to submit this MCP to be a first-class tool in either of these and more store systems, pay special attention to how tools need to be configured, described, and tagged to make sure that this will pass plugin store review without issues. Implement the equivalent of the tests we have for the appropriate API routes for this MCP implementation, making sure that we follow protocol implementation best practices. Create a dedicated landing page for agentic website visitors that has an easy path for them to quickly implement the MCP within their own runtime and products. When in doubt about any step of the implementation, please use the ask user question tool to get my feedback. First create a scope document and have me verify it, then implement the full document right away." (Dictated but not read 🤣 using WhisprFlow) This should get you 95% of the way there. The rest is some manual testing, deploying, and telling your customers you have an MCP now.
@rauchg ·
Super bullish on WebMCP. Much like Tesla FSD meets the world where it is (streets, stoplights, potholes and all), agents *need* to ride the existing WWW infrastructure… WebMCP makes it more efficient. Some pretty unique wins too. e.g: Next.js dev pages could expose debugging tools directly to agents in the specific tab they’re testing, with page-specific context, instead of sifting through server logs. No separate MCP server to find and configure because the page directly exposes its own 'agent tools'. e.g: in this world 𝚏𝚡 + 𝚊𝚐𝚎𝚗𝚝-𝚋𝚛𝚘𝚠𝚜𝚎𝚛 is a complete web dev stack with zero loss in debugging depth
@_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
@EXM7777 ·
CLI > MCP every MCP server you connect to your agent loads ALL its tool definitions on EVERY turn you're literally burning tokens for nothing, money you're paying that never touches your actual task there are a few tools that fix this, one i tried recently is mcp2cli it converts your MCP servers to simple commands that the agent calls only when needed apparently is saves 96-99% on tokens... definitely worth a try
@akshay_pachaar ·
MCP meets agent skills MCP already gave agents a standard way to connect to tools, resources, and external systems. Now it also defines a standard way to discover and load Agent Skills directly from MCP servers. The flow is simple: → connect to MCP server → discover available skills → inspect skill metadata → load the relevant 𝗦𝗞𝗜𝗟𝗟.𝗺𝗱 only when needed Under the hood, Skills are served through MCP’s existing Resources primitive. That means 𝗦𝗞𝗜𝗟𝗟.𝗺𝗱, references, scripts, examples, and other supporting files are exposed as resources that the client can read on demand. This is especially useful for context window management. Instead of loading every workflow instruction upfront, the agent can first discover what skills are available and pull in only the one required for the current task. A useful mental model is: tools = what the agent can do resources = what the agent can access skills = how the agent should perform a reusable workflow Previously, that workflow knowledge often lived separately in docs, repos, prompt files, or custom integrations. Now the MCP server can expose the capability and the playbook for using it together. So you get: → standardized skill discovery → on-demand context loading → cleaner distribution and versioning → reusable workflows that travel with the server MCP was already the connection layer. Skills now add a standardized way to ship reusable agent know-how on top of it. The illustration below visually summarizes everything that we discussed so far. Read more: https://t.co/bTdnng9nNC Cheers! :)
@_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
@arpit_bhayani ·
Fun fact: swapping UUIDs for plain integers in your MCP tool parameters cuts agent errors. When you compare UUID-based tool parameters against integer alternatives, you get several errors, and the reason is simple ... A UUID like a3f9c1e2-88b4-4d1e-9c77-... is not something the model can reason about. So, when the model needs to fill in that parameter, it is not recalling a value; it is pattern matching against what a UUID looks like. That produces a plausible-looking string that does not exist in your system. This is the core mismatch between how APIs and MCP tools get consumed. REST APIs are built for a client that already has the ID, fetched a moment ago from a database query. Even MCP is called by a model that is generating the parameter value from context, and context is made of 'words'. The fix is simple - never let the model see the raw UUID in the first place. Resolve it internally (if possible). If a tool needs to reference an entity, expose a human-readable name (even a var name works) or a simple index, and translate that back to the UUID on your side. This is worth remembering the next time you are about to pass your database's primary key straight through to a tool schema. Hope this helps.
@Aurimas_Gr ·
𝗠𝗖𝗣 plus 𝗔𝟮𝗔, here is how they complement each other 👇 Protocol wars continue to rage, let's understand how Googles A2A (Agent2Agent) protocol is different from MCP and how they complement each other (read till the end). 𝘔𝘰𝘷𝘪𝘯𝘨 𝘱𝘪𝘦𝘤𝘦𝘴 𝘪𝘯 𝘔𝘊𝘗: 𝟭. MCP Host - Programs using LLMs at the core that want to access data through MCP. ❗️ When combined with A2A, an Agent becomes MCP Host. 𝟮. MCP Client - Clients that maintain 1:1 connections with servers. 𝟯. MCP Server - Lightweight programs that each expose specific capabilities through the standardised Model Context Protocol. 𝟰. Local Data Sources - Your computer’s files, databases, and services that MCP servers can securely access. 𝟱. Remote Data Sources - External systems available over the internet (e.g., through APIs) that MCP servers can connect to. 𝘌𝘯𝘵𝘦𝘳 𝘈2𝘈: Where MCP falls short, A2A tries to help. In multi-Agent applications where state is not necessarily shared 𝟲. Agents (MCP Hosts) would implement and communicate via A2A protocol, that enables: ➡️ Secure Collaboration. ➡️ Task and State Management. ➡️ User Experience Negotiation. ➡️ Capability discovery - similar to MCP tools. 𝗛𝗼𝗻𝗲𝘀𝘁 𝘁𝗵𝗼𝘂𝗴𝗵𝘁𝘀: ❗️ Open protocols for Agent communication are important but they are just a piece of the picture, there will be a need for standards that govern all of the existing protocols and other missing pieces. E.g. ❓ How do we standardise tracing and Observability in multi-agent IOA systems? ❓ How do we retain the identity of the running job of an AI Agent instance if the communication standard is not unified in different parts of the pipeline? ❓ ... ✅ More on this in my future posts, stay tuned! Let me know your thoughts in the comments. 👇
@DivyanshT91162 ·
Your AI agent might be wasting thousands of tokens just figuring out which tools it can use. Apify built a CLI to change how AI agents interact with MCP. Meet "mcpc" — a universal MCP client that lets an AI agent access MCP servers through a single Bash tool instead of wiring up dozens of separate tool functions. Here's why this is interesting: → Dynamic tool discovery: Find the tools you need instead of loading everything into context upfront. → Persistent sessions: Keep multiple MCP server connections alive in parallel. → Full MCP support: Access tools, resources, prompts, tasks, and skills through shell commands. → Security built in: OAuth 2.1, OS keychain credential storage, and a proxy to protect credentials from AI-generated code. → Composable workflows: Pipe JSON output into "jq", "xargs", and other shell utilities to build repeatable automations. Get started: "npm install -g @apify/mcpc" Then connect to an MCP server: "mcpc connect https://t.co/x8sIZ8ADtL @apify" The bigger idea? Stop flooding your AI agent with tools. Let it discover the right ones when it needs them. MCP provides the standard. The CLI gives agents a familiar interface to use it. REPOO👇
@techNmak ·
MCP performance starts earlier than the tool call. In a common direct tool-calling setup, the model receives the names, descriptions and parameter schemas of the tools available to it. With a handful of tools, this is usually manageable. As the tool surface grows, those definitions take up more context, and choosing between similar tools can become harder. This is why I don’t think an MCP server should automatically mirror a REST API. An API may have separate endpoints for creating, updating, reading and listing different resources. Application code already knows which endpoint it wants. A model has a different problem. It has to understand the available tools first, choose one, and then produce valid arguments. A smaller tool surface can make that job easier. Instead of exposing a separate tool for every operation, the server can keep a few general operations and pass the resource or action as data. The exact schema can then be fetched when it is actually needed rather than putting every possible schema in front of the model from the start. There is a tradeoff. If the complete schema is not always present, the model may occasionally get a field wrong. But that can be a perfectly reasonable failure mode if the server returns a useful validation error and the model can correct the call. I think we sometimes spend too much context trying to prevent mistakes that are cheap to recover from. The same problem appears after the tool call. Reducing the number of tools does not help much if one successful read sends an enormous object back into the context window. For large results, it can make more sense to return the useful structure first and fetch the heavier details only when they are needed. @Cometml describes both problems in its write-up on optimizing the Opik MCP server. Their original data-management interface exposed about 30 endpoint-shaped tools. They reduced that surface to four general tools. In one example, a trace that would have occupied 131,710 tokens was represented as a 6,652-token skeleton, with the omitted details still available for later reads. I don’t think four tools is some ideal number. The more useful point is that the model did not need thirty endpoint-shaped interfaces to work with the same underlying data. If I were reviewing an MCP server, I would look at more than how quickly its tools execute. I would also look at how much interface the model has to carry, how difficult it is to choose the right operation, and how much data comes back afterwards. MCP may sit on top of an existing API, but that does not mean the model should have to use the API the same way application code does.
Watch video@RoundtableSpace ·
Someone used Claude Code with an open-source Blender MCP addon to create most of the 3D assets for a fishing game. → A single Claude Code session controlled both Blender and Unity through the Model Context Protocol → The developer's case study describes a 40-part, 42-bone crab model created in 53 minutes → Claude rendered images from multiple angles so the developer could review and give feedback → The MCP for Blender addon is MIT-licensed and also works with Codex, Cursor and other AI tools Repo: https://t.co/T8C31vaXcs
Watch video
@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
@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?
@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.
@0xfluxsec ·
I've spent all day working on an LLM <---> MCP tool to perform automated vulnerability analysis on a directory of binaries, working as a state machine. Screenshot of some output attached. The idea is that it will analyse its own results and make recommendations to a vulnerability analyst who can go off and triage further, which may speed up the process (and/or inspire other post-processing tools / workflows). I tested it with Claude + IDA Home and it found the same vulnerabilities through the tool as it did from yesterday. I then realised IDA Home doesn't include headless, so I spent this afternoon porting it over to Ghidra using an MCP integration there which was annoying as it was over a differnet protocol. Interestingly, switching to Ghidra as the backend from Ida gives slightly weaker results (using the same model) which I am trying to debug. A clarification from yesterday: a DKOM-based privilege escalation path from high integrity to System is the more accurate description of what the LLM produced an exploit for. I've made that clearer on GitHub too. The point I'm conveying is that AI and LLMs are driving this. What stood out to me was that the LLM was able to reason far beyond my initial, limited attempt and identify that path to SYSTEM via using an arbitary physical memory read & virtual write vuln (whilst constrained by 32-bit addressing), which I thought was absolutely wild! That's some crazy capability imo. I used a known vulnerable driver because it is a good sample set for testing this functionality. After testing a data set of known vulnerable drivers to validate output, you can then move onto testing binaries of which the status of their exploitability is unknown, that will be the next step of this. Anyway I need a break from this for this afternoon as my brain is tired, but I'm looking forward to seeing where this project goes!
@jianw851 ·
MCP is becoming the USB-C for AI. Instead of building a separate integration between every AI model and every tool, Model Context Protocol gives them a common way to connect. 𝗧𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗯𝗲𝗳𝗼𝗿𝗲 𝗠𝗖𝗣 → Claude needs Slack → ChatGPT needs GitHub → Gemini needs Google Drive → Every model + every tool can require its own integration. With 3 models and 3 tools, that's 9 one-off connections. 𝗧𝗵𝗲 𝗠𝗖𝗣 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵 MCP puts a standard layer between the AI application and external tools. → Claude → MCP → Slack → ChatGPT → MCP → Drive → Gemini → MCP → GitHub Now you're connecting through a common protocol instead of rebuilding integrations for every model. 𝗪𝗵𝗮𝘁 𝗠𝗖𝗣 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗱𝗼𝗲𝘀 → 𝗪𝗿𝗶𝘁𝗲 𝗼𝗻𝗰𝗲: A tool exposes an MCP server and compatible clients can use it. → 𝗡𝗼𝘁 𝗷𝘂𝘀𝘁 𝘁𝗲𝘅𝘁: Models can access files, query data and take actions through connected tools. → 𝗦𝘄𝗮𝗽 𝗺𝗼𝗱𝗲𝗹𝘀: Your integrations don't have to be rebuilt every time you change the underlying AI model. 𝗛𝗼𝘄 𝗼𝗻𝗲 𝗿𝗲𝗾𝘂𝗲𝘀𝘁 𝘁𝗿𝗮𝘃𝗲𝗹𝘀 You → AI app → MCP server → Tool/Data The tool does the work, the result comes back through the same path. That's the interesting part of MCP. The model doesn't need to know how your database, GitHub repo or internal API works. It just needs a standard interface for interacting with it. 𝗪𝗵𝘆 𝗶𝘁 𝗺𝗮𝘁𝘁𝗲𝗿𝘀 As AI agents move from answering questions to actually doing things, tool access becomes just as important as the model itself. MCP gives developers a common layer for connecting those agents to the real world. The future of AI agents may not be about one model doing everything. It may be about models + tools + a common protocol.
Watch video
@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.
@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 👇
@asmah2107 ·
Three protocols are competing to become the TCP/IP of multi-agent systems. You should know how they differ. Bookmark this. > MCP Model Context Protocol (Anthropic) → Standardises how agents access tools and external resources. → Before MCP: every tool needed a custom integration. N agents × M tools = N×M interfaces. → After MCP: one standard. N+M interfaces total. → Already adopted by VS Code, JetBrains, and most major frameworks. → Think REST for agent-to-tool communication. > A2A Agent-to-Agent Protocol (Google) → Peer-to-peer collaboration between agents. → Agents negotiate, share findings, and coordinate without a central orchestrator. → Solves the "who is in charge" problem for decentralised systems. > ACP Agent Communication Protocol (IBM) → Governance-first. Security and compliance built into the handshake. → Designed for enterprise deployment where auditability is non-negotiable. The parallel: REST vs SOAP vs GraphQL. One will win. Two will become legacy. We're early. Follow for the system design layer of AI nobody else is writing about.
@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?"
@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.
@jianw851 ·
Most people think AI agents fail because of the model. They're looking in the wrong place. The real bottleneck is integration. For years, every AI application had to build custom connections to every database, API, SaaS tool, file system, and internal service. New model? More integration work. New tool? More integration work. New workflow? Even more integration work. The result was a nightmare: N models × M tools = endless glue code. That's why MCP (Model Context Protocol) matters. MCP is doing for AI what USB did for hardware. A common standard that allows models to connect to external systems through a consistent interface. Instead of rebuilding integrations over and over, AI applications can communicate through a shared protocol. But most people only see the tool-calling part. The real architecture is much bigger: • Hosts • Clients • Servers • Tools • Resources • Prompts • Transport layers • Lifecycle management • JSON-RPC communication • Security controls • Observability This is where AI moves beyond demos. Because enterprise AI isn't about asking ChatGPT a question. It's about enabling AI to safely work across: → Databases → Internal documents → Code repositories → Cloud platforms → Business applications → Developer infrastructure MCP isn't flashy. It's infrastructure. And infrastructure is what turns experiments into products. The teams learning MCP today are building the foundation for tomorrow's agentic systems. My prediction: In a few years, understanding MCP may become as important for AI engineers as understanding APIs is for software engineers today. The future of AI won't be won by models alone. It will be won by the systems connected around them. Are we witnessing the emergence of the standard protocol layer for agentic AI?
@milan_milanovic ·
The Chrome team built an official MCP server that gives coding agents real DevTools Your agent usually debugs a frontend by reading the code and guessing what the browser does. With one 𝗻𝗽𝘅 line in your MCP config, it gets a live Chrome it can drive and inspect. It reads 𝗰𝗼𝗻𝘀𝗼𝗹𝗲 errors with source-mapped stack traces and checks network requests. It can also record real 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝘁𝗿𝗮𝗰𝗲𝘀. It works with Claude Code, Cursor, Codex and most MCP clients. Google collects usage stats by default, a flag turns that off. Check the repo: https://t.co/fcdSXinrje
@gokulr ·
PRODUCTSPEC MCP SERVER We just shipped the ProductSpec MCP server. This is the next step in making Product Specs useful to AI coding agents. The problem is simple: agents can write code fast, but they often don't know the product intent behind the code. They see the repo. They see the issue. They see the prompt. But they usually don't have a durable control file that says: • what problem this work is solving • what is in scope • what is explicitly out of scope • what acceptance criteria must pass • what AI evals should be run • what success looks like after launch That is what ProductSpec is meant to provide. The new MCP server lets coding agents access Product Specs directly as structured tools. An agent can now call: list_product_specs get_product_spec validate_product_spec get_scope get_acceptance_criteria get_ai_evals get_success_metrics get_related_artifacts check_completion_claim The important one is check_completion_claim. Before an agent says “done,” it can ask ProductSpec what still needs to be verified against the Product Spec. That changes the workflow. Without ProductSpec: - Founder or PM writes intent somewhere. - Engineer or agent gets a loose task. - Implementation drifts. - Everyone debates whether the thing that shipped was the thing that was requested. With ProductSpec: - Intent lives in the repo. - The agent reads the same control file as the team. - Scope and acceptance criteria become visible before coding starts. - Completion gets checked against the original product intent. You can configure it in any MCP-compatible coding environment as a stdio server. MCP config: command: npx args: ["--yes", "-p", "@productspec/parser@latest", "productspec", "mcp"] The open source repo now includes: • the ProductSpec standard • parser and validator • GitHub Action • agent skills • Decision Trace • MCP server • (Not in the repo, but there is a free privacy-friendly Git native Product Spec editor at ProductSpec dot io) My view: the next generation of software teams will need a product intent layer. Git stores implementation history. Jira and Linear store work history. Figma stores design artifacts. ProductSpec stores what the team meant to build, why it mattered, and what had to be true before the work was done. That intent now speaks MCP. Builders using coding agents: put a .product-spec.md file next to the work, then make the agent read it before writing code. The control file is where AI-native product development starts.
@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!
@pauliusztin_ ·
I’m building a GraphRAG MCP server for my personal assistant. Here's what surprised me: Building the knowledge graph was straightforward... Designing how the agent interacts with that memory was the hard part. The architecture is simple at a high level: • Ingest data into a unified memory • Extract entities + relationships into a graph • Index for hybrid and graph retrieval • Expose everything through an MCP server • Connect it to a harness like Claude Code or OpenCode But MCP tool design is where things get tricky... The goal is to let... • The agent query memory using natural language (while the MCP server translates it into @MongoDB queries) • The agent write to memory as naturally as possible But if you expose raw database operations, agents struggle. So I designed the server around how agents actually search and write: 1/ Search tools • nl_query_memory → LLM maps natural language queries to @MongoDB hybrid search + graph queries • query_memory → structured queries as a fallback when NL fails • deep_search_memory → progressive disclosure over large results (50+ docs), storing intermediate state (e.g., YAML index) for step-by-step exploration 2/ Write tools • ingest_url • ingest_file • ingest_conversation → auto-triggered via a hook every ~10 conversation turns The goal is to give the agent a set of high-leverage primitives that it can dynamically compose, like LEGOs within SKILLs. This is why I like building the MCP layer with @PrefectIO @fastmcp It keeps the server thin, so the same Python modules power both: • Batch ingestion pipelines orchestrated with @PrefectIO • Real-time memory access via @fastmcp, with built-in durability from @PrefectIO (which is critical for production orchestration) Then you hook it to the harness: Claude Code / OpenCode → skills + hooks on top of MCP If you’re building agentic GraphRAG systems, this is the pattern I’d recommend: Graph for memory. FastMCP for access. Harness for behavior. P.S. What’s the biggest bottleneck in your MCP servers right now?
@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
@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
@_jaydeepkarale ·
Back doing long form content after a while. If you want to understand how to test MCP server, this video is for your. In this I speak about MCP Inspector, an interactive utility from @AnthropicAI that let's you test your MCP tools without any hassle Write your MCP server in any language, run it using MCP inspector
Watch video
@RaulJuncoV ·
When you add an MCP server in front of your legacy API. 😅 Don’t get me wrong, MCP can make an old API accessible to AI. But the slow endpoints, inconsistent data, missing permissions, and undocumented behavior are still there. Now an agent can run into those problems faster. MCP is a useful adapter. It’s not an architecture upgrade. Even if your manager says the company is now “AI-forward.”
@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.
@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
@sagar_batchu ·
We wrote up how MCP servers are being used to attack the agents that connect to them. An agent trusts an MCP server to describe its own tools and return its own results. The exploits that abuse that trust have names now: tool poisoning, rug pulls, cross-server shadowing. None trip traditional security tooling, because nothing is breached. The attacks and the defenses, in full: https://t.co/7MFeyqUSpq
@patilvishi ·
Model Context Protocol (MCP): A Standard Way for AI Agents to Connect with Tools One AI agent needs: - Gmail - GitHub - Slack - PostgreSQL - Jira - Google Drive - AWS Another needs: - Stripe - Salesforce - Redis - Kubernetes Should every AI framework build custom integrations for every service? That doesn't scale. This is exactly the problem that Model Context Protocol (MCP) is designed to solve. What is MCP? Model Context Protocol (MCP) is an open protocol that standardizes how AI applications connect to external tools, data sources, and services. Instead of building custom integrations for every LLM and every tool: AI Agent ↓ MCP ↓ Tools & Data Sources One protocol. Many integrations. Why MCP? Without MCP: Agent A → GitHub API Agent B → GitHub API Agent C → GitHub API Different integrations everywhere With MCP: Agents ↓ MCP Client ↓ MCP Server ↓ GitHub Every agent speaks the same protocol. 1. MCP Client The client lives inside the AI application. Responsibilities: - Discover tools - Request resources - Invoke tools - Receive responses LLM ↓ MCP Client 2. MCP Server The server exposes capabilities. Example: GitHub MCP Server ↓ Repositories Issues Pull Requests The agent doesn't need GitHub-specific logic. It simply communicates with the MCP server. 3. Resources Resources provide read-only information. Examples: - Documents - Database records - Files - Logs - Configuration - Knowledge Base MCP Server ↓ Resources ↓ LLM Reads 4. Tools Tools perform actions. Examples: - Create issue - Send email - Deploy service - Update ticket - Execute SQL - Restart server LLM ↓ Tool Request ↓ MCP Tool ↓ Result 5. Prompts MCP servers can also expose reusable prompts. Example: Summarize PR Generate Release Notes Review Code Incident Analysis Agents can reuse standardized prompts across applications. 6. Multiple MCP Servers Production systems rarely use just one server. AI Agent ↓ MCP Client ↓ GitHub MCP Slack MCP Postgres MCP Filesystem MCP AWS MCP One agent. Many services. 7. Security Every MCP server should enforce: ✔ Authentication ✔ Authorization ✔ Input validation ✔ Audit logging ✔ Least privilege The protocol standardizes communication. Security remains the responsibility of the application and server. Production Architecture User ↓ Conversation Memory ↓ Planner ↓ LLM ↓ MCP Client ↓ ──────────────────────── GitHub MCP Server Slack MCP Server Database MCP Server Filesystem MCP Server AWS MCP Server ──────────────────────── ↓ Results ↓ Reflection ↓ Final Response MCP vs Traditional APIs Traditional Integration: LLM ↓ Custom GitHub Code Custom Slack Code Custom Database Code MCP: LLM ↓ MCP Client ↓ Standard Protocol ↓ Any MCP Server Less custom integration. More interoperability. Common Mistakes - Assuming MCP replaces APIs - Giving agents unrestricted tool access - No authentication - No authorization - Ignoring server security - Treating every resource as writable - No audit logs Best Practices ✔ Use MCP for standardized integrations ✔ Separate tools from resources ✔ Protect every MCP server ✔ Expose only required capabilities ✔ Validate all tool inputs ✔ Monitor MCP requests ✔ Apply least-privilege access ✔ Log every action ✔ Version MCP servers carefully Key Takeaway CP doesn't replace APIs. It provides a standard way for AI agents to discover and interact with them. Instead of writing custom integrations for every application: - MCP Clients communicate using one protocol. - MCP Servers expose tools, resources, and prompts. - AI agents gain a consistent interface to external systems. As AI ecosystems continue to grow, interoperability becomes just as important as intelligence. That's where MCP shines. It turns disconnected tools into a standardized ecosystem that AI agents can use safely and efficiently.
@therealdanvega ·
🤖Claude Code just shipped a fix for one of MCP's biggest problems: context window bloat. Enable tool search and your MCP tools drop from 25% to 14% of the context window. Tools load on-demand instead of all at once. Settings → enable_tool_search: true https://t.co/GdxPyDXVmK
@StainlessAPI ·
MCP is approaching an inflection point, and the limiting factor is becoming obvious. Last week we held our first event in SF with @KeycardLabs, @Cloudflare, @temporalio, and @humanlayer_dev. We talked about what’s breaking in MCP right now, and what it will take to make agent-driven software robust. Some hard truths: - Many MCP servers work in demos but fail across real-world use cases. - “Giant agent skills” are becoming an anti-pattern with thousands of lines explaining things the model already knows, without clarity on the 5% it doesn’t. - Standard MCP approaches (one tool per endpoint or dynamic tools) scored ~50% correctness, but more advanced implementations reached ~70%. - The real kicker: when agents wrote code against production-grade SDKs, correctness jumped to 90–95%. But capability is only half the story. Control is the other half. An in-house Gmail MCP server was great for drafting emails… until it sent one unintentionally. The question isn’t just “can the agent do this?” but “what is it allowed to do?” OAuth scopes and coarse endpoint controls aren’t enough, and we’ll need fine-grained, programmable boundaries like: - Limit an agent to a single document - Cap refund amounts - Prevent broad, unintended actions If AI interfaces are going to replace dashboards, the underlying systems need to behave like an operating system kernel, not a shell script. Capability gets attention. Control earns trust. Trust is what scales.
@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
@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.
@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!
@JulianGoldieSEO ·
𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 𝘀𝗵𝗶𝗽𝗽𝗲𝗱 𝟯 𝘃𝗲𝗿𝘀𝗶𝗼𝗻𝘀 𝗶𝗻 𝗼𝗻𝗲 𝘄𝗲𝗲𝗸 𝗮𝗻𝗱 𝘁𝗵𝗲 𝗠𝗖𝗣 𝘂𝗽𝗴𝗿𝗮𝗱𝗲 𝗮𝗹𝗼𝗻𝗲 𝗰𝗵𝗮𝗻𝗴𝗲𝘀 𝗵𝗼𝘄 𝗶𝘁 𝗵𝗮𝗻𝗱𝗹𝗲𝘀 𝗹𝗮𝗿𝗴𝗲 𝗽𝗿𝗼𝗷𝗲𝗰𝘁𝘀. Here's everything that actually matters across all three releases: → MCP tool result persistence now holds up to 500,000 characters. Before this large database schemas and codebase indexes would get truncated and Claude would make wrong assumptions about the rest. Now it sees the whole thing. → /powerup command launches interactive tutorials with animated demos right in your terminal. Fastest onboarding path available and it surfaces features most people miss for weeks. → Force remote settings refresh blocks startup until it fetches the latest config. If the fetch fails it exits instead of running with outdated permissions. No drift across teams. → Amazon Bedrock now has an interactive setup wizard. No more manually editing config files. Guided AWS authentication, region selection, and model selection. → 60% speed improvement on write tool diff computation for files with tabs, dollar signs, and ampersands. Shell scripts and config files noticeably faster. If you use MCP integrations check your max result size setting. Set anthropic_max_result_size to allow up to 500,000 characters in your MCP server config. Three versions in one week. This tool is moving fast. Update now: npm install -g @anthropic-ai/claude-code
Watch video
@ThePracticalDev ·
Wiring an agent straight to an MCP server leaves prompt injection in tool responses, data exfiltration and runaway recursive calls unwatched. This dev puts a bidirectional egress proxy in the path, checking calls out and payloads back. { author: @jitu028 + @GoogleDevExpert } https://t.co/TjvFYznp6J
@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.
@JulianGoldieSEO ·
X MCP server: X just handed AI agents a live feed of the internet's conversation. It dropped June 30th. Almost nobody is talking about it. Before: connecting your AI to X meant building your own server, wiring the API by hand, and babysitting logins. Hours of work. Now X hosts the whole bridge at https://t.co/jOR6M3o0fj. Your agent gets 200+ tools: → Search live posts and conversations → Spot trends as they break → Look up any user or thread → Pull real questions people are asking right now Content creators: stop guessing topics. Read the live demand. One catch: it's read-only. Research window, not a megaphone. And the #1 setup mistake: turning on all 200 tools at once. Your agent gets confused. Start with 2. New models get the headlines. Live data is the real upgrade.
Watch videoBest Model Context Protocol tweets
Xholic studies what works in your niche, drafts posts in your voice and schedules them for the hours your audience is online.
No card needed · Nothing to cancel
Browse all tweet collectionsLive demo: no sign-up or login needed · takes about 2 minutes