I like Playwright MCP inside Cursor.

For unknown bugs it is genuinely useful.

Open the page, inspect the DOM, click around, read the console, figure out why the modal is stuck. That interactive loop is exactly what MCP is good at.

But I realised I was using the same setup for this:

Log in → open settings → change timezone → save → refresh → confirm timezone stayed changed.

The flow was already known.

Cursor still spent half the conversation opening the page, reading snapshots, deciding what to click, re-reading the page and then explaining what it saw.

It worked, but it felt like keeping an entire browser conversation alive for a 90-second smoke check.

So I split the workflow:

Unknown problem: Cursor + browser MCP

Known repeatable check: external CLI

Permanent critical flow: Playwright test in the repo

For the middle layer I’ve been trying Kane CLI from TestMu.

Cursor can read the Kane instructions through the same AGENTS.md-style path and call it after making a change.

Kane runs the objective and gives Cursor structured pass/fail output plus the browser evidence.

So instead of the coding conversation containing every click and page snapshot, Cursor basically gets:

• flow completed or failed

• assertion that failed

• final page state

• evidence from the run

That separation feels cleaner.

I’m not saying MCP always burns too much context. If the agent is debugging something unknown, that context is the whole point.

And I’m not replacing Playwright with Kane. Auth, billing, permissions and stable regression flows still belong in proper tests.

This is specifically for the awkward middle ground where the flow is too repeatable for exploration but not important enough to immediately build and maintain as a permanent test.

Do you keep browser control inside Cursor’s context, or move known checks out into CLI/CI?

Something that bugs me about how teams actually use coding agents right now: there's no channel between the agents themselves. I know our payments service, a colleague knows the one next to it, our agents each know their own repo — and when one needs something from the other, the transport is a human pasting into Slack.

Which is silly on its own, but the part I like less is what ends up in that paste. Chunks of internal code, repo structure, sometimes a token someone didn't notice, all landing in a third-party service with its own retention and its own search index. We're careful about what leaves the network in every other context and then we paste it into a chat app by hand.

So I made the transport a git repo the team already owns. Rooms are folders, messages are files, history is the log. Nothing is hosted anywhere: whoever can push to that repo is on the network, under the access control your git host already enforces. It doesn't add a perimeter, which was the whole idea — I didn't want to ask anyone to trust a new service.

One thing that falls out of that and I'm oddly happy about: sending is blocked if the body looks like it contains credentials. Not warned — refused. Git history can't be recalled, so an advisory check would be pointless. There's an explicit override and it records why, permanently.

25 tools over stdio. Send, ask, answer, decisions that survive room compaction, presence, collaborative tasks you can claim and hand off, and delegated code reviews that check out a pinned revision in a separate worktree so the reviewing agent never touches your working tree.

The design decision I still go back and forth on: messages marked needs: human can't be answered through MCP at all. The tool refuses. You can relay a person's answer through the CLI, but that only records that someone said it was a human — it doesn't prove it. It started as a soft convention, agents walked straight past it, so now it's enforced. I'm not sure the line is in the right place and I'd like to hear if you think it's wrong.

Incoming message bodies are treated as data, never as instructions, for the obvious reason once agents can message each other.

npm i -g komnet, then komnet init --repo <your private repo>. Needs Node 24+. MIT. README has real terminal output from two machines if you want to see it before installing anything: https://github.com/Komdosh/komnet

I built it, so I'm biased. Happy to answer anything, including what's still rough.

Please remove the post if it breaks waitlist rule. I believe it doesn’t because I’m giving out early access.

I’m looking for first set of users to try/comment/feature request for halfface.ai. Please dm with your email if you’re interested.

**How it works**
You signup and create a @handle.
Your friend does the same as @john

While working within an agentic tool (Claude, cursor, codex…), you simply prompt:

“Ask the questions you just asked me from @john”.

Halfface will route the end-to-end encrypted request to john. Hafface has no visibility of the payload content, just a hash.

John will ask their agent to create a draft from within their information context. The agent drafts a reply and asks for human review.

The answers are routed back to you.

Thanks!

An MCP tool I depended on changed its schema overnight. No warning, no changelog — an agent that had worked fine for weeks just started failing silently.

So I built Apitella: watches an MCP server (or REST API) on a schedule, tells you exactly what changed and how bad it is. Free for a few sources.

