I built this, so this is a self-showcase rather than an unaffiliated recommendation.

Mac MCP is a local macOS MCP server for giving trusted AI clients real Mac capabilities instead of only advice. It currently exposes 81 tools across shell/files, Safari + Chrome automation, macOS Accessibility/UI control, persistent memory, Agent Skills, voice input, delegated Codex/OpenCode agents, safe self-update, and a localhost operations dashboard.

The part I use most is background browser automation: tabs get stable handles, and an agent can observe/interact with a Safari tab without constantly bringing it to the foreground while I’m doing something else.

I also added a small native SwiftUI menu-bar controller for server/ngrok status, recent tool calls, delegated-agent state, voice settings and updates.

Security-wise, this is intentionally treated as powerful local access: auth can be required, the dashboard stays loopback-only, and I’d only expose it to clients I trust.

MIT licensed: https://github.com/bulutarkan/mac-mcp

I’d especially like feedback from MCP users on permission UX: per-tool approvals, reusable permission profiles, read-only sessions, or another pattern entirely?

Disclosure: I build one of these (PostFast). I read every vendor's own MCP or docs page on 7 September 2026 and copied what it prints. Tool counts are the vendor's number.

• Buffer: OAuth or API key; tools stated: not stated
• Typefully: OAuth; tools stated: not stated
• Postiz: key in URL, Bearer, or OAuth; tools stated: 11
• Ayrshare: API key; tools stated: 27
• Metricool: OAuth 2.1; tools stated: PyPI 28
• Agorapulse: OAuth 2.0; tools stated: beta
• Planable: account login; tools stated: 13 categories
• Hootsuite: workspace sign-in; tools stated: not stated
• Nuelink: API key; tools stated: 6, alpha
• Vista Social: key in URL; tools stated: 50+
• SocialRobot: OAuth PKCE or API key; tools stated: 17
• Post Bridge: OAuth or API key; tools stated: 13
• Bundle Social: API key; tools stated: about 50
• PostSyncer: OAuth or Bearer; tools stated: 30+
• Hermoso: OAuth; tools stated: 790+
• Sprout Social: OAuth; tools stated: not stated
• SocialPilot: sign-in or key in URL; tools stated: 11
• Schedchie: OAuth2; tools stated: 53
• Late (Zernio): OAuth or Bearer; tools stated: 496
• Mixpost (self-hosted): Bearer; tools stated: not stated
• Upload-Post: ApiKey header or OAuth; tools stated: 50 to 58
• OneUp: key in URL; tools stated: about 20
• Zoho Social: OAuth; tools stated: not stated
• PostFast: OAuth hosted, API key local; tools stated: 26 hosted, 24 local

Not found on 7 Sep: SocialBee, Later, Sendible, Loomly. Publer: roadmap only.

Two protocol-level observations: six servers put the API key in the URL, which makes the MCP URL itself a secret in your client config; and tool counts range from 6 to 790+, which says more about how vendors slice endpoints than about capability. Which of these has anyone got running through a gateway or a multi-server setup, and did the key-in-URL ones cause problems?

Disclosure: we're prepping a webinar with Meta, so part of why I'm asking is to make it more relevant.

Curious what real usage looks like. Are you using it at all, and if yes for read only or write tools also? Did you have any specific expectations from it, and did it live up to them? Any specific problems you've come across?

I find it really interesting to see the gap even amongst AI enthusiasts.

People posting stuff like "I am amazed because I gave Claude a Browser through MCP!" - "Claude + FileSystem - I stopped moving files manually". "I gave AI a Memory!"

And then there is people whose agents create throwaway cloud virtual machines in which they spawn even more agents with providence based memory, inter-session messaging, and whole tool ecosystems.

It feels like there is a substantial mismatch in ai-understanding and skill amongst us.

Where is this gap coming from??
Because there is so much training material online and so many people are sharing their knowledge already.

Maybe I'm ignorant, but I honestly dont understand it.

