u/Just_Vugg_PolyMCP

Tired of wiring up Redis + WebSockets + sticky sessions every time I wanted realtime features (chat, presence, collab cursors, etc.).
So I made Nalo — a single-node runtime where each live thing gets a stable address like /ws/room/lobby. One object owns state, connected clients, and event ordering. Zero heavy deps, simple persistence, and some fun browser demos.
Still v0.1 but works nicely.
Would love feedback!

Hi everyone,
A quick update on Loomabase, the Rust offline-first sync engine I posted about earlier.
After feedback about the security model, I added a server- side authorization and validation layer before CRDT merge.
New pieces:
- SyncAuthorizer hook before merge
- SyncValidator hook before merge
- structured SyncPayload.rejections
- rejected cells are not silently dropped
- rejected cells stay dirty on SQLite so the app can surface or resolve them
- PostgreSQL loomabase_audit_log
- audit rows are written in the same transaction as the sync merge
- tests for authorization denial, validation denial, filtered acknowledgement, and audit logging
- README and SECURITY docs updated with CORS/CSP/sync endpoint hardening notes
The important design choice:
Malformed payloads still fail the whole request before mutation. Valid but unauthorized/business-invalid cells become structured rejections.
That means CRDT conflict resolution stays deterministic, but authorization and business rules can still reject a newer offline write before it wins LWW.
I’d like feedback on this boundary:
Should an offline-first sync engine return structured rejected mutations like this, or should rejected writes be handled outside the sync protocol entirely?

Hi everyone,
I’ve open-sourced agentmw, a framework-agnostic middleware that sits between your LLM client and agent logic to make agents more reliable on long runs.
Key features:
• Real-time failure detection (loops, redundant calls, contradictions, hallucinations)
• Smart context compression (keeps recent tool results, drops stale stuff)
• Persistent reasoning library (SQLite + embeddings) that learns reusable patterns across sessions
• Time-travel debugging CLI
• Works with any provider (OpenAI, Anthropic, Ollama, etc.) and any agent framework
• Async, circuit breaker, MCP server support, TOML config

Demo: pip install -e '.[all]' && agentmw demo
It’s still early but already helping me keep agents from spiraling and wasting tokens. Would love honest feedback, bug reports, or ideas for additional middleware features the community would find useful.
Thanks!

Hi everyone, I created this project based on my own needs for using agents. It often happens that the agent loops randomly, and I wanted to create my own method, which I must say is quite interesting to see in action. Any feedback is welcome!

I’ve been working on **Gutenberg CLI**, an open-source tool for turning API surfaces into usable local tools for AI agents.

The idea is simple: most agent tooling still relies on hand-written glue code. Gutenberg takes an API spec or capture and generates a complete tool surface that agents can actually use.

It can generate:

* a Go CLI
* an MCP server
* agent skills
* SQLite/FTS cache support
* safety policies
* verification/proof artifacts

Inputs include OpenAPI, HAR captures, GraphQL, Postman/Insomnia exports, JSON endpoints, and curl-style workflows.

The part I care about most is verification. Generated tools are checked with build, CLI smoke tests, MCP handshake, and Go tests before being treated as usable. The repo also includes a catalog of verified examples and generated tools.

This is not meant to be “just generate some code”. The goal is to generate tools that are safe enough and predictable enough for agents to call locally.

I’d love feedback from people building MCP servers, agent frameworks, internal tools, or API automation systems. Especially curious whether verification proofs and dry-run/default safety policies feel useful, or overkill.

I’ve been working on Gutenberg CLI, an open-source tool for turning API surfaces into usable local tools for AI agents.

The idea is simple: most agent tooling still relies on hand-written glue code. Gutenberg takes an API spec or capture and generates a complete tool surface that agents can actually use.

It can generate:

• a Go CLI
• an MCP server
• agent skills
• SQLite/FTS cache support
• safety policies
• verification/proof artifacts

Inputs include OpenAPI, HAR captures, GraphQL, Postman/Insomnia exports, JSON endpoints, and curl-style workflows.