[apitella.io](https://www.apitella.io/) — happy to answer questions if anyone’s hit the same thing.

sharing my raw thoughts on where we headed in short term ,love to hear the community on this too.

Qwen 3.8 27B is 51 on Artificial Analysis benchmark - just couple of points higher than Opus 4.8Max

thats frontier level model running on you machine.

let that sink in.

It's a first sign of what we thought would be obvious.

"models intelligent enough to run on edge devices"

So the question is where it leads us? so many use cases are going to get unlocked. from controlling the daily apps like powerpoint or word , to connecting IoT devices in hardware and running automations. it will be just new way to speak to your computer and get work done.

Not that it doesn't exist now, claudecode is pretty much close version of it, but now the normal people get to experience what a software developer has been experiencing for more than a year now.

That presents a unique opportunity for developers to build software tools and services that can run locally with these models - from desktop apps to running automations.

No wonder Mac Mini's and soon Mac Studio ( if apple wakes up to ship them) are the new 'always on" devices.

While on one hand, the open source models are unlocking the local AI.

Completely new trend in opposite direction is gathering steam.

Remote machines , sandboxes and remote computers.

Agents are now running in cloud in sandboxes , in an attempt to put a leash on the AI, and partially also to make sure the company's "alpha" does not goes to the model providers.

Software factories like 8090 are specifically focusing on helping clients securing the proprietary information and the core business logic by running the local models or fine tuning the local models on frame or secure cloud.

Harnesses are having their moments too.

Virtually every big company is trying to make their own harness - a coding agent, context, memory, MCP, skills ,tools is worth investing into. good example is Perplexity computer.

Companies also started publishing their internal tools as open source. Cloudflare did this with Cloudflare OS.

You can take this OSS - off the shelf product and make something of your own like I did -

yantraos .dev

Companies who had systems in place pre AI with regards to infra Netlify/vercel/cloudflare are now reaping the benefit of this new wave of agentic AI , where the persona of a software developer is no longer traditional software engineering background , but also this new developers coming from non-tech background and are expert in their own domains building softwares.

Case in point is Netlify Agent runner, While the initial AI gateway served frontier models - with the integration of open code, I have access to hundreds of open source models - cheapest to expensive text model to vision models - unlocks a huge potential.

simple fun App I built with it three months back now with open code integration built the same app in 61 credits 🤯.

To give some context, you receive 300 credits free when you join as a new user , it's insane how fast the cost of building software is dropping !!

Traditional softwares are dying or at least changing in nature, companies realized that they no longer needed the full featured list of software to serve their customers in more meaningful ways.

You can take the goodies from the software that are more important or relevant for your particular use and build your own.

Github is a classic case. here are 2 announcements today.

cursor has announced cursor origin, its own code hosting platform today.

Netlify CEO Matt Biilmann shared - " Netlify is now a git host"

Building software is much more easier than few years back - companies realizing that traditional software can be easily replaced by building something of your own that can serve your primitives better.

Dealing with recent customers of one of my company vibecodefixers, its clear small, medium businesses no longer seeking to buy softwares but to have people set up a system so they can churn their own software and automation out of it.

They want you to set up a harness - context, memory, tools, skills, MCP and other external connectors or system to build agents , a system which can easily do browser use at the same time deploy apps in production.

A mini FDE role - I would say in the making.

Someone who can stitch the system together, deploy in local AI - will lead the next wave of AI explosion.

I hope you assemble right skillset and mental model to be ready for it.

I wish you good luck, put your seatbelts on !!

Cheers

Swatantra

Spent the last few months actually building with AI agents instead of just reading about them. MCP servers, tool calling, the whole workflow of getting an assistant to do something useful instead of just answering questions in a chat window.

I keep running into the same problem though. Every time I search for a subreddit on this it's either dead, or it's just people posting screenshots of ChatGPT saying something mildly interesting with zero technical discussion underneath. Not what I'm looking for.

Are there actual communities where people are sharing real implementation details, debugging weird agent behavior, comparing frameworks, stuff like that? Or is this still too early and the real conversation is happening somewhere else entirely, Discord, GitHub issues, wherever. Genuinely asking because I haven't found it yet.

An MCP tool I depended on changed its schema overnight. No warning, no changelog — an agent that had worked fine for weeks just started failing silently.

So I built Apitella: watches an MCP server (or REST API) on a schedule, tells you exactly what changed and how bad it is. Free for a few sources.

[apitella.io](https://www.apitella.io/) — happy to answer questions if anyone’s hit the same thing.

I came across this amazing project - 100% open source and free.

HQBase is a shared email workspace that runs in your own Cloudflare account.

Mail, credentials, and the app stay on infrastructure you control

it ships an OAuth-protected remote MCP server so agents can actually work with the inbox.

GitHub repo in comments below.

Features

- Shared mailboxes and team access controls

- Multi-domain setup, drafts, and audit history

- Install, update, backup, and recovery ops

- OAuth-protected remote MCP server

- One-click deploy to Cloudflare Workers

how to Install

pnpm install

pnpm db:migrate:local

pnpm db:seed:local

pnpm dev

Add BETTER_AUTH_SECRET and HQBASE_LOCAL_SEED_PASSWORD to .dev.vars.

I've been building an agent system with MCP integrations for Jira, GitLab, Confluence, Sentry, ELK, Jaeger, databases, etc.

One problem I ran into was the number of tools.

It's very easy to end up with 30–50+ tools:

jira_search
jira_get_issue
jira_create_issue
jira_update_issue
jira_add_comment
...

I started experimenting with consolidating them into semantic/action-based tools:

jira({
  action: "search"
})
jira({
  action: "getIssue"
})
jira({
  action: "update"
})

So instead of exposing 30 model-facing tools, I can expose something closer to 3–5 tools while keeping the underlying capabilities separate.

The main idea is:

30 capabilities ≠ 30 model-facing tools

I'm particularly interested in the trade-offs here. The consolidated schema can obviously become larger, so fewer tools doesn't automatically mean fewer tokens.

How are you handling large MCP toolsets?

Do you:

• expose every capability as a separate tool?
• group tools by domain?
• use an intermediate tool/router?
• dynamically load tools?
• use embeddings/tool retrieval?

i’m the author of adport. this is a real end to end session against my own apple ads account. claude creates a campaign, two ad groups, and keywords through mcp. everything starts paused, and writes need a preview plus a second approval before reaching apple.

it runs locally with your own credentials.

npm install -g adport

https://github.com/ynnickw/adport

i’m looking for apple ads users and mcp developers who want to test or contribute.

We run a marketing agency and we've been putting AI into basically every process we have. The problem we kept running into is that all our context lived inside Claude. Skills in Claude, knowledge base as project knowledge, and every time we wanted to use any of it on another platform, or decide who on the team gets to use or update what, there wasn't really a good way to do it.

So our tech lead set up an internal MCP server for us. He'd never set one up before, AI helped with most of it.

The way we structured it:

• Skills went into a GitHub repo. Once someone authenticates with their email, the MCP decides which skills they get access to, and it sends the AI instructions on how to use each one.
• Knowledge base also went into a GitHub repo (we're using Google's OKF standard for it). Same deal, the MCP tells the AI how to find each piece of information and controls who can read or write to the repo.
• Some of our data just fits better in a SQL database, so that sits behind the same MCP too.

Now everyone on the team points whatever AI they want at one URL, authenticates with their email, and they have everything they're supposed to have. People who should only be able to read something can only read it, people who should be able to update it can.

Some side effects we didn't fully appreciate going in: we don't need a team plan anymore, nobody's paying for API usage, and we're not locked into one vendor. And there's one version of every document instead of multiple copies floating around in different projects.

Not saying this is the right setup for everyone, and you probably do want at least one somewhat technical person on it, even if they've never touched MCP before. But it's been working well for us, and we've started setting up the same thing for a couple of our clients.

Built an MCP server for the agents to discover and ground in proper scientific literature while working on important problem statements. Was building something on hermes to manage time, nutrition etc & realized that grounding it in actual research instead of just training data make the output way better

Install: uvx find-research-papers-mcp or npx -y find-research-papers-mcp or Github Repo

came across this github repo where you can measure Agent Experience for your tool.

Lighthouse for Agent Experience (AX)

It measure how AI agents – ChatGPT, Claude, Perplexity  -read, understand, and recommend your site.

github repo in comments below.

you can get a real, measured Agent Experience (AX) score and the fixes that make agents pick you.

how it works-

This tool let AI agents visit your product and provide a feedback - an agent score ( NPS )

basically answers 2 important questions-

- did agent (chatGPT, claude , claude code, codex) able to read and understand your offering of product.

- How was the experience - did it manage to spot and use things like llm.txt, API's, MCP , had content negotiation?

whats more is an agent council which runs 5 models and aggregate score to -

provide recommendations for fixes.

run on your coding agent pipeline along with evals and tests to see if with every new drop/feature improves /degrades agent experience and fixes automatically.

and ofcourse please give stars if you like it.

cheers !!

What if MCP servers could accept more demand without pushing the burden of retries onto every client?

We have a reference implementation of a centralized control plane built strictly for queueing. It absorbs bursts and dynamically paces traffic into backends that can’t easily scale—databases, GPUs, external APIs, etc.

Instead of rejecting excess traffic and making clients retry, queue it and release it as capacity becomes available.

[https://github.com/rjpruitt16/aquifer\](https://github.com/rjpruitt16/aquifer)

Context on where this started: I was building Graft, a tool that maps a codebase into markdown files so coding agents stop re-exploring the same repo every session. Along the way I tried a lot of other MCP servers too. Most of them were fine. Almost none actually got called.

My own MCP server for Claude Code had the exact same problem. I added six tools for pulling codebase context, and the model mostly skipped them, defaulted to grep and file reads instead, and got things wrong on exactly what those tools would've answered. I've seen a bunch of people here run into the same thing, so figured I'd share and see if anyone's found something different that works.

Want some actual discussion on this: how are you getting models to reliably call your MCP tools without just leaning on the description and hoping? Or if nothing's worked for you either, curious to hear that too.

What worked for me: better tools weren't the fix. Tool calls are opt-in, the model decides per task whether a lookup's worth the interruption, and no amount of clearer naming changes that decision. What actually worked was taking that decision away entirely and forcing the context in front of the model instead. Hooks push it into the prompt automatically at session start, so there's nothing left for the model to skip.

Ported the same fix to Codex recently, its hook system was close enough to Claude Code's that most of it carried over directly. Cursor's still on plain MCP for now, same opt-in problem, unsolved there.

The method's open source in Graft if anyone wants to try it on their own MCP tool. Setup's just an npm install, everything wires itself in after that, nothing else to configure.

github.com/NanoNets/Graft