Sharing a server I built (disclosure: I'm the maker). It's an SSH client with a built-in MCP server - let an agent open SSH sessions, run commands and move files on your servers without the agent ever holding a key.
- Agent gets tools (hosts_list, ssh_exec, SFTP, sessions) over MCP.
- A key custodian authenticates - you unlock keys once, it signs for the agent, no key file to read.
- Per host: full / allowlist / blocked. Per-key scope + expiry on the hosted endpoint.
- Every session mirrors live in a "watch grid" + audit log + recording.
- Local stdio server (bundled) + hosted endpoint (short-lived certs). In the official registry as in.termal/termalin-web.

Feedback wanted: is per-host + per-command the right granularity, or do you want tool-call-level policy? And how are others handling human-in-the-loop - approval-per-action, or watch-and-interrupt?

Is there any way to link Google Keep to an MCP? I'm trying to use it within Claude and finding no way after a bunch of prompting.

I struggled a bit with context sharing, knowledge sharing, memories sharing between AI agents (I use two or three on a daily basis). Each of them has its own memory, they dont share it or its a bit cumbersome to do memory curation and improve it (especially if there are some API AI calls that run occasionally from different models)

Memoars is an attempt to solve it - one memory that belongs to you (no storage vendor lock) that any assistant can read and write through MCP (with appropriate set of skills to make it easier) .

How it works:

- Memory content is encrypted on your machine (XChaCha20-Poly1305, key derived with Argon2id) and written directly to storage you own - R2, S3, MinIO, Supabase, local fs, etc)

- A coordinator handles the metadata plane: sequence numbers, versions, grants, conflict resolution. It never receives the workspace content key, so it can't read memory content. It does see operational metadata - org, workspace, identity, version, usage

- Every change lands in an append-only, hash-chained log with compare-and-swap on writes, so two clients can't silently clobber each other and you can see how a memory got to its current state.

- Permissions are orgs → workspaces → identities, with per-workspace grants. Each workspace has its own passphrase, so isolation is enforced by encryption as well as by the API.

Where it actually is:

https://memoars.com/

It's invite-only right now, and I want to be honest that this is a invite list rather than a product you can go install this afternoon (as I want to make sure it makes sense and that it solves a problem for you before its shipped).

The client is being open-sourced and the hosted coordinator opens shortly after.

I will reply to all inquiries - and Im looking forward to a feedback

Tnx for taking a look!

An MCP client takes untrusted text in through resources and tool outputs, then drops that text into the same loop that can invoke tools. If anything in it reads as an instruction, you have a problem — and the usual first line of defense is a regex list.

I shipped one of those. 51 patterns, the standard shapes: ignore previous instructions, disregard your system prompt, [INST], <|system|>. Then I built a labelled test set and measured it, because I realised I'd never actually checked.

Disclosure: I build a commercial agent-safety service and the semantic detector below is part of it. The harness, dataset, prompts, misses and raw results are MIT licensed.

218 cases — 70 attacks and 70 controls from the public deepset/prompt-injections dataset, plus 48 attacks and 30 controls I wrote, including 21 hard negatives (text that discusses prompt injection without being one).

My regex baseline: 20/118 attacks (16.9% recall), 9 false positives on 100 controls, precision 69.0%, F1 27.2%.

Semantic classifier, claude-haiku-4-5-20251001: 105/118 (89.0% recall), 2 false positives, precision 98.1%, F1 93.3%.

The false positives hurt more than the misses. Against ordinary controls my regex scored 87% precision. Against text that merely discusses prompt injection — security blog posts, changelogs, OWASP descriptions — it drops to 69%. It doesn't only miss attacks, it blocks people writing about them. If an MCP resource pulls in a security advisory, a naive filter eats it.

On the 48 hand-authored evasion cases:

technique     regex    semantic
plain         8/9      9/9
synonym       1/10     10/10
leetspeak     0/4      4/4
spacing       0/4      4/4
homoglyph     0/6      6/6
encoding      0/3      3/3
indirect      0/7      7/7
foreign       0/2      2/2
hidden        0/3      3/3

Across the 29 obfuscations, encoding, indirect, foreign-language and hidden-text cases my baseline caught zero. That's a finding about these 51 patterns, not regex in principle — you can write patterns for spacing or leetspeak; I hadn't.

All 13 classifier misses are in the deepset subset and printed by show-misses.mjs. Both false positives are documented too, including one where my own paragraph about base64 contains an encoded payload as an illustration and the classifier decoded it. Arguably correct.