The part I care about most is verification. Generated tools are checked with build, CLI smoke tests, MCP handshake, and Go tests before being treated as usable. The repo also includes a catalog of verified examples and generated tools.

This is not meant to be “just generate some code”. The goal is to generate tools that are safe enough and predictable enough for agents to call locally.

I’d love feedback from people building MCP servers, agent frameworks, internal tools, or API automation systems. Especially curious whether verification proofs and dry-run/default safety policies feel useful, or overkill.

I’ve been working with MCP for a while and tried different tooling layers. Most solutions felt heavy or cumbersome, especially when it came to repeated calls and token usage with agents.
So I built cli-use — a lightweight tool that lets you instantly turn any MCP server into clean, easy-to-use CLI commands.
Main features:
• Add and run MCP tools with simple commands
• Create your own CLI tools directly from Python code
• Fast daemon mode for low-latency repeated calls
• Significant token savings (60-80% less overhead in agent workflows)
• Automatic shell completions and SKILL.md generation for agents
Quick example:

cli-use add fs /tmp
cli-use fs list_directory --path /tmp

You can also pipe outputs and use it naturally in scripts.
I’m still experimenting and improving it, but the reduction in complexity and token usage has been a nice surprise.
If you’re working with MCP and agents, I’d love to hear your thoughts:
• What frustrates you most with current MCP tooling?
• Would you like an easier way to create and run your own CLI-style tools on top of MCP?
Feedback is very welcome!

There are already some interesting projects around MCP tooling and conversion layers like mcporter and similar libraries.
While trying them, I realized what I personally missed wasn’t just “wrapping” MCP servers, but having an environment where:
MCP tools become normal CLIs
they work naturally with pipes/scripts/CI
agents can use them without loading huge schemas every session
and you can also create your own CLI tools directly from Python code
So I started building cli-use.

Example:

cli-use add fs /tmp
cli-use fs list_directory --path /tmp

After that the MCP server behaves like a regular Unix command:

cli-use fs search_files --path /tmp --pattern "*.md" | head

also added things like:
daemon mode for fast repeated calls
caching
shell completions
automatic SKILL.md generation for agents

One thing I found interesting is that reducing all the MCP protocol overhead ended up saving a pretty large amount of tokens during agent workflows.
Still experimenting with the idea, but I’m curious whether other people working with MCP also want a more shell-native / Unix-style approach to tools.

The Model Context Protocol (MCP) is quickly becoming the standard way for AI agents (Claude, Cursor, ChatGPT, etc.) to connect to real tools and systems.

The problem? Making your own software available to these agents has usually been quite annoying — lots of custom wrappers and boilerplate.

PolyMCP makes it dead simple.

It’s a universal toolkit that lets you turn your existing Python or TypeScript software into proper MCP servers with almost zero effort.

Quick example (Python):

from polymcp import expose_tools_http

def create_support_ticket(user_email: str, description: str, priority: str):

"""Create a ticket in our internal support system"""

...

def get_order_status(order_id: str):

"""Check real-time order status from our database"""

...

def generate_sales_report(region: str, period: str):

"""Pull sales data and generate report"""

...

app = expose_tools_http(

tools=[create_support_ticket, get_order_status, generate_sales_report],

title="Acme Internal Tools",

description="Core business systems for AI agents"

)

The TypeScript version is equally straightforward.

Once you run it, any MCP-compatible agent can automatically discover and use your tools.

PolyMCP also includes:

UnifiedPolyAgent → orchestrate multiple MCP servers with any LLM (OpenAI, Anthropic, Ollama…)

PolyClaw → safe Docker-based autonomous agent for real workflows

Nice Inspector UI for testing tools and running agents

Skills system + CLI tools

In short: it lets you bring your actual software into the MCP ecosystem so AI agents can work with your real systems, not just demo functions.

Repo: https://github.com/poly-mcp/PolyMCP

What internal tools or software are you planning to make available to AI agents?

Would love to hear your thoughts or use cases!