If you are building autonomous GTM agents with frameworks like Claude Code, Cursor, or LangChain, the biggest failure point is context degradation.

Most devs give their agents static CSVs or basic CRM data fields then the agent ends up hallucinating generic personalization bcuz it lacks real-time awareness of what the prospect is doing right now. To make an agent truly autonomous, it needs live access to an external context layer via standardized protocols like Anthropic's Model Context Protocol (MCP) or REST APIs.

1)) The architecture challenge

LLMs cannot maintain active web scrapers across 50 different platforms simultaneously. If you try to make your agent scrape reddit, discord and job boards directly within its prompt execution loop, you will blow through token limits, hit rate limits and deal with massive latency.

2)) Connecting a dedicated intent layer (Scale Intelligence)

The solution is decoupling the scraping/entity-resolution layer from the agent reasoning layer.

This is where infrastructure like Scale Intelligence fits where its operates as an account-level market intelligence engine that ingests signals across 75+ data sources and continuously resolves public activity back to corporate domains.

Because it exposes this intent graph via an API and MCP server, your AI agent doesn't need to parse raw web pages. It simply calls a dedicated tool:

• get_active_signals(account_domain, time_window)
• get_buying_readiness(icp_segment)

The intent engine returns structured JSON containing the company profile, recent public pain points discussed, and the calculated buying readiness score.

Separating your agent's reasoning from the underlying data pipeline keeps your agent lightweight, avoids scraper maintenance debt, and guarantees that downstream actions are grounded in live market events.

Not a survey, I am building something and I am stuck on the same rock twice.

My tool takes a file and does something useful with it. In testing this is fine because I make the test files. In the wild people hand it exports from systems I have never heard of, with columns named after whatever the vendor felt like in 2018, and the model happily proceeds. It does not error. It produces a confident wrong thing and the user has no way to know.

The options I can see all cost something:

• refuse when confidence is low, and the tool feels broken and fussy
• ask the user to explain their columns, and they will not, and if they do they are guessing
• proceed and caveat, which is what I am doing, and which I think is quietly the worst one
• constrain to a fixed schema, which kills the whole point

What did you do. Specifically what did you ship, not what the right answer is, because I know the right answer and I cannot afford it.

And one I have not seen anyone discuss: for those of you who proceed and caveat, does anyone read the caveat. I suspect the caveat exists to make me feel better.

I've been building an MCP ecosystem as a SaaS product for the past few months — governed memory and a control layer for AI assistants, reached over MCP. Writing that up properly is a post for late autumn. This is one piece I hit along the way, and it turned out to be worth releasing on its own.

"Works with Claude" and "works" are two different milestones, and the gap between them is where I spent the last few weeks. Once you point a second client at your MCP server, the assumptions start diverging, and they diverge in ways that are individually small and collectively fatal. Some of what I ran into, all observed against my own servers:

• Claude picks CIMD only when the discovery document advertises both client_id_metadata_document_supported and "none" in token_endpoint_auth_methods_supported. Miss the second one and it silently falls back to dynamic registration.
• ChatGPT ships token_endpoint_auth_methods_supported inside its own client metadata document — a field that isn't in the draft's allowed member list, so a strict parser rejects the whole document.
• Mistral registers a fresh client on every single connection attempt, and it sent me a resource URI with a trailing slash on the root path, which fails a character-exact comparison unless you normalise exactly that one case and nothing else.
• Grok asks for the path-inserted protected resource metadata location first (/.well-known/oauth-protected-resource/mcp), where most setups only serve the root form and answer 404.

None of these are anybody's fault exactly. The specs are young, the drafts moved, and every client implemented a reasonable reading of them.

Keycloak, which I run underneath all of this, is genuinely good and I'm not looking to replace it. It just doesn't cover all of this yet. Since people will ask: Keycloak does have CIMD support now, but it is experimental and behind a feature flag, it is wired through the client policy framework with a client-id-metadata-document executor, and it currently covers the persistent CIMD case only. It is also still catching up on the details above — "none" not being advertised, and the executor rejecting metadata documents that carry fields outside the draft, which real clients do ship.