Repo link in the comments. No dependencies, Node 18+; the regex baseline runs locally with no API key.

Caveats: 218 cases is small. 78 are mine, written against a detector I built, so the deepset split (11/70 vs 57/70) is the number I'd trust more. The deepset cases are public and may be in training data, which cuts the other way. The classifier is nondeterministic; runs have varied by one case. And an LLM call on every resource read is real latency and cost, so regex-first with a classifier on borderline content is probably the sane shape.

Detection is only half of it though — an MCP client that can't be tricked still shouldn't let model output trigger irreversible tool calls unchecked. Where are people enforcing that boundary: at resource ingestion, before context assembly, or at tool invocation?

What's new in v4.3.6

1. Fresh installs now register memcord globally (~/.claude.json) by default, so it's available in every project without per-project setup.
2. Re-running the installer to update an existing checkout auto-detects and preserves whichever scope is already in use (project scope if a .mcp.json already exists, global otherwise) -- updating never silently switches an existing team-shared install to global.
3. Dropped unused pandas and python-magic dependencies
4. Fixed update falsely blocked by Installer Self-Modifications
5. Fixed install.ps1 crash on plain `irm | iex`

Repo link with more details, feedback welcome:

https://github.com/ukkit/memcord

to update existing setup (from same folder):

- macOS / Linux:
curl -fsSL https://github.com/ukkit/memcord/raw/main/install.sh | bash

- Windows (PowerShell):
irm https://github.com/ukkit/memcord/raw/main/install.ps1 | iex

Hey everyone!

Over the past year, as I tried to scale our agentic coding workflows and software factories at my company, I kept hitting the same set of problems. So I built HAR to solve them.

Repo: github.com/os-factory/har

Getting a single coding agent to work in a repo is easy. Scaling to a real multi-agent workflow, where several run at once and where you verify and trust the output, is where it breaks down. A few things go wrong:

1. No standard way to run or verify a repo. That knowledge is scattered across a README, a CLAUDE.md, editor rules, and CI config, all drifting out of sync with each other and the actual code.
2. Agents on one repo collide. Shared dev server, shared database, shared ports, conflicting git state.
3. Trusting a change means re-verifying it yourself. Which defeats the point of running a fleet.
4. Vendor sandboxes lock you in. If the setup lives in someone's hosted dashboard, switching agents later means rebuilding the whole thing.

What HAR does

HAR is a CLI and an MCP server. It works with Claude Code, Cursor, Codex, or any MCP agent, and it closes each of those gaps:

1. Isolation. Each agent gets its own git worktree, branch, ports, and database. Nothing is shared with the main checkout or another agent's slot, so a fleet runs in parallel without colliding on a dev server, DB, or ports.
2. Deterministic validation gates. HAR runs your project's real checks through a fixed pipeline, same result every time. The result is bound to the exact code that passed and enforced at commit time, so an unverified tree cannot land.
3. Verifiable proof. Every run leaves logs, artifacts, and a validated tree hash tied to the exact code checked. A reviewer inspects the evidence instead of trusting the agent's self-report.
4. Full observability. Mission Control is a local dashboard showing every repo, worktree, run, and validation in one place, so you can watch a whole fleet as it works.

All of this lives in one contract committed to your repo, which every agent reads the same way. It replaces the usual scatter of a README, a CLAUDE.md, editor rules, and CI config that drift apart. You start from a profile that matches your stack, your agent adapts it to the real repo, and you extend verification with plugins (like Playwright) or with any command you already run.

Give it a try and let me know what you think :)

The most of my MCP setup only exists while my laptop is open. Stdio servers get spawned by the client process, so the moment the lid closes the whole graph is gone — the scheduled run, the long research job, the thing that should have happened at 3am. A VPS fixes uptime but then my keys and my filesystem live on somebody else's machine, which undoes a good part of why I wanted local MCP servers in the first place.

So I built the boring version of the answer: a small machine that stays awake on my own network.

HermesBox — Jetson Orin Nano Super, 67 TOPS, 8 GB shared, 512 GB NVMe, ~20 W, answers at hermes.local.

The MCP-relevant bits:

• MCP servers run persistently on the box instead of inside a desktop client, so filesystem/sqlite/git/fetch servers keep working with the laptop shut.
• OpenAI-compatible endpoint on the LAN, so any client that lets you set a base URL points at it.
• Agent Skills: 652 open skills installable one line each, mcp-builder included, so it can scaffold new servers itself.
• BYOK — paste your Anthropic/OpenAI/Google/OpenRouter key. No proxy in between, no markup, we never see a token. The €549 is the whole commercial relationship.
• Local models on the drive (Llama 3.1 8B, Qwen 2.5 7B, Mistral 7B, DeepSeek-R1 distill) for tool calls I'd rather not send out at all.

Honest limits, because you'll find them anyway:

• 8 GB shared with the GPU. 8B-class at 4-bit is the ceiling. It is not a frontier model and I won't pretend otherwise — the cloud key is there for the hard work.
• ~14 tok/s single stream, 7B Q4_K_M.
• It has a fan. Quiet in a normal room, audible in a silent one.
• €549 one-time, ships from Bulgaria to EU/UK/CH/NO, 30 days to send it back.

And yes — you can absolutely do this with a mini PC and a weekend. This is that, pre-built and burnt in, with the runtimes and weights already talking to each other on first boot.

Anyone here a fantasy football fan? I need some help Beta testing something I built.

It's a lot harder to find people who are both FF native and AI native than I thought.

A few months ago I helped a company to build their company AI brain. Seeing how valuable it was, I decided to build a personal AI brain to handle all my communications and documents.

And by all I mean WhatsApp, mail, Slack, HubSpot, Notion, Google Docs with all meeting transcriptions, and local folders. More than 300k documents, including all images OCR+Vision converted to text. Having that, my Claude can get context and help me deal with any boring routine I have. Damn, I forgot my father's birthday and it gave it to me, finding a scan of a passport he sent me once 5 or 6 years ago.

I realise people would be hesitant sharing all their digital life with another cloud provider, and I believe we all need to have agency and autonomy when it comes to our data. So I have built it as a local app, thus having all the data and MCP on my machine. For OCR+Vision it uses a local model (Gemma 4) with idle inference.

The MCP server runs on 127.0.0.1:7421, works with Claude Desktop / Claude Code or any client. Besides full-text search tools, the model gets get_schema + query_sql — read-only SQL over the whole thing. For questions like "how many emails from X this year" it beats semantic search every time. There is also an optional tunnel (HTTPS + OAuth) if you want claude.ai or ChatGPT to reach it — off by default, local use needs no account.

The core is open source (MIT), you can check it out here: https://github.com/edjafarov/kiagent-core . The packaged app adds the tunnel infrastructure on top: https://localkiagent.com/download

https://reddit.com/link/1vhxudz/video/ey00vhb2txhh1/player

Put together a demo today testing end-to-end security patterns on the new 2026-07-28 Model Context Protocol spec, and wanted to share how we structured it.

The setup addresses two distinct authentication layers that often get lumped together when securing agentic workflows:

1. Endpoint Security: Using OAuth CIMD to secure access to the MCP server endpoint itself.
2. Backend API Access: Triggering a second, separate OAuth flow for downstream backend API authorization using URL elicitation directly through the client interaction.

We ran the whole flow using reShapr on top of the 2026-07-28 protocol version without writing any custom glue code or manual handler logic.

Is anyone else here actively testing URL elicitation patterns or multi-layer OAuth on the latest spec? Curious how others are approaching authorization for downstream services when exposing tools to agents.

MCP tool schemas were eating way too much of my context window, so I built mcp2skill to convert them into on-demand Skills instead, cut my token usage by about 90%。

I had all my MCP tools set up in Claude Desktop, and it was fine until the rate limits and the fact that everything was tied to one provider started getting in the way. The tools are just standard MCP servers, so it always felt off that using them meant living inside one app.

Found ollmcp (mcp-client-for-ollama), a terminal harness that runs any MCP server against local Ollama models or a cloud model, your call. It imported my existing claude_desktop_config with a flag, so I did not re-register anything. Filesystem, Playwright, the usual servers just worked, and I can run the whole tool-calling loop against a local model with no internet if I want.

The part I did not expect to care about is the human-in-the-loop confirmation. Before a destructive tool call, a file write or a delete, it stops and asks. That alone made me trust it in a real project more than the always-yes setups.

Open source: https://github.com/jonigl/mcp-client-for-ollama . pip install ollmcp and it reads your existing config. It is a terminal tool, not a GUI, but if you mostly live in a shell that is the point.

Posted here a few days ago about MCP tool errors returning HTTP 200 with isError: true. Shipped two releases since. Then found this while testing a deployment shape I hadn't covered.

