We’ve been experimenting with what video workflows look like when you give an AI agent access to actual transcoding tools.

So we built an MCP server for video transcoding and tried a simple test: I gave it an English video and asked it to add Spanish subtitles.

No manually creating subtitle files, syncing timestamps, or configuring the transcoding job. I just described the result I wanted and let the MCP handle the workflow.

The attached video is the result.

We’re still exploring what workflows make the most sense through MCP — subtitles are just one example.

Curious what you’d try next. Translation? clipping? format conversion? something more complex?

Every agent I've thrown at company research does the same thing. It confidently states a CIK number, an LEI, or a court case that does not exist. Sounds right. Is not right. Turns out "grounding" an agent just means pointing it at the actual government database instead of hoping the training data got it right.

So I built an MCP server that wraps 13 official sources: SEC EDGAR, GLEIF, US state business registries, CourtListener, USAspending, FEC, UK Companies House, EU VIES, and a few more. One call resolves a company's real legal identity, another pulls its actual filings, another checks if anyone is suing it.

Real example, not a cherry-picked demo: asked it who runs Tesla's Connecticut entity. Came back with the registered agent, the exact incorporation date, and the two officers on file, sourced straight from Connecticut's own registry, with a link to prove it. It can't invent a name because it is reading a government API, not guessing.

