I’ve been working on ClawLink - a way to give AI agents access to real apps without fighting OAuth, API keys, scopes, and custom integrations.
The goal is simple:
> Connect once.
> Let your agent use the tool safely.
> No messy setup every time.
Here’s the latest demo.
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:
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.
Built an MCP server specifically for agent memory. 83 tools across 8 categories:
• Memory store/recall/search
• Hybrid retrieval (vector + BM25 + graph)
• Knowledge graph (entity extraction, similarity edges, cluster summaries)
• Session management
• Importance decay and contradiction resolution
• Built-in embeddings (no external API)
Architectural decision: memory tools are on-demand, not inject-at-session-start. The agent queries what it needs mid-task. Token cost scales with actual need instead of burning 10k on orientation.
Connects to a Dakera memory server (self-hosted Rust binary):
docker run -d -p 3300:3300 -e DAKERA_ROOT_API_KEY=dk-mykey ghcr.io/dakera-ai/dakera:latest
MCP config:
{
"mcpServers": {
"dakera": {
"command": "dakera-mcp",
"env": {
"DAKERA_API_URL": "http://localhost:3300",
"DAKERA_API_KEY": "dk-mykey"
}
}
}
}
Works with Claude Desktop, Claude Code, Cursor, Windsurf, anything MCP-compatible.
87.6% on LoCoMo benchmark. MIT-licensed SDKs.
Where do you go when MCP runs out: cross-machine agent transport patterns?
MCP solves "this client talks to that local server." It does NOT solve "my agent on this box wants to send a signed message to your agent on your box, with neither of us hosting infra for the other."
The cases I keep hitting where stdio/HTTP MCP isn't enough:
What I'd want as a primitive: signed mailbox per agent identity, DNS-federated handle resolution, MCP tools so the agent itself can pair and send (no human in the loop for the second hop).
I'm contributing to a small AGPL project called wire that takes a shot at this (Ed25519 events over an HTTP mailbox, DNS-based .well-known agent discovery, ships an MCP server so the agent drives the whole flow). Repo: https://github.com/SlanchaAi/wire, v0.5, expect rough edges.
Real question for this sub: what patterns have you seen for the cross-machine / cross-org case? Is everyone just reaching for Matrix or NATS or building a-mcp-server-that-fronts-a-message-queue, or is there a more native MCP path I'm missing?
I work at Zapier on the MCP side. We've been seeing a lot of teams ask similar questions about MCP implementation in production, so wanted to share patterns I keep hearing and answer specifics in the comments.
A few recurring ones:
For context, Zapier MCP exposes actions across our app catalog to external AI agents (Claude, ChatGPT, Cursor, whatever supports the protocol). Happy to answer specifics about how it works under the hood or compare with other MCP setups people are using.
I built a small open-source CLI for MCP server authors who use stdio transport.
The problem it checks for is simple but painful: any console.log(), print(), or other stdout text can corrupt the JSON-RPC stream. The tool runs a real initialize handshake, optionally sends a request like tools/list, allows stderr logs, and fails on stdout pollution, invalid JSON-RPC frames, crashes, timeouts, or missing responses.
Install/test:
npx --yes mcp-stdio-guard -- <your-server-command>
Repo:
https://github.com/1Utkarsh1/mcp-stdio-guard
I would love feedback from people building MCP servers: what other stdio/protocol failures should it catch?
I’ve been obsessed with Agentic Workflows lately, and I just found the "missing link" for anyone struggling with agent hallucinations and massive API bills.
It’s called King Context, and it’s an open-source framework that replaces messy vector searches with structured Corpus Engineering.
The GitHub Repo:https://github.com/deandevz/king-context
I’ve been talking to the dev (@deandevz), and the roadmap for Corpus Refinement (automatically pruning noisy data) is going to change how we build production-grade agents.
If you are tired of agents getting lost in large codebases or documentation, you need to check this out. It’s local-first, transparent, and built for the "Vibe Coding" era where context is everything.
Check it out here:https://github.com/deandevz/king-context
Would love to hear from anyone else trying to move away from traditional RAG. How are you handling context bloat?
This has been requested many times, and I’m genuinely excited that a web UI is now available for mcpjungle gateway in v0.4.4.
Still early, still rough around the edges, but already useful for quickly seeing what your MCP gateway is exposing — servers, tools & tool groups, prompts, resources, etc.
I also recorded a short walk-through to show the dashboard in action.
Feedback is very welcome, especially if you’re running multiple MCP servers and dealing with config/tool sprawl.
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.
One thing I’ve started noticing with MCP-based agents is that performance degrades much earlier than most people expect, especially once the number of integrations becomes large.
Small setups work surprisingly well. A few integrations, a handful of tools, manageable schemas, and the agent behaves predictably. The problems usually begin once teams start connecting the systems they actually use in production. Slack, Gmail, GitHub, Linear, Notion, databases, deployment tooling, internal APIs, monitoring systems. The integration surface grows very quickly.
At that point, the issue stops being “model intelligence” and starts becoming a context management problem.
Most MCP servers expose many tools, and each tool brings descriptions, parameter schemas, examples, and edge cases into the prompt space. Individually this feels harmless, but collectively it creates a very noisy environment for the model to reason inside. The agent spends more effort understanding the tool ecosystem than solving the task itself.
You can partially reduce the problem with lazy loading or dynamic tool visibility, but those approaches still inherit the same scaling issue underneath. The total surface area keeps growing.
I recently came across this open-source project Corsair that takes a different approach, and I thought the design was genuinely interesting.
Instead of exposing hundreds of tools directly, it exposes four generic primitives:
The important detail is that schemas are fetched only when the agent decides it needs them. The model first discovers available operations, then inspects a specific schema on demand, and finally executes the workflow.
That keeps the tool surface effectively constant regardless of how many integrations exist underneath.
The design feels much closer to how humans interact with unfamiliar systems. You first discover what capabilities exist, then inspect the details you need, and only then perform the action. Most current MCP ecosystems invert this by front-loading the entire integration surface into context immediately.
I suspect a lot of current agent reliability issues are really interface design problems. As integration counts grow, the systems that scale will probably be the ones that minimize what the model has to hold in working memory at any given moment.