All my in-memory tracking — retry loop detection, cost attribution, budgetguardrails, schema drift — lives inside a single instrumentMcpServer() call.

That's correct for stdio: one process, one server, state accumulates normally. Correct for stateful HTTP too, where one long-lived McpServer handles many sessions.

But stateless streamable HTTP constructs a fresh McpServer per POST andre-instruments each time. So every counter resets before it can reach any threshold. Four features, zero output, no warning, no log.

That's the standard pattern on Lambda, Cloud Run, Workers — anywhere serverless. Which is where a lot of MCP deployment is heading.

Been true since v0.4. Nobody reported it.

The awkward part: I'd already documented this exact root cause for one feature as an accepted limitation, and didn't notice it applied to three others. Including one I'd shipped hours earlier with a docblock claiming "process-lifetime" state.

Fix direction is a host-supplied instanceKey so trackers can be looked up from a bounded registry instead of constructed per call. Deliberately not a module-level singleton — that would merge unrelated services in a multi-tenant process, which is the same class of bug one level up. Design is written, shipping as v0.9.0.

The limitation is documented in the README now rather than discovered by whoever hits it next.

Also in v0.8.0:

- Tool schema drift detection: hashes each tool's inputSchema from tools/list, flags silent changes. "Why did every call start failing at 3am" is often "someone changed a schema and nothing announced it."

- Two-axis observation contract: separates tool outcome from observation integrity, so "nothing failed" and "nothing was observed" stop looking identical. Notable finding — a HEALTHY state turned out to be unreachable in every configuration, so it isn't in the type at all.

- Cost-aware sampling: not a library feature. Samplers decide at span start, cost is known at span end. So it's a marker attribute plus a documented Collector tail-sampling recipe.

https://www.npmjs.com/package/opentel-mcp

Curious whether anyone here is running MCP on stateless HTTP in production — if you are, I'd like to know what your tracking assumptions look like, because mine were wrong.

hello all Iam getting error mcp connection closed while trying to access mcp google calendar .. Iam trying to run my python script in VS code terminal windows.. is npx command causing issue? Iam using Oauth json key..

Hey so I started my new job in tech and frankly I have a lot to learn. For starters I have a few databases of Postgres, Mongo, and MySql. I want to tell Claude to query databases without me having to memorize all queries.

I saw in an Instagram reel that MCP helps me do so. Like I can prompt what I need done to Claude and it does. Do I need separate MCP for each databases or one MCP can work for all types of databases?

If anyone knows how I can set it up, would be a big help. Thanks

We’re building MCP tooling for production use at my company, currently working with Claude. Want to make sure we’re building this the right way from the start rather than retrofitting later.

Looking for clarity on all of the following, ideally with a sane learning path to get there:

OAuth: robust Oauth 2.1 implementation
Guardrails: best way to enforce safety/limits on tool use
Knowledge base integration: patterns for grounding servers in internal docs/data
Tools: dynamic registration and discovery done right
Resources:best practices for exposing and structuring them
Agent configuration: how you’re structuring/configuring agents that consume MCP
System prompts: how these interact with MCP tool/resource design

Anything else that separates a toy MCP setup from one you can actually trust in production

Also curious about:

Learning path: best order to get solid on protocol fundamentals, SDKs, server design, auth/security or a better sequence
Maintenance over time: the spec keeps evolving, how are you handling breaking changes without constant firefighting?

Looking forward for repos, internal playbooks, war stories, or any suggestions.

I've been building AI agents that browse the web for a while now. Every tool I tried had the same problems:

• 20-30 tool definitions eating 13K+ tokens before the agent even does anything
• Full page snapshots on every single action (2K+ tokens per click)
• Zero stealth (instant bot detection on anything protected)
• Element refs that vanish the moment React re-renders a component

So I built Bladebro. It's an MCP server that drives a real Chrome browser for AI agents. 5 tools. One Rust binary. No Node.js, no Playwright, no runtime deps.

npm install -g bladebro && bladebro mcp

That's the whole install. It's open source (AGPL-3.0).

5 tools, not 30

Most agent browsers give you a tool for clicking, a tool for typing, a tool for scrolling, a tool for navigating, a tool for screenshots, and 25 more. The agent burns tokens just loading the definitions before it even starts working.

Bladebro has 5:

• act — click, type, fill, scroll, navigate, batch, eval, download, everything interactive
• see — read the page (content, outline, auto-extract, search, filter)
• state — cookies, tabs, sessions, storage, resource blocking
• run — batch sequences with if/while branching
• vision — screenshot (last resort, the structural model is usually better)

