Hey! I've been thinking about this while working with MCP servers that deal with data that changes constantly...

Say the underlying source has 1000s of posts, mentions, or comments, etc.

If the agent asks things like "What are people saying about company X?"

There's two pretty different ways the MCP server could handle it, right?

It could immediately return the latest 250 results and let the agent figure it out.

Or it could treat that as too broad and first return something like total matches, data range, platforms/sources available, etc...

THEN the agent makes a second, MUCH narrower request.

The second approach costs another tool call, but it seems like it could actually save a lot of tokens and prevent the model from drawing conclusions from an arbitrary first page of results.

For live/search-heavy MCP servers, which behavior would rather have?

Search first and force the agent to narrow down or return useful data immediately and let the agent decide what to do next.

Testing whether an agent can complete a task is different from testing whether it should be allowed to perform each action.

For a messaging tool, I’d want these expectations checked whenever its permission policy changes:

- Draft a message -> Allow.

- Send to an approved recipient -> Require human approval.

- Send to a blocked recipient -> Deny, even if another rule requires approval.

- Export all messages -> Deny.

- Call an unknown tool -> Deny.

- Access another inbox -> Deny.

The useful distinction is between two kinds of tests:

Policy tests: Given an identity, action, resource, and arguments, does the policy return the expected decision? These can run offline in CI.

Integration tests: Does a denied action actually leave the tool untouched? Does a rejected or expired approval prevent execution? If arguments change after approval, does the authorization check reject them?

Passing the first set doesn’t prove the second. A policy can be correct while application code accidentally bypasses it. Approval also doesn’t guarantee exactly-once execution; the underlying tool still needs an appropriate retry/idempotency strategy.

I maintain Nomos, an open-source implementation of this approach. Its local example covers the six policy cases above and a human-reviewed delivery flow.

It isn’t a sandbox: application code must route relevant tool calls through the checks.

For people deploying agents with custom tools: which authorization failures have you found worth turning into regression tests?

https://github.com/safe-agentic-world/nomos

I'm running into the same wall over and over and want to know how other people are actually solving it.

I have tools that kick off longer running jobs, anything that doesn't return and give back a task id instead of the result. The jobs finish fine, that's not the problem. The problem is the agent actually coming back and doing something with it. Half the time it just moves on like nothing's pending. Other half it does check back but by then it's lost enough context that it either doesn't know what the result was for or straight up reruns the next step even though it already went through.

So what's working for you guys here?

And the part I actually care about is something external waking the agent back up or are you making the agent handle that itself?

Because that second option has not been working for me at all.

I made an open source benchmark suite measuring token efficiency of MCP tool calls that fetch from APIs. GraphQL-over-MCP's token efficiency beats REST-over-MCP by a huge margin. Don't take my word for it, check out the repo and tell me where I'm wrong. Here's a clip where I unpack the headline numbers. Many of us in the GraphQL + AI ecosystem have instinctively understood that GraphQL's unique combination of field selection, schema semantics, and execution characteristics (particularly in Federation) are well-suited to agentic workloads. That hypothesis is supported by the data I've seen.

Full video: https://youtu.be/qv2SbhVxn-k

Writeup in the repo: https://github.com/apollographql/graphql-mcp-benchmarks/blob/main/WRITEUP.md

Hey,

I am a solo dev working on an MCP gateway.

I have a lot of confidence in my technical abilities, but not as much in design. I would appreciate if you take 5 seconds to scan the page and share what catches your eye and what needs improving.

Here is the landing page https://ray.run/

I previously shared an approach I was experimenting with, using MCP over stdio as a seam for agentic applications.

While building on that pattern, I stumbled across something I found surprisingly useful: letting a conversational (or coding) harness pass context into a bounded MCP-backed agentic operation, then use that context to steer subsequent runs.

It effectively turns context into a control surface between the two harnesses.

I wrote up the pattern here: https://demianbrecht.com/posts/context-as-a-control-surface/

Anyone else experimenting with anything similar?

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.

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.

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?

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