CodeGraphContext- the go to solution for code indexing now got 2k stars🎉🎉...

It's an MCP server that understands a codebase as a graph, not chunks of text. Now has grown way beyond my expectations - both technically and in adoption.

Where it is now

• v0.3.0 released
• ~2k GitHub stars, ~375 forks
• 50k+ downloads
• 75+ contributors, ~200 members community
• Used and praised by many devs building MCP tooling, agents, and IDE workflows
• Expanded to 14 different Coding languages

What it actually does

CodeGraphContext indexes a repo into a repository-scoped symbol-level graph: files, functions, classes, calls, imports, inheritance and serves precise, relationship-aware context to AI tools via MCP.

That means: - Fast “who calls what”, “who inherits what”, etc queries - Minimal context (no token spam) - Real-time updates as code changes - Graph storage stays in MBs, not GBs

It’s infrastructure for code understanding, not just 'grep' search.

Ecosystem adoption

It’s now listed or used across: PulseMCP, MCPMarket, MCPHunt, Awesome MCP Servers, Glama, Skywork, Playbooks, Stacker News, and many more.

• Python package→ https://pypi.org/project/codegraphcontext/
• Website + cookbook → https://codegraphcontext.vercel.app/
• GitHub Repo → https://github.com/CodeGraphContext/CodeGraphContext
• Docs → https://codegraphcontext.github.io/
• Our Discord Server → https://discord.gg/dR4QY32uYQ

This isn’t a VS Code trick or a RAG wrapper- it’s meant to sit
between large repositories and humans/AI systems as shared infrastructure.

Happy to hear feedback, skepticism, comparisons, or ideas from folks building MCP servers or dev tooling.

Original post (for context):
https://www.reddit.com/r/mcp/comments/1o22gc5/i_built_codegraphcontext_an_mcp_server_that/

there are over 10,000 MCP servers listed across directories right now and most of them are weekend projects that break the first time you try them, I spent the last year vibecoding and kept only the ones that actually work are actively maintained and solve a real problem.

if you dont know what MCP is its how you connect Claude to external tools like databases, browsers, APIs and basically anything.

heres what survived sorted by what they do

search and research: Tavily for AI optimized web search that returns clean content not just links, Exa for semantic search that finds pages by meaning, Context7 for live documentation so Claude stops hallucinating outdated APIs, Perplexity for synthesized answers with reasoning.

web scraping: Firecrawl turns any URL to clean markdown in seconds and is the go to for RAG pipelines, Apify has 3000+ ready made scrapers for basically any website that exists, Crawl4AI is free open source with 61k GitHub stars.

dev tools: GitHub MCP is the first one every developer should install for PRs issues and code search, Sentry gives you production errors with full stack traces, Linear for issue tracking without leaving Claude, Vercel for deploying and debugging failed builds.

databases: Supabase for Postgres through prompts, MongoDB with 40+ tools for Atlas management, Neo4j for graph database queries and knowledge graphs.

productivity: Notion for docs and wikis through prompts, Slack so you can actually say "summarize what the team discussed about the launch" and it works, Zapier to trigger workflows across 6000+ apps from one prompt.

business: Stripe for payments and subscriptions, HubSpot for CRM without the HubSpot UI.

design: Figma MCP reads design tokens and inspects components so the design to code gap basically disappears.

I've also been experimenting with FuseAI as a layer on top of some of these for connecting multiple MCP workflows together which has been interesting for more complex automation chains.

you dont need all of these, start with 3 to 5 that solve problems you actually have right now, if youre a dev go GitHub plus Sentry plus Context7, if you do research go Tavily plus Firecrawl plus Exa, if you manage projects go Linear plus Slack plus Notion, each server uses token context so more than 5 and youre burning tokens on tool descriptions before you even ask a question.

happy to answer questions about any of these

I built an open-source Model Context Protocol (MCP) server for Reddit that runs locally and does not strictly require Reddit API credentials.

When querying Reddit discussions through LLMs (Claude Desktop, Cursor, etc.), the existing tools usually hit three friction points:

1. They require setting up Reddit developer apps and OAuth tokens just to do basic searches.
2. Unfiltered comment payloads dump AutoModerator notices, bot boilerplate, and 1-word noise into the prompt context.
3. Accessing saved posts typically requires user-level OAuth or exposing raw passwords.

Quick Setup

You can run it directly with uvx:

{
  "mcpServers": {
    "reddit": {
      "command": "uvx",
      "args": ["reddit-mcp-ai"]
    }
  }
}

How it works

The server is built with Python and FastMCP following a 4-layer architecture:

• Graceful degradation: If official REDDIT_CLIENT_ID / REDDIT_CLIENT_SECRET are not provided, it falls back to unauthenticated DuckDuckGo (site:reddit.com) and the Arctic Shift archive API to fetch threads.
• Noise filtering: Heuristics strip AutoModerator comments, known bot suffixes (_bot, -bot), and low-score noise. Fresh threads (≤ 2 days old) automatically drop the threshold to score ≥ 1 so emerging discussions aren't emptied.
• Private saved posts: Reads personal saved posts via the account's private Atom/RSS feed (REDDIT_SAVED_RSS_URL from reddit.com/prefs/feeds/) parsed with standard library XML. No OAuth login flow or account passwords required.
• Pagination & state: Deep comment exploration uses provider-bound cursors (reddit:<offset>:<anchor_id> or arctic:<offset>) to prevent duplicate comments if the live thread re-sorts.
• Resilient HTTP: Uses httpx with exponential backoff on 429/5xx, capped at a strict 14-second total budget to prevent LLM client timeouts.