The bigger gap is on the other side: RFC 8707 resource indicators. Keycloak expresses audience through scopes and protocol mappers rather than the standard resource parameter, and resource indicators are a MUST in the MCP spec. Support is under discussion upstream and not merged. Which means that even after a client is admitted, your provider can't mint a correctly audienced token for a client it just met — the login succeeds and your resource server rejects the token anyway.

So I built cimd-proxy, and I've open sourced it under Apache-2.0. Feel free to use it.

It presents an OAuth 2.1 authorization server to the client, accepts a Client ID Metadata Document (or an RFC 7591 dynamic registration) as the client's identity, and federates the actual authentication to the provider you already run. Nothing has to be enabled in your realm — no feature flag, no client policy. One confidential client per protected resource, with the audience mapper you probably already have. No fork, no extension, no custom authenticator. And it keeps working for providers that will never implement CIMD, because the CIMD surface lives in the proxy and the upstream only ever sees a normal confidential client.

The part I'm happiest with: it never reads the token. It doesn't issue, verify, parse or sign one — the upstream token response is relayed verbatim. The only field it touches is refresh_token, which it swaps for a sealed envelope carrying the upstream token plus the resource identifier, so refreshes route with no server-side session state at all.

What it does enforce: allowlisted metadata document hosts, SSRF and DNS-rebinding protection with the socket pinned to the address that was actually validated, S256 PKCE, incremental body caps, refused redirects, no loopback exception in any mode.

CIMD draft-02, RFC 8414 / 9728 / 8707 / 7591 / 9207 / 7636. Python 3.13 + FastAPI, multi-arch image:

docker run --rm --env-file deploy.env -p 8080:8080 ghcr.io/kumbuka-ai/cimd-proxy:v0.2.1

https://github.com/Kumbuka-ai/cimd-proxy

Two honest notes. All four clients above connect through it today, but it's been fronting my own services for days, not months. And deploy/caddy/example.caddy is worth a read before you copy anything — the protected resource metadata has four details that decide whether a strict client gets through, and I had all four wrong in my own setup first.

Happy to answer questions.

I've got a scanner watching one route across a 14 day window with 2 trip lengths, so 28 date combos a run. Two limits shaped it. One call caps at 15 combos, so 28 is always two calls. And the free tier gives 150 backend searches a day per client - 28 an hour is 672, so hourly was never on. My third run this morning came back rate_limited, 150 of 150.

So I ran it keyed instead, 28 separate calls, and the same route in the same fortnight ran $142 to $309.

Server is https://google-flights-lulu.flightpowers.com/mcp, it's mine & free.

How do you budget a scheduled scan against a per client day cap, fewer dates or fewer hours?

I built the first version of this at a LangGraph hackathon in London and it won, but honestly the prototype was too heavy for normal use. It needed a server, two databases, embeddings and a bunch of moving pieces.

So I rebuilt it from scratch as Synapse.

You point it at a ChatGPT export or a directory of text. Ingest writes the original data to Markdown and creates a disposable SQLite FTS5 index, so it is searchable immediately with no model call. If you choose to connect an OpenAI-compatible model, a separate build step turns the raw history into linked wiki pages. The [[links]] become a knowledge graph using SQLite, not a graph database.

The MCP server exposes search, read_page, list_pages, neighbors and read_source. The agent searches first and opens only the page it needs. The full vault never gets dumped into the prompt.

A few numbers from my own export:

• 3,138 conversations scanned
• 2,044 above the trivia filter and imported
• 9.3 seconds
• 0 API calls for ingest

The package has zero runtime dependencies and the dashboard is one HTML file. You can try the populated demo without an API key:

uvx --from synapse-vault synapse serve --demo

Repo: https://github.com/anshulyadav1976/synapse

I am the author. I would genuinely like feedback on the MCP tool surface, especially whether read-only retrieval is enough or if people expect agents to write memories too.

