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

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.

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.

Looks to me like the Tasks API is the only real hard break, and Roots/Sampling/Logging just have the 12-month runway.

Am I missing anything that bites sooner?

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 put together my thoughts on WebMCP and how you can utilize it today in this crisp article!

If you run coding agents locally, you've probably had the "wait, what did it just do?" moment. I got tired of not being able to prove it, so I built Kriya.

It sits between your agent and your tools. Every tool call (any MCP server, or even a desktop app with no API) passes: policy → approval-if-it-matters → budget → a signed audit line you can verify yourself, offline. Routine stuff runs; anything that moves money or deletes things pauses for an Approve/Deny in your UI.

100% on-device. MIT core, on npm + crates.io. macOS only for now (Windows/Linux next).

Not trying to spam — genuinely want to know what's missing before I build the wrong thing. What would you want it to catch?

Repo + 50s demo in first comment.

django-orm-lens v0.8 shipped today. Static analysis over your models.py files — no DJANGO_SETTINGS_MODULE, no runserver, works with a broken venv. Three surfaces (VS Code, CLI, MCP server) share one parser.

What's new in v0.8

Every feature was researched against proven prior art before a single line was written — Atlas, Prisma, Sourcegraph, Knip, PyCharm, DataGrip, factory_boy, flake8-django, Roslyn, Ruff, Clippy.

Inline QuickFixes (16 rules) — Ruff-style codes DOL001..DOL032 with Clippy-style Applicability (safe/suggestion/unsafe gate auto-apply). Covers: - .count() > 0 → .exists() - .first() is None → not .exists() - null=True on CharField/TextField - Missing on_delete on FK - Missing __str__ on Model - datetime.now() → timezone.now() - N+1 attribute-access-in-loop heuristic - render(request, ..., locals()) and Meta.fields = '__all__'

Per-rule severity overrides: djangoOrmLens.rules = { "DOL007": "off", "DOL013": "error" }. Suppress inline: # django-orm-lens-disable-next-line DOL007.

Factory generator — right-click any model → factory_boy DjangoModelFactory scaffold with Faker providers keyed by field type. CharField(max_length) scales word-count buckets; DecimalField(N,D) computes left_digits=N-D; choices= maps to Iterator; M2M gets @post_generation. FK chains pull related factories transitively.

Time-Travel Schema Diff — pick two commits from git log, get a typed markdown diff (Add/Drop/Rename/Modify events) ready to paste into a PR description. Renames are first-class events, never Add+Drop.

Impact Analysis — "what breaks if I remove this field?" Workspace-wide reference scan across every Django layer (models, serializers, forms, admin, views, urls, templates, tests, migrations) with Certain / Likely / Possibly confidence tags on every finding. Handles ORM string refs, kwarg lookups (filter(author__id=1)), Meta.fields tuples, and template variables — the string-typed surface Pyright can't reach.

Interactive Query Builder — right-click a field or model → pick a template → snippet inserted at cursor (with tab-stops) or in a fresh untitled buffer. .filter(field=?) on an FK auto-appends .select_related(...); .annotate(post_count=Count('post_set')) honours related_name; .prefetch_related for M2M.

Also in this release: sidebar UX overhaul (stable TreeItem.id, MarkdownString tooltips with clickable command: deep-links, activity-bar badge, FileDecorationProvider badges), 100/100 tests up from 4 at start of dev.

Install

code --install-extension frowningdev.django-orm-lens
codium --install-extension frowningdev.django-orm-lens
pip install --upgrade "django-orm-lens[mcp]"

Full release notes: https://github.com/FROWNINGdev/django-orm-lens/releases/tag/v0.8.0

Why static-only

Point it at any Django project without setup — no settings module, no dependencies except our parser. Runs in CI or on the plane.

Trade-off: custom get_queryset overrides, dynamic model classes are invisible. But 95% of what you actually want to see lives in `mo

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.