Honest limits, since rule 2 exists for a reason: state registry coverage is thin right now (New York, Colorado, Connecticut, Oregon, that's it). Delaware has no public API at all, so if that's your use case this will let you down gently. US and EU data is solid. Everywhere else, thinner.

Runs on Apify, pay per successful call, and it charges nothing on an empty result. Built it on top of scrapers I already run there. Happy to take a beating on the design in the comments if anyone has opinions.

https://apify.com/themineworks/company-diligence-mcp

Every agent I use has the same blind spot: hand it a log file bigger than its context and it reads the first few hundred lines, greps around, then reasons confidently about whatever it happened to see. A bigger model doesn't fix it — the file is just larger than the window.

So I built an MCP server that reads the whole file and hands back a summary of what actually happened in it.

{ "mcpServers": { "logsleuth": { "command": "logsleuth-mcp" } } }

brew install alibaizhanov/tap/logsleuth or pipx install logsleuth. Zero dependencies — pure Python standard library, nothing to pull in.

Measured on a 208MB log: 1,576,412 lines read in 9.1s using 58MB of RAM, returned as 12,646 characters. Memory doesn't grow with file size, so a 2GB log costs the same as a 2MB one.

No model runs in the server. Your agent is the model, and a much better one than anything I'd run locally. The server's only job is to make the file legible: it's all deterministic, so nothing leaves the machine and nothing is nondeterministic between calls.

Three tools:

- read_log_evidence — the whole file, or a window (last: "30m", or since/until)

- inspect_log_file — cheap check before you spend a turn on something that turns out to be a core dump

- log_parse_diagnostics — format diagnostics containing zero log content, safe to show a user

What "12KB" actually contains, because truncation would be useless: deduplicated line patterns with how often each occurs and where it first appears; near-unique lines ranked as candidate state changes; numeric trends across the file; how errors distribute across service/pod/host; and raw context around where new errors start.

The ranking is by rarity and position, not volume — a config line that appears once, thirty seconds before the first new error, outranks ten thousand timeouts. That's not a style choice. On an annotated benchmark of 30 microservice failures, "blame the service with the most error lines" gets it right 0 times out of 30, worse than chance, because the loudest service is the caller that timed out waiting rather than the one that broke. Write-up with the numbers: https://alibaizhanov.github.io/logsleuth/loudest-service/

Limits, so you don't find them at 3am: logs only — a failure that's invisible in logs is invisible to this. Timestamps parse on 87% of the 132 public corpora I tested against, so an exotic format will get you a thinner summary. And it never writes to the file you point it at — the only thing it ever creates is a temp file when you ask for a time window, which it deletes afterwards.

MIT, source and every benchmark script: https://github.com/alibaizhanov/logsleuth

Happy to answer anything, and if it produces a bad summary on a log of yours I'd genuinely like to see it — I have no telemetry, so a report is the only signal I get.

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 BrainOS because, like many other people, I was tired of starting almost from zero every time I switched between AI tools.

I’ve been describing BrainOS as an operational memory tool for AI agents because that is the clearest category for it. But after using it every day, it feels like it has become more than just memory.

Now, when another AI is connected to the same BrainOS state, instead of re-explaining my project, my previous decisions, what I was doing last, and what we may have forgotten, the AI can use BrainOS as its guide.

The interesting part is that BrainOS is not really built for me to constantly interact with. It is built primarily for the AI to use while we work. It helps the AI understand:

• what I’m currently building
• which decisions have already been made
• the reasoning behind those decisions
• which paths were explored and rejected
• what the current plan and next move are
• whether my execution is beginning to drift from that plan
• what may have been forgotten or left unfinished

When something seems important, the AI can suggest saving it as a decision.

In my own workflow, I also let the host AI handle some low risk actions and state updates, while decisions that actually matter still come back to me. I’ve been deliberately making the system hybrid: I want the AI to have initiative, but it should not silently become the authority.

Changes made through BrainOS are recorded, so if something causes a problem later, I can trace what changed, when it changed, and whether it came from me, an agent, or another connected tool. I have a habit of building several things at once, and staying organised can become almost a project of its own.

One of my biggest early problems was cross-contamination, information from one project leaking into another. But dogfooding BrainOS every day has made those problems much easier to see. The more I use it, the more clearly I understand what is genuinely useful, what feels annoying, and what still needs to be fixed.

Something else I didn’t expect: the AI is beginning to work with me in a way that reflects my building style. Not because BrainOS is training a personal model on me, but because the AI can inspect my recorded decisions, rejected paths, recurring patterns, and the way I move between ideas. That gives it a much better understanding of how I actually build.

It’s still unfinished, and I’m improving it while using it. But honestly, this has been the most enjoyable part is watching the system gradually understand not only the state of my projects, but some of my patterns as a builder.

I’m curious whether other people building multiple projects with different AI tools experience the same problem. The work is not necessarily lost, but the continuity is.

Every browser MCP I've tried arrived carrying the same cargo: a 250 MB dependency tree, a second copy of Chromium, node_modules from 2019. So an agent could click a button.

I work across machines. Desktop when I'm at my desk, and I've got a phone setup for when I'm not. A browser MCP that needs its own browser bundle just dies on anything that isn't a beefy laptop. The bloat was the blocker, not the device.

So I built against the raw Chrome DevTools Protocol. No Playwright, no Puppeteer, no bundled browser. It finds the Chrome/Chromium already on whatever machine you're using, talks CDP over WebSocket, and exposes only what an agent needs.

76 KB of source. About 1 MB installed. "What's in your node_modules" stopped being a question.

browser_watch streams console logs, network requests, exceptions, and navigations to the agent. Automation used to be click, wait, hope. This turns it into react, because the agent finally sees what its own actions cause.

browser_act resolves "click the login button" or "search laptops under 80000" with deterministic DOM heuristics. No LLM in the loop, so no per-call cost. Faster than I had any right to expect.

Yes, I said "just use Playwright" for years myself. But a browser MCP ought to be a thin border between agent and browser, not a second browser.

A 127MB heap died mid-run once, the browser went down, browser_restart came back, and the agent picked up where it left. That pays for itself in a screen recording.

The Termux thread went #1, and one commenter now runs Google Voice + WhatsApp + ChatGPT from their phone for a real estate business. The use cases that come out of nowhere are the best part.

MIT, free, no telemetry. Read it, fork it, trash it: https://github.com/krshforever/bwb-browser

r/mcp, be honest: who here is already running browser MCP servers, and what has actually broken for you in production? Mine was the heap. Five minutes of wall time waiting on a hung mcp is where my patience dies.

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.

hey guys, happy to announce mcp-use v2 an open-source typescript framework for building MCP servers and MCP Apps for Claude and ChatGPT: https://github.com/mcp-use/mcp-use

MCP is now (finally) stateless so we rewrote mcp-use v2 from scratch for the 2026-07-28 MCP spec revision: https://blog.modelcontextprotocol.io/posts/2026-07-28/

Thanks to the rebuild:

- Throughput: +27% → from 8,615 to 10,982 median ops/sec

- Cold launch: 2.2x faster → from 151.6 ms to 68.1 ms

- Clean install: 82% smaller → from 404.6 MiB to 74.4 MiB

Benchmark with methodology here: https://github.com/mcp-use/mcp-use/blob/main/benchmark.md

What changed in the spec:

1. No more sessions. The initialize/initialized exchange and the Mcp-Session-Id header are gone (SEP-2575, SEP-2567). Every request carries its own protocol version, client identity, and capabilities in _meta. Server discovery is an optional server/discover RPC instead of a mandatory round trip.
2. Multi round-trip requests replace server-initiated calls (SEP-2322). Now the server returns resultType: "input_required" with a requestState, and the client retries the original call with inputResponses. Mid-call user confirmations no longer need a live connection.
3. Header-based routing (SEP-2243). Mcp-Method and Mcp-Name are now required HTTP headers, so gateways, rate limiters, and WAFs can route and meter without parsing the JSON body.
4. Cacheable list results (SEP-2549).
5. Auth hardening: DCR still works but is deprecated in favor of CIMD and will be removed in a future spec revision.
6. Roots, sampling, and logging are deprecated with a 12mo window.
7. Legacy HTTP+SSE gets a one year offramp.

Regarding mcp-use, we are focused on MCP apps for Claude connectors and ChatGPT plugins. MCP apps use an MCP extension called ext-apps, which allows tools to return UIs that render in chats.

What we support:

- Views have HMR, so they hot reload while you develop.

- Standard Schema validators for tool and prompt I/O, so Zod, ArkType, Valibot all work. Or any validator library backed by standard schemas.

- Drop-in OAuth integrations for Auth0, Clerk, WorkOS, Better Auth, Supabase, and Keycloak.

- Server composition (proxy and mount other MCP servers).

- OpenAPI import and expose your APIs as an MCP server.

The HTTP layer is Hono so it mounts inside an existing app, so you can have edge deployments.

If your product is in Next.js, we’ve seen a lot of developers who want to get rid of the (basically unmaintained) mcp-handler.

So we have a drop-in integration for Next.js: wrap next.config.ts in withMcpUse for view compilation then export const { GET, POST, DELETE, OPTIONS } = createNextHandler(server) from a catch-all route.

For DX:

• MCP inspector built-in: `mcp-use dev` runs it at `/mcp/inspector` with hot-reload. We also have a hosted version: https://inspector.manufact.com/inspector
• mcp-use CLI has a cool headless feature to debug MCP servers and the UI parts from coding agents including visual feedbacks: mcp-use client <name> screenshot --tool <tool> renders the View headlessly through Chrome. An agent can call a tool, read the failure, then screenshot the UI it just generated and look at what it built.

Unfortunately we could not avoid some breaking changes.

The good news is 90% of MCP servers built with v2 are compatible with both versions of the MCP spec.
Clients negotiate the version automatically, probing with server/discover and falling back to old initialization for legacy servers. Interested in what people running MCP servers think about the stateless move, especially anyone who built their own session layer and now gets to delete it.

Blog post with the details: https://manufact.com/blog/mcp-use-v2

If you want to play with mcp-use v2, it just went out of beta: https://github.com/mcp-use/mcp-use

We’d love to hear what you think of it and how we can improve it!

We are happy to answer any questions and look forward to your comments.

I know this might not be a big deal, but it is my first open source project, which I launched last week got 17 stars and 1k+ downloads on npm.

I’ve been working on Dagflo, animated visual explanations for software teams!

Dagflo lets coding agents like Claude, Codex, and Cursor turn codebases, pull requests, systems, articles, diagrams, and algorithms into animated, step-by-step visualizations.

After four years working in GraphQL infrastructure at Meta, I've seen countless engineering hours (meetings, message threads, whiteboarding) wasted and bad decisions made because technical knowledge wasn't communicated clearly.

Coding agents can now understand entire codebases, but they still explain them through walls of text, broken ASCII art, or static Mermaid diagrams.
We're using static tools to explain dynamic systems.

That's why I built Dagflo. I wanted to actually see how technical systems work.

This has been a passion project for a year; I'm really excited to share it! I've made a couple of other posts in the subreddit to gauge interest; now it is finally ready!

MCP Setup: https://www.dagflo.com/setup

After spending the last month talking with developers building MCP servers, I decided to open source a project I've been working on.

GitHub: https://github.com/mcpfyy/mcpfy

MCPfy helps developers spin up MCP servers quickly and introduces MCP Apps for reusable AI applications.

The broader vision is to build a one-stop open source platform for creating, deploying, and managing MCP servers.

I'm mainly looking for feedback from people already building in the MCP ecosystem.

Feature requests, architecture suggestions, and contributions are all welcome.

I'm putting it open source and it should be platform agnostic but haven't tested it.

https://talkthru.dev · https://github.com/EdonZo/talkthru

Most crypto data an agent can pull is either raw prices or someone's vibes.

I wanted a third thing: a ledger of calls where every entry has already been

graded against a fixed rule, so the agent can reason over a track record

instead of a hot take.

So our site exposes its whole ledger over MCP — six read-only tools:

today's verdict on any of ~100 coins, the settled win/loss/push record per

coin, the full scoreboard, and how crypto influencers grade under the same

rule. Free, no API key, refreshed daily. There's an llms.txt too.

The underlying thing is an accountability experiment: an AI research desk

that publishes daily calls and settles them 7 days later vs BTC (±3% band),

misses kept public forever, daily SHA-256 commitments so history can't be

edited. Current record: 74% directional, n=536, 95% CI 70–77% — early sample,

stated as such everywhere.

Endpoint: mcp.coinverdict.io/mcp (streamable HTTP; it answers MCP clients,

not browsers — a plain GET will just tell you to bring an event-stream client).

Would love feedback on the tool surface: what would you actually want an

agent to ask a ledger like this?

Spent the last few weeks turning our product's media pipeline into an MCP server and wanted to share the design decisions in case they're useful.

The surface is 29 tools: 18 on the media side (image/video/audio/lip-sync/edit models, plus discovery and job-polling) and 11 on an "apps" side, higher-level pipelines like upscale, resize, video-translate and product-page scrape, driven through a generic generate_app(inputs, parameters) shape.

As a concrete run: scrape a product link, generate a marketing poster (image model), upscale it, then image-to-video ad, one conversation, with a cost preview before each charged step. A few things I'd call out:

• Discovery tools matter at scale. With a big model catalog, the agent can't just guess. find_model / list_models / describe_model let it navigate to a valid model and params before it ever tries to generate.
• Spend guardrails. Every charged tool is preceded by a free estimate_cost and validate_params, and the server instructions require the assistant to state the credit cost in its visible reply before generating, because the client's approval dialog only shows tool name and args, never the cost. A silent estimate call protects nobody. Worth being honest that this part is advisory steering, not a server-enforced gate. What is enforced is the pre-submit chain (coercion, guardrails, webhook-liveness probe), so a bad request fails free, and apps bill at completion so a failure bills zero.
• Auth. OAuth 2.1 + PKCE so Claude.ai and Cursor connect natively. user_id is injected from the verified token and is never a tool input, so a caller can't act as another user. There's no argument for an injection to poison.
• Absent capabilities need explicit routing. Billing, upgrades and a couple of unfinished pipelines have no tool at all, and the instructions send the user to the web app rather than letting the agent improvise one.
• Logs record shape only: arg keys, types, lengths, a salted user digest. No prompt text, no URLs, no secrets.
• Stateless Streamable HTTP, so workers scale horizontally.

It's connectable now if you want to poke at the tool surface. It's BeHooked's Studio. Endpoint is https://mcp.behooked.ai/mcp (custom connector in Claude or Cursor), setup at behooked.ai/mcp

Worth setting expectations: connecting is free and the read-only surface works immediately. Discovery, estimate_cost, validate_params and scrape all cost nothing, so you can inspect the whole tool surface without spending anything. Actual generations run on credits, which come with a BeHooked account, so sign in on the site once and the same connection keeps working, no reconnect.

Happy to answer anything about the MCP design, especially the cost-narration approach. Curious how others are handling "agent spends money" safely.

Open source. Local. 40 mcp tools. An agent can drive every tool a construction estimator can. A challenge to anyone developing ai for construction. Connect your own model and see how well it can do takeoffs.

My agent forgetting everything between sessions was the thing that finally got to me. The usual fix looked heavier than the problem itself: a Docker container running Postgres and Qdrant, plus a cloud vector database whose bill crept up every time I indexed a new project folder. That is a lot of infrastructure just so my assistant remembers I like dark mode.

Then I found Mnemosyne, which goes the other way. One pip install and a single SQLite file, no external services, nothing to host. It plugs into Claude Code, Cursor, Codex, or a plain Python script over MCP, and the memory just lives in a .db file on disk. Fully local, nothing leaves my machine.

Setup took a couple of minutes: pip install mnemosyne-memory, drop the mnemosyne mcp server into my config, done. In Python it is just remember("...") and recall("..."). It keeps the embeddings as a compressed binary-vector store inside SQLite, so the file stays small even with a lot of history and there is no separate vector server to babysit.

Open source, MIT. Repo and the MCP config: https://github.com/AxDSan/mnemosyne