Finally I understood what happens on the other side when Claude calls connect, and the server identifies you and your access.. (Or better say, Claude helped me understand it). At first it was all acronyms for me. What made it click was understanding one client connect, once, end to end. Everything collapsed into three primitives that each fire exactly once, in a fixed order.

1. Discovery. A fresh client POSTs with no token and gets a 401 back carrying a WWW-Authenticate header that points at /.well-known/oauth-protected-resource. That header is the whole trick. The 401 is not the server slamming a door, it is the server handing over directions. Two GETs later (protected resource metadata names the auth server, auth server metadata lists the endpoints) the client knows everything it needs, having sent zero credentials.

2. Registration. No developer console. The client POSTs its own details to the registration endpoint and gets a client id on the spot. This is RFC 7591, and it is the part people trip on when they ask why this could not just be an API key. An API key assumes you already know the caller and can hand it a secret. MCP clients are strangers by design, so dynamic registration is the only model that works.

3. The grant. One human moment: a PKCE challenge, a consent screen that names the client, approve, done. At consent time the server bakes the user identity into the grant as props, so every later request just unwraps it. No per-request session lookup on the hot path.

There is one more cool trick: my server also performs OAuth as a client, upstream, because it bundles other servers that demand their own auth. Same three primitives, walked from the other side. Doing it by hand gave me real appreciation for how much invisible work Claude does every time you click connect and it just works. So it's just a multiplexer (not sure if it's a right term) for MCP servers.

Full walkthrough with the actual responses from the live server: https://prashamhtrivedi.in/mcp-oauth-primitives/

Curious how the rest of you are handling MCP auth right now. Across my own fleet I have Better Auth, an OAuth envelope wrapped around an API key, a hand-rolled JWT setup, and one static bearer token still holding out, so I do not think there is one right answer yet.

I've been working with AI coding agents (mostly Codex and Claude Code) on fairly large TypeScript projects, and I kept noticing the same thing.

The model wants to answer a simple question like:

• Where is this function defined?
• Who calls it?
• What's its inferred type?

...and ends up reading an entire 2,000-line file.

That felt incredibly wasteful, especially when the answer is just one function.

So I built SymbolPeek.

It's an open-source (MIT) MCP server that gives LLMs symbol-level access to your codebase instead of file-level access.

For TypeScript/JavaScript it uses the official TypeScript Compiler API, so it can answer things like:

• read_symbol
• find_references
• find_callers
• find_callees
• go_to_definition
• get_type
• get_call_hierarchy

For Rust, Python, Go, Java, JSON and Markdown, it currently provides syntax-aware navigation powered by Tree-sitter.

One real example from the project itself:

Instead of sending a 65 KB file (1,791 lines), the agent requested exactly one nested function and received about 2 KB of source.

I also added lifetime statistics because I wanted to know whether semantic navigation actually makes a measurable difference.

Current numbers from my own daily usage:

```text Requests: 162 Files avoided: 163 Lines avoided: 352,910 Bytes avoided: 6.4 MB

Estimated tokens saved: ~1.61M Average context reduction: 95.7% ```

These aren't synthetic benchmarks—they come from real coding sessions.

The goal isn't to replace grep or reading source files.

It's to stop AI assistants from loading huge files when they only need one declaration.

The project is completely free and MIT licensed.

I'd love feedback from people building MCP tools or using Codex, Claude Code, Cursor, Cline, Roo Code, Windsurf, etc.

GitHub:

https://github.com/pioner92/symbolpeek-mcp

On a flat plan (Max/Pro) you don't know how close you are to the 5-hour limit until it hits mid-task. On an API key, it's a surprise bill (unless your actively checking ofc), agents just spend

uvx nable ai-budget reads Claude Code's session logs on your machine (nothing uploaded), asks once whether you're flat-rate or metered, then shows tokens this window, month to date, burn rate, and a heads-up before you run out.

Flat plans get measured in usage, not dollars. A heavy month pulling ~$5k of list-price compute on a $200 plan is normal. That's subsidy the provider eats, not overage. Metered plans get measured in dollars. Token counts are exact; any dollar figure is a list-price estimate, never your real bill.

Also ships as an MCP server, so the agent can check its own budget before a big task instead of you finding out after.

Next: nable guard install. Cost preflight in front of the Terraform/kube/cloud CLI commands your agent runs. Propose-only, it never auto-executes.

Free, local, open source. https://github.com/getnable/finopsmcp

