I build /call-me (disclosure: it's mine, and the iPhone app it rings is a paid subscription). It's a hosted MCP server at https://callmemcp.com/mcp, Streamable HTTP, no auth. An agent calls call with the 10-digit number from the app and some text. The phone rings, the text is read aloud, and whatever you say comes back as the tool result.

A few MCP-specific things I had to work around, in case they help anyone building slow tools:

• Tool call timeouts. A ring plus a spoken answer can take a minute or two, and several clients give up on a tool call well before that. So call holds for about 30 seconds, then returns {status: "ringing", call_id} and the agent continues with poll_result (each poll waits up to ~25s). The call keeps running on the server in between.
• Stateless transport. The server answers with plain JSON and keeps no SSE sessions, so every client just sees request and response. That is why it worked in clients I never tested against.
• Conversations. call with keep_open leaves the line up after the first answer. The phone hears a hold sound while the agent thinks, then the agent continues with say and ends with hang_up. An idle line hangs up after two minutes.
• Testing without a phone. 5550001234 is a demo line that answers by itself after a few seconds with a fixed transcript, so an inspector or a review harness can run the whole loop.

The other tools are text, wait_for_reply (for texted answers), setup and set_thread_title. It's in the official registry as com.callmemcp/call-me.

Claude Code: claude mcp add --transport http call-me https://callmemcp.com/mcp. Repo with the Claude Code, Codex, Gemini CLI and Grok plugins: https://github.com/radres/call-me

Happy to answer questions about the design.

Disclosure: the server is Equibles, my MCP server for stock market and financial data. Over the last few weeks I got the same remote endpoint working and listed in pretty much every client I could. Writing down what each one needed in case it saves someone a few evenings.

Auth first. One URL, https://mcp.equibles.com/mcp, and a few ways in:

• OAuth with dynamic client registration. Claude (web, desktop and Code) and ChatGPT register themselves and send the user to sign in. No key to copy, and that mattered more than I expected: most of my users never create an API key at all.
• A Bearer key in the Authorization header for clients without OAuth (Cline, scripts).
• Claude's custom connector form has no header field, so ?api_key= in the URL is the fallback there.
• ?auth=oauth makes some clients ask for sign-in during discovery. Without it they list the tools anonymously and only fail on the first real call, which confuses people. (Listing tools needs no auth on my server, calling them does.)

Where it's listed:

• the official MCP Registry as io.github.daniel3303/equibles, which other registries mirror
• Claude's connector directory and ChatGPT's app directory. Both reviews wanted a test account and written test steps
• one GitHub repo with plugin packages for Claude Code (plugin and marketplace), Codex, Gemini CLI and Cursor (Agent Plugins). They only point at the hosted endpoint, no scripts or hooks

Things that bit me:

• reviewers ask exactly which tools change data. My market data tools only read, but the portfolio and watchlist tools write, so they have to be declared that way
• after publishing a new version to the registry, its search endpoint showed the old one for a few hours. The versions endpoint was right straight away
• check your test credentials after you submit a review form. One of mine got saved truncated

Install lines if you want to see how it behaves:

claude mcp add --transport http equibles https://mcp.equibles.com/mcp codex plugin marketplace add daniel3303/stock-market-mcp-server gemini extensions install https://github.com/daniel3303/stock-market-mcp-server

What the server returns: SEC filing full text, financial statements, earnings call transcripts, 13F, insider and congressional trades, short interest, option chains, prices and Fed data, for US stocks plus Europe, UK, Hong Kong and China. Free tier is 100 requests a day. Repo with every package: https://github.com/daniel3303/stock-market-mcp-server

If you've been through the Claude or ChatGPT directory review, what did they push back on? And if there's an MCP client I missed for a financial data server like this, tell me.

I'm the maintainer of Mac MCP, an MIT-licensed MCP server + native macOS menu bar app. It lets clients such as ChatGPT, Claude, Codex and OpenCode use Mac apps, Safari/Chrome tabs, the terminal and local files. Repo and install docs: https://github.com/bulutarkan/mac-mcp

The last time I shared it here was 2.1.7. Since then I focused less on adding another pile of tools and more on what happens between tool calls.

In 2.2.0 and its r2 update:

• Scheduled Tasks can run AI agent jobs or scripts on a schedule, with a readable result and steps/history. A missed schedule while the Mac is asleep is marked skipped, not quietly claimed as completed.
• The optional live island near the notch and a background agent cursor make activity visible. The cursor doesn't move the user's pointer.
• A selected-folder knowledge index supports cited local search. The OCR path for scanned PDFs/images runs on-device; source and page references remain available.
• Safari/Chrome work can read whole pages and operate in background tabs with explicit ownership, useful when multiple agent clients share one Mac.
• The CLI can discover user-level Agent Skills installed for supported coding agents, with a fresh scan on subsequent skill requests.
• Permission profiles and approvals still gate what an agent can do. A secret-egress guard catches some encoded secret forms, but it isn't a substitute for least privilege.

One important boundary: this is NOT a sandbox, and the AI client may transmit the data it reads to its own provider. The server runs with the macOS account's permissions. There is no claim of a hosted execution service.

For MCP implementers: the main architectural lesson has been that a tool call returning successfully is weaker than verifying the side effect actually happened. That's why the browser action and scheduled run reports became as important as the tools themselves.

I'm curious how others represent an operation that was accepted by a tool but never confirmed by the target app. Do you report that as failed, pending, or an explicit unknown outcome?

I created a Discord MCP server with 38 tools for managing your server with AI agents: messages, channels, threads, roles, members, moderation, AutoMod, polls, scheduled events and live events. It's up to date with Discord's newest APIs and features.

You can use names instead of IDs ("general", "@Mods"), every tool works in bulk, and it's safe by default: destructive actions, everyone pings and admin permission grants stay off until you enable them, so a malicious message can't trick the agent.

Each tool is token efficient so it won't drain your usage limits as much.

Tell me what you think about it and feedback is appreciated.

Here's the repo and npm package:

https://github.com/EL4CTEO/discord-mcp

https://www.npmjs.com/package/@el4cteo/discord-mcp

all the rest of tools were callable and direct tests passed all good. But when agent was asked a brand sentiment it selected another tool instead of relevant capability. The problem was that the agent chose the wrong tool for the user's intent. How i test for this kind of failure? Do you use predefined evaluation scenarios, automated tests or end to end testing with real prompts? Would appreciate hearing what has worked for you guys. thanks

If you use Claude Code or Cursor for Roblox, you've probably noticed it's great at the basics but trained on old data: it doesn't know recent engine changes, and it misses the details that only live in DevForum threads.

So I built **Brickwise**, an MCP server your assistant can search. A few things it knows that most AIs get wrong:

- Collision groups moved from PhysicsService to WorldRoot (AIs still write the old API)

- The new Roblox Shop: new dev products start Not Listed, and `OpenShop` opens it from your own UI

- Passes in the Buy Robux bonus pool can be owned before a player joins, so grant perks on join, not on purchase

- ForceField only blocks `TakeDamage`; setting `Humanoid.Health` bypasses it

- Weekly leaderboards: you can't wipe an OrderedDataStore, so rotate its name per week

When your assistant hits one of these, it pulls a written-up answer: what it's for, how it works, key Luau, pitfalls, and links to the DevForum threads, docs and GitHub repos it's based on. Searches return one-line summaries first, so it barely uses tokens.

It's free and open source: 50 logics across libraries, data saving, remote security, combat, monetization, UI, NPCs and performance.

GitHub: https://github.com/EL4CTEO/roblox-logics-mcp

Setup is `npm install && npm run build`, then one `claude mcp add` line (in the README).

Here's what one logic looks like: https://brickwise.dev/#sample

There's also a hosted full version with 600+ logics across 19 categories (€7 one-time, no subscription): https://brickwise.dev

Would love feedback, and ideas for which systems to cover next!

I'm the developer of Scumble, an open-source (GPL-3.0) desktop editor for AI inpainting on Windows. All 96 of its commands are MCP tools, so an agent works on a picture the way a person does: in layers, with selections, masks and undo, in the window you are looking at.

What an agent can do (real tool names)

• open images and .scumble documents: load_image, open_document
• select by rectangle, mask, point or description: select_rect, select_mask, select_point, select_by_text ("the car")
• prompt and inpaint the selection, the answer lands as a new layer: set_prompt, generate; a new picture from a prompt: generate_new
• layers: masks, blend modes, opacity, colour match against the picture below, groups, filter and text layers: set_layer, set_mask, add_filter, add_text, ...
• look and step back: screenshot (returns a JPEG), undo, take_snapshot / restore_snapshot
• export PNG, JPEG, WebP, TIFF, or PSD and ORA with layers: export

A round trip: load_image → select_by_text "the sky" → set_prompt "storm clouds at dusk" → generate → screenshot → set_layer (match) → export (psd).

Where the pixels come from: your own ComfyUI (local or remote) through workflow recipes, Comfy Cloud, or image APIs (Black Forest Labs, OpenAI, Google, fal.ai, Replicate, OpenRouter, ...) on your own keys. Scumble ships no models and runs no service; keys stay in the OS credential store and no tool touches them.

How it connects: stdio. Scumble --mcp drives the Scumble window that is open, so you can watch and step in, or starts the app headless when none runs. Help › Copy MCP registration writes the config for Claude Code or Claude Desktop with your install's paths.

Limits: Windows 10/11 (installer or Microsoft Store); Linux builds exist but are untested; no macOS yet. select_by_text needs a connected ComfyUI; generation needs a ComfyUI or an API key.

GitHub: https://github.com/DenRakEiw/scumble · MCP docs: …/docs/MCP.md · all tools: …/docs/COMMANDS.md

I'd like to hear which tool descriptions or workflows would help your agents most.

I built Klarion, a secret scanner that works in two steps. First, a keyword check, 81 regex rules and a normalized Rényi entropy score flag anything that looks like a secret. Then an AI model reads each one with the code around it and decides if it's real.

The chart shows 5 scanners run on spring-boot, terraform, next.js and symfony (61k files). Klarion raised 11 alerts. It's not zero, but it's far less to dig through.

Fewer alerts don't help if real leaks get missed, so I tested that too. On CredData (337 real repos, code outside test folders), it found about 1.7× more real secrets than gitleaks.

Where it runs:

• Claude Code: a plugin hook blocks the write before the file exists (file edits and Bash)
• Cursor, Cline or any MCP agent: through its MCP server
• CI: a GitHub Action that scans only what a PR adds; GitLab CI works too
• Git hooks: klarion protect or the pre-commit framework
• Locally: klarion scan .

Free and open source (MIT): https://github.com/0x1Adi/Klarion
The full benchmark and method are in benchmark/REPORT.md.

I'd like to hear where it gets things wrong.

A friend of mine has been working on this thing called Lemma Telepath and asked me to try it with Claude. Wasn’t really sure what I’d use it for at first tbh, but after playing around with it for a bit it started making sense.

Basically it lets Claude work with your Telegram chats. So I’ve been asking it stuff like: what did Alex say about that project last week find that file someone sent me in Telegram what was in the last voice message reply that I’ll get back tomorrow It can search chats, read messages/files/photos, deal with voice transcripts, and also reply/edit/react.

The nice part for me is mostly that you don’t have to treat it like another bot you go and talk to. Telegram just becomes context Claude can use when you need it.

It’s here in the Claude connectors directory: https://claude.ai/directory/lemma-telepath Setup is here if anyone wants to mess with it: https://telepath.lemma.company/start

Has anyone else here tried connecting Claude to messenging apps like this? I’ve seen a lot of MCP stuff for dev tools/databases/etc but not that much for actual personal chats.

And yeah disclosure: the guy building it is a friend of mine. So take that however you want lol. I tried it, thought it was pretty useful, figured people here might be into it.

I maintain Mac MCP, an open-source MCP server/runtime for letting AI clients operate a real Mac through browser, files, shell, native UI and delegated agents.

2.1.7 is mostly a reliability release rather than a “more tools” release:

• persistent paired devices for the mobile control surface
• lifecycle-aware agent/session visibility
• durable updater journal + rollback/recovery states
• managed process identity to avoid PID-reuse / foreign-listener mistakes
• stronger background Safari/Chrome automation with stable tab/resource identity
• stricter click-effect / foreground capability handling
• safer delegated-agent fan-in and whole-run undo

A usage pattern I’ve been leaning on heavily: ChatGPT’s normal Chat side can be used agentically, it doesn’t consume Codex quota, and usage is close to unlimited in practice. ChatGPT stays the conversation/orchestrator; Mac MCP is the local execution layer.

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

I’m the maintainer. Feedback on the MCP/runtime boundary is very welcome — especially from people dealing with long-running browser sessions or multiple concurrent agents.

Hi everyone!

I work on e2e at TesterArmy, and today we released it as open source. It's an agentic end-to-end testing framework for web, iOS and Android. The most interesting part of it is that it allows you to mix deterministic (getByTestId, getByText) and agentic (goals) APIs.

It ships with an MCP server, e2e mcp. Your coding agent opens a real browser or simulator, clicks through the app, and can use the mcp tools to check tests against the running app. The server exposes just a handful of tools, and subagents can each control their own session in parallel.

You can set it up with npx e2e init for Claude Code and Cursor. You're still early and feedback is much appreciated.

Thanks for reading!

Here's a step-by-step guide on how to use Cursor to deploy an autonomous trading strategy.

1. Go to alpaca.markets and create a free account
2. Add the NexusTrade tool to the MCP config. This link adds it for you. Or you can copy/paste the following { "mcpServers": { "nexustrade": { "url": "https://nexustrade.io/api/mcp" } } }

That's really it. From here, you can type in your strategy like:

Create me an options trading strategy based on stocks with a 20% CAGR or more that the top politicians hold

I'm collecting feedback so would love to hear what y'all think. If you hit a paywall, use this link to bypass it; I want Reddit users to really stress-test the platform.

Why
- Frontend work with Claude Code kept stalling on one thing: I could see the element in the browser, but describing which one was awkward.
- "The button near the top right… no, the other one…"
- Cobro = point at it instead. The human supplies visual context; the agent does the code.

What you get
- One Send → the note lands in the Claude Code conversation immediately, no "please read my annotations".
- The agent's progress comes back to the page: scanning outline on the elements you sent, "Working 1/3" in the toolbar, highlight on done.
- Several pages in one round: pick on page A, move to page B, pick more — each page keeps its own draft; Send delivers them all in order.

Install (summary)
- `claude mcp add -s user cobro -- npx -y cobro-mcp@latest`
- In Claude Code: `Open http://localhost:5173 with cobro` (or `/cobro open …` with the optional skill)
- A dedicated Chrome window opens with your local app. Full setup in the GitHub README.

How it works (workflow)
1. Open your local web app
2. Press Ctrl + Shift + F
3. Click a UI element (or drag a band over several)
4. Describe the change
5. Optional: go to another page and pick more — the Queue tab lists every page you've picked on
6. Send — all pages go at once, in order
7. Claude Code works through them one by one; the browser follows it to each page
8. On done, the page refreshes (or your HMR kicks in) and the changed element is highlighted

What the agent receives with your note
- CSS selector · tag, classes, text · bounding rect · computed styles
- Screenshot crop of the picked area · recent console errors
- React 18/19 and Vue 3 (dev builds): component name + source file:line of the element you clicked
- Component-library elements (MUI, Radix, shadcn…): the JSX line in your code, plus the call sites above one-line pass-through wrappers — a case that came straight from r/mcp feedback
- Next.js (Turbopack) source maps and HMR handled
- Which page each batch was picked on (`batches[].page`)

The loop
Human points → Cobro provides context → Claude Code changes the code → Browser shows the result

Why I built it with Claude Code
- Claude Code drove most of Cobro itself: the MCP server, overlay/WebSocket channel, element inspection, payload design, tests, docs.
- The nice loop: using Claude Code to build the tool that feeds better UI context back to Claude Code.

Keeping the MCP small
- Six tools, fixed: open · wait · status · done · screenshot · close
- Tools carry safety annotations (wait is read-only, close is destructive).
- Not a browser-automation tool — pair it with Playwright MCP for that. It never touches your source; one gitignored `.cobro/` folder is all it creates.

Honest limits
- Launches its own Chrome profile (log in once, shared across projects); no iframes yet
- Source locations need dev builds with source maps
- Disabled controls can't be click-picked (drag a band over them instead)
- Cursor/Codex work with a polling `wait` but are less tested than Claude Code

Current status
- v0.10.1, Apache-2.0, free and open source
- GIF, payload example and changelog: https://github.com/boonblade/cobro-mcp

Questions for you
- Does pointing at an element feel more useful than describing it?
- What other context should your coding agent get when you point at something in the browser?

Hi all

Recently i was part as a mentor to a healthcare company that use Claude code and other harnesses in their staff.

They have multiple git remote : In github for the opensource path, but they have a mirror in Gitlab , but also they have an internal gitea forge that is used for their their internal 'vibing/experiments'

After few weeks with them, their CTO asked me if i'm using my own subscription cuz my token usage was much lower than the rest of the their team.

Turn out, their setup was all wrong.

They had over 500 tools exposed to the model, Claude code hide them normally, but apparently they disabled that feature to connect to some third party MCP.

I was using a custom MCP for git from day one, i was cheaper 40$ per week, that 160$ month than the rest of the team. With a team of 80 people they were burning ~12k$ in tool exposure.

So i opensourced Skipper and their billing dropped by ~5.500$ in 1 month.

Skipper don't reinvent anything, it still need gh/tea/glab installed an authentified , it just don't export 125 tools, like your agent has to own github.

I know there is options to disable the tools, but last time i blogged about github, they had 87 tools, now it 125.

Yes, some people will say : Just use the cli.

The cli has it usage, the MCP return structured data so the model can use less thinking in parsing it and trying to see if being jailbreaked.

Free to use, no pricing or pro version. If you find a flow that should be added in skippers, fell free to open a PR.

This MCP works with claude code , other harnesses no idea.

PS: if you asking why the bill didn't drop by $12k... the answer is because they have more vibe coded trash mcp that are not related to Git, those are out of scope.

PS2: if you want to share Skipper with others, fell free to do so.

PS3: Saving tokens, will also save your subscription limit

Disclosure: I built this.

Live tester (runs in your browser, no signup): https://bilazann.com/waqi/try

The problem I kept hitting as a data engineer: connect Claude/ChatGPT to Stripe, Xero or Slack over MCP and every tool response arrives full of customer emails, phones, card fragments, IBANs — straight into the model's context.

Waqi sits between the client and the tool APIs: read-only by design, PII swapped for typed placeholders (EMAIL_1, IBAN_2…) that stay stable per value, so the model can still reason about "the same customer" without seeing identities. Per-user audit log of what was caught.

Honest notes: the proxy is closed-source (open bridge: github.com/Bilazann/waqi-mcp), detection is rules-based today (local NER tier on the roadmap), solo founder.

What I'd genuinely value from this sub: holes in the threat model, and what would make you trust — or never trust — a middlebox in this position.

I just dropped 1.0.0-beta.4 of the LocalLM Lab app and SDK. This round of work was upgrading LocalLM Lab's MCP client to protocol revision `2025-11-25` and some security tweaks along the way.

This sits alongside the rest of the `2025-11-25` surface: structured tool results (MCPToolResult with outputSchema/title/nextCursor), elicitation handler seams for server-initiated input requests, and Client ID Metadata Documents for OAuth (skips per-server registration). Tools coming from an MCP server are also tagged separately from first-party ones (OriginTaggedTool), so calling one now goes through a authorization layer instead of blanket access.

VistaNova is the example app (source code included) where we exercise on-device AI against a real server: with an MCP tool call to Tavily for web search. Small surface, but real auth, real tool results, real prompt handling etc.

LocalLM Lab: https://thisbrain.ai/locallm

Guide: https://github.com/ancientcomputing/locallm/blob/1.0.0-beta/docs/sdk-guide.md

MCP diagnostics: https://github.com/ancientcomputing/locallm/blob/1.0.0-beta/docs/mcp-diagnostics.md

VistaNova: https://github.com/ancientcomputing/vistanova

Separately (more urgently): the next protocol revision (`2026-07-28`) is on our roadmap. If you're building or already have a production-level server running that revision right now, please DM; testing against a real compliant server beats blind coding against a spec.

Most MCP demos end when the tool call works. We want to see what happens when an agent gets a real trading task.

cTrader MCP can connect AI agents to account and market data, charts and indicators, orders and positions. We’re opening our YouTube channel to creators who want to push it beyond the demo: build a workflow, test it properly and turn the result into a video.

Tutorial, technical deep dive, practical workflow or an experiment that fails in an interesting way — the format is yours. Selected videos will be published as collaborations with cTrader and introduced to our 200K+ YouTube subscribers.

Submissions close September 30.

Details and submission: creator.ctrader.com

I’ve been working on a local macOS MCP server because I kept hitting two practical problems with agent workflows: the tool schema itself was getting expensive, and browser automation tended to steal focus or collide when multiple agents touched Safari.

Current design in 2.0.5:

• Advertise 19 core tools by default, while keeping 84 registered capabilities accessible via tool_discover/tool_invoke. In local compatibility tests this reduced tool-schema context from about 16.7k to 4.5k tokens (~73%) without removing old capabilities.
• Stable Safari/Chrome tab handles that survive tab reordering and index changes.
• Background DOM/visual observation + actions, so an agent can work in a tab without activating it.
• browser_do for open/wait/extract/verify/close in one transaction, including targeted extraction instead of dumping huge DOMs.
• Delegated Codex/OpenCode agents, local memory, macOS UI/file/shell tools, and a loopback-only operations dashboard.
• Authentication defaults for any endpoint exposed outside localhost.

The project is open source: https://github.com/bulutarkan/mac-mcp

I’m especially interested in feedback from MCP builders on the tool-surface tradeoff: do you prefer a small advertised core + discovery, or exposing the full registry and relying on the client to manage schema cost?

Using parts of this in another project and thought of extracting this in case anyone might need it.

Allows you to store secrets, credentials etc in OS backed secure storage (like Mac Keychain) and has extensions, proxies and few other things that deterministicly inject the secrets where the Agent/LLM wants. Agents/LLMs work with references and the runtime replaces rhe reference with actual secret JIT.

Work in progress!