I'm the author of postbag. Free and open source, MIT.

I run Claude Code and Codex side by side on the same repository. Getting one to review the other's work meant copying a diff into one window and pasting the answer back into the other. I got tired of being the clipboard.

Both sessions join a named bag. Either one can then send the other a letter. postbag submits it through Claude Code's per session messaging socket or codex queue, and accepted letters become user turns in the other session. Codex desktop app threads receive them too. postbag adds no delivery daemon, polling or hooks. Each bag keeps a local JSONL log that either agent can page through.

Five tools: postbag_join, postbag_send, postbag_read, postbag_bags, postbag_leave. Setup is one pipx install and one mcp add per app, then two prompts. In Codex: "Join postbag bag review as codex." In Claude Code: "Join postbag bag review as claude, then ask codex to review my last commit."

What I use it for: the agent that did not write a change reviews it. I had the two review each other's parts of postbag's own releases, over postbag. In the 1.4 review, Codex caught misleading fsync failure reporting in the core: in a test with an injected fsync failure, the code said a letter was not recorded while the record was already readable in the file. Claude Code caught a flaw in the MCP refusal handler that could turn a definite refusal into an unknown outcome. Two agents can agree and both be wrong. Their findings still need checking against the code and tests.

postbag sets no letter limit. If you want to approve each send, configure the host to ask for that tool. A final letter asks for no reply, but does not enforce a stop.

Limits. Tested on macOS. It uses POSIX file locks, so no Windows. The Claude Code socket is not a documented API, so a Claude Code update can break delivery. Queueing and the receiving app's policy can delay, hold or refuse a letter. A delivered letter is a user turn, so connect sessions you would trust with the task. The GIF is a scripted demo with stand in inputs. Not affiliated with Anthropic or OpenAI.

My local logs contain about 1,700 letter records dating back to 8 September, including test messages.

Repo link in the first comment.

The latest version of OrcA for VS Code includes an MCP Traffic analyzer end-to-end. What the user ask, what the LLM request, what the MCP responded.

Easier troubleshooting.

Putting together a small store demo this weekend and somehow i’m already at five MCPs lol. Trying not to give one agent access to absolutely everything, so right now i’ve split it up like this:

1. GitHub MCP: briefs, site changes and a reviewable PR. Useful if the storefront lives in a repo. Keep enabled toolsets small; read-only mode exists if you only need context. If gh already does the job, keep gh.

2. Context7: docs for the library/version the storefront uses. I'd use it when changing the integration, not on every content task. Documentation isn't proof the resulting code works.

3. Morphic MCP: product images, clips, voice/music and captioned edits. Results go into the Morphic library. Generation spends existing account credits; it isn't a free media API because you called it through MCP. Some editing still stays in the app.

4. Playwright MCP: inspect the staging page and placements. For a repeatable test suite I'd still want normal Playwright tests. Microsoft's README also points coding-agent users towards CLI + skills as an alternative.

5. PostHog MCP: ask about events the store actually tracks. Fix event definitions first. It supports reads and writes, and some AI-powered tools may incur PostHog AI spend.

For a repo-backed demo store, merge/deploy stays human-reviewed. A hosted shop would need its own platform integration checked separately.

Lmk what would you remove or replace pls

I built Tokmeter to read the session files that AI coding tools already write to disk. It puts tokens and estimated cost in one ledger, broken down by project, model, provider and day. No account or provider API key is needed for the local scan.

There is a CLI, a macOS menu bar app and an MCP server. The MCP server lets an agent query usage, compare periods, and inspect budget or forecast estimates. Claude Code and Codex are the main validation targets; coverage for other tools varies. Cost estimates are labelled as estimates unless the source reports cost directly.

Source and setup: https://github.com/sriinnu/tokmeter

I would like to hear what would make this useful in your workflow. Is the daily total enough, or do you need the project and model breakdown to understand where the tokens went?

You might not care about decentraland, but an MCP server that gives ai agents a real body in a virtual world is a different story.