Hey folks, I built an iOS app called Signal not Noise. It's a todo app with one constraint baked in: you can only have 3 active tasks per day. The idea is forcing prioritization instead of letting a list grow to 40 items you'll never finish.

I just shipped an MCP connector for it so you can view and add todos from any MCP client using your own AI subscription instead of us running inference for you.

Endpoint (streamable-http): https://signal.lifeisagame.ai/mcp

Manifest:

{"name": "ai.lifeisagame/signal-not-noise", "title": "Signal not Noise", "description": "AI-driven daily-focus todo app on your phone (max 3/day). View & add todos from any MCP client.", "version": "1.0.1", "remotes": [{"type": "streamable-http", "url": "https://signal.lifeisagame.ai/mcp"}\]}

App Store link if you want to see the app itself: https://apps.apple.com/us/app/signal-not-noise-todo-list/id6782360346

Happy to answer questions about the implementation, auth flow, or the tool schema I exposed. Also open to feedback on the manifest if anything looks off.

If you're building an agent locally, you've probably found yourself manually poking at it with weird prompts to see if it breaks. We turned that into a slash command.

humanbound-test is a plugin (works in both Claude Code and Cursor) that:

• Auto-detects your local FastAPI agent server
• Tunnels it out with ngrok
• Helps you fill in one config file describing your agent's endpoints/payload/auth
• Runs an adversarial test (prompt injection, jailbreaks, tool abuse, multi-turn) through the Humanbound platform
• Sends results to your inbox, or streams them in-editor with /humanbound-test:resume <id>

You don't need to remember the slash command either. It also picks up natural language like "pentest my agent" or "test my chatbot for jailbreaks."

Install (Claude Code):

/plugin marketplace add https://github.com/humanbound/plugins.git
/plugin install humanbound-test@humanbound-plugins

Cursor needs a symlink for now since 2.5 doesn't support Git-URL plugin installs yet, steps are in the README.

Heads up on scope: it's FastAPI-only right now (other frameworks are on the roadmap), and running a test requires a logged-in hb session since it dispatches through the hosted Humanbound platform rather than running fully offline. It's also v0.1.0/preview, so command names and config schema may still shift.

Repo's here if you want to try it or file an issue: https://github.com/humanbound/plugins

Single-agent is basically solved/commoditized at this point. The interesting question for the next few years is how multiple agents work together. I see two fundamentally different bets emerging:

Camp 1 — Workflows (orchestration). LangGraph, CrewAI, n8n-style: you predefine the graph — agent A drafts, agent B reviews, agent C merges. Deterministic, debuggable, reliable. But the structure has to be designed before the work, so it only handles the paths you anticipated. Great for repeatable pipelines, weak for open-ended work.

Camp 2 — Rooms (free collaboration). Agents join a shared space like teammates in a meeting — potentially from different vendors (Claude Code + Cursor + Codex in the same thread), they negotiate who does what, and the structure comes from protocol instead of a predefined graph: a task board, explicit ownership, and evidence-gating (a task is only "done" when a different agent verifies it — otherwise you drown in phantom "done"s).

The tradeoff is real: workflows are predictable but rigid; rooms are flexible but chatty (token burn is no joke) and need guardrails to converge.

My bet: workflows win for known, repeatable shapes; rooms win for the messy 80% of real work where you don't know the shape upfront — and the endgame is hybrid: a room that spawns workflows for the parts it understands.

Full disclosure: I'm building in the room camp (Agent Room — a hosted MCP server any client can join), so I'm biased. Change my mind:

• Which camp are you actually betting on?
• Has anyone made cross-vendor agents (Claude + Codex + Cursor) genuinely cooperate in production?
• What's missing in MCP itself for either model?

Your AI coding editors can execute code in aws sandbox (aka Lambda Microvm) via mcp.

Easy, fast, isolated microVM sandboxes for AI agents and untrusted code on AWS Lambda MicroVMs — Python SDK, asb CLI, and MCP

https://github.com/dhanababum/agent-sandbox-os

A while ago, I thought the main problem with AI agents was simple: they forget everything between sessions.
But I’m not sure that is the best description anymore.

Agents have larger context windows now. They can read project instruction files, resume previous sessions, search old conversations, and use different memory systems.
They are getting better at remembering. But I keep running into a different problem:

The agent remembers an old decision, but does not know that it was replaced. It finds a note that was correct three months ago and quietly treats it as current.
It remembers what we chose, but not why we chose it or which alternatives we already rejected. It can retrieve ten relevant tasks, but it does not know which one is the priority now.