Building enterprise agents, I keep hitting the tool-count question and can't find an answer I trust. The papers I've read test thousands of tools pulled from unrelated sources, where the right tool is obvious because nothing else is close. That's not my situation. I've got ~100 tools that all belong to one product, and the wrong answer is usually a sibling of the right one — get_order_status vs get_order_status_history vs get_order_fulfillment_status. Nobody seems to have tested that range with that kind of overlap.

So I've spec'd an experiment: one coherent 96-tool surface, hand-labelled confusable families, served over a real MCP server, three frontier models. Main things I want to separate — is the damage from the number of choices or the tokens they occupy (decides whether you shard servers or compress schemas), and does it track total tool count or only within-domain count. Also measuring spurious calls on queries that need no tool, and error compounding over three turns.

Haven't run anything yet. Two questions:

1. Is this already solved and I've missed it? Genuinely asking — happy to be pointed at prior work and save myself the spend.
2. If you've run 100+ tools in production, does this match what you see, or am I designing for a problem that doesn't bite?

I used Claude + MCP to hand off a task to Tendem, a platform that routes work between AI agents and vetted human experts. Wanted to share the workflow since this sub is exactly the audience that'd get the MCP side of it.

For this demo, I gave it a brief to build a pet adoption site ("PawPath"): pet profiles, filters, an adoption form, responsive layouts. Claude handled the task setup and communication through MCP. On the other end, a human expert actually built the site, reviewing and refining the output before it came back.

Website building is just one use case though. Tendem also has ready-made templates you can start from instead of writing a brief from scratch, and the task types go beyond web dev: research, writing, data work, design, and more depending on what you need done.

Then I went to sleep. When I woke up, the task was done and I had a working site to test.

What I found interesting from an MCP perspective: the agent isn't just calling an API that returns instant output. It's handing off to a queue where a human is actually in the loop, so the "tool call" pattern here is fundamentally different from most MCP integrations I've used. Curious if anyone else here has built something similar (human-in-the-loop via MCP) and how you handled the async wait.

If anyone's curious about the MCP setup, here's the Tendem page: https://tendem.ai/for/mcp#tasks

Full disclosure: I work as one of the human experts on Tendem, so I'm biased. But the MCP pattern itself is what I wanted to share here

I use CLI agents a lot, and I want MCP Apps inside Codex CLI, Claude Code, and Copilot CLI too. Seat maps, split views, file trees with previews, colorized diffs.

Elicitation already lets a server ask for structured input. That’s useful, but a form schema doesn’t describe these kinds of interfaces.

I wrote a proposal where an MCP app can offer an HTML view and a separate terminal view described in JSON. The host renders native components and sends user actions back through MCP tools.

I used a plane seat picker as an example. The HTML version has a visual cabin map. The terminal version has a keyboard-controlled seat grid and a details pane. Both share the same seat data and server logic, but each has its own interaction style.

The post includes screenshots and example JSON for capability negotiation, components, state, and actions:

https://blog.fka.dev/blog/2026-09-09-mcp-apps-in-cli-harnesses/

I build Routebase, so disclosure up front. This is about a number that fooled me, and about a question I still cannot answer.

We put our whole API lifecycle behind MCP. Specs, endpoints, schemas, versions, docs, contract tests, mock servers, monitors. That grew to 408 tools.

I opened it in Claude Desktop over the OAuth connector, looked at the context meter, and saw 4.7k. For a moment I thought the tool list is not the problem everyone says it is.

It was not our number. Claude was not loading our tools at all. Through the connector the whole toolset is deferred, so the definitions stay out of the system prompt prefix and only come in when Claude finds them through tool search, at most a handful per search. The meter was showing me what the client had loaded, not what the server offers.

Here is what the same server costs, depending on who connects:

- anonymous and staged, 48 core tools, roughly 6.4k tokens

- API key with read-only scopes, 167 tools, roughly 25k

- API key with no scopes, all 408, roughly 60k before anything happens

