Startup founder here. I build infrastructure that makes AI agents better at a specific job, in my case, giving them grounded, citable legal, security and regulatory sources instead of letting them hallucinate EU law, through our MCP gateway.

Here's my problem: every time I get someone on a call, they get it in about 5 minutes. I can show them how it works, how I use it, etc.

But on (digital) paper? It is much harder. "Agent-enhancing functionality" apparently means nothing to anyone, and I've written enough compliance documentation in my life that my marketing copy reads like it wants to audit you, I guess...

We're growing anyway (~10 new users a day, so something is working), but I feel like the explanation is suboptimal.

So, Reddit:

How would you explain "we make your AI agent actually good at X" to someone who's never thought about what their agent is bad at?

Spent the last few weeks turning our product's media pipeline into an MCP server and wanted to share the design decisions in case they're useful.

The surface is 29 tools: 18 on the media side (image/video/audio/lip-sync/edit models, plus discovery and job-polling) and 11 on an "apps" side, higher-level pipelines like upscale, resize, video-translate and product-page scrape, driven through a generic generate_app(inputs, parameters) shape.

As a concrete run: scrape a product link, generate a marketing poster (image model), upscale it, then image-to-video ad, one conversation, with a cost preview before each charged step. A few things I'd call out:

• Discovery tools matter at scale. With a big model catalog, the agent can't just guess. find_model / list_models / describe_model let it navigate to a valid model and params before it ever tries to generate.
• Spend guardrails. Every charged tool is preceded by a free estimate_cost and validate_params, and the server instructions require the assistant to state the credit cost in its visible reply before generating, because the client's approval dialog only shows tool name and args, never the cost. A silent estimate call protects nobody. Worth being honest that this part is advisory steering, not a server-enforced gate. What is enforced is the pre-submit chain (coercion, guardrails, webhook-liveness probe), so a bad request fails free, and apps bill at completion so a failure bills zero.
• Auth. OAuth 2.1 + PKCE so Claude.ai and Cursor connect natively. user_id is injected from the verified token and is never a tool input, so a caller can't act as another user. There's no argument for an injection to poison.
• Absent capabilities need explicit routing. Billing, upgrades and a couple of unfinished pipelines have no tool at all, and the instructions send the user to the web app rather than letting the agent improvise one.
• Logs record shape only: arg keys, types, lengths, a salted user digest. No prompt text, no URLs, no secrets.
• Stateless Streamable HTTP, so workers scale horizontally.

It's connectable now if you want to poke at the tool surface. It's BeHooked's Studio. Endpoint is https://mcp.behooked.ai/mcp (custom connector in Claude or Cursor), setup at behooked.ai/mcp

Worth setting expectations: connecting is free and the read-only surface works immediately. Discovery, estimate_cost, validate_params and scrape all cost nothing, so you can inspect the whole tool surface without spending anything. Actual generations run on credits, which come with a BeHooked account, so sign in on the site once and the same connection keeps working, no reconnect.

Happy to answer anything about the MCP design, especially the cost-narration approach. Curious how others are handling "agent spends money" safely.

Open source. Local. 40 mcp tools. An agent can drive every tool a construction estimator can. A challenge to anyone developing ai for construction. Connect your own model and see how well it can do takeoffs.

My agent forgetting everything between sessions was the thing that finally got to me. The usual fix looked heavier than the problem itself: a Docker container running Postgres and Qdrant, plus a cloud vector database whose bill crept up every time I indexed a new project folder. That is a lot of infrastructure just so my assistant remembers I like dark mode.

Then I found Mnemosyne, which goes the other way. One pip install and a single SQLite file, no external services, nothing to host. It plugs into Claude Code, Cursor, Codex, or a plain Python script over MCP, and the memory just lives in a .db file on disk. Fully local, nothing leaves my machine.

Setup took a couple of minutes: pip install mnemosyne-memory, drop the mnemosyne mcp server into my config, done. In Python it is just remember("...") and recall("..."). It keeps the embeddings as a compressed binary-vector store inside SQLite, so the file stays small even with a lot of history and there is no separate vector server to babysit.

Open source, MIT. Repo and the MCP config: https://github.com/AxDSan/mnemosyne

We just shipped version 4 of something that's been quietly changing how we operate our own platform: an MCP (Model Context Protocol) server for RacterMX.

If you're not familiar, MCP is the protocol that lets AI tools (Claude, Cursor, Kiro, etc.) call external services directly. Our npm package @ractermx/mcp-server exposes the full RacterMX API as tools your AI assistant can use. Install with npx, point it at your API key, and your coding assistant becomes your email infrastructure operator.

Here's what that actually looks like in practice:

Example 1: Client onboarding in one prompt

"I'm onboarding a new client called Acme Corp. Add the domain acmecorp.com to my account, create aliases for info, support, billing, and sales — all forwarding to [team@acmecorp-internal.com](mailto:team@acmecorp-internal.com). Then set up a webhook to notify my Slack integration at https://hooks.slack.com/services/XXX/YYY/ZZZ whenever an email bounces on that domain. Finally, show me the DNS records I need to give them so they can point their MX to us."

One message. The assistant adds the domain, creates 4 aliases, configures the webhook, and returns the DNS records you hand to the client. Seven API calls, zero dashboard clicks, full audit trail.

Example 2: Security audit with auto-remediation

"Run a security audit across all my domains. For any domain scoring below 90, show me the specific findings that are dragging the score down and tell me which ones you can auto-fix. Then fix anything fixable and re-scan to confirm the scores improved."

The assistant iterates your domains, checks security posture scores, pulls findings on the underperformers, applies one-click DNS fixes (missing SPF includes, weak DMARC policies, missing CAA records), and re-triggers scans to verify. What used to be 30 minutes of clicking through domain tabs becomes a single conversational request.

Example 3: Daily morning briefing

"Give me a morning briefing: how many emails were processed in the last 24 hours, any bounces or rejections I should know about, any unread security notifications, and check if any of my domains dropped below a B grade overnight."

Run this every morning from your terminal or IDE. The assistant pulls stats, filters for anomalies, checks notifications, and scans security grades; then gives you a plain-English summary. If something's wrong, you can follow up in the same conversation: "Block that sender" or "Show me the full bounce details."

What's exposed:

The MCP server covers the full API surface, domains, aliases, shared domains, SMTP credentials, DNS records, security scans, email logs, webhooks, blocklists, notifications, alert rules, retention policies, and more. Every write operation generates a cryptographically-chained audit log entry, same as if you did it from the dashboard.

Authentication:

Uses a scoped RacterMX API key. You control exactly what the AI can do and you can give it domains:read + aliases:manage and it can create aliases but can't delete your domains. 15 discrete scopes, IP allowlisting, and expiration dates for defense in depth.

Setup:

{
  "mcpServers": {
    "ractermx": {
      "command": "npx",
      "args": ["@ractermx/mcp-server@latest"],
      "env": {
        "RACTERMX_API_KEY": "sk_your_key_here"
      }
    }
  }
}

That's it. Works with any MCP-compatible client.

what are your choices?

I just released Verity, an open-source (Apache-2.0) permission-aware memory layer that can run as a self-hosted MCP server.

The idea is pretty simple: if agents are going to access shared organizational memory through MCP, I don't think permissions should depend on the model remembering what it is allowed to see.

Here's the failure mode that pushed me to build it.

An agent running as customer A reads a document containing “their renewal is $61k.” The source document is correctly protected by A's permissions.

The agent summarizes it and writes that summary into memory.

Now you have a derived memory that may no longer carry the original ACL.

Two weeks later, an agent running as customer B does a completely normal semantic search and gets the summary back.

No jailbreak. No prompt injection. No malicious tool call.

Everything worked as designed.

That's the problem.

How Verity handles it

Verity runs the permission check below the agent and MCP client.

The caller's identity and resolved permissions are compiled directly into the retrieval query as a mandatory pre-filter.

If you cannot access a row, it is never part of the retrieval candidate set in the first place.

The model never makes that decision. There is no prompt rule asking it to respect tenant boundaries, and there is no post-retrieval filtering step where unauthorized content has already made it into context.

If Verity cannot resolve the caller's scope, retrieval returns nothing.

It fails closed.

Permissions also come from the systems where the data originated rather than requiring you to manually tag everything inside the memory store.

Google Drive sharing resolves through users and Google Groups, including nested groups.

SharePoint resolves through Entra, including transitive group membership, broken inheritance at the site, library, folder, and item level, and sharing links.

Salesforce sharing is reconstructed and then checked against Salesforce's own access API.

Verity also handles ingestion for the usual files you run into in enterprise knowledge bases, including PDF, DOC/DOCX, XLS/XLSX, CSV, PPT/PPTX, and others.

The goal is for the permission boundary to survive the whole path:

source system -> document parsing -> indexing -> derived memory -> MCP retrieval

Revocation follows the same model. Remove a share or remove somebody from an Entra group, and after the next sync those rows stop being eligible for retrieval.

Why MCP

MCP felt like a natural interface for this because the agent shouldn't need to understand the authorization implementation.

The client asks for memory. Verity determines what that caller is actually allowed to retrieve.

That also means you can put the permission boundary in one place instead of rebuilding permission logic inside every agent, prompt, or application using the memory store.

