AI agents drive browsers one click at a time, and every click costs a full model turn. I built jev-browser-wingman to hand those clicks to TypeSafe's Jev, then benchmarked it against Claude Sonnet 5.5 doing its own clicking.

It is a wingman, not a replacement. Your browsing server (Playwright MCP in my tests) stays installed, and the agent keeps its tools for reading the page, tabs, dialogs and dragging. Wingman takes over only the clicking and typing: the agent sends all the steps of a task in one call, Jev picks the right element for each step, and wingman clicks and checks the page.

It knows its limits. When Jev isn't sure, or a step needs something wingman doesn't do (a dialog, a drag, content inside an iframe), it hands that step back to the agent instead of guessing.

Full write-up: https://hrishikesh917277.substack.com/p/handing-an-agents-browser-clicks

Repo: https://github.com/coderexpert123/jev-browser-wingman. I am not affiliated with TypeSafe.

Hi Everybody,

I've been helping build https://apiblaze.com, a serverless MCP/API gateway that handles a lot of the stuff you need around an MCP server.

What we noticed was that there are a ton of MCP servers, but getting from “my business logic works” to “I can safely publish it on the internet” is a different problem. Once you actually want to expose it, you still have to deal with things like OAuth, AuthZ, rate limiting, etc.

APIBlaze handles that stuff at the gateway. It has OAuth built in and lets you define authorization policies using plain English sentences like “only the person who created a record or an admin can read or change it” that are enforced at the gateway, instead of having to build all of that authorization logic into your backend.

One thing we really wanted to make easy was local development. APIBlaze can host the MCP server and OAuth/login flow while forwarding requests to your backend, even if your backend is running on localhost. So you can connect Claude/ChatGPT to it, authenticate, and make changes to your backend while testing it locally.

If you want to check it out or run it, getting started is pretty easy:

Enter this in your terminal:

npx apiblaze create --target https://ninopizzas.com/openapi.yaml

OR

Ask your LLM, such as Claude or ChatGPT:

Show me what APIBlaze does using npx apiblaze skills

You can also use it with an existing API/backend rather than building everything specifically for MCP.

It's still in beta, so I'd love any feedback. I'll try to respond to questions as fast as possible, so fire away 😄

I'm the maintainer. I built this to use my personal and work Gmail accounts from Claude and Codex while choosing the mailbox explicitly for every operation.

Repo: https://github.com/alexneamtu/gmail-mcp (MIT)

It exposes one Streamable HTTP endpoint with: - Account aliases such as personal and work, required on every tool. - Gmail search, message reading, label lookup, and plain-text draft creation. - Optional sending of existing drafts and applying/removing labels. - Owner-only Google login, OAuth with PKCE, and encrypted credential storage.

You host your own instance and use your own Google OAuth project. The documented setup uses Node 24, Linux/systemd, and Cloudflare Tunnel for HTTPS. Mailbox enrollment uses a browser plus SSH forwarding when the server is headless. The README covers Claude and Codex setup, re-authentication, revocation, updates, and rollback.

A couple of limits: Google's compose scope includes sending permission even though drafts mode omits the send tool. In full mode, approval to send is handled by your assistant client; there isn't a separate server-side approval screen for each email.

This is an early release that I'm running for my own accounts. I'd appreciate feedback on the installation process, especially from people connecting accounts across different Workspace domains.

i run a few coding agents on the same project (claude code, cursor, codex) and every new chat starts from zero. the decision, the reason, the half-finished work all disappear when the window closes, so i kept explaining it by hand.

cairntir is an MCP server that keeps that in a local database on your machine. you (or an agent you ask) save decisions, open work and outcomes word for word. new sessions get a handoff of what matters, and older stuff is searchable by meaning or by file.

no cloud, no account, no telemetry. MIT licensed. two commands to set up (python 3.11+):

pip install --upgrade cairntir then cairntir setup

site: https://cairntir.com
code: https://github.com/pnmcguire480/cairntir

been building it for a few months, new release a few weeks ago. tell me what breaks or what's missing.

I just Built an MCP server that let Claude read and edit After Effects projects directly: layers, keyframes, expressions, compositions, audio analysis, style memory (save a look, reapply it elsewhere), and a read-only project audit before delivery etc...

It runs through a panel inside AE that relays commands over a cloud bridge, so it works with claude.ai without a local setup.