It knows that something is unfinished, but not whether it is actively being worked on, blocked, abandoned, or waiting for a decision. So I’m starting to think agent memory is becoming less of a storage problem and more of a truth problem.
Maybe remembering something is not enough. The agent also needs to know:

Where did this information come from?
Was it only an idea, or was it actually decided?
Is it still active?
Has it been replaced?
When was it last checked?
Does the current work conflict with it?

I’m building an open-source MCP project called BrainOS around this idea. It keeps decisions, their reasons, rejected alternatives, plans, blockers, and current project state. It can also check whether a new proposal conflicts with something already decided.

I’m not claiming that I have solved the agent memory. But, I’m trying to understand what the real problem has become as agents get smarter and smarter.
What breaks first in your current memory setup?
Is it forgetting, stale information, retrieving the wrong thing, treating a suggestion as truth, or losing continuity between different AI clients?

BrainOS is open source, and I can share the repo if anyone wants to see how I’m approaching it.

I run multiple agents every day. And there's this one problem that keeps showing up no matter how well everything else is built.

An agent needs to sign up for something. Or it needs to receive a verification code. And suddenly I'm manually hacking together an email address just to get past that step.

I'm curious how other people are actually solving this.

Are you using a service built for it? Got your own flow setup? Or just dealing with the pain every single time because nothing better exists yet?

Quick implementation and demo of SEP-2149.

archex is a stdio MCP server that gives agents structural code context instead of raw search hits: query/scout for token-budgeted bundles with a receipt (freshness, skipped candidates, completeness), symbol and file-outline lookups, and graph tools (neighbors/path/stats/hubs) for blast-radius and architecture questions against an exported dependency graph. 17 tools total, nothing hosted in the core path, every result deterministic for a given index revision.

Where it sits next to other tools in this space: measured against cocoindex-code (a retrieval-engine competitor) and Graphify (a graph/memory-layer MCP tool) on the same 19-task benchmark — required-file recall 0.95 vs 0.32 vs 0.70, cold-start 0ms vs 4.7s vs 937ms for a cold graph build. Self-run, checked-in, reproducible: docs/ARCHEX_VS_COCOINDEX.md. Graphify and archex aren't quite the same category (graph/memory layer vs retrieval engine) — the doc keeps that distinction instead of collapsing them into one leaderboard.

Six clients get a matching install-client target (Claude Code, Codex, Cursor, OpenCode, Pi, oh-my-pi); five get the optional non-blocking hook. Apache 2.0, 3,619 tests. Demo attached.

github.com/Mathews-Tom/archex

Star if it's useful, open an issue for gaps, share it with anyone building agent tooling that needs real code context instead of a grep dump.

Disclosure: I'm the author. Self-hosted, local-first, fully launched (tagged PyPI releases through v0.19.2), not a waitlist.

spent the last weeks building grabbit, a reddit lead gen tool, and this week shipped its MCP server. 16 tools. today claude used it end to end: searched threads, pulled subreddit rules to check where self promo is even allowed, read full threads, drafted replies, then marked entries as replied. watching it close the loop was genuinely weird

things that mattered more than I expected:

tool descriptions are prompts. the keyword tool takes a nested AND/OR query, nobody reads docs, so the syntax explanation with an example lives in the description and the model gets it right

verb grammar. list_ get_ search_ create_ update_ delete_ set_ add_ remove_, once the names were consistent the model stopped guessing wrong tools

payload budgets. a reddit thread with 100 untruncated comments is 60KB+. we measured, capped comments at 50 with 500 char bodies, ~35KB worst case

filters as enums (relevancy:high, intent:buying) beat free text, the model composes them reliably

happy to answer anything about the design. site is grabbit.sh if you want to poke at it, I'm the founder

MCP v2 finalizes in about a week (July 28) and I've been digging through the RC. Really into the fact that it's going stateless, no more sticky sessions feels like a real weight off if you're running anything horizontally scaled.

One thing that stings a little: sampling is getting deprecated. I'd actually planned to add it to one of my servers and just never got around to it, so it's a bit of a "well that window's closed" feeling.

For anyone running a server with actual traffic, how's migration prep going on your end?

I've spent the last six months on an MCP server that gives a repo one shared memory file .. decisions, open questions, standing rules .. that every agent session reads at startup and writes back to. npx klypix-mcp install wires it into Claude Code, Cursor, Cline, whatever speaks MCP. Apache 2.0, repo at the bottom.