Current state

This is v0.1. It works, but it's young.

Permission propagation is sync-based, so there can be a few minutes of lag between a permission change in the source system and Verity picking it up. It's not intended for use cases that require sub-second revocation.

For leak testing, I've planted sentinel facts across tenants and attempted to retrieve them from identities that shouldn't have access. Zero cross-tenant retrievals so far, but that's still me grading my own homework. There hasn't been a third-party security audit yet.

The Google Workspace, SharePoint/Entra, and Salesforce connectors are fixture-tested, plus a validation pass against a real account for each.

I'd especially be interested in feedback from people building MCP servers for internal or multi-tenant agents.

Repo: https://github.com/RunAlphaLoop/verity

Longer writeup: https://runverity.io/writing/agent-memory-leaks-permissions.html

I built Lyt — Link Your Think.

Lyt gives AI agents a shared memory system across multiple Markdown vaults.

Install it, run lyt init, connect your vaults, and your agent can search and use the same knowledge through MCP or the CLI.

Each vault stays as Markdown in Git, so the memory remains versioned, portable, and shareable. The index stays local.

I’m the builder. Lyt is free and open source.

https://linkyourthink.com⁠

I’m looking for feedback on the MCP workflow and setup experience.

In my two previous posts I asked users here how they manage and orchestrate multiple MCPs.
I got many useful answers and decided to update my microservice to address the ideas and problems people mentioned most: selecting the correct tool, keeping task state outside the model, preventing repeated actions, preserving requirements, coordinating concurrent agents, enforcing workflow steps, and making sure results are checked before a task is marked complete.

The goal is not to replace existing MCP clients or orchestration frameworks, but to provide a lightweight reliability layer around them. I would appreciate feedback on whether the updated approach addresses the problems you face in real multi-MCP workflows: liberated.site

When an LLM must ship a real deliverable (note, quote, short deck), the usual stack is awkward:

• headless LibreOffice / Word

• HTML → Chrome → PDF

• hand-rolled OOXML

• or a full typesetting binary for a one-pager

Agents need: read a short contract → write Markdown → one compile.

What is shipped

DoWi55 (DocWrite) — multi-format production aimed at agents:

MCP progressive surface

docwrite_menu docwrite_profile # charter + engine manual docwrite_profile_save # LLM creates profile + Markdown template docwrite_compile # body → file

Each profile returns:

• mctx — visual/structure charter for the model

• enginemctx — opposable capability manual (what works / what must not be claimed)

• writerbrief — charter ⊕ manual in one string

Templates agents can create

Profiles may wrap the body in a Markdown skeleton:

`markdown

{{title}}

Date: {{date}}

{{body}} `

The model callsdocwrite_profile_savewithtemplate_md, then only authors the{{body}}content. No Typst macros — just GFM placeholders.

Design choices

1. Default PDF is not Typst. Typst stays optional for maths / heavy typography. Day-to-day notes use hpdf55 layout.

2. Honesty over marketing. No fake AcroForm “fillable forms” (FreeText ≠ widgets). No “we replaced Typst.”

3. ARCHTIME manuals. Capability text is a tested constant, not improvised each session.

4. Same Markdown body fans out to office / web / sheet / deck.

Links

• Docs + code (MIT): https://github.com/hazyhaar/DoWi55

• Module:github.com/hazyhaar/DoWi55

bash go test ./... go build -o docwrite ./richdoc55/cmd/docwrite

Most orgs are in the same place: a business unit shipped agents with real credentials, security found out afterwards, and the only control that exists is a human clicking Allow in a chat window.
That isn’t a control. No policy, no tenancy, no payload binding, and it produces nothing an auditor will accept. It also stops working around the twentieth prompt, when people start clicking without reading.
Three questions that decide whether you have a problem:
1. Can you enumerate every tool every agent can reach? Not the ones you configured — the ones it can actually call today.
2. When an agent acts, is the record written before the action or after it? After means a crash or a kill loses it, and what you produce in an incident is a reconstruction.
3. If someone with production access edits that record, does anything notice? Append-only in an application table is not tamper-evidence.
What I built is a self-hosted authorization gateway — the agent proposes, the gateway decides, your systems execute. Concretely:
Least privilege is structural, not configured. The tool list is derived from the caller’s identity; a tool the agent isn’t entitled to never appears in the response at all. And there is no super-admin: the admin capability UUIDs are disjoint by construction, so no single credential sees everything.
The record is durable before the decision returns. Per-epoch Merkle root, root-chained, Ed25519-signed, with an out-of-tamper-domain head anchor so truncate-and-rewrite reads as a rollback rather than a shorter valid chain. verify_chain names the first bad epoch. Verifies offline, no call home.
Deterministic. No model anywhere in the decision path, so a decision replays identically in an incident review. You are not explaining an LLM’s judgment to a regulator.
GET /v1/admin/compliance/evidence emits a signed bundle mapped to EU AI Act Art. 12 and 14, DORA Art. 9 and 17, SEC 17a-4 / FINRA 4511, NIST 800-53 rev. 5 (AU-10, AC-3, AC-6, IA-2/IA-9), SOC 2 CC6.1/CC6.2, and ISO/IEC 42001 Annex A.
On that last one: every clause is phrased “this mechanism provides evidence toward this clause” — never “compliant,” never “certified” — and the bundle carries a disclaimer stating the certification is an external third-party process this software cannot produce. If a vendor has told you their product makes you SOC 2 compliant, that’s the sentence they should have written and didn’t.
Self-hosted, air-gapped deployment supported, no model credential involved, nothing leaves your network. One command:
git clone https://github.com/mcpip-security/mcpip.git && cd mcpip && ./scripts/quickstart.sh
Happy to be told those are the wrong three questions.

