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.

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?

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

I am working on a task to serve the APIs that we have over MCP. The problem I ran into was that the api returns large JSON and the LLM sometimes just ignores certain things plus also token consumed. I started experimenting with json to markdown and now I feel the errors are less. So I made it into package. It converts JSON to Markdown with special attention to tables since my API returns large array of large JSON.

I published this article on my site dedicated on ai agent. Let's have a look. Thank you

I would like to share the source code of an MCP server I recently built on public listing site without deploying it on a cloud server. Users will themselves install the MCP server locally.

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?

one-context-mcp stops the repeated setup explanation every time you switch AI tools. It stores project context locally in a small SQLite database and exposes it through MCP tools that every connected assistant can read and update.

pip install one-ctx
https://github.com/m4vic/one-context-mcp

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.

Quick implementation and demo of SEP-2149.

Ask an LLM for tonight's NBA or MLB odds and it'll give you a confident, totally made-up number. It can't not, the odds change by the minute and were never in its training data.

So I put a sports odds API behind an MCP server. Model calls a tool, gets the actual current board instead of inventing one.

Four tools:

• get_odds — moneyline, spreads, totals for a league
• get_props — player props (points, strikeouts, passing yards, etc)
• get_events — fixtures and scores
• get_books — what's covered

Hosted, streamable HTTP, same key works for REST and MCP:

{ "mcpServers": { "propzapi": {
    "url": "https://api.propzapi.com/mcp",
    "headers": { "X-API-Key": "YOUR_KEY" }
}}}

Free key, no card, 750 calls a month to mess with it.

Limits up front since someone will ask: it's DraftKings odds, not a multi-book aggregator, and in-season only, so right now that's MLB and soccer, NBA and NHL are dead until fall. Props are the part I actually cared about. They come back grouped per player with both sides paired, which is the bit most odds APIs make you fight.

Honestly the part that sold me on doing it at all was watching the model de-vig a market by itself once it could just fetch the numbers. Way better than me pasting a screenshot of the app into chat.

Solo build. Mostly I want to know if the tool schema reads clean to your agents or if I've named something in a way that confuses tool selection.

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

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 run mcpindex, a trust layer for MCP servers. I ran a census of whether the source repository behind every server in the official registry is still publicly reachable, and 1,830 of the 13,105 referenced GitHub repos are not. That is 2,069 listed servers. The npm/pip packages usually still install; you just cannot read the source before wiring the tool into an agent.

How I checked it, since the number is only worth the method:

- Every repo from two independent vantages: authenticated GitHub API from a datacenter IP, and the unauthenticated web UI from a home IP. Different network, method, and auth. Only repos both agreed were unreachable are counted. Zero disagreements across all 1,830.

- Confirmed only after two failures 48 hours apart, so a blip does not count.

- The measurement is timestamped to Bitcoin via OpenTimestamps, so the date is verifiable.

The part worth sharing for anyone building similar tooling: anonymous git ls-remote against a deleted or private repo returns a 401 credential prompt, not a 404. If you trust anonymous git, you file every dead repo as a generic error and report zero casualties while looking fine. That masked all 1,830 in my first two passes.

Honest limits: a 404 cannot tell a deleted repo from one made private on purpose, so I say "not publicly accessible," not "abandoned." Both checks read the same registry URL, so if a project moved I would wrongly flag it. Only the maintainer can catch that, and there is a dispute link on every page.

Report and method: https://mcpindex.ai/research/source-liveness
Open dataset (CC-BY-4.0, DOI): https://doi.org/10.5281/zenodo.21501868

Happy to go into the method in the comments.

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.

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