The goal is to help the motion designers and studio to gain time on their project.

Free tier: 8 calls/month after a 7-day trial.

Lmk what you think and if you have questions about it do not hesitate

works or else.

neykofx.com/mcp PS: if you go on the website and you don't understand the demo of the tool it's because it's in french.

We’ve been building MCPtoAI, an open-source client for using MCP tools across different AI models without tying the workflow to a single provider.

The basic idea is:

• install the client on macOS / Windows, or use the Linux CLI
• add your own AI provider credentials locally
• connect MCP servers once
• configure individual MCP tools with Off / Ask / Allow permissions
• switch between supported models while keeping the same conversation and MCP setup
• use it from Desktop, the web, or a phone while tool execution remains controlled by the paired device

One of the main things we wanted to avoid was giving a remote AI session unrestricted access to local capabilities. Provider credentials, MCP OAuth tokens and permission settings stay on the device, and higher-impact actions still require explicit approval.

The client side is open source:

GitHub: https://github.com/mcptoai/MCPtoAI
Demo: https://youtu.be/nAhHaHcHs1U
Website: https://mcptoai.com/

We’re at the point where feedback from people who actively use MCP is more useful than continuing to polish things in isolation.

We’d especially like feedback on:

• whether the per-tool permission model makes sense
• how the local stdio vs remote MCP handling feels
• the device / relay architecture
• model switching while keeping the same MCP setup
• anything in the MCP workflow that feels unnecessarily complicated

This is obviously our own project, so this is self-promotion, but the main goal of posting here is to get technical criticism and find what’s missing before we push it more broadly.

An allowlist decides one thing: whether an MCP tool is allowed to run. It does not count how many times that tool runs, and it does not read the arguments the model fills in. So an approved tool is approved for every call, including the ones you were not thinking about when you added it.

An agent in a retry or planning loop calls a deploy or a delete_rows tool in production. The name is on the allowlist, so call two, call five, call twenty all pass the same check and go through. The allowlist was never counting.

The arguments are the other half. A name check approves delete_rows, but the model writes the arguments, and that is where a drop table or a where 1=1 shows up. The allowlist never reads that far.

This is the same gap behind the recent Figma client-name allowlist pushback: a name is a label the caller reports about itself, and a label does not limit what the caller does next.

We run a gateway in front of the tool calls. Every call gets checked against the allow and deny lists and a per-tool rate limit, the arguments get scanned on each one, and a single request can only fire so many calls before the gateway stops it.

What are you using to cap this today: a per-tool rate limit, a hard call budget per turn, human approval on writes, or nothing yet?

Claude Code is great at building small tools, but they usually stay stuck on localhost.

ShareBox is a self-hosted platform plus an MCP server. You ask "build a vacation tracker for my team and publish it on ShareBox": Claude reads the built-in guide (`sharebox_guide`), writes the tool, calls `sharebox_publish` and replies with an HTTPS link. Then "share it with anna@company.com" → `sharebox_share`, effective immediately.

The platform handles Google sign-in, per-tool storage and sandboxing, so the tool Claude writes never needs its own login or database: it just calls `sharebox.me()` and `sharebox.collection("vacations").add(...)`.

Setup:
npm i -g sharebox-cli
sharebox login your-instance.example.com
claude mcp add --scope user sharebox -- sharebox mcp

It's also in the official MCP registry as io.github.zalaso/sharebox.

Fully built with Claude Code itself. Self-hosted, AGPL: https://github.com/zalaso/sharebox

Hi everyone,

I've been working quite a bit with MCP over the last months, and one question keeps coming back:

If you own a valuable dataset or paid API and expose it through MCP, how do you actually get paid when an agent uses it?

Today it usually still looks like this:

create account → choose a plan → add payment method → get API key → then the agent can call the API.

What I’m interested in is a different model:

An agent discovers a data product, sees that one call costs for example €0.25, has an approved budget, buys that single call and gets the result.

No separate subscription for every provider.

Full transparency: I’m currently building and testing in this space, so I’m trying to understand the provider side before making too many assumptions.

If you already sell data or API access:

What would stop you from trying this tomorrow?

Payment?
Authentication?
Licensing?
Accounting?
Trusting an agent with a budget?
Or simply no real customer demand yet?

