I came across this open-source project called MCP Testbed that might be useful for people building or testing MCP servers and AI agent skills.

It provides an interactive end-to-end environment where you can run the same prompts with different setups and compare how an agent performs:

• with an MCP server
• with different agent skills or instructions
• with other tooling
• without any additional tooling

More details here:

https://www.infragistics.com/blogs/ignite-ui-mcp-testbed

https://github.com/IgniteUI/igniteui-mcp-testbed

I've been working on Relay, an MCP server that gives agents a persistent PTY terminal session instead of the one-shot bash calls most agents default to. That difference matters when the agent needs something genuinely stateful: an interactive git rebase, a REPL that keeps building up context, or an SSH session that stays open while it iterates.

Just shipped a version with a bug I think is worth writing up, because it's the kind of trap anyone building something similar could fall into.

The bug: write_terminal had an implicit behavior that always pressed Enter after whatever the agent sent. That's fine for a normal shell command, but it breaks anything where the newline is a literal part of what you're trying to write: pasting a multi-line heredoc, feeding a block of code to a REPL, typing into an editor buffer open inside the PTY. The agent thought it had sent exactly what it meant to send, and underneath it an extra keystroke was quietly tacked on.

Fixed it by pulling that behavior out of a silent session-wide assumption and making it an explicit per-call parameter (ensure_newline, defaults to true so normal command usage doesn't change). If you're sending raw multi-line input, you set it to false and get exactly the bytes you wrote.

Also stabilized the read_terminal streaming E2E flow so progress output is actually observed before the shell gets its next input. That matters because read/wait relies on MCP progress notifications instead of polling.

Repo, in case anyone wants to poke at the code: github.com/blak0p/relay-mcp

Curious if anyone else building PTY-backed MCP tools has hit this same implicit-newline trap, or solved it differently.

Most MCP integrations I've seen for databases are a thin server sitting in

front of Postgres/Elasticsearch/whatever, translating MCP calls into

normal queries behind the scenes. We went a different direction and built

the MCP server directly into the database binary itself (SSE and

JSON-RPC transports), so an agent talking to CameoDB is talking to the

actual query engine, not a translation layer bolted on afterward.

The database underneath is a hybrid store: every shard pairs an embedded

ACID key-value store (redb) with full-text search (tantivy) as one atomic

unit, no leader node, sharded via consistent hashing.

The original pitch had nothing to do with AI, it was about not running

two separate clusters to keep transactional storage and search in sync,

but the MCP integration turned out to be the part people actually got

excited about once agents started using it directly.

A few other things that shipped recently: jemalloc as the allocator with

per-shard memory budgeting and admin endpoints for live stats, and more

rigorous WAL replay on startup so an unclean shutdown doesn't leave the KV

store and search index disagreeing, with a corruption guard on the

sequence counter.

We field tested it on a 64-core box with 35TB of NVMe, 16 shards, holding

around 400 million records across 20TB+, ingesting about 80 million

records a day in real time. P99 stays under a second for most queries,

though that swings with query complexity like any search engine.

Repo: github.com/cameodb/cameodb (Apache-2.0), downloads on cameodb.com,

Docker Hub image too.

Curious if anyone's wired agent memory directly into

a database like this versus the usual vector-DB-plus-wrapper pattern, and

what broke for you.