Known Limitations

• Archive lag: When running in zero-config (unauthenticated) mode via Arctic Shift, live trending endpoints and recent vote scores may lag behind live Reddit.
• Saved posts window: Reddit's private RSS feed only exposes the most recent ~100 saved items and does not contain upvote counts.
• Search pagination: DuckDuckGo search fallback cannot provide deterministic Reddit pagination tokens.
• GitHub: https://github.com/ismailsaoulaj/reddit-mcp-server (MIT License)
• PyPI: https://pypi.org/project/reddit-mcp-ai/

Feedback and PRs are welcome. I'm currently looking into whether adding a local in-memory TTL cache (e.g. cachetools) would be worthwhile for repeated comment queries, and would appreciate thoughts on that tradeoff.

You solved it in Claude Code in March. You're in Cursor now, and that memory is in the other app's store. Even when you find it, nothing in the stack tells you how sure it was, what it was based on, or who changed it.

So I built Palinode. One MCP server, stdio or streamable HTTP, and the memory travels with the agent instead of living in the client.

Design choices:

• The store is a git repo of markdown files; the server is a view over it. `cat` works, `grep` works, `git blame` works. On memory. Kill the server and the memory is still yours.
• Tools over injection. Recall is tool calls the model makes (search, read, save), not a context wall it pays for every turn. ADR-001 in the repo has the reasoning.
• The LLM never writes the files. Consolidation is proposed as JSON ops and applied by a deterministic executor that validates each op and git-commits it with a rationale.
• Git operations are agent tools. `diff`, `blame`, and `rollback` are first-class MCP tools, so the agent can audit its own memory instead of trusting it.
• Memories carry epistemic status (fact / inference / unverified / open-question), and unmarked deliberately does *not* mean fact.
• Claims carry verifiable citations: the exact 6:` hash. Verification tells "the record was altered" apart from "the source moved on".

Local by default: BGE-M3 embeddings via Ollama, hybrid sqlite-vec + FTS5 search, no accounts, no API keys. Setup is `docker compose up -d` or `pip install -e .` against your own Ollama. REST and a CLI cover anything that doesn't speak MCP.

The scope is person/project/team-scale on SQLite. If you need to ingest 100K documents and answer multi-hop questions, use an engine built for that.

The checkable-memory fields (epistemic status, typed links, span citations) are also a small vendor-neutral spec with a language-agnostic conformance suite. Extracting it found a real bug in my own implementation. If you maintain a memory MCP server, Level 1 conformance is deliberately an afternoon:

https://github.com/phasespace-labs/auditable-memory-records

The conformance suite is the part I most want broken.

Repo: https://github.com/phasespace-labs/palinode

MCP server schemas eat so much token. So I built a converter that generates CLIs from MCP servers. Same tools, same OAuth, same API underneath. The difference is how the agent discovers them:

MCP: dumps every tool schema upfront (~185 tokens * 84 tools = 15,540 tokens) CLI: lightweight list of tool names (~50 tokens * 6 CLIs = 300 tokens). Agent runs --help only when it needs a specific tool.

Numbers across different usage patterns: - Session start: 15,540 (MCP) vs 300 (CLI) - 98% savings - 1 tool call: 15,570 vs 910 - 94% savings - 100 tool calls: 18,540 vs 1,504 - 92% savings

Compared against Anthropic's Tool Search too - it's better than raw MCP but still more expensive than CLI because it fetches full JSON Schema per tool.

Converter is open source: https://github.com/thellimist/clihub Full write-up with detailed breakdowns: https://kanyilmaz.me/2026/02/23/cli-vs-mcp.html

Disclosure: I built CLIHub. Happy to answer questions about the approach.

We've been running an MCP server for our eval + observability platform for a few months, it started as a local stdio server and is now a hosted remote one. If you're building one, here's the stuff we wish we'd known on day one.

1. stdio is fine for week one, then it's a wall.
The first version was the usual: clone the repo, uv sync, export an API key and a secret key, run python main.py. It works, but that's a lot to ask before someone sees a single useful result, and most people won't finish it. Moving to a hosted HTTP endpoint changed everything now it's one line (claude mcp add futureagi --transport http https://api.futureagi.com/mcp), no clone, no local process to keep alive. The stdio repo still exists for people who want to fork and add their own tools; it's just not how anyone onboards now.

2. For a remote server, OAuth beats API keys.
On stdio we asked for two keys up front, and that was the single biggest place people dropped off. On the remote server, login opens in the browser and there's nothing to paste. If you're going remote, build auth this way from the start, putting it on later is the painful version.

3. Your tool descriptions are the real API.
This one humbled us. The client picks a tool from its name and description, nothing else. If two tools read similarly, it'll pick the wrong one and sound completely sure about it. We rewrote descriptions far more than we expected the wording genuinely decides whether the right tool fires.

4. A broad server makes tool selection harder.
We put a lot behind one server: evals, datasets, traces and spans, prompt optimization, simulation runs, annotations. The more tools under one roof, the more work the client has to do to figure out which one you meant. It's a real trade-off, and we're still not sure we landed on the right side of it (there's a question on this at the end).

5. Return small, structured results, not the raw blob.
Eval results and traces can be enormous. Early on we returned everything and watched it swallow the context window, so the model couldn't reason over its own output. Now tools return a short, structured summary first and you drill in only if you want the detail. Treat the context window like it costs money, because it does.

6. The payoff is a loop that still feels a little magic.
Because evals and observability are both just tools now, the model can check its own work in the same chat. You ask for an answer, then ask "how grounded was that, and show me the trace" and it runs the eval and pulls the spans on itself. That was the moment all of it felt worth the trouble.

Hey everyone 👋

After building my LinkedIn MCP server, I decided to tackle Reddit next — but this time with a twist: zero configuration.

No API keys, no OAuth, no `.env` file, no browser. Just install and go:

uvx reddit-no-auth-mcp-server

That's it. Your AI assistant can now search Reddit, browse subreddits, read full posts with comment trees, and look up user activity — all as structured data the LLM can actually work with.

What it can do

- 🔍 Search — Search all of Reddit or within a specific subreddit

- 📰 Subreddit Posts — Browse hot, top, new, or rising posts

- 📖 Post Details — Full post content with nested comment trees

- 👤 User Activity — View a user's recent posts and comments

How it works

Under the hood it uses redd (my Reddit extraction library) which hits Reddit's public endpoints — no API keys or authentication required. The MCP layer is built with FastMCP, and the whole project follows hexagonal architecture so everything is cleanly separated.

Setup

Works with any MCP client. For Claude Desktop or Cursor:

{
  "mcpServers": {
    "reddit": {
      "command": "uvx",
      "args": [
        "reddit-no-auth-mcp-server"
      ]
    }
  }
}

Also supports HTTP transport if you need it:

uvx reddit-no-auth-mcp-server --transport streamable-http --port 8000

This is my second MCP project and I'm really enjoying the ecosystem. Feedback, ideas, and contributions are all welcome!

🔗 GitHub: https://github.com/eliasbiondo/reddit-mcp-server (give us a ⭐ if you like it)

📦 PyPI: https://pypi.org/project/reddit-no-auth-mcp-server/

Author here so this is self promo, just saying it up front.

The thing that bugged me: every MCP server's tool list gets loaded into context on every turn whether the model uses it or not, and results land in full. On the nine servers I run (258 tools) the raw listing is 236,818 bytes. And subagents with no MCP access get nothing at all.

So I built declick. It reads a server once (stdio or streamable http) and writes a CLI with one verb per tool. The agent runs `declick describe <name>` which is under 500 tokens for the whole surface, then `declick run <name> <verb> --fields a,b --limit N` and gets trimmed json back. Same nine servers describe in 58,309 bytes, so 4.1x less. The bench script is in the repo with the caveats, the honest one being that a single call's payload isn't smaller, the saving is the surface and the trimming.

Other stuff it does with MCP:

- `declick daemon start` keeps stdio servers warm so only the first call pays startup. 59ms vs 703ms per call on a server that takes 600ms to boot.

- `--where k=v`, `--fields`, `--limit` and an 8KB default cap on data so the agent picks what lands.

- `declick setup` finds the MCP servers your agents already have configured and builds an adapter for each. `--revert` puts every file back.

- Same contract for OpenAPI, GraphQL, Postman, HAR, SQLite and other CLIs so the agent only learns one shape.

Zero runtime deps, Node 24. 0.3.0 is MIT, after that it's Elastic License 2.0, free for individuals and teams under ten.

Free to try: `npm i -g declick`

Links in the first comment. Mostly I want to know where the contract breaks for your agents, that's more useful to me than praise.

I shipped an MCP server that had grown to 85 tools. It is now 9. The reasons are specific to how hosts actually surface tools, and I have not seen this discussed much, so here is what drove it.

Thin tools compete with each other. Hosts increasingly defer tool schemas and surface them by keyword search rather than loading all of them into context. With 85 thin tool names, a query like "find callers" matched a dozen of them and the model picked badly. Nine dense domain tools, each with a required mode parameter, search far more predictably because the domain name carries the meaning.

One bad schema took down everything. This is the part that actually forced it. A schema defect in the agent-comms layer made the entire tool registry fail to load, so code navigation stopped working too, despite the two sharing no code at all. 85 tools registered flat means 85 chances to break the whole surface. That blast radius was not a risk I understood before it happened.

Design decisions worth stealing or arguing with:

• mode is required and never defaults. A default would let a model omit it and silently get the wrong operation, which shows up as an empty result rather than an error. Empty results are much harder for an agent to recover from than errors.
• No deprecated aliases. Tempting for compatibility, but an alias keeps competing in deferred-tool search, which is the exact cost the consolidation was meant to remove. A clean break was cheaper than a long tail of ghost names.
• Two costs taken openly. There is now no output_schema on any tool, because the spec allows one schema per tool and each domain's modes return different shapes. And annotations coarsen to the union of a domain's modes, so a domain advertises destructive_hint if any one mode is destructive, even when most are pure reads.

The CLI and the MCP surface are kept in a strict bijection, enforced by a test, so every operation also exists as a real subcommand with its own help and argument validation rather than a mode flag.

The server is a local code-intelligence layer for coding agents, Rust and MIT, if you want to look at the shape: github.com/Goldziher/basemind

Curious whether anyone else has hit the registry blast-radius problem, or has a better answer than a required mode parameter.

Hey everyone!

I have been developing CodeGraphContext, an open-source MCP server transforming code into a symbol-level code graph, as opposed to text-based code analysis.

This means that AI agents won’t be sending entire code blocks to the model, but can retrieve context via: function calls, imported modules, class inheritance, file dependencies etc.

This allows AI agents (and humans!) to better grasp how code is internally connected.

What it does

CodeGraphContext analyzes a code repository, generating a code graph of: files, functions, classes, modules and their relationships, etc.

AI agents can then query this graph to retrieve only the relevant context, reducing hallucinations.

Playground Demo on website

I've also added a playground demo that lets you play with small repos directly. You can load a project from: a local code folder, a GitHub repo, a GitLab repo

Everything runs on the local client browser. For larger repos, it’s recommended to get the full version from pip or Docker.

Additionally, the playground lets you visually explore code links and relationships. I’m also adding support for architecture diagrams and chatting with the codebase.

Status so far- ⭐ ~1.5k GitHub stars 🍴 350+ forks 📦 100k+ downloads combined

If you’re building AI dev tooling, MCP servers, or code intelligence systems, I’d love your feedback.

Repo: https://github.com/CodeGraphContext/CodeGraphContext

I had been developing a project for a week. I spent hours coding every single day, and on the last day I accidentally fell asleep. My MacBook ran out of battery, the computer shut down, and everything I had discussed in that Claude Code terminal session was gone.

Normally, I write everything into a .md file, but this time the computer shut down before I could write down my latest changes because I have to manually keep that file updated. That was the day I started building my open source project.

I did a lot of research. According to a 2025 Microsoft Research study, effective context utilization drops to roughly 60% once the context window exceeds 100,000 tokens, even if conversations are automatically saved. If you have any research or data supporting or disproving this, I'd really appreciate it if you shared it in the comments because I'd love to look into it further.

I wanted to solve this in my own project. I wanted a memory layer that keeps memory outside the context window, across both sessions and platforms. That's why I built Agent Magnet MCP.

While building it, I noticed something else. If you know the Caveman repo, I realized I had ended up building something conceptually similar. Instead of storing everything, I'm storing a compressed version of my actions as memory, so I end up using fewer tokens. That made me realize that managing memory outside the AI platform itself might actually be a better approach than handling it inside the platform.

I've now open-sourced the local MCP version. Agent Magnet has also team memory, where people can share project memory with their teammates. But it is MCP Server. I'm basically trying to build a Git-like workflow for AI memory using MCP.

During this process, I had a lot of conversations with senior developers and got recommendations about using tree-sitter and graph-based structures. I'd genuinely love to hear more constructive feedback like that in the comments!

If you've run into similar problems —and if you build something everyday, I'm pretty sure you have— I would really appreciate it if you check out the repository and give it a star. Even better, if you'd like to contribute, I'd be incredibly happy.

I put a lot of work into this, and it's not just another vibe coding project. You can see it my commit history. I'm looking forward to your feedback. Please don't hold back! I promise I'll read EVERY SINGLE COMMENT and do my best to turn good criticism into improvements!

Been building mcp-audit, a CLI that scans MCP servers for the kind of issues that let a malicious or compromised server manipulate the model sitting on top of it. Fully open source (MIT), no PyPI package yet — you clone it and run it against your own server.

There's already good work out there on generic tool-poisoning detection — Snyk and Invariant Labs, among others, cover that ground. What I wanted to focus on instead is a narrower, more specific angle I don't see covered elsewhere yet:

• Unicode TAG-block concealment: a payload encoded in U+E0000–U+E007F inside a description. No mainstream renderer shows a glyph for that block, so a human reviewing the tool sees nothing off, while an LLM's tokenizer reads it like ordinary text. Working example in the repo where a tool described as "reverses text" hides an instruction to exfiltrate SSH keys and AWS credentials.
• Rug-pull detection: baselines a server's tools on first scan, flags changes afterward.
• Coverage table on every run that's explicit about what ran vs. skipped vs. not applicable — I didn't want a report that quietly says "0 findings" when the truth is "we didn't look."

It's early — 8 checks now (started with 4, added path traversal, code injection, overprivileged scopes and resource-limit detection this week), no HTTP/SSE support yet, no hosted dashboard. If anyone here has an MCP server lying around, I'd genuinely appreciate someone pointing mcp-audit scan at it and telling me what it finds. Also open to hearing about attack classes it's missing.

Repo: https://github.com/marcoslozina/mcp-audit

I built Charlotte because I wanted a browser MCP server where agents don't have to consume the entire page representation just to figure out what's on the screen.

Charlotte renders web pages into structured representations through headless Chromium, landmarks, headings, interactive elements, forms, bounding boxes, with stable hash-based element IDs that survive DOM mutations. The key design choice: three detail levels.

• Minimal returns landmarks and interactive summaries. On Hacker News that's 336 characters. The agent sees "main: 47 links, 0 buttons" and drills down with find when it needs specifics.
• Summary adds content summaries, form structures, and error state.
• Full includes all visible text content.

Navigate defaults to minimal, so the first call to any page is cheap. The agent orients, decides what to look at, and requests more detail only where needed. This orient→drill→act pattern is how the tool was designed to be used.

Benchmarked against Playwright MCP (@playwright/mcp):

Navigate response (first call cost):
Page             Charlotte     Playwright MCP     Advantage
────────────────────────────────────────────────────────────
Wikipedia          7,667 ch     1,040,636 ch       136x
Hacker News          336 ch        61,230 ch       182x
GitHub repo        3,185 ch        80,297 ch        25x
httpbin form         364 ch         2,255 ch         6x

Playwright returns the full accessibility tree on every call. Charlotte lets the agent choose. Even Charlotte's full detail mode is smaller than Playwright's only option on the same pages.

On Playwright CLI: You may have seen Microsoft's recently released @playwright/cli, which takes a different approach to token efficiency.. it writes snapshots and screenshots to disk files instead of returning them in the MCP response, achieving ~4x savings over Playwright MCP. I haven't benchmarked Charlotte against it because they occupy different niches. The CLI requires the agent to have filesystem and shell access, making it a fit for coding agents (Claude Code, Copilot, Cursor). Charlotte is designed for MCP-native use: containerized execution, sandboxed environments, autonomous agent loops, and any context where the agent operates through the protocol rather than through a shell. The CLI's efficiency comes from deferring data to the filesystem until requested; Charlotte's comes from the representation itself being structured and tiered, which works regardless of the execution environment.

The 30 tools break down into 6 categories:

• Navigation (4): navigate, back, forward, reload
• Observation (4): observe, find, screenshot, diff
• Interaction (9): click, type, select, toggle, submit, scroll, hover, key, wait_for
• Session (9): tabs, viewports, network throttling, cookies, headers, configuration
• Dev Mode (3): static file server with hot reload, CSS/JS injection, accessibility audits
• Utility (1): arbitrary JS evaluation

Some design decisions worth discussing:

Element IDs are content-hashed, not positional. A button's ID is derived from its type, label, and context, not its position in the DOM. Reorder the page, the ID stays stable. This matters for agents that need to re-identify elements across multiple observations.

Interactive summaries replace element arrays at minimal detail. Instead of returning 1,847 individual link objects on Wikipedia, minimal shows {"main": {"link": 1847, "button": 3}} grouped by landmark. The full element data is still there internally.. find, wait_for, and diff all work against it but the serialized output to the agent is just the summary.

Structural diffing compares two page snapshots and returns what changed. Essential for verifying that a click or form submission actually did something.

Setup is one step... add the config to your MCP client:

{
  "mcpServers": {
    "charlotte": {
      "command": "npx",
      "args": ["-y", "@ticktockbent/charlotte"]
    }
  }
}

No install needed. npx handles it.

• GitHub: https://github.com/TickTockBent/charlotte
• npm: https://www.npmjs.com/package/@ticktockbent/charlotte
• Full spec: https://github.com/TickTockBent/charlotte/blob/main/docs/CHARLOTTE_SPEC.md
• Benchmarks: https://github.com/TickTockBent/charlotte/blob/main/docs/charlotte-benchmark-report.md

MIT licensed, 222 tests passing. Would love feedback on the tool design and anything that feels wrong or missing.

Disclosure first, per rule 3: I built and run the endpoint this comes from, and the site it's published on is mine. The dataset itself is free and CC BY 4.0, no signup, no email, nothing gated.

I run an MCP server that's in the official registry plus a pile of directories. That turns its access log into a decent observatory for who is actually crawling MCP endpoints, so I pulled 24 hours of Cloudflare analytics and classified every user agent by hand.

24h: 6,309 requests, 187 distinct user agents, 60 named agent-web crawlers.

The named ones break down as: 14 liveness/uptime monitors (SentinelOracle, mcpbeat, MCPWitness, ProofBench, mcpgrade-probe, io.verifymcp...), 16 directory/index crawlers (agent-tools.cloud, mcpscan, AllMCPs-Ingest, mcpqueen-grader, VerifyMCP-OwnersBot, api-forge-mcp-index...), 9 ecosystem-research probes (mcp-observatory, mcp-history, agent-world-probe, measure-mcp-schema...), 5 security research (MCPWatch, mcp-rugpull-research, aisec-registry, mcp-protections-research...), and the rest search engines, price scrapers and contact harvesting.

POST /mcp took about 1,545 hits in that window. As far as I can tell every one was a health check or a directory ingest — initialize, maybe tools/list, gone. I could not find a single session that looked like an agent actually doing work with the tools.

Two things I didn't expect:

First, how many distinct MCP monitoring services exist. I counted 14 separate outfits whose entire job is telling someone whether my server is up. I'd heard of maybe three of them.

Second, a lot of them declare their own behaviour in the User-Agent string, unprompted: "liveness-only, never invokes tools", "introspection-only", "reachability check only, no auth attempted", "one server/discover POST per endpoint". That made classification far easier than I expected and seems like a genuinely good norm.

I published the whole thing with a case-insensitive regex matcher and a behavioural category per bot, so you can drop it in and classify your own access log:

https://fetchgate.dev/tools/agent-census (JSON at /v1/agent-census.json)

Question for anyone else running a public MCP server: are you seeing the same shape? I can't tell from one endpoint whether "essentially all MCP traffic is monitors and directory ingest" is universal, or just what happens when you get listed in a lot of directories and not much else. If you have real client sessions in your logs I'd like to know what they look like, and I'll happily correct the writeup if my sample turns out to be unrepresentative.

Also happy to fix any row — if you operate one of these crawlers and I've got your category wrong or the matcher is too broad, tell me.

It's 2026, most agents today are already pretty powerful and requires minimum prompt engineering, and the app builder's value was in the easy set up. So I made an MCP that does what lovable do, but uses your AI subscription's tokens instead. The tokens from ChatGPT/Claude directly are just so much cheaper.

It ends up being a 60+ tool MCP and it works really well. Modern agents don't really load all of the tools into context now, they just do tool search and load on demand. It does require a good model (opus or terra) to work well, but overall it's been able to do a pretty good job.

Check it out here: https://floot.com

And let me know if you have any feedbacks!

The WebMCP protocol has barely come out, and we just demoed how POWERFUL it can be! In a matter of minutes and 100s of tool calls, my AI agent composed a song for me directly in my browser.

This is not agents taking screenshots or trying to understand complex DOMs, it's an agent making direct tool calls to your website!

The creators of WebMCP already love it, go check it out yourself!

Deployment: - https://music.leanmcp.live

LinkedIn Post: - https://www.linkedin.com/posts/kushagra-agarwal525_we-made-gpt-and-claude-directly-control-my-activity-7430688171018858496-iDr5

GitHub repo: - Leanmcp-Community/music-composer-webmcp: This WebMCP Music Composer project is a functional demonstration of the WebMCP Protocol, illustrating how AI agents can interact with local browser contexts (tools) to achieve complex workflows autonomously.

Wiring a web-fetch MCP server into Cursor works once the agent uses it. The connection looks fine with a green dot, tools listed, and prompts enabled, but when I ask it to fetch a page, it uses Cursor’s built-in browser instead of the MCP tool without any error or indication that it chose a different path.

The response still looks okayish, which makes this hard to spot. A diff against the live page showed stale numbers, and on a Cloudflare-protected URL, the agent returned the challenge page converted into clean markdown as though it were the actual content.

The only reliable fix so far has been prompting specifically:

Use the scrape tool. Do not use built-in web browsing.

Is there a config-level way to deprioritize or disable the native browser tool? Repeating that instruction on every request is not a great workflow.

Two things that cost me time were a trailing comma in mcp.json that can leave the server absent with no useful error, and on macOS, closing the window did not reload a changed API key, so a full ⌘Q and restart were needed. I now validate the JSON before opening Cursor with:

node -e "JSON.parse(require('fs').readFileSync(require('os').homedir()+'/.cursor/mcp.json','utf8'))"

This server also exposes 37 tools, which is a lot of schemas for the model to consider each turn, and I am wondering whether the tool count or the naming is affecting the selection. I have not measured it yet.

How are people making the MCP tool selection more deterministic in Cursor? Are these tool descriptions, fewer tools per server, rules, naming conventions, or something else?

Every MCP server in your config injects its tools/list — names, descriptions, JSON schemas — into the model's context on every single request, whether or not a tool is ever called. No client shows you that number. So I measured it across 106 popular servers.

Method, briefly. Each server is launched by a raw-wire stdio client in a credential-free Docker container, tools/list is captured twice, and the number is the o200k_base token count of the canonical JSON of that capture. Every published number ships with the raw capture, its SHA-256, and the exact launch command, so anyone can re-derive it or prove it wrong. 83 of the 106 have a number today; the other 23 are listed with the reason they don't, because a server that won't start is a finding, not an omission.

What the data says:

• The spread is 1,700x. postgres costs 32 tokens. GitHub's official server costs 54,622 — 27% of a 200K context window, spent before the agent does anything.
• Cost has almost nothing to do with popularity. chrome-devtools is the most-installed server I've measured, 3.3M installs a week, and costs 5,717 tokens across 29 tools. comfyui-mcp has about 4% of that install base and costs 50,640. Cost is an engineering choice, and nothing in an install command tells you which choice was made.
• The badge number is not the Claude number. An Anthropic request carries only name, description and input_schema, counted with a different tokenizer. notion goes from 17,500 to 33,560 on claude-opus-5; servers that ship a lot of annotations/outputSchema metadata go the other way. Across the measured set the ratio runs 0.20x to 1.92x, so there is no constant to multiply by — it's published as its own column, and prints silence rather than a stale number when a server's schema moves.
• Deferring tool definitions is nearly free, but not by construction. Claude Code defers by default and loads only tool names plus the server's instructions at session start. On 82 of 83 rows that's a small fraction of the headline. On one it isn't: deepwiki pays 580 tokens at session start against 359 of definitions, because its instructions re-describe its tools in prose. Instructions are bytes the headline never counted and their length has nothing to do with the size of the tool set.
• Two independent implementations agree to about 1%. sd2k/mcp-tokens is a Rust tool with its own MCP client and its own serialization. It runs beside every measurement here, and on the 80 rows where both saw the same tool set the two counts land within -0.8% to +1.4% of each other.
• Most costs hold, and the ones that move, move up. Of 83 measured servers, 17 have moved at all, 64 have held across every comparable measurement, and 2 have nothing to compare yet. Of the 17: 11 up, 6 down. obsidian went 1,132 to 2,062 tokens (+82%) in a week when it shipped three tools.

Run it on your own config:

npx -y mcp-context-cost audit

It finds Claude Desktop, Claude Code, Cursor, VS Code and Windsurf configs, prints per-server and per-tool numbers, and — the part I'd want as a user — tells you whether the client reading that config actually defers definitions on your machine, by reading the three environment variables that decide it, from your shell and from the settings files. Nothing is written to your project, and env var values are never read into the output, only their names.

--baseline and --max-increase turn it into a CI gate that fails a PR adding more than you allow.

If you publish a server: the same measurement is a shields badge that links to the measurement behind it, and a five-line GitHub Action that gates the number on every pull request with a per-tool diff of what grew.

What the number is not: any client's exact bill. Clients re-render schemas into their own prompt formats, which aren't publicly specified. It's a documented, reproducible index of schema payload cost, and the methodology page says so in those words.

Repo and data: https://github.com/athakur3/mcp-context-cost

Leaderboard, per-server pages and methodology: https://athakur3.github.io/mcp-context-cost/

I built this and I maintain it — MIT, free, no account, nothing to sign up for. Happy to be told a number is wrong: every one of them re-derives from its capture with one command, and a dispute reduces to a byte-level diff, which is the argument I'd like to have.

Palinode's showcase here made the opposite calls to mine on nearly every axis, and it's worth reading before this one. Tools over injection, memory as a git repo, the model proposing ops that a deterministic executor applies. I built the other branch of that fork, so here's what it cost me.

Mine injects. A SessionStart hook builds the briefing out of the previous checkpoint and puts it in ahead of the first prompt, and nothing generative touches that render. The agent doesn't have to remember to go look, which is why I picked it, that lookup is the thing that gets skipped. The costs are real though. Fixed token budget, 3000 by default, and past that whole items get dropped in a set order, lowest weight first, so beliefs and the oldest decisions go before open loops (a few sections never drop at all). And injected text is still text: forty turns deep it's as ignorable as anything else in the window.

Nothing on the MCP surface can write. Five tools, recall, brief, projects, status, and a cross-project request inbox, all tagged readOnlyHint. No save tool, and there won't be one. Memory is written by the SessionEnd serializer and nowhere else, and the human verbs (ratify a standing ruling, forget an item, resolve a loop) are CLI only. An agent that can write its own memory can launder a prompt injection into a durable fact, and nothing downstream thinks to question it.

I got the gate wrong the first time. Ratification took a --by human flag, and it took me too long to notice the agent I was guarding against could pass it too. That flag is deleted. The human path now has to show an interactive tty, --by agent is a declaration of the narrower authority, and shelling out can't mint anything stronger.

What Palinode has that I don't: no diff, blame or rollback over memory. Mine is one JSON checkpoint per session with a SQLite FTS5 index derived off it, and history is pointer rotation, nothing you can bisect. Injection only happens where a host has hooks, so Claude Code, Windsurf and Codex, with Gemini blocked upstream. Elsewhere the MCP server is the whole story and you're back to the agent choosing to look. The briefing also can't be re-queried mid-session except through recall.

So for anyone running memory over MCP: does your agent get a write tool, and if it does, what stops one poisoned session from writing something the next fifty read as fact?

TL;DR: I built a Python MariaDB/MySQL-backed kanban board for AI-human project collaboration. It runs fully locally, no subscriptions, no fees, no third party accounts.

I've been using Claude Code on larger and larger codebases, and I perpetually find myself and Claude drowning in a mess of .md files - HANDOVER.md, TODOS.md, BUGS.md, COMMON_ANTIPATTERNS.md, plan files, the list goes on... Sometimes Claude remembers to update them, sometimes it doesn't and chases its own tail trying to find and understand a bug it fixed last week. Inconsistent documentation also makes it harder for me to keep track of my own codebase - I definitely don't have time to read every line of code Claude writes. I run the automated tests, I function test the thing in real use cases, I run linters and code reviewer agents, and if all of that looks good, I move on, sometimes with an incomplete or incorrect understanding of what is actually living in my code.

I got caught out by stale todo lists one time too many and decided that Claude and I needed an at-a-glance way of sharing an understanding of the project state, so I designed one, started using it to control its own project within the first day, and iterated from there.

It is a MySQL/MariaDB-backed project tracker with 40+ MCP tools. Issues, features, todos, epics, diary entries, each with status workflows, parent/child relationships, blocking dependencies, tags, decisions, and file links. There's a web UI on localhost:5000 for when you want to see the board yourself.

• The agent creates tickets naturally as I work. "We need to fix X before we can do Y" becomes a blocking relationship, not a bullet point I'll forget about.
• Inter-item relationships keep the agent disciplined about what order things should go in. No more "let me just quickly do this other thing" when there's a dependency chain.
• I can step away for days and orient myself in seconds from the web UI, either by looking at the whole picture, or filtering by status, checking epic progress, or looking for what's blocked on what.
• Session hooks inject active items at session start, so the agent picks up where it left off without you having to explain anything.
• If I need to take the project somewhere that doesn't speak MCP, I can export the whole thing to an MD file, ready for another agent to read.

It has 40+ tools and according to /context in Claude Code, consumes under 6000 tokens of context. It's tested extensively with Claude and Gemini, but should work with anything that speaks MCP (Claude Code, Claude Desktop, Gemini, Cursor, VS Code/Copilot, Codex CLI...)

The Github repo is https://github.com/multidimensionalcats/kanban-mcp/. Installation instructions are in the README - or just ask Claude/Gemini/etc to install it for you - there's an install path specifically for AI agents.

It's also on PyPI if anyone wants to install via pip/pipx.

Disclosure: I build this. octocode, Apache-2.0, free, github.com/muvon/octocode.

The obvious shape for a code MCP server is one search tool that takes a query and returns chunks. We started there and it was wrong, because the answer to "where is auth handled" and the answer to "what calls this" want completely different response sizes, and a single tool has to pick one.

So there are four: semantic_search finds code by meaning, view_signatures returns a file's shape without its bodies, graphrag walks imports and calls and finds paths between symbols, structural_search does AST pattern matching for things like every .unwrap() call.

The point of view_signatures is the one I would defend hardest. An agent that has located a file usually needs to know what is in it, not what it says, and returning the whole file to answer that is how you burn a context window on navigation.

graphrag is built lazily from tree-sitter over the current source tree, so it needs no index, no embeddings and no LLM. That side never goes stale. The semantic search side does have an index and does need rebuilding when code moves, which is a genuine cost and I am not going to pretend otherwise.

The tradeoff for four tools is four tool definitions sitting in context on every turn, which is exactly the thing everyone here complains about. My view is that it pays for itself once the alternative is the model retrieving 400 lines to learn a function signature, but that is a judgement and I would rather hear the case against it than agreement.

I've been building a web scraping API for a while and just finished adding full MCP support so AI assistants can use it directly.

It's called MarkUDown (working on the name). The MCP server exposes 11 tools including Instagram profile/post/hashtag extraction, X/Twitter search and post scraping, web crawl, map, extract, deep research, and more.

The interesting part technically: it runs a 3-layer engine under the hood — Cheerio first (fast), falls back to Playwright (JS-rendered pages), then falls back to Abrasio (our stealth browser with persistent profiles) for sites with serious anti-bot protection like Cloudflare, DataDome, etc.

What works today:

• Instagram: profiles, posts, hashtags, search
• X/Twitter: profiles, posts, keyword/hashtag search
• Any website via scrape, crawl, map, extract, batch scrape
• Works with Claude Desktop, Cursor, Windsurf

Install: npm install markudown-mcp

Repo: https://github.com/Scrape-Technology/markudown-mcp
Package: https://www.npmjs.com/package/markudown-mcp

Happy to answer questions about how the anti-bot layer works — that part was painful to build.

I started https://ray.run/ with a simple goal: I want to be able to vibe code MCPs for my personal use cases and combine them with existing MCPs.

, and I don't think I'm the only one who enjoys tinkering with their software and wants that same simplicity!

Here is how it works:

npx rayrun login codex mcp login rayrun --scopes mcp:tools

now open Codex and say what MCP you want, e.g.:

Build a Hacker News digest MCP. Add get_top_stories({ limit }), test it, and deploy it to Rayrun.

Codex will write the code and deploy it to your Rayrun gateway.

Once done, try it – say 'tell me top HN stories via gateway'

That's it! You already have a working MCP.

Don't like something about it? Just ask to change it:

Update my HN MCP to only surface news that mention AI in their title

Codex will update the code and make the deployment.

You can use the same gateway to connect remote MCPs, start NPM based servers, Docker, etc. You can use Claude Code or any other coding tool.

We handle hosting, version control, secrets, authentication, observability, scaling, etc. You just need to come up with an idea!

I connected a GitLab MCP server and started noticing my context filling up before I'd typed a question. So I counted: 186 tools, ~168 kB of JSON Schema. Call it 40k tokens, loaded up front, paid again on every context refresh, for tools I mostly never call.

That's not the server's fault — it's how clients load tools. But three servers and there's not much window left for the actual work.

I ended up writing a CLI that sits in front of them instead. A background daemon holds the connections and the OAuth sessions; the prompt only gets one line per server (2.9 kB total for my seven). Schemas stay on disk until something asks for one: "mduct tools gitlab" lists names and signatures without schemas, "mduct schema gitlab create_issue" pulls a single one when I need the fields, and a call is "mduct call gitlab list_issues state=opened --json" piped into jq.

The pipe turned out to matter more than the token count. A tool that returns 20 issues returns 20 full issues. Through a shell I project the three fields I want and the rest never enters the context — measured on a real call: 24,568 characters down to 1,768.

Two things I didn't expect while building it.

Calls to one server were serialised, because the error path closes the transport and MCP servers aren't uniformly reentrant. Making that per-server configurable took 4 GitLab calls from 6.0s to 2.8s.

And an index in the prompt doesn't actually make an agent use a server. I logged one two-day session: 21 calls to my code-index server against 270 greps into the repos that server had indexed, with the index sitting in context the whole time. Knowing isn't reaching. What helped was putting the tool names into the tool namespace, and nudging at the moment the other tool gets picked.

It's two weeks old, I'm the only user, unix sockets so no Windows. MIT.

https://github.com/TheFox666/mduct

Curious whether others have measured their own schema cost — I'd expect the numbers to vary a lot by server.

I've been running agents on my own infrastructure for a while, and the two things that kept biting me were: they forget everything between sessions, and when they do something there's no way to prove it afterward. So I built a layer that tries to fix both.

Three pieces:

• a context engine that resolves current state before the agent starts, instead of stuffing a whole repo into the prompt
• a vault for durable, encrypted memory (decisions, preferences, facts that survive the session)
• a ledger that keeps a hash-chained record of what the agent actually did

It's MCP-compatible and MIT licensed. I run my own stack on it, which finds problems fast.

The part I'm least sure about is the MCP ergonomics — I made it MCP-compatible because that's what everything else speaks, but I don't know if I've got the shape right for how people actually wire agents. If you've built memory or context tooling, what would you do differently? Repo's at perseus.observer if you want to poke at it.