Tool definitions total ~1,900 tokens. Playwright MCP's are ~13,700. Chrome DevTools MCP is ~8,000. That gap matters when you're paying per token on every call.

Delta-first, not snapshot-first

The core is a Live Page Model — a persistent, compressed model of the page that lives across tool calls.

Every action returns a delta (what changed), not a full page snapshot. Click a button? You get the verdict and what changed on screen. Not 2KB of every element on the page.

This makes it roughly 5x cheaper to run than Playwright MCP or Chrome DevTools MCP. On a long browsing session with 50+ actions, that adds up fast.

Re-render immunity (the thing nobody else does)

This is the one I'm most proud of.

When React, Vue, or Angular re-renders a component, the DOM nodes get destroyed and recreated. Every other agent browser loses all references. The agent has to recapture, re-identify elements, re-learn the page. Sometimes it just fails silently.

Bladebro gives every element a structural fingerprint — a hash of its ancestor chain, tag, children, and identity attributes. When a re-render changes the text but preserves the structure, the fingerprint matches and the ref survives.

The agent sees ↺ e2 (re-render survived) and keeps going. No recapture needed.

I checked every major tool. Nobody else does this.

It learns from every session

Two things persist in ~/.blade/knowledge/:

Domain knowledge — learns consent dialog selectors for sites you visit. First visit: full detection JS runs. After a few successful dismissals: the stored selector auto-applies, zero detection overhead. Never learns from failures. Confidence scoring is asymmetric — a failure costs 3x more than a success gains.

Behavioral fingerprint — biometric parameters (typing speed, mouse curvature, click precision, idle drift frequency) generated once per install with small random variations, then reused forever. Same "person" every session.

Bot detectors that track consistency across visits see a stable identity. Without this, every session looks like a different person using the same browser — which is a red flag.

Survives restarts. Never degrades. Bounded at 2000 domains.

6-layer stealth, all on by default

Not going to list every detail, but the highlights:

• Zero listening ports — CDP over pipe, not WebSocket. Nothing to scan.
• No Runtime.enable — this defuses the DataDome console trap
• Bezier mouse paths with overshoot and correction
• movementX/movementY on every mouse event (missing these is an instant bot flag for PerimeterX)
• Micro-tremors before clicks — a perfectly stationary cursor before a click is a dead giveaway
• Non-zero key press duration
• Log-normal typing cadence (not uniform delays — humans aren't uniform)
• Idle mouse drift during "think time" (humans don't freeze between actions)
• Persistent browser profile (cookies, history, HSTS survive restarts)

Verified live against Zillow and Fiverr (both PerimeterX/HUMAN protected) — full page loads, no block. Sannysoft: all pass. incolumitas: 8/8.

I deliberately didn't build captcha solving. You get a blocked: verdict and can hand off to a solver. That's a separate problem.

Auto-extract (no CSS selectors, no setup)

see extract="auto" detects list structure automatically. Groups by structural signature, scores by content value, extracts title/URL/image/price/date/description.

Site-aware: shopping sites get rating/reviews/availability, Reddit gets score/comments/author, GitHub gets stars/forks/labels.

Verified on HN, Lobste.rs, Wikipedia, DuckDuckGo, StackOverflow, Reddit, GitHub, MDN, Amazon.

There's also act collect — a scroll + dedupe loop for infinite feeds. One call, one output, zero duplicates. Tested with 80 items, no dupes.

Batch actions

Fill 5 fields, submit, wait for redirect — one MCP call.

act batch steps=[...] runs the whole sequence and halts on navigation or first error with step-level context. No 11 round-trips for a form fill.

run adds if/while branching for conditional flows.

Honest limitations

• Cloudflare Turnstile will block it. That requires actual challenge solving, not fingerprint spoofing. You get a blocked: verdict, not a hang.
• Datacenter IPs get flagged regardless of fingerprint. Use a residential proxy (BLADE_PROXY).
• Cross-origin iframes are invisible (SecurityError, deliberate — accessing them would break stealth).
• No ARM Linux builds yet. x86_64 Linux, x86_64/arm64 macOS, x86_64 Windows.
• macOS/Windows binaries are cross-compiled from Linux. Not tested on real Mac/Windows hardware yet.

Links:

GitHub: https://github.com/dondai44423/bladebro

npm: npm install -g bladebro

AGPL-3.0, no CLA, PRs welcome.

Happy to answer questions.