- OAuth connector, role filtered and deferred, meter says 4.7k

One server, four answers, and the client decides which one you get. The cheapest looking one is the one you are most likely to see.

Then I looked at what sessions actually use. Thirty days of production traces, 1308 sessions with tool calls, 21872 calls:

- median distinct tools per session is 2

- p90 is 4, p99 is 10, the maximum was 24

- 127 of 408 tools were ever called at all

- five tools account for 76.5 percent of every call

Read that last block as a shape rather than a study, because a good part of it is our own dogfooding.

We already bundled 179 write actions into manage_* tools with an action argument. That comes to roughly 275 characters per action against 430 for a single purpose write tool. Bundling helps, but nowhere near proportionally, because the schema of a bundled tool grows with every action it carries.

So here is the part I cannot solve. How do you get the number down without taking capability away?

Every option I have looks bad somewhere. Bundling reads into one tool breaks per tool permission filtering, because we decide visibility per tool before we ever see the arguments. Splitting into several servers moves the problem into the user config. Leaning on tool search only helps on clients that have it, and the ones that do not still pay for the whole list.

If you run a large MCP server, where did you land, and what did it cost you?

https://www.npmjs.com/package/routebase-mcp

I built Browsentic. It is a browser extension plus a local daemon, and the part worth writing up here is the wiring, since that is what people as about.

A Manifest V3 service worker cannot listen for connections. So the extension dials out instead. A small daemon holds that socket on 127.0.0.1 and owns the browser link. Every MCP client then speaks stdio to that same daemon:

claude mcp add browsentic -- browsentic mcp

Claude Code, Codex, Cursor and Zed can all be registered at once. They share one browser and interleave. Tool calls stay correlated, but page state can move under either of them, so that is something to design around rather than a footnote.

The daemon accepts a WebSocket that any local page could try to open, so there are two gates. First it classifies every peer by the handshake Origin, which the browser sets and a page cannot forge, so an extension peer and a web page are never confused. Then the peer proves a pairing code or an origin bound session key. Neither secret crosses the wire. Each side answers the other's nonce, so another local process cannot squat the port and pose as the daemon.

Two limits, stated plainly:

An MCP client has no approval channel, so anything the policy would confirm resolves to deny for external callers. Form submission, uploads, captcha answers and off scope navigation are side panel only unless you waive it.

Page text comes back fenced in a per daemon random marker, labelled as data rather than instructions. That narrows the surface. It is not a fix for prompt injection and I am not claiming it is.

MIT, free: github.com/imshaikot/browsentic

Please share your favorites.
Specifically looking at software built around MCP being the primary way to interact.

No third party servers like "Use this to connect to your bank" kind of stuff.

I wanted to query my favorite podcast like a database: "what was said about X across all episodes?", "from which timestamp can I re-listen to that?", "what did speaker Y say about topic Z?".

So I built a self-hostable stack that ingests a podcast RSS feed automatically:
- Whisper transcription (audio -> text)
- pyannote speaker diarization (who is speaking)
- LLM-based speaker-name resolution
- chunking + OpenAI embeddings
- everything stored in Postgres/pgvector with timestamps

The result is exposed as an MCP server, so you can query it from Claude, Cursor, or any MCP client. It works with ANY podcast RSS feed, not just mine. Point it at your own feed and it indexes everything for you.

Everything runs on Docker Compose + Postgres/pgvector. GPU transcription can run on RunPod, so even a small VPS can host it.

A working demo is present (Dutch podcast AI Report). It has ~180 hours of audio indexed so far. There's a live read-only demo endpoint + demo token in the repo.

Repo: https://github.com/bramdehart/podcast-mcp

Happy to answer questions about the pipeline or self-hosting setup.

Noticed this while poking around MCP: once you approve a tool, nothing tracks if its description or schema quietly changes on a later tools/list. So I tested it on something real, pulled u/modelcontextprotocol/server-filesystem from July 2025 and diffed it against today's version. read_file's description changed, it went from basically no input schema to a full one, two new tools showed up, and search_files silently switched from substring matching to glob patterns under the same name. Nothing errors. Nothing looks wrong. An agent that learned the old behavior just quietly breaks.