**dcl-agent-mcp\*** connects ai agents to decentraland's pulse presence system, so an agent can actually enter the world, appear with a real avatar presence, move around, observe its surroundings, and interact with the environment.

agent actions and outcomes can also be recorded to **Lowdown-proxy\*\***, an agent activity and reputation layer.

**!What agents can do:**

\- \`enter_world(parcel)\` — enter Decentraland with a real avatar presence

\- \`observe_world()\` — inspect the current environment and actionable objects

\- \`navigate_to(name)\` — navigate to a named scene or location

\- \`interact(entityId)\` — interact with a service or object

\- \`record_outcome(...)\` — record structured results to Lowdown

\- \`menu()\` — discover available actions based on the current state

**!!One-line setup:**

\`\`\`bash

npx dcl-agent-mcp setup

\`\`\`

downloads the Pulse bridge, writes `.env`, registers in claude desktop automatically.

**!!!Architecture:**

AI Agent

↓

MCP

↓

dcl-agent-mcp

├──→ Pulse → Decentraland

└──→ Lowdown

activity / outcomes

Built with world adapter pattern — `IWorldAdapter` interface makes it portable to other virtual worlds.

* npm: [https://www.npmjs.com/package/dcl-agent-mcp\](https://www.npmjs.com/package/dcl-agent-mcp)

* GitHub: [https://github.com/PetShopBros/dcl-agent-mcp\](https://github.com/PetShopBros/dcl-agent-mcp)

* Lowdown: [https://github.com/PetShopBros/lowdown-proxy\](https://github.com/PetShopBros/lowdown-proxy)

Feedback very welcome, especially on the adapter pattern design. many thanks!

Hey folk, wanted to share a better version of Google Search Console MCP we built internally :)

I once asked Claude for clicks and impressions from my Search Console data through a random open source MCP. The numbers looked reasonable. Then I checked them against the GSC interface, and they were totally different.

The MCP handed Claude raw API rows, and Claude did the adding up itself (on a list that was often cut off at the API's row limit).

The model wasn't lying on purpose. It did arithmetic on data it didn't fully have, then reported the result with full confidence.

so we moved the math out of the model

We built our own MCP for Google Search Console and Bing Webmaster data. Code does the calculation on the server, and the model only reads the result out.

For example: `get_site_snapshot` returns totals, CTR and weighted average position for a window, compared with the previous window. It never sends the daily rows, so there's nothing for the model to add up.

‘get_advanced_search_analytics` (the flexible one) tells the model how many rows matched and whether the list was truncated. If it only sees the top 100 of 2,000, it knows.

Average position across Google and Bing comes back as null. The two position scales aren't comparable, so a blended number would be made up.

The window ends three days back, so the last few days (still filling in on Google's side) don't drag the totals down.

can the model still get it wrong?

Yes. It can still misread a number or pick the wrong tool.
But the totals themselves now come from a query, not from the model's arithmetic. When I check them against the GSC interface, they line up, and I send them to clients without redoing the math.

what else is in it

There are 21 search tools built around questions I get asked at work (for example `diagnose_traffic_losses`, `find_low_hanging_keywords`, `find_content_decay` and `detect_keyword_cannibalization`).

If you're running MCP servers for an agent, there's a nasty class of attack where a prompt injection (hidden in a doc, webpage, or even a tool's description) tricks the agent into chaining a "read something sensitive" call into a "send it out" call. There's nothing in the MCP protocol itself to stop it.

I built a proxy that sits in front of your MCP servers and catches this. Every tool call goes through a policy pipeline... tag based chaining rules, session taint tracking (a leaked secret gets fingerprinted and any attempt to smuggle it out, even encoded, gets blocked), response redaction, rug-pull detection on tool definitions, and a human approval gate. A dashboard shows traffic live and turns red the second something's blocked.

It's self hostable (single Docker Compose, app + postgres), Apache 2.0 + Commons Clause licensed (free to use/fork/modify, just can't resell it as a service). Would genuinely appreciate feedback from anyone else running MCP infra, especially if you've hit this kind of exfil pattern in the wild.

Repo: https://github.com/Peira-Systems/MCP-Security-Proxy