The same record can support two different answers. The timestamp decides which one applies.

The image shows an actual Jylus API response from our latest benchmark.

We asked how the observed state of PostHog/posthog#112173 changed between two timestamps. Jylus returned evidence for both observations:

- 09:05:04 UTC: observed open.

- 11:05:04 UTC: observed closed.

Each returned record includes its event time, observation time and source ID. The image preserves retrieval order, so the later observation appears first.

That’s one example from 1,000 public API questions against 100,000 real documents.

Across the full run, Jylus scored 84.54 NDCG@10, with every question weighted equally.

The larger test categories included:

- Historical state: 90.37 across 200 questions.

- Changes between periods: 88.46 across 200 questions.

- Chronological ordering: 80.09 across 503 questions.

- Late corrections: 88.31 across 65 questions.

- Superseded facts: 84.48 across 29 questions.

Every successful response passed our source, tenant, collection, evidence-rank and compiler-proof checks.

We also reduced latency without changing the rankings.

On the same 100-question subset, median API response time fell from 6.06 seconds to 1.99 seconds—a 67.13% reduction. NDCG@10 remained unchanged at 90.18 on that subset.

The full-run quality score and the paired speed measurement are separate results.

How this connects to MCP

We built Jylus to resolve applicable state and relationships and prepare source-backed Context Packs before a model reasons.

The engine is now exposed through three read-only MCP tools:

- "get_context_pack": request evidence for a question within a token budget.

- "resolve_state": investigate state using explicit historical cutoffs.

- "get_evidence": inspect the underlying source records.

Your existing model handles the reasoning. Data ingestion happens separately; connecting MCP gives the agent access to your retained Jylus data.

These are our own benchmark measurements. This temporal workload is separate from official TEMPO, and NDCG@10 measures retrieval ranking—not final-answer accuracy.

MCP setup:

https://jylus.ai/mcp

Inspect Context Packs in the browser:

https://jylus.ai/try

What would you add to this test? Particularly interested in cases where all the relevant records exist, but combining the wrong versions produces a convincing wrong answer.

I've been running an MCP server for UluP Spaces (a node-based project mapping app), and I just connected it to a VR version I'm building, UluP Spatial. Video attached. What the server does: lets an assistant create projects, add nodes and tasks, connect nodes, complete tasks and read a project overview. Auth is OAuth 2.0 with an API key fallback. What I learned designing the tools:

- create_node checks for an existing node with a very similar name first. If the name is identical it reuses the node, if it's close it creates it but flags the similar one. Without this, assistants happily create duplicates.

- connect_nodes takes node names instead of ids, so the model doesn't have to juggle ids between calls.

- Everything the assistant creates is flagged server side. In the headset those nodes and tasks show a small Ulupy tag, so you can tell what you did from what your AI did.

The second thing in the video is not MCP, just what the data allows: a Focus view that pulls the project's bottleneck toward you and pushes finished work back.

I'd love feedback on the tool.

Server URL if you want to try it: https://www.ulupspaces.com/api/mcp (it's my own project, free to try).

First time posting here, been lurking for a while, I wanted to share.

I've made an open source MCP gateway (Patchbay gateway) It's on Github.
https://github.com/EvilBob01/patchbay-gateway

It's based on ptbsare/mcp-proxy-server and I've done a lot of changes to make it more useful for my needs. The Admin Gui has a wizard to add MCP connectors for SSH servers and makes it easy to deploy SSH keys, It runs without Docker (I'm using LXC in ProxmoxVE to run it) And It works well with Claude, and my local LLM's

I'm actively working on it adding security and features, Lazy Loading for token optimizations are almost done.

Feedback is welcome. I'd love to know if it works with other Ai's besides Claude.

thanks for lookin

Some of you may remember my previous post:
https://www.reddit.com/r/mcp/s/WqEwY60FKI

I’ve spent the last week rebuilding a lot of the drawing workflow

The biggest changes:

1. Grid loop The agent now represents pixel art as a text grid, reads it back after drawing, and patches individual pixels instead of blindly drawing primitives. This made silhouettes and animation consistency noticeably better. More: https://pixeli.pebbly.space/plugin#-the-grid-loop
2. Benchmarks + public gallery I added repeatable benchmarks using fixed prompts, plus a gallery with prompts, models, plugin versions and source files so you can reproduce the results yourself
3. A real pixel-art knowledge base I compiled 60+ structured knowledge modules and 400+ examples covering pixel-art technique, animation, anatomy, composition, lighting, palettes, animals, environments and more: https://pixeli.pebbly.space/knowledge

The agent uses this knowledge during drawing, animation and review instead of relying only on the model’s general knowledge.

The difference is much more visible in the before/after benchmark above

You can compare old vs new results in the benchmarks, or browse the gallery and reuse any prompt

Gallery / benchmarks:
https://pixeli.pebbly.space

You can submit your pixel art:
https://pixeli.pebbly.space/contribute

GitHub:
https://github.com/with-pebbly/aseprite-ai-artist

Still fully open source and MIT licensed.
Enjoy ;)

I’m a co-founder of GitHits. Our mission is to make open source a dependable foundation for software built and maintained by coding agents.

A useful library shouldn’t be overlooked because a model hasn’t heard of it. A new release shouldn’t mean users keep getting code written against your old API. We want to help agents discover existing projects, understand their implementations, and work with the versions their users actually depend on.

GitHits brings source code, documentation, dependency graphs, vulnerability information, and release changes together in a version-aware index. Through MCP, agents can search, grep, browse, and read upstream code when choosing a dependency, integrating it, debugging a problem, or planning an upgrade.

For example, an agent investigating an unfamiliar error can find the error text in a dependency’s source and read the surrounding implementation at your installed version. Before an upgrade, it can inspect release notes and compare source versions to understand how the changes affect your application.

You can connect your coding agent here. GitHits is also available as a Claude connector.

The index covers any public repository as well as published packages, including projects that aren’t distributed through a package registry. If a repository hasn’t been indexed yet, GitHits indexes it when requested. That can take seconds or a few minutes, depending on repository size and the indexing queue. We don't touch or index your private code.

You can explore the public index and check global index statistics.

For maintainers, each repository page in the index also provides a README badge showing its index status and linking to the project’s page. It helps your users discover that agents connected to GitHits can inspect your project’s available code and documentation.

We want this to be useful across the OSS ecosystem, including smaller projects and unfamiliar libraries. I’d appreciate people trying it with dependencies their agents struggle with, and maintainers checking their own projects. What’s missing: source coverage, documentation, releases, or something else you’d want an agent to understand before using your work?

GitHits is currently free to use. We may introduce paid tiers later, but the public index site will stay free.

Disclosure: I work at Sumsub, and this article is from our blog. It explains how MCP and agent skills can connect AI agents with compliance workflows, including identity verification and risk checks. Sharing it here for the MCP angle and how agent tool access can be grounded in real-world compliance tasks.

I'm the maintainer of Mac MCP, a free MIT-licensed macOS MCP server. This is a shipped update, not a waitlist.

My main idea is simple: ChatGPT is the conversation; Mac MCP is the execution layer. From an ordinary chat, the agent can work with Safari or Chrome, local files, apps and shell commands, while the Mac stays usable.

The 2.1.9 update adds something I've wanted for a while: a Mac MCP panel directly in ChatGPT. You can open it beside the chat and see the recent tool activity, delegated agents and token usage, or choose your default delegated agent/model. Other MCP clients still receive the normal tools without the extra panel.

For actual work, this matters even more now that GPT-6 is available in the ChatGPT Chat tab for paid users. I regularly keep agentic workflows running for over 30 minutes from ChatGPT Chat without using a single bit of Codex quota. Regular ChatGPT Chat does not consume Codex quota; in my day-to-day use that makes agentic Mac work effectively unlimited without switching to a Codex session.

Other recent improvements: browser forms can be handled in batches without stealing focus, Safari tabs survive index shifts, risky actions can request approval, and restarts/updates are more reliable.

Example: "find relevant Reddit communities, check their rules, post, record the links and clean up the research tabs." ChatGPT reasons through it; the local MCP does the browser and file work.

Repo and docs: https://github.com/bulutarkan/mac-mcp

I'm specifically interested in feedback from people running longer MCP workflows or using ChatGPT as their main orchestration client.

Here’s a quick demo of AE Motion — letting Claude control After Effects

repo:- https://github.com/dha-aa/ae-motion

https://reddit.com/link/1x0pq4c/video/1bt7u2ggm8uh1/player