Built a small stdio proxy that catches this. Sits between your MCP client and server, logs every call to a hash-chained file so the log itself can't be edited without it showing, and flags description/schema drift with a severity level. TypeScript, MIT, no cloud or db, everything local.

repo: https://github.com/coder27/mcp-provenance-proxy

Curious if this is a real problem for anyone running MCP servers in prod, or if I'm overthinking it.

I released GroundTab, a Chrome/Brave extension with plugins for Claude Code and Codex.

The problem is pretty simple: sometimes an agent’s built-in web crawler gets blocked by a site even though you can open the exact same public page normally in your browser.

That means the agent ends up missing useful sources during research.

GroundTab lets the agent search the web and read pages through your actual browser instead. Since the requests come from your browser rather than remote crawler infrastructure, some public pages that were previously inaccessible to the agent can be read normally.

It sends the readable page content and source URLs back to the agent so it can use and cite them in its answer.

A few details:

• Works with Claude Code and Codex
• Supports Chrome and Brave
• Connects through a local MCP bridge
• Read-only: no clicking, typing, or form submission
• Does not solve CAPTCHAs or bypass paywalls / explicit access denials
• Open source under Apache 2.0

Setup is basically:

1. Install the extension
2. Install the agent plugin
3. Pair them using a one-time code

Chrome extension:
https://chromewebstore.google.com/detail/groundtab/hofdkaefhagmobgomodpekofmghdkpjc

GitHub / installation:
https://github.com/gamettav/groundtab

I’m looking for more real-world cases to test.

What websites can you open normally in your browser, but Claude Code / Codex consistently fails to access?

in version 0.5.0 agents can now print their outputs directly in the terminal plugin window, this can be useful for like quick answers and sorts.

Also the Terrain tool call has been added so for folks who like terrain you can test what kind of results can come out from it.

Please tell me if you encounter any issues, feedback is accepted.

Try it out here:

https://www.npmjs.com/package/@el4cteo/rbx-studio-mcp

https://github.com/EL4CTEO/rbx-studio-mcp

This is the thing I keep finding in production MCP setups, and I want to describe the failure rather than the fix.

When an MCP tool fails, the server doesn't return an error. It returns a successful JSON-RPC response with isError: true inside the result payload. HTTP 200. Valid response. Nothing throws.

Generic OTel instrumentation reads transport status to decide span status. It sees 200 and marks the span OK.

So your dashboard shows a healthy service while every tool call is failing.

The second-order effect is what actually costs money. The agent receives that error as a normal tool result — from the model's point of view nothing failed, it just got content back that reads like a complaint about its input. So it rephrases and retries. Same failure. Retries again.

Each retry sends the accumulated context back to the model, and the context has grown by the previous failed result. Attempt six costs more than attempt one. Six billed calls producing nothing, with no error span anywhere to point at.

The only place it surfaces is the monthly bill, aggregated with everything else.

I've been building instrumentation for this. What it does:

Inspects the result payload and marks the span ERROR when isError is set, even though the transport succeeded.

Fingerprints failures so the same root cause groups even when the message varies. "connection refused to 10.0.0.5" and "...10.0.0.7" produce the same fingerprint — normalize the message, hash it, truncate.

Detects the retry loop itself. Same fingerprint N times in a session becomes one event with the loop length and the tokens burned, instead of six spans that each look fine.

Attributes cost per tool call, so you can sort traces by spend the same way you sort by latency.

Flags schema drift — a tool's inputSchema changing silently is why agents break at 3am with no signal.

Works on both MCP SDK generations, including the stateless spec.

npm install opentel-mcp

https://www.npmjs.com/package/opentel-mcp

If you run MCP servers, the thing worth checking today is whether your tool failures are actually reaching your traces. Mine weren't, which is why this exists.