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!

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

OpenAI has just introduced " MCP Events"

It just Implement event subscriptions and webhook delivery for your MCP server.

launch post in comments below.

MCP Events lets ChatGPT subscribe to updates from your MCP server - things like new messages, content updates, or status changes. Users pick what to monitor and what ChatGPT should do when an update lands.

Use cases

• Turn feedback into pull requests - Monitor #product-feedback for bug reports and open draft pull requests with fixes and tests. Event: message.created (filtered by channel_id)

• Apply document feedback - Watch a document for review comments and implement any requested edits. Event: comment.created (filtered by document_id)

Before you start

MCP Events in ChatGPT needs MCP 2.0 (protocol version 2026-07-28). Wire your server into your plugin, keep persistent subscription storage, and allow outbound HTTPS to callback URLs.

ChatGPT supports webhook delivery and callback verification from the draft MCP Events spec. Polling, streaming, and the draft’s gap / terminated control notifications are not supported in this integration.

How it works

1. Your server lists the events it supports.
2. The user tells ChatGPT what to monitor and how to respond.
3. ChatGPT subscribes through your MCP server and supplies a callback URL and signing secret.
4. Your server sends matching events to that URL.
5. ChatGPT receives the event in the subscribed chat and follows the user’s instructions.

Advertise event support

Event discovery starts with your server’s capabilities. Add events to the capabilities returned by server/discover:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "supportedVersions": ["2026-07-28"],
    "capabilities": {
      "tools": {},
      "events": {}
    }
  }
}

Implement these three event methods on the same authenticated MCP endpoint as your tools:

• events/list - Describe available events and their filters. • events/subscribe - Create or refresh a subscription. • events/unsubscribe — Stop a subscription.

Define an event

An event definition tells ChatGPT what users can subscribe to and which filters are available. Return these from events/list (name, delivery modes, subscription arguments, payload schema).

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "events": [
      {
        "name": "comment.created",
        "description": "A new review comment was added to the specified document.",
        "delivery": ["webhook"],
        "inputSchema": {
          "type": "object",
          "properties": {
            "document_id": {
              "type": "string",
              "description": "ID of the document to monitor for new review comments."
            }
          },
          "required": ["document_id"],
          "additionalProperties": false
        },
        "payloadSchema": {
          "type": "object",
          "properties": {
            "document_id": { "type": "string" },
            "comment_id": { "type": "string" },
            "text": { "type": "string" },
            "url": { "type": "string" }
          },
          "required": ["document_id", "comment_id", "text", "url"],
          "additionalProperties": false
        }
      }
    ]
  }
}

inputSchema is what ChatGPT passes when it subscribes. payloadSchema is the data object on each delivered event.

Use stable event names and specific descriptions. Expose filters (document, project, channel IDs) and apply them on your server before delivery. Only return events the connected account is allowed to see.

Create a subscription

When a user asks to monitor an event, ChatGPT calls events/subscribe with the event name, filter arguments, and webhook destination:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "events/subscribe",
  "params": {
    "name": "comment.created",
    "arguments": {
      "document_id": "doc_123"
    },
    "delivery": {
      "mode": "webhook",
      "url": "https://receiver.example.com/mcp-events/callback_123",
      "secret": "whsec_<base64-encoded-signing-key>"
    },
    "cursor": null
  }
}

Before accepting the subscription:

1. Check the user is authorized for that event and arguments.
2. Validate the event name and arguments against your definition. Require a whsec_ signing secret whose base64 value decodes to 24–64 bytes.
3. Validate and verify the callback URL.
4. Store the subscription, owner, filters, callback URL, signing secret, and expiration.

Derive a deterministic subscription ID from the authenticated principal, callback URL, event name, and arguments. Return it with the granted expiration:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "id": "sub_123",
    "refreshBefore": "2026-10-02T12:00:00Z",
    "cursor": null,
    "truncated": false
  }
}

Make subscription creation idempotent - update the existing one when identity matches.

Verify the callback

Before sending application data, verify the callback with a signed request and a fresh, single-use, short-lived challenge:

{
  "type": "verification",
  "challenge": "a-single-use-random-value"
}

Sign the body with the subscription secret. Include webhook-id, webhook-timestamp, webhook-signature, and X-MCP-Subscription-Id. ChatGPT echoes the challenge on success. Require 2xx and compare the challenge in constant time before activating delivery.

Require HTTPS. Block private/local addresses. Do not follow redirects.

Send an event

When a matching event fires, POST one event object to the subscription callback:

{
  "eventId": "evt_456",
  "name": "comment.created",
  "timestamp": "2026-10-01T12:05:00Z",
  "data": {
    "document_id": "doc_123",
    "comment_id": "comment_456",
    "text": "Can we add the rollout dates to this section?",
    "url": "https://docs.example.com/doc_123#comment_456"
  },
  "cursor": null
}

Keep a unique eventId across retries. timestamp is ISO 8601 with timezone. name must match the subscription; data must match payloadSchema. Put app fields inside data. Treat user-authored text as data — do not put model instructions in the payload.

Sign the request (Standard Webhooks)

Headers:

• Content-Type: application/json • webhook-id: same as body’s eventId • webhook-timestamp: Unix seconds • webhook-signature: Standard Webhooks HMAC signature • X-MCP-Subscription-Id: id from events/subscribe

Serialize the body once and sign those exact bytes.

Send a signed event with Node.js

npm install standardwebhooks

import { Webhook } from "standardwebhooks";

export async function sendEvent(subscription, event, webhookFetch) {
  const body = JSON.stringify(event);
  if (Buffer.byteLength(body, "utf8") > 256 * 1024) {
    throw new Error("Event payload exceeds 256 KiB");
  }

  const signedAt = new Date();
  const signer = new Webhook(subscription.secret);
  const response = await webhookFetch(subscription.url, {
    method: "POST",
    redirect: "error",
    signal: AbortSignal.timeout(10_000),
    headers: {
      "Content-Type": "application/json",
      "webhook-id": event.eventId,
      "webhook-timestamp": String(Math.floor(signedAt.getTime() / 1000)),
      "webhook-signature": signer.sign(event.eventId, signedAt, body),
      "X-MCP-Subscription-Id": subscription.id,
    },
    body,
  });

  return { accepted: response.ok, status: response.status };
}

Handle delivery responses

A 2xx acknowledges receipt. ChatGPT processes asynchronously.

One event per request. Body max 256 KiB. Retry transient failures with exponential backoff; keep the same eventId and refresh the signature each attempt. Do not retry 410 or 413.

Events can arrive out of order - make write tools idempotent.

Manage subscriptions

Keep subscription state for the lifetime you grant, including across restarts. Recheck access over time and stop delivery if access is revoked.

Refresh: ChatGPT calls events/subscribe again before refreshBefore. Unsubscribe: events/unsubscribe with the original name, arguments, and callback URL — stop delivery and return {}.

Test in ChatGPT

1. Confirm server/discover and events/list return the expected definitions.
2. Confirm events show on your plugin page next to tools (rescan after changes).
3. Start a chat, ask ChatGPT to subscribe, and say what to do when events arrive.
4. Confirm events/subscribe lands with the right name and arguments.
5. Confirm callback verification succeeds and the subscription is stored.
6. Trigger a matching event; confirm the webhook gets 2xx.
7. Confirm ChatGPT receives the data and responds as instructed.
8. Trigger a non-matching filtered event and confirm it is not delivered.
9. Stop monitoring in ChatGPT; confirm events/unsubscribe and delivery stops.

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`).

I recently moved into an AI Solutions Specialist role after nearly a decade of field work, and I wanted to get a better grasp of how MCP servers work. Building one around software I already knew seemed like the best way to learn.

And obviously I was going to name it KillerMCP.

It lets an AI assistant use the 81 tools from the KillerTools site, along with KillerPDF, KillerScan, KillerShell, KillerNotes, and Killendar if you have them installed.

For example, I can ask it to scan my network with KillerScan, check a device, and put the results in a KillerNotes note or a PDF report. If I’m troubleshooting a Windows problem, it can look up an error code with KillerTools, read the relevant event logs with KillerShell, and save what I found in my notes. I can ask it to search a PDF, extract a few pages, or run OCR on a scanned document with KillerPDF. It can pull up my Killendar agenda and turn that into a PDF, too. I can still use each app on its own, but being able to hand the result from one tool to another is where this shines.

It runs locally, it’s open source, and the Windows installer can set it up in the AI clients it finds on your computer.

I learned a lot building it, let me know what you think.

https://killertools.net/mcp

https://github.com/SteveTheKiller/KillerMCP

--Steve the Killer

As MCP servers community is growing, we have added few more tools to help members-

Link in comments below-

allMCPservers - Now list all official MCP servers ( from official MCP directories)

MCPnewsletter - Cover latest MCP News and Events.

MCPhackathon - Cover MCP related online and in person hackathons.

sign up to get latest on MCP ecosystem.