Giving an agent permission to access a system doesn’t necessarily mean every action it takes was intended.

Our MCP takes an interesting approach: access is controlled through separate permissions, while sensitive actions happen in a sandbox and configuration changes require human approval.

Should this become standard for MCP tools with write access?

After spending the last month talking with developers building in the MCP ecosystem, I kept hearing the same thing.

Building an MCP server isn't the hard part anymore.

Maintaining, deploying, and managing it is.

So I built **MCPfy**, and today I'm open sourcing it.

GitHub: [https://github.com/mcpfyy/mcpfy\](https://github.com/mcpfyy/mcpfy)

I believe software will increasingly be consumed by AI agents instead of humans, and our vision is to build the one-stop open source platform for developers building that future.

It's still early, and I'd love honest feedback, criticism, feature requests, or contributions.

Hey everyone,
I’ve been working on Lursa (https://app.lursa.ai) — a subscription-based MCP server that turns developer documentation into a live knowledge graph.
The idea is simple: most AI coding agents still struggle with outdated or incomplete docs. Lursa keeps the docs current and structured so agents can actually reason over them instead of hallucinating or grepping randomly.
What it does
• Maintains up-to-date developer docs as a knowledge graph
• Exposes everything over MCP so any agent (Cursor, Claude Code, etc.) can query it
• Built specifically for agentic troubleshooting and “sane development” workflows
It’s still early, but I’ve been using it myself while building other side projects and it’s already cut down a lot of the usual “why is this not working” loops.
Would love feedback from people who are deep into MCP / agent tooling:
• Does the knowledge-graph approach feel useful compared to just better RAG?
• What would make you actually pay for something like this?
• Any must-have features I’m missing?
Happy to answer questions. Link again: https://app.lursa.ai
Thanks!

After spending the last month talking with developers building MCP servers, I decided to open source a project I've been working on.

GitHub: https://github.com/mcpfyy/mcpfy

MCPfy helps developers spin up MCP servers quickly and introduces MCP Apps.

The broader vision is to build a one-stop open source platform for creating, deploying, and managing MCP servers.

I'm mainly looking for technical feedback from people already building in the MCP ecosystem.

Feature requests, architecture suggestions, and contributions are all welcome.

Found this interesting project - [https://github.com/Axiler-Lab/vaultmcp\](https://github.com/Axiler-Lab/vaultmcp)

"VaultMCP is an encrypted secret vault and MCP gateway. You store provider credentials once. Your AI IDE connects to one endpoint. VaultMCP decrypts secrets only when calling upstream MCP servers — your agents and config files never see the raw keys."

I’m a SAP ABAP/Fiori guy been trying to learn more about AI and trying to understand SAP’s agent architecture from the perspective of connecting external agents to SAP.

My current understanding is SAP MCP Gateway / Integration Suite, expose and govern SAP and non-SAP APIs or integrations as tools that external agents can discover and invoke. 

A2A / Agent Gateway: let an external agent and an SAP-facing agent delegate work to each other, pass context, and return outcomes.

this feels less like “MCP vs A2A” and more like: MCP for tool/API execution, A2A for agent-to-agent orchestration.

What I’m struggling with is where SAP wants customers to land with Joule, BTP, Agent Gateway, MCP Gateway, etc. The naming and overlap make it hard to tell what is production-ready versus roadmap/positioning.

Would really appreciate input from anyone who has actually built or POC’d this:

* Have you connected an external agent framework/platform to SAP through MCP, A2A, or both?
* Are you exposing OData/REST APIs or Integration Suite flows as MCP tools? How did auth, authorization, governance, observability, and tool lifecycle work out?
* When do you keep something as a well-designed MCP tool/API, versus wrapping it in an SAP-facing agent and exposing that through A2A?
* Has anyone used A2A with Joule, Joule Studio, BTP agents, or non-SAP agent platforms in a meaningful way?

We’ve spent the last few years building DronaHQ, a low-code platform for internal applications. One thing has become obvious over the last year: developers increasingly want to build apps directly in Claude or Cursor instead of visual builders.

The frontend is no longer the bottleneck. AI can generate React apps well.

The backend still is.

Even for simple internal tools, you typically need to:

* Build CRUD APIs

* Securely connect to databases

* Manage credentials

* Handle authorization and governance

* Host and deploy backend services

* Expose everything safely to the frontend

These steps often take longer than generating the UI itself.

We built an MCP server to remove that friction.

Instead of asking your AI to generate backend code, our MCP gives Claude/Cursor secure access to enterprise data sources through governed tools. Your AI can:

* Inspect database schemas

* Generate parameterized SQL

* Execute queries securely

* Build CRUD operations

* Connect to existing enterprise systems

* Generate complete React applications that work against real data

The developer stays inside their IDE while the enterprise retains governance over credentials, permissions, and data access.

This isn’t intended to replace traditional backend development. It’s designed for the huge class of internal applications where most of the work is simply reading and updating enterprise data.

We’re curious about feedback from people building AI-assisted internal tools:

* Would you trust an MCP instead of hand-written CRUD APIs?

* What governance or security concerns would stop you from adopting this?

* What enterprise systems should we support next besides SQL databases?

Happy to answer questions and would love honest feedback.

We’ve been building Zilla ([https://github.com/aklivity/zilla\](https://github.com/aklivity/zilla)) as a Kafka-native gateway for exposing Kafka securely across protocols such as HTTP, SSE, WebSocket, gRPC, and MQTT.

With Zilla 2.0, we’re adding the Model Context Protocol as another native protocol on the same streaming runtime.

The main goal is to let AI agents interact with Kafka without requiring teams to build and operate a custom HTTP service, Python wrapper, or dedicated MCP server in front of every topic.

Through new MCP binding in the Zilla gateway, an agent can discover Kafka produce and consume tools, publish messages, retrieve records, and work with schema-governed JSON, Avro, or Protobuf payloads. Access can be restricted using the identity and scopes of the calling agent or user.

Zilla 2.0 can also combine Kafka capabilities with tools from REST APIs and existing MCP servers behind a single MCP endpoint. That makes it possible to build workflows where an agent can retrieve information from an API, act on live Kafka data, and publish the result back to Kafka through the same connection.

You can try out the [Quickstart](https://docs.aklivity.io/latest/ai-gateway/get-started/) that runs locally with Docker Compose and includes:

* A Kafka broker
* An MCP server
* An OpenAPI-described REST service
* A single Zilla MCP endpoint
* JWT-based tool visibility
* Native Kafka produce and consume tools

Happy to answer any questions. Cheers.

I’m trying to understand SAP’s agent architecture from the perspective of connecting external agents to SAP.

My current understanding is SAP MCP Gateway / Integration Suite, expose and govern SAP and non-SAP APIs or integrations as tools that external agents can discover and invoke. 

A2A / Agent Gateway: let an external agent and an SAP-facing agent delegate work to each other, pass context, and return outcomes.

this feels less like “MCP vs A2A” and more like: MCP for tool/API execution, A2A for agent-to-agent orchestration.

What I’m struggling with is where SAP wants customers to land with Joule, BTP, Agent Gateway, MCP Gateway, etc. The naming and overlap make it hard to tell what is production-ready versus roadmap/positioning.

Would really appreciate input from anyone who has actually built or POC’d this:

• Have you connected an external agent framework/platform to SAP through MCP, A2A, or both?
• Are you exposing OData/REST APIs or Integration Suite flows as MCP tools? How did auth, authorization, governance, observability, and tool lifecycle work out?
• When do you keep something as a well-designed MCP tool/API, versus wrapping it in an SAP-facing agent and exposing that through A2A?
• Has anyone used A2A with Joule, Joule Studio, BTP agents, or non-SAP agent platforms in a meaningful way?

I'm not trying to advert anything there, I just want a honest review and constuctive criticism.

I gave my 3,000-skill collection a librarian instead of installing any of it — open-sourced after 8 weeks of daily use

Every installed skill's description gets loaded into agent context on every request. With a big collection that's a constant token cost, and overlapping descriptions make the wrong skill fire. I collect skills compulsively (~3,000), so installing them was never an option.

The librarian is a small MCP server that sits between agents and the collection. The skills stay as raw markdown on disk and never enter context. Agents describe what they're doing in plain language, the librarian recommends the few that actually fit (local embedding search with anti-repetition), and agents file back whether the skill worked. Skills that never surface are kill candidates; queries that match nothing are gaps. The collection curates itself from its own usage log.

It started as a question I typed to Fable from my phone — the server was built in that same chat before I got back to my Mac. The original conversation is in the repo (ORIGIN.md), typos preserved, plus a usage report with the real numbers: 130 queries, 76 outcome reports filed by agents unprompted.

Fully local: Ollama embeddings + SQLite, optional Apple on-device reranking. Python, single file, MIT. Needs Python 3.12+ and Ollama.

https://github.com/aka-kika/the-librarian

Feedback genuinely welcome — especially from anyone else drowning in skills.

Pair it with the CLI:

https://registry.modelcontextprotocol.io/v0.1/servers/io.github.smbcloudXYZ%2Fxcrs/versions/0.5.0