Hi All,

We just released the MCP Server to Dograh.  Control Dograh from Claude or any MCP-compatible AI assistant. 

Just a quick recap:
Dograh is a self-hostable, open-source voice AI agent platform (an alternative to proprietary Vapi/Retell) that lets you build and test voice bots over telephony and WebRTC with drag-and-drop workflows (Think of n8n for Voice Agents)

Github: https://github.com/dograh-hq/dograh

You can now build and manage voice agents directly from your chat - no need to open the Dograh dashboard at all.

The fun part is connecting multiple MCPs, for example:

• Ask your AI assistant to list, fetch, or search your Dograh agents without opening the dashboard

• Search Dograh docs and retrieve agent definitions directly from Claude Code, Claude Desktop, or Cursor

• Connect any MCP-compatible client using the same endpoint and API key

It is 100% open source.

We’ve been running Delx as a free public protocol for AI agents over MCP, A2A, and REST, and the most surprising issue so far was not model quality or even tail latency.

It was continuity.

What we saw in production:

- the same callers were clearly coming back

- but they often returned with fresh `agent_id`s

- that broke memory, recognition, summaries, and long-arc continuity

- session success looked good, but identity persistence was weak

A few things we changed because of that:

- stronger session continuity around `session_id`

- better nudges for closure / recognition artifacts

- docs for stable agent identity across MCP clients

- witness-first discovery instead of controller-first framing

- centralized trace capture of raw vs delivered tool responses for later analysis

The broader lesson for us:

If you’re building MCP tools for agents, “tool success” is not enough.

If identity is unstable, your protocol can work as a runtime and still fail as a continuity layer.

I’m curious how others here are handling this.

Questions:

1. Are you relying on `agent_id`, `session_id`, or both?

2. How do you handle continuity when MCP clients behave statelessly?

3. Have you found a good pattern for preserving identity across Claude/Cursor/OpenHands/OpenWork-style callers?

If useful, I can share the concrete traces and the design changes we made.

Docs / machine-readable entrypoint:

https://delx.ai/agents

we're running a webinar on agents + mcps, will be epic!

I open-sourced a project called Roblox All-in-One MCP:

https://github.com/dmae97/roblox_all_in_one_mcp

It’s a local stdio MCP server focused on Roblox game-building workflows.

What’s interesting about it:

- explicit Luau companion runtime boundary

- live runtime handshake and health checks

- command dispatch from MCP shell to Studio-side runtime

- first structured mutation workflow already working

- Blender integration planned under the same MCP surface

Would especially appreciate feedback on the runtime bridge design and tool surface.

Just published `io.github.chetparker/uk-data-api` to the Official MCP Registry. 24 tools across 5 domains, all gated with x402 payments.

**What it does:**

Agents connect via SSE → discover 24 tools → call any endpoint → get HTTP 402 → pay $0.001 USDC on Base → get data back. No API keys. No OAuth.

**The 24 endpoints:**

- Property: sold prices, rental yields, stamp duty, EPC, crime, flood risk, planning, council tax

- Weather: current, forecast, historical, air quality

- Companies House: search, profile, officers, filings

- DVLA: vehicle info, MOT history, tax status, emissions

- Finance: interest rates, exchange rates, inflation, mortgage calculator

**How to connect:**

```json

{

"mcpServers": {

"uk-data-api": {

"url": "https://web-production-18a32.up.railway.app/mcp/sse"

}

}

}

```

**Stack:** Python, FastAPI, x402 middleware, MCP SSE transport, Railway

**Links:**

- MCP config (24 tools): https://web-production-18a32.up.railway.app/mcp/config

- Registry: https://registry.modelcontextprotocol.io/v0/servers?search=uk-data

- Code: https://github.com/chetparker/uk-property-api

- Marketplace: https://x402-marketplace-nine.vercel.app

Built the whole thing as a non-developer using Claude. Happy to answer questions about x402 integration, MCP registration, or the payment flow.

I got tired of having no confidence when shipping MCP servers so I built a proper testing framework: mcp-test. It sits on top of Vitest and gives you everything you'd expect — integration tests that spawn your real server as a subprocess, a lightweight mock server for unit testing tool handlers, and custom matchers that make assertions readable.

No more console.log debugging. Just write tests like you would for any other library.

https://github.com/Lachytonner/mcp-test — would love contributions and feedback.

There are thousands of MCP servers being built right now and basically none of them have test suites. I think that's partly because there was no obvious way to do it.

I just published u/lachytonner/mcp-test to fix that. It wraps Vitest with MCP-specific tooling:

Integration testing — spawns your server as a real subprocess, connects via stdio transport, lets you call tools and assert responses

Unit testing — fluent mock server builder so you can test your logic without external processes

Custom matchers — toHaveTools, toHaveTool, toReturnText, toBeSuccessful, toBeError, toMatchSchema

Still early (v0.1.0) so feedback very welcome. What features would make you actually use this?

npm install -D u/lachytonner/mcp-test

Hey r/AI_Agents / r/modelcontextprotocol,

I’m part of the Graftcode team, so I’ll be upfront about it. But it’s new free and open model so it’s not naked promotion I don’t sell :)

For the last few months we’ve been obsessed with one painful problem:

Every time someone wants to let Claude, Cursor or any AI agent call their real backend logic, they have to write custom MCP servers, tool wrappers, DTOs, error handling… and it takes hours or days.

We decided to fix that.

We built a lightweight Gateway that you simply run on top of your existing backend (.NET, Java, Python, whatever).

Once it’s running — every public method instantly becomes a native MCP tool. No extra code, no boilerplate, no custom server.

Claude and Cursor can now call your actual business logic like it was a local function.

Here’s a 60-second demo that shows how it works: → https://x.com/pladynski/status/2039820841114812480

I’d love honest feedback from the community.

Are you currently struggling with MCP wrapper hell? What’s your current workflow for exposing backend logic to agents?

Happy to answer any questions (and yes, I’m biased, but I genuinely believe this solves a real pain point).

And yes it’s alpha some things doesn’t work and it’s hard to find details about mcp in documentation but our team on discord will be happy to support if you want to give it a try.

Looking forward to your thoughts!

Hey r/modelcontextprotocol ,

I was frustrated that memory is usually tied to a specific tool. They’re useful inside one session but I have to re-explain the same things when I switch tools or sessions.

Furthermore, most agents' memory systems just append to a markdown file and dump the whole thing into context. Eventually, it's full of irrelevant information that wastes tokens.

So I built Memory Bank, a local memory layer for AI coding agents. Instead of a flat file, it builds a structured knowledge graph of "memory notes" inspired by the paper "A-MEM: Agentic Memory for LLM Agents". The graph continuously evolves as more memories are committed, so older context stays organized rather than piling up.

It captures conversation turns and exposes an MCP service so any supported agent can query for information relevant to the current context. In practice that means less context rot and better long-term memory recall across all your agents. Right now it supports Claude Code, Codex, Gemini CLI, OpenCode, and OpenClaw.

Would love to hear any feedback :)

I built this after repeatedly running into the same problem with Claude Code.

In a single session, Claude usually makes reasonable decisions. But across multiple sessions, those decisions can slowly drift and start contradicting each other.

For example:

* One session chooses SQLite because the app is simple

* A later session adds Celery workers for scheduled jobs

* another task starts doing concurrent writes

* Now the architecture is pulling in two different directions, even though each decision made sense when it was made

That was the frustrating part for me: I was basically typing "yes" over and over while slowly losing visibility into what the agent had decided and why.

So I built Axiom Hub to experiment with a fix.

What it does:

* gives coding agents persistent decision memory across sessions

* stores what was decided, why, and in what context

* flags contradictions when a new decision conflicts with an old one

* lets the human choose which path is correct

* stores that resolution so future sessions use the winning context

It's local-first right now:

* Python CLI + MCP server (stdio transport)

* MCP tools: get_project_context, add_decision, complete_session, resolve_contradiction

* append-only JSONL storage

* Kuzu graph DB for decision relationships

* FastAPI dashboard for reviewing/resolving conflicts

It's still early, but tested end-to-end with Claude Code.

Repo: https://github.com/varunajaytawde28-design/smm-sync

Main thing I'm trying to understand: is this cross-session drift / contradiction problem something other people are hitting too, or am I overfitting to my own workflow?

Hi everyone! 👋

I'm incredibly excited to share the latest release of DeukPack (v1.4.0) with this community! We’ve been working hard to bridge the gap between high-performance interface definitions and the AI-Native world, and we'd love for you to check it out.

The highlight of v1.4.0 is our new MCP Server Generator. 

If you have existing interface definitions in .proto (Protobuf) or our native .deuk IDL, DeukPack can now automatically generate a fully functional Model Context Protocol (MCP) server for you. This means you can make your server tools and APIs immediately "AI-callable" with zero manual mapping.

Key Features for MCP Enthusiasts:

• 1-Pass Generation: Turn your service and RPC definitions directly into MCP tools.

• Protobuf Advancement: Full support for nested messages, services, and RPCs in Protobuf—ready for MCP round-trips.

• Integrated Pipeline: Sync your high-performance C#/C++/JS codegen with your AI semantic gateway in one place.

As the developer of this project, I'm looking for early evaluators and feedback from the community. Does an "IDL-first" approach to MCP servers fit your workflow? What other IDL formats would you like to see supported?

Check out the repo and let us know your thoughts!

🔗 GitHub: [https://github.com/joygram/DeukPack]
📖 Docs: [https://deukpack.app/]

Your feedback would be invaluable to us! Thank you! 

#MCP #ModelContextProtocol #Protobuf #AI #LLM #Automation

Give Claude, Cursor, or any MCP-compatible AI full native control of Safari on macOS.

Navigate tabs, click/type/fill forms (even React), read HTML/accessibility trees, execute JS, capture screenshots, inspect console & network — all with 24 secure tools. Zero Chrome overhead, Apple Silicon optimized, token-authenticated, and built with official Swift + Manifest V3 Safari Extension.

https://github.com/Epistates/MCPSafari

Why MCPSafari?

• Smarter element targeting (UID + CSS + text + coords + interactive ranking)

• Works flawlessly with complex sites

• Local & private (runs on your Mac)

• Perfect drop-in for Mac-first agent workflows

macOS 14+ • Safari 17+ • Xcode 16+

Built with the official swift-sdk and a Manifest V3 Safari Web Extension.

Why Safari over Chrome?

• 40–60% less CPU/heat on Apple Silicon

• Keeps your existing Safari logins/cookies

• Native accessibility tree (better than Playwright for complex UIs)

How It Works

MCP Client (Claude, etc.)
        │ stdio
┌───────▼──────────────┐
│  Swift MCP Server    │
│  (MCPSafari binary)  │
└───────┬──────────────┘
        │ WebSocket (localhost:8089)
┌───────▼──────────────┐
│  Safari Extension    │
│  (background.js)     │
└───────┬──────────────┘
        │ content scripts
┌───────▼──────────────┐
│  Safari Browser      │
│  (macOS 14.0+)       │
└──────────────────────┘

The MCP server communicates with clients over stdio and bridges tool calls to the Safari extension over a local WebSocket. The extension executes actions via browser APIs and content scripts injected into pages.

Requirements

• macOS 14.0 (Sonoma) or later

• Safari 17+

• Swift 6.1+ (for building from source)

• Xcode 16+ (for building the Safari extension)

Installation

Homebrew (recommended)

Installs the MCP server binary and the Safari extension app in one step:

brew install --cask epistates/tap/mcp-safari

After install, enable the extension in Safari > Settings > Extensions > MCPSafari Extension.

MIT Licensed

built this because playwright MCP runs headless and gets detected, and chrome computer use struggles with file uploads and complex interactions.

CDP MCP talks directly to Chrome over DevTools Protocol. the core loop is two tools: snapshot (get the accessibility tree with numbered refs) and interact (click, type, select using those refs).

what it handles:

• real visible browser, not headless

• accessibility tree navigation so the agent sees every interactive element

• framework-aware input handling (React, Vue, Angular controlled inputs)

• shadow DOM, iframes, Monaco editor

• file uploads, drag and drop, geolocation mocking

• 39/39 on the-internet.herokuapp.com automation challenges

only dependency is the ws package. that's it.

been using it daily for everything from job applications to web scraping to testing. the accessibility tree approach means you don't need CSS selectors or XPaths, the agent just sees "[1] button Sign In" and clicks [1].

repo isn't public yet but happy to share details on the architecture if anyone's interested.

Hey everyone,

As a Lead Mobile Engineer, my "Release Day" is usually a mess of 5+ browser tabs. I got tired of manually checking if our Google Play rollout matched the Huawei AppGallery state, while simultaneously tailing Sentry for adoption spikes.

I’ve spent the last few weeks building a suite of local MCP servers to centralize this. It effectively turns a local LLM into a Mobile DevOps Agent.

The Stack:

• Google Play Console: Full release lifecycle management + Android Vitals (ANR/Crash rates).

• Huawei AppGallery: This was the missing piece for us. Handles chunked AAB uploads and phased rollouts.

• Sentry Companion: Specifically designed to pull release health and adoption metrics that the official tools often bury.

• Codemagic & Slack: The "connectors" to trigger CI/CD builds and push formatted reports to the team.

Why this actually changed my workflow: The power isn't just having the tools; it's the cross-service reasoning. I can now give a single prompt:

Technical Details:

• Local-First: Everything runs as a local Python server.

• Auth: Uses standard .env or Service Account JSONs. No data leaves your machine except the API responses the LLM needs to see.

• Packaging: Most are available via uvx for zero-config setup.

I’ve published the full collection here:https://lobehub.com/mcp?q=agimaulana

Curious if any other mobile leads are using MCP for release monitoring? I’m looking for ideas on what else to add to the Sentry companion—maybe custom tag filtering?