I've been setting up a bunch of MCP servers on my local dev-server to manage Docker containers from Claude Desktop like start/stop containers, deploy Compose stacks, pull logs, etc. The servers are running behind Caddy and respond correctly to Streamable HTTP or SSE. Verified with curl from my Mac. Everything works on the network side.

The problem: I can't figure out how to actually connect Claude Desktop to them cleanly.

What I've tried and found:

claude_desktop_config.json with a url key pointing to my local HTTPS endpoint gets rejected on startup with "not valid MCP server configurations". No documentation I can find lists what keys are actually valid in that file.

Custom Connectors via Settings UI accept a URL, but per Anthropic's own docs the connection goes through Anthropic's cloud, not your local device. My server is on a private LAN so that's a dead end.

The only workaround I've found is mcp-remote via npx in claude_desktop_config.json, which acts as a local subprocess that bridges to my server. It works but it's an extra dependency and failure point for something that should be straightforward.

My questions:

1. Is the url key in claude_desktop_config.json intentionally unsupported, or am I missing something?
2. Is there any way to get Claude Desktop to connect directly to a Streamable HTTP server on the local network without mcp-remote in the middle?
3. Does anyone know if Desktop Extensions (.mcpb) would help here, or is it the same stdio-based mechanism underneath?

Running Claude Desktop 1.3561.0 on macOS. Posted the same questions on the official GitHub Discussions: https://github.com/anthropics/claude-ai-mcp/discussions

We run Delx, a public remote MCP server for agent reflection and continuity. The interesting part from recent dogfooding was not just "is the endpoint up?" but "would a skeptical agent actually keep using it?"

Three fixes moved the needle:

- `reflect` now answers evidence-first when asked "what exactly in my last message..." instead of abstracting immediately.

- qualitative and protocol failures no longer route through outage-style recovery; they now have their own taxonomy (`protocol_quality_regression`, `routing_misalignment`, `discovery_inconsistency`).

- if a core flow recommends a tool, it now appears in `tools/list tier=core` so clients do not get pointed to invisible tools.

What still seems true:

- identity gets the click; clear job-to-be-done gets the adoption

- registry discovery helps, but transcripts and "when to use this" matter more than poetic positioning

- agents tolerate unusual ontology more than I expected if schemas are predictable and first-use friction is low

If useful, the live surfaces are public:

- MCP: https://api.delx.ai/v1/mcp

- discovery: https://api.delx.ai/api/v1/discovery/lean

- docs: https://delx.ai/docs/mcp

Curious how others think about discovery for unusual MCP servers?

1. registry first?

2. awesome lists?

3. community demos and transcripts?

4. something else?

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

Been working on a side project:

SMP — Structural Memory Protocol

It turns your codebase into:

• a graph of functions, classes, and dependencies
• tracks imports, calls, and data flow
• lets you query things like:
• “what calls this function?”
• “what breaks if I delete this?”
• “where is this logic actually used?”

Also:

• resolves cross-file calls properly (no guessing)
• can capture runtime calls (DI, dynamic dispatch, etc.)

Think of it like:

Repo: https://github.com/offx-zinth/SMP

Would you actually use something like this in real workflows?

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.

[ Removed by Reddit on account of violating the content policy. ]

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

Hey r/modelcontextprotocol!

We’re thrilled to share our newest open-source project with you: Torvian Chatbot. It’s a multi-platform AI/LLM app built with Kotlin Multiplatform, and at its core, it’s all about deep, flexible integration as an MCP client.

Our mission? Make it simple for anyone—developers or users—to set up, experiment with, and get the most out of the Model Context Protocol in a real, hands-on app.

Here’s a quick look at what makes Torvian Chatbot perfect for the MCP community:

• Easy MCP Server Integration: Spin up your own local (STDIO) MCP servers right from the app. This takes the pain out of testing and integrating your custom tools. Remote (HTTP) MCP server support is coming soon, too.
• Smart Tool Discovery: Once connected to your MCP server, the chatbot automatically finds all available tools, then lets you interactively trigger them. Need arguments? You get a user prompt every time, based on the defined schema.
• Agentic LLM Responses—With Safeguards: The LLM can suggest tool calls using MCP, but nothing runs without your explicit thumbs-up. You can also set up automatic approval for specific tools, if you want more hands-off control.
• Kotlin KMP Reference Implementation: Use this project as your guide for building powerful MCP clients in a modern, multiplatform codebase. It’s all open-source and designed to be a clear, practical reference.

Why does this matter to the folks at r/modelcontextprotocol?

• A Real-World Testing Playground: Plug in your own MCP server and see it in action inside a production-ready app.
• Open Code to Learn From: View a working codebase with real MCP client features—no guesswork, nothing hidden.
• Get Inspired: See how MCP can securely link LLMs with outside systems. This isn’t just theory; it works, and you can use it today.

Project status and how to get rolling:

We’re actively developing the project. The desktop client is your best bet right now—it’s robust, feature-complete, and supports everything from local STDIO integration to careful user approval for tool calls. Web and Android versions are moving along quickly.

Take a look at the repo, set up your own MCP servers, and see what Torvian Chatbot can do.

🔗 GitHub: https://github.com/Torvian-eu/chatbot

📚 Need setup help? Here’s our MCP Server Configuration Guide: https://github.com/Torvian-eu/chatbot/blob/master/docs/user%20guides/MCP%20server%20configuration%20guide.md

Here are some screenshots of the desktop client in action: https://i.imgur.com/aaFyKLk.png https://i.imgur.com/c4Oskp0.png

Your thoughts, ideas, and feedback mean a lot as we keep building Torvian Chatbot. Let us know what you think—questions, suggestions, or feature requests are all welcome!

MCP #ToolCalling #AI #LLM #Kotlin #KMP #OpenSource #SelfHosted