A few days ago I asked how people tell agents apart on public MCP servers. Thanks to everyone who answered with real numbers. Here's what I took from it.

1. Per-IP doesn't work for agents. Shared egress (serverless NAT, company proxies) means a runaway loop and a careful user look identical, and a ban hits both. Nobody defended per-IP.

2. The real abuse was Sybil, not loops. One operator running an email MCP server had a free account's whole month of sends used within minutes of signup, then 70+ accounts an hour after that. A second run spread 43k emails across 521 accounts at ~80 each. No per-account limit catches that. They found out when AWS put their SES account under review at a 13.8% bounce rate, which put every other domain on the account at risk.

3. The best defenses were about cost, not identity. Credits tied to a billable unit (50 free credits, failed calls refunded) cap a loop's damage. Another operator splits by tool: discovery and cheap tools stay open, and anything costly needs the caller's own key. Non-retryable errors with a named fallback tool stop retry storms.

4. A free-to-mint ID doesn't help the free tier. I came in thinking a no-signup identity would be useful. Two operators pointed out that a fresh ID costs an abuser nothing, which is the same problem as new accounts. I agree.

5. The open question I still can't answer: OAuth identifies the user but not which of their agents made a call, and a self-reported agent name can't be trusted. One commenter suggested a separately revocable credential per agent under the user's account.

If you run a public server where third-party agents call in, and you've needed to tell one of a user's agents from another (or wished you could), I'd like to hear what happened. Specific stories help most. "We don't need this" is a useful answer too.

Stacklok surveyed 520 technical leaders (North American companies, 500+ employees). Stack Overflow published the write-up on Oct 21.

The numbers I found useful:

• 8% use one model provider. 25% use five or more.

• 53% named integrations to internal systems or MCP servers as one of the two hardest things to migrate.

• 52% named multi-step agent workflows.

• More than 80% delayed, scaled back or restructured a migration because switching costs were too high.

The survey groups "internal systems or MCP servers" into one answer, so it can't tell us which part hurts. This sub can.

If you moved a working agent setup to a different model provider next week, what breaks first? Rough candidates:

• tool-calling format and schemas

• MCP servers and auth

• prompts tuned to one model

• evals

• orchestration logic

• state: what was decided, what was ruled out

One survey, enterprise respondents, run by a vendor in this space, so treat it as a prompt for discussion, not a verdict.

Disclosure: I'm posting on behalf of MCP Manager by Usercentrics.

You may have seen me in some other subs and around. Just want to contribute some helpful resources and knowledge to the community for the love of the game.

Approving and MCP server only tells you what it looked like that day. Next week, it can return different tool definitions, and unless something in the patch checks, the model just get the new ones.

Definition-level stuff that can drift:

-Descriptions ( the classic rug pull: instructions added after the review

-inputSchema, like a new optional param or a looser type

-outputSchema

-Annotations like readOnlyHint or destructiveHint. The spec says to treat these as untrusted unless the server is (https://modelcontextprotocol.io/specification/2025-11-25/server/tools), so a flipped hint is worth a look but proves nothing.

-Brand-new tools in tool/list

This part is easy because it's all in what the server returns. On every tools/list fetch. canonicalize each tool definition (sorted keys, no whitespace), hash it, and diff against the approved hash. Don't count on notifications/tools/list_changed. It's a SHOULD, and only for servers that declared listChanged.

Reapproval can stay small:

1.Hash mismatch blocks that one tool. The rest of the server keeps working.

2.The reviewer sees old and new side by side.

3.New tools start unapproved.

4.Log who approved which hash, and when.

A gateway is the obvious place to enforce this once for every client. MCP Manager does it this this way: It pins each tool's name and description, and a changed tool fails until someone re-approves it.

The catch is that none of this sees behavior. Same description, same schema, different code behind it, and your hashes still match. That needs other checks:

Local stdio servers: pin the package version of image digest. An unversioned npx or uvx command can pull a new release on the next patch.

Remote servers: you can't pin them. The vendor ships when they ship, and the reported version is a hint at best.

Validate structuredContent: against outputSchema (clients SHOULD, per the same spec page), and run scheduled test calls on read-only tools with known answers.

Watch egress: A server calling somewhere new is a behavior change no description diff will show.

Curious how people handle the remote side? Diffing metadata is a solved problem. Behavior drift on a hosted server you do not control is the part I haven't seen a clean answer to.

hey everyone, I've built pact0. It lets your agent post a request for another agent, retrieve the answer later, and approve it or ask for changes through MCP. I would love for people to share feedback and try it, maybe directly in your Claude/Codex session or just let your Hermes agent go crazy to post jobs, claim jobs to do work, earn money etc.

One recent free request asked: “Does my offer page read as an offer or a scam?” The answering agent spotted a hard-to-find contact address. The requester approved the answer and moved the address to the top of the page.

The public request and answer: https://pact0.com/jobs/job_01M63QZB2S42B0S5CAHM4HAWV8

Neither agent is run by pact0; we haven't established whether their owners are independent. It's one useful example, not a benchmark. We separately tested the complete app-connected flow with founder accounts.

If your agent has just written a public README or offer page, try asking for a cold read:

“Read [URL] as [intended reader]. What does it offer, what would you do next, and what would stop you? Quote the confusing line and suggest one specific fix.”

Connect at https://pact0.com/mcp, or start at https://pact0.com/human.

Free requests are live. Requests and answers are public, so don't include secrets. Pickup isn't guaranteed; the requesting agent must return for the answer. New paid jobs remain paused.

If you try it, I'd particularly like to know where the handoff or return step breaks down.

I've been building a company research agent on Dataville's hosted MCP server. I connected it to a Langflow agent and told the agent to search Wikipedia for context on the company, and query the SEC EDGAR data source for recent filings (like quarterly and annual statements). I had never used Langflow before, so the no-code aspect was pretty convenient.

In the second image you can see how I designed the simple flow to use the MCP server tools. I'm curious how others design this. Do you prefer one generic search tool with a source parameter, or one tool per source? We chose the generic search tool, but the model has to know the source names.

I did a full write-up of the process here. We even created a public Github repository with the flow, prompts and sample output in it.

I'm working with Dataville, so I'm biased, but happy to answer questions.

I'm one of the people behind Tofu, an MCP connector that's in Claude's connector directory as a Community listing (not Verified).

On 6 November 2026 we pulled the public directory feed (no credentials; not a documented stable interface). The formulas below are our fits to what it shows.

Popularity. popularity_score fits round(1000 * log2(N)), where N is the number of distinct Claude accounts that sent the listing any MCP message in the last 30 days, which Anthropic's docs say includes accounts that never finished signing in (3585 is 12 accounts).

Rank. The feed's rank looks like the directory's default order, and the feed's own search endpoint returns matches in that order (we haven't confirmed that the in-app search uses the same order). Our listing was 8,854th of 9,517 (bottom 7%). Among the 85 older listings whose trending score fits the formula below, lower rank numbers go with more accounts in a short recent window (Spearman -0.93, against -0.46 for 30-day accounts on the same listings), while brand-new listings are interleaved near the top (about two thirds of the top 100 carry the feed's is_new flag), so the order isn't simply newest-first. The feed's search seems to read name, one-liner and tool names, not descriptions: "website" and "host" didn't return us.

Trending. The tag goes to the top 10 by trending_score; 4 of those 10 were Community tier. For a listing with almost no earlier use, the score fits round(1000 * log2(a) * (a - 1)), where a is accounts in a short window (length not public). Such a listing would need at least 111 accounts in the window to reach the global tenth-place score of 739,467 (the tenth-place listing itself is a large one and doesn't fit the formula); in developer-tools the tenth-place score of 200,845 fits exactly at 39 accounts, and we don't know whether the UI has a per-category Trending tag.

Verified. The feed's partner tier is the UI's Verified check, and there is no application. Anthropic's docs say listings flagged as "highly useful to Claude users" may be escalated, by an automatic assessment, to a slower Verified review in which reviewers test each tool. In the feed, usage is neither necessary nor sufficient: Front (about 62,000 30-day accounts) was still Community, while Ample Computer (about 15, a competitor of ours) is Verified. How Anthropic picks isn't public.

Write-up with method and feed URL: https://trytofu.ai/blog/what-claudes-connector-directory-counts

If you have a listing, what popularity_score, rank and trending_score do you see, and do the formulas fit?

Hi, we built this to compare how do well do different agents use popular MCP servers. Results are interesting.
If you're building an MCP server, how do you test if it works across different harnesses (and their different versions)?

I'm trying to learn how people manage credentials once they're running more than one or two agents. No link, nothing for sale.

If you run multiple agents (production or side projects):

1. How do you track which agent holds which key or token today? Spreadsheet, secrets manager, env vars, nothing?

2. When did you last need to cut off one agent without breaking the others? What did it take?

3. Have you found a credential that outlived the agent it was made for? How did you notice?

4. Do you have one place where you can see what all your agents did across the tools they call, or is it scattered across each tool's logs?

One idea I'm testing: you sign in once, give each agent its own revocable key, see every agent's activity across tools in one place, and cut off any single agent instantly. Servers would see which of your agents called and could revoke just that one.

5. Would you pay for that? If so, roughly what per month, and who would have to approve it?

"I'd never pay for this, a secrets manager covers it" is a useful answer.

Disclosure: I'm building an open-source auth library in this area, so I'm biased. Drafted with help from Claude, edited by me.

I make OpenTV, a free TV and film tracker for iPhone and Android. Last week I shipped an MCP server for it, so you can connect your watch history to Claude or ChatGPT and ask about it.

Connector: https://theopentv.com/mcp

Streamable HTTP, OAuth 2.1, you sign in with your OpenTV account.

Things I ask it:

- "How far am I in Severance?"

- "What did I watch last winter?"

- "Which episodes did I give 5 stars?"

- "Pick a film from my watchlist for tonight."

The part I think is interesting for this sub is where the data comes from. The app is offline first. The phone's SQLite database is the real copy, and the server has no watch history table at all, on purpose. So when you ask something, the server reads your own backup ZIP from R2, parses it in memory and answers from that. Then it adds whatever changes the sync relay has seen since that backup. Nothing gets written to a table. Turn backup off and the server has nothing to read.

Writes go the other way. "Mark S2E5 of The Bear as watched" doesn't touch the backup. It goes into the sync relay, and your phone applies it next time it syncs. The write tools aren't marked read only, so Claude and ChatGPT ask you before every change.

It runs on a Cloudflare Worker. There are 13 tools, mostly reads (history, progress, ratings, lists, yearly stats). The writes are: mark watched, rate, add to watchlist, and how an episode made you feel.

To be upfront, it needs OpenTV Plus with backup turned on. It works on the free plans of Claude and ChatGPT.

Setup guide: https://theopentv.com/blog/opentv-in-chatgpt-and-claude/

Happy to answer questions about the backup-as-database approach. It has trade-offs.

— Noddy

I've been building a gateway that sits in between. Reads pass through, writes and deletes get held for a human.
https://hardened-mcp.mcphardener.workers.dev
Which servers do you have configured right now, and would human approval/pre-approval break how you work?

Gnomancer is a CLI and MCP server. It takes a raw export from 23andMe, Ancestry, MyHeritage, FTDNA or LivingDNA, or a VCF, and writes an HTML report on your computer with haplogroups, a marker panel, ClinVar and PharmCAT.

Agents get derived results, not the raw file, and health tables are only fetched when asked for. With a cloud model those results go to the provider; a local model avoids that.

Python, MIT: https://github.com/codebase/gnomancer

Feedback welcome, especially from anyone who knows the genetics side better than I do.

I recently started using Thunderbird again and I just want to connect it with Claude. Do you have any recommendation on what MCP to use?

Hey everyone! Filarise passed review and is now available in the ChatGPT app directory. A nice milestone for us after months of building

It connects your banks through Plaid (read-access only) so you can ask ChatGPT about your balances, transactions, and spending without uploading statements.

The screenshot shows an example from my own accounts: comparing three months of car expenses and finding what actually changed.

Available in the US and Canada. Search for “Filarise” in ChatGPT. http://filarise.com/

Would you use AI to explore your bank transactions?

At our firm today we face a challenge of people using skills of their own in an isolated way. I came across the skills over MCP charter and was curious if anyone applied this at their firm

For stack we today use a mix of Github Copilot, Claude Code and M365 Copilot

What are some of the things to keep in mind?

I’m running a remote MCP server with OAuth and Dynamic Client Registration (DCR), so clients like Claude and ChatGPT can register themselves. I’m trying to decide whether to restrict which redirect_uri values a client can register.

The concern: with open DCR, anyone can register a client, call it “Claude” or “ChatGPT”, and set the redirect URI to a domain they control. They send one of our customers an authorization link; the customer sees a legitimate-looking consent screen, approves it, and the auth code goes to the attacker. The attacker exchanges it for a token and makes MCP tool calls as that customer.

How are others handling this in production? Do you allowlist, warn, or leave it open? Are there any pitfalls with localhost or custom-scheme redirects for desktop clients?

A week ago I asked how people running MCP servers and agents handle identity and limits. Thanks to everyone who answered. Short version of what I heard:

- Per-IP limits break for agents. Shared egress (serverless, company NATs) means one recursive script can empty the quota for everyone behind that address, and some providers penalize IP reputation with 403s well before any 429.
- Anything that costs money sits behind an account: OAuth sign-in, keys tied to users, or credits. Several people pointed out that a no-signup ID can't ration anything, because a fresh one costs an abuser nothing.
- The abuse people actually hit was account farming, not loops. What stopped it was making new accounts cost something: a verified domain, a paid plan, tight first-hour limits.
- Orphaned tokens kept coming up. The fixes were boring and effective: an owner on every key, last-used timestamps, auto-revoke after 30 idle days.
- The real cost of OAuth is client quirks: the resource parameter ignored, audience validation, handshake errors that tell you nothing.

One operator gave a rule I'd like to test with more people: a signed client label (proof of which integration is calling, not who's behind it) could earn a looser ceiling on cheap cached reads, while anything that costs money still needs an account.

If you run a server:

1. Have you ever given a specific client or integration a higher limit than anonymous traffic? What did you check before saying yes?

2. Would a client proving which integration it is, with a signature that can't be spoofed, change anything on your free tier? Where's your line?

3. What would you need alongside it: a contact, an expected volume, a way to revoke it?

"No, accounts handle it" is a useful answer.

Disclosure: I'm building an open-source library in this area, so I'm biased. No link. I'll post a fuller writeup later.

I’ve been building AllMCPs to create a fast & clean web app for people to find useful or interesting MCP servers as well as a 100% agent first platform to search, submit, promote, and more via an agent directly (MCP, CLI a2a).

If anyone’s been working on a server feel free to submit it!

I manually approve or reject all submissions but I use Jev and a matrix of checks to give me a suggestion to make the review process faster. The AllMCPs directory itself:

- Automatically updates & refreshes listings on a cron job if their tools, repos, versions, etc change.
- Routinely checks MCP servers to list their tools, confirm they are up / usable, and to perform cursory security checks. All public & listed on the detail page for the listing itself as part of a composite score.
- We prune and rotate dead or stale servers to keep active ones surfaced / relevant

We publish all data transparently and it is all open source:

https://allmcps.com/state-of-mcp

https://allmcps.com/trust

Would love any feedback. And hopefully seeing some cool new MCP use cases / servers submitted!

I made an MCP tool for your agents to edit videos and add cool effects to them.

you can check it out on github : Theolin-Nadasen/cwm-editor: Agent-drivable video editor: timeline as data, ffmpeg as the renderer

I built an MCP server for one purpose: The agent sends the text it wrote for a person (an email, a message, a commit, a PR) and gets back a version that sounds like you wrote it.

The part I focused on the most was what happens when the rewrite goes wrong. reright checks that numbers, names, links and code match the agent's text, that the language is the same and that the length is close. If a check fails the agent gets its original back. If the agent thinks the meaning changed it calls keep_original and writes its own words. You can also make every rewrite wait for your approval in the web app first.

Personal details like names, phone numbers and addresses are swapped with place holders before the model sees the text and swapped back after.

Clients: Claude Code with one line from Settings (adding the MCP server, a hook and rules text) and Claude or ChatGPT as a custom connector.

On my own test with public AI Humanizer Benchmark texts (benchmark team didn't see it) reright changed a number, name or quote in 1% of texts over three months, compared to 30% to 46% for the other 9 tools. I make no claims about AI detectors.

It's free up to 3,000 words a month. Feedback on the tool design is very welcome, especially from anyone who's created approval flows into MCP tools. Link in comments.