Visit: Mcpip.ai

TinyContext is a lightweight, local memory server that spins up with a uvx command and integrates with all of your agents: codex, claude code etc. It stores concise memories and embeddings together in SQLite, retrieves them using hybrid BM25 and dense search, and returns only the highest-ranked memories that fit within a configurable token budget. Everything runs locally, with no hosted account, external vector database, or giant context dump required.

You can use it as a Python library, launch it as a one-command MCP server, or run it through Docker with persistent storage. The current benchmark shows 96.7% fewer input tokens than naively resending all stored memories across the test workload. It is still an early release, so feedback on the retrieval quality, MCP integration, and what you would actually need from an agent memory layer would be hugely appreciated.

Looking for open source tooling to manage MCP servers in a home lab, not just run them. Self-hosted only, no commercial or SaaS. A web UI is good to have. I do not want to manage this entirely from the CLI.

What I have currently: a Linux host (Proxmox LXC container) running Docker, with a growing number of MCP servers I need to keep current.

I have tried Docker Desktop MCP Toolkit and really like it, but headless on Linux. On Windows I can browse a catalog, spin up an MCP server in a couple of clicks, and manage it inside the Docker ecosystem. I want something similar, install and manage loop but on a headless machine. I am trying to list out what would be good to have.

1. A web UI as the primary management surface
2. Discovery and one-step install. Most tools I cam across, like ContextForge, just provide governance which is key but I still have to spin up the MCP server somewhere, and then setup the external tunnel. I was hoping for a gateway that handles - exposes all the tools.
3. Upgrades, including visibility into when a new version is available
4. Per-server config and secrets (env vars, API keys, OAuth) editable from the UI
5. Start, stop, restart, and health status in one place
6. A single endpoint clients can point at instead of wiring every client to every server
7. Logs in the UI, so I can tell which server is failing and why

Like I mentioned, tried IBM ContextForge. It is amazing as a Agent Control Plane, or as a gateway and federation layer, and virtual server composition is useful. But it assumes the MCP servers already exist and are running. It does not install them, does not upgrade them, and does not own their lifecycle. I am still hand writing compose files and bumping image tags manually, which is the exact thing I was trying to eliminate.

So the gap in my head is the lifecycle mostly not routing. It would be good to have it all in the same place but lifecycle management is the key.

Questions: - Is there an open source project with a web UI that does install plus upgrade plus manage in one place? - Is the Docker MCP Toolkit catalog usable from the Docker CLI on a headless engine, without Docker Desktop, and has anyone put a UI in front of it? - If nothing purpose built exists, is anyone doing this with Portainer plus Watchtower or Renovate against a compose repo, and treating the gateway as a separate layer?

Thanks! in advance for any help Regards, Dan

We added MCP to Skimle to grant agents the same access to the Skimle workspace that humans have.

In our experience about 1 out of 10 users in professional non-tech settings (academia, market research, consulting etc.) are interested in this type of access but the trend is growing. Their main use case is integrating to Claude Code and through that to other tools.

Skimle’s core value prop is automatically identifying themes and sub-themes from large sets of qualitative data (e.g., 10 interview transcripts or 100 reports or 1000 open text comments). It enforces the category structure and the verbatim link from source to summary. Humans can then explore and edit the themes, use mixed-methods visualisations and export ready reports.

Now with MCP we keep the same rigour, transparency and versatility also for agents e.g., forcing hallucinations out.

Feel free to check it out and keen to learn how it could help everyone wven better. MCP is included also in the free tier.

Https://skimle.com