The MCP plumbing was the easy part. The interesting mess was everything that broke once more than one agent could write to the same file. The log, in order:

1. Two writers, one file. The app and an agent hook both save the same file. The app's save was a plain overwrite, so it silently destroyed any card an agent captured while the app was open. I lost real decisions before I even noticed. The fix was a three-way merge (base snapshot vs mine vs disk) under a lock, plus one hard rule: the save refuses to write a file that lost a card. That one rule has caught more bugs than any test I've written.

2. The merge kept resurrecting deleted duplicates. De-dup collapsed twin edges, then the next merge brought them right back, because a union of "ours" and "theirs" re-adds whatever one side deleted. Every cleanup quietly undid itself on the next save. I had to teach the merge that an exact twin is the same edge, not two opinions.

3. The same card, serialized twice, turned into a "conflict". A card written by an agent, then re-serialized by the app after opening, produced different bytes for identical content. The merge saw both sides changed vs base and duplicated the card into a conflict twin. My test harness never caught it, because the fixtures were byte-identical by construction. They inherited exactly the assumption that was wrong. Quitting and reopening the actual app caught it in a day.

4. My first eval number was a lie I almost shipped. First measurement said 95% recall vs 0% cold. It never reproduced. After hardening the judge: 0/20 cold, 55% with the brief injected at session start, 73% with brief plus one search round, on 20 frozen questions about decisions actually made in the project. Small n, self-eval, all the caveats apply. But it reproduces, and the 95 is banned from every piece of copy I write now.

5. Retrieval kept ranking a rejected proposal above its rejection. Ask "what's our caching strategy?" and it matched the Redis proposal (high similarity) over the later decision that killed it, which lives in a different card and scores lower. Similarity has no concept of "no longer true". So now corrections supersede instead of delete, and when recall surfaces a card that a later card contradicts, the result carries an explicit warning: matched a STALE card, do not act on it. The agent at least sees the ground is contested instead of getting a confident wrong answer.

6. Thresholds tuned on test data fell apart on real data. Overlap detection passed at 0.5 on short fixture cards. Real cards are long, and the same detector measured about 0.33 in the field. Standing rule since then: nothing counts as verified until it runs against the real six-month file.

Two things surprised me in the other direction. The brief didn't grow linearly. It's a graph you traverse, not a log you replay, so at 900+ cards it's still around 3–5k tokens. And the sessions started coordinating through the file in ways I never designed: lane claims ("I'm editing middleware.ts, shout if you're mid-edit"), one-shot messages that get delivered at another session's next prompt, and cards anchored to git blob hashes that flag themselves as drifted when the code they were decided against moves on. 14 cards are flagged as I type this. The notes confess when they rot.

What six months left me believing, weakly held: the hard problem in agent memory isn't storage or retrieval. It's write contention and truth maintenance. The moment two sessions write, memory is a distributed system, and most memory layers are designed like single-writer diaries.

Where I'd honestly like to be told I'm wrong:

• I picked three-way merge over CRDTs because the file has to stay human-editable and git-versioned. Wrong call?
• Is there a better formal model for supersession than edges plus warnings? Bitemporal databases and event sourcing keep coming up, but both give up the one-readable-file property.
• At what scale does this collapse? 900 cards works. I have no idea about 9,000.

Repo in the first comment.

I have been building HostShift, an open source Go CLI for migrating Ubuntu and Debian web servers. While adding MCP support, I kept running into an uncomfortable design question: how much authority should an agent have over a real server migration?

My answer was to make the MCP layer useful for discovery, planning, explanation, review, dry runs, capability inspection, and rollback metadata, but deliberately unable to apply target changes.

The source server is always read only. HostShift does not use sudo there, restart services, install packages, change configuration, or create temporary snapshots. Actual target changes still require a reviewed CLI command from the operator.

The MCP server also exposes the migration workflow, source safety policy, capability catalog, and an operator prompt. The deterministic Go CLI remains the execution engine, so MCP is an optional operator layer rather than the thing performing the migration.

I would be interested in hearing how other MCP developers draw this boundary for infrastructure tools. Giving an agent enough context to help while keeping apply authority outside the protocol felt like the least surprising model to me.

GitHub: https://github.com/oguzhankrcb/HostShift

Documentation: https://hostshift.karacabay.com

FiveClaw can now spin up a codespace with FXServer and your framework plus the FiveClaw agent all pre-configured. Your AI editor(Claude Code, Qwen Code, Pycharm) can connect directly and immediately begin developing in an isolated environment. https://fiveclaw.xyz