DEV Community: Qaiser Mehmood

Building MCP servers for Claude & Cursor? Here's a starting point.

Qaiser Mehmood — Sun, 26 Jul 2026 06:21:09 +0000

Most MCP servers I see in the wild start as a quick script and stay that way — no validation, no structured logging, no tests, and a deploy story that means shipping node_modules around.

I got tired of rebuilding the same scaffolding every time a client project needed a Model Context Protocol server, so I open-sourced the template I now start every one from: 🚀 mcp-server-template

It's a production-ready TypeScript/Node.js foundation for building MCP servers that connect AI agents like Claude Desktop and Cursor to your tools, data, and workflows.

𝗚𝗲𝘁𝘁𝗶𝗻𝗴 𝘀𝘁𝗮𝗿𝘁𝗲𝗱 𝘁𝗮𝗸𝗲𝘀 𝗳𝗼𝘂𝗿 𝗰𝗼𝗺𝗺𝗮𝗻𝗱𝘀:

git clone https://github.com/qmmughal/mcp-server-template.git
cd mcp-server-template && npm install
cp .env.example .env
npm run dev

That spins up a working server in watch mode. npm test runs the Vitest suite, npm run build bundles everything into a single dist/index.js with esbuild — no node_modules to deploy.

𝗪𝗵𝗮𝘁 𝗮 𝘁𝗼𝗼𝗹 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗹𝗼𝗼𝗸𝘀 𝗹𝗶𝗸𝗲:

Every tool gets a Zod schema, a definition, and a handler — so a malformed AI payload gets rejected with a clean error instead of crashing your process:

const schema = z.object({
  text: z.string().describe("The text to process"),
  repeat: z.number().int().min(1).max(10).optional()
});

export async function handleExampleTool(args: unknown, service: ExampleService) {
  return withErrorHandling("process_text", async () => {
    const { text, repeat } = validateArgs(schema, args);
    const result = await service.processText(text, repeat);
    return { content: [{ type: "text", text: result }] };
  });
}

𝗘𝘅𝘁𝗲𝗻𝗱𝗶𝗻𝗴 𝗶𝘁 𝗳𝗼𝗿 𝘆𝗼𝘂𝗿 𝗼𝘄𝗻 𝘁𝗼𝗼𝗹𝘀:

Drop a new file in src/tools/ following the same schema → definition → handler shape
Register it in src/tools/index.ts — add your definition to the tools list and a case to the switch statement that routes CallToolRequest to your handler
Put your real logic in src/services/ so the protocol layer stays thin and your business logic stays unit-testable in isolation
Resources (data the AI can read) and Prompts (reusable templates) follow the exact same pattern in their own folders — copy the example, rename, adjust the schema

Structured pino logging routes safely to stderr throughout, so it never corrupts the MCP stdio transport regardless of what you add.

When you're ready to ship, tag a release and a GitHub Actions workflow publishes to both npm and the MCP Registry automatically:

git tag v1.0.0 && git push origin v1.0.0

The goal is simple — spend your time on the logic that makes your MCP server useful, not on re-solving logging, validation, and bundling for the fifth time.

It's MIT licensed and live on GitHub now. If you're building agentic AI integrations, I'd love feedback or a star:

🔗 github.com/qmmughal/mcp-server-template

MCP #ModelContextProtocol #AgenticAI #TypeScript #OpenSource #AIEngineering #ClaudeAI

AgentWire: Wireshark for the Agentic Stack

Qaiser Mehmood — Sun, 26 Jul 2026 06:07:46 +0000

Every team building with AI agents eventually hits the same wall: the moment a request leaves your application and enters the world of LLMs, tool calls, and MCP servers, it disappears into a black box. You can see the final answer, but not the packet trail that produced it — which model actually answered, how many tokens it burned, how long each hop took, or whether something in that chain quietly leaked a secret or got hijacked by a prompt injection.

That's the gap AgentWire is built to close.

What it is

AgentWire is an open-source observability, security, and cost-analytics layer for AI agents, LLMs, and MCP servers. The project's own tagline sums up the ambition well: OpenTelemetry + Wireshark + Cloudflare for AI agents. In practice, that means one system doing three jobs that today live in three different toolchains:

Observability — trace every hop between a user, an agent, an LLM, and any MCP servers it calls, the way OpenTelemetry does for microservices.
Security — inspect that same traffic for prompt injection, secret leakage, and malicious patterns, the way an edge gateway inspects HTTP traffic.
Cost intelligence — attribute a dollar figure to every packet, broken down by agent, model, and provider, so "why did our OpenAI bill triple" has an actual answer.

It's built on ASP.NET Core, licensed Apache 2.0, and designed from the start as an event-driven system rather than a simple logging wrapper — because agentic traffic doesn't arrive as tidy request/response pairs, it arrives as a high-throughput stream of packets that need to be ingested, enriched, and queried without blocking the agent itself.

Where the project stands today

AgentWire is honest about being an active MVP rather than a finished platform, and the README draws a clear line between what's real today and what's on the roadmap:

Available now:

Trace ingestion via POST /v1/traces
Packet inspection via GET /v1/packets
Cost rollups via GET /v1/analytics/costs
An optional Next.js dashboard scaffold

Planned:

A YARP-based gateway with collector microservices
ClickHouse as the analytical store for packet-scale data
A prompt injection scanner and a full replay engine
A multi-tenant, enterprise-ready edition

That's a deliberately narrow MVP: get a local ingestion API and cost endpoints working on SQLite first, prove the data model, then grow into the full event-driven architecture.

Examples: getting a trace flowing

1. Clone and run the API

With the .NET 10 SDK installed:

git clone https://github.com/qmmughal/AgentWire.git
cd AgentWire
dotnet run --project src/AgentWire.Presentation

The API comes up on localhost:5102.

2. Send a trace

Every time an agent talks to an LLM, you send AgentWire a packet describing that exchange — which agent, which provider and model, the prompt, the response, and the token/latency numbers:

curl -X POST http://localhost:5102/v1/traces \
  -H "Content-Type: application/json" \
  -d '{
    "traceId": "demo-001",
    "agentId": "support-bot",
    "modelProvider": "openai",
    "modelName": "gpt-4o-mini",
    "systemPrompt": "You are a helpful assistant.",
    "userPrompt": "Hello",
    "llmResponse": "Hi there!",
    "promptTokens": 12,
    "completionTokens": 8,
    "latencyMs": 220
  }'

Ingestion is asynchronous by design, so the call returns immediately with an acknowledgement while the packet is enriched and stored in the background:

{
  "status": "accepted",
  "traceId": "demo-001"
}

3. Inspect the packet

Pull the packet back to see what AgentWire recorded and enriched:

curl http://localhost:5102/v1/packets

[
  {
    "traceId": "demo-001",
    "packetId": "pk_9f2c1a",
    "agentId": "support-bot",
    "modelProvider": "openai",
    "modelName": "gpt-4o-mini",
    "promptTokens": 12,
    "completionTokens": 8,
    "latencyMs": 220,
    "cost": 0.0000042,
    "timestamp": "2026-07-26T10:15:03Z"
  }
]

(Field names and exact values will track whatever the schema looks like by the time you run it — this is illustrative of the shape, not a frozen contract.)

4. Roll it up into cost

The same packet feeds the cost-analytics endpoint, so you can see spend sliced by agent, model, or provider instead of digging through a provider dashboard:

curl http://localhost:5102/v1/analytics/costs

{
  "totalCost": 0.0000042,
  "byAgent": {
    "support-bot": 0.0000042
  },
  "byModel": {
    "gpt-4o-mini": 0.0000042
  }
}

5. Optional — dashboard and local infra

If you'd rather look at a UI than curl JSON:

cd src/Client/dashboard
npm install
npm run dev

That opens a Next.js dashboard on localhost:3000 against the API above.

And if you want to start poking at the pieces the full architecture will eventually run on — Postgres, Redis, RabbitMQ, ClickHouse — they're all wired into a Compose file:

docker compose -f deploy/docker-compose.yml up -d

App container builds aren't wired up yet, so dotnet run stays the way to run the API itself for now.

Where it's headed architecturally

The target architecture is a proper event-driven pipeline: a YARP-based API gateway takes in traffic from agents, SDKs, and OpenTelemetry exporters; a stateless Traffic Collector validates and pushes packets onto a message broker (RabbitMQ/MassTransit) to absorb spikes; a Traffic Analyzer consumes that queue, enriches the data, and batch-writes into storage; and a parallel Security Scanner and Cost Engine run over the same stream without adding latency to the agent's actual request path.

Storage is deliberately polyglot — PostgreSQL for relational metadata like organizations, projects, and agents, with row-level security for tenant isolation; ClickHouse for the high-volume, time-series packet data that needs fast aggregation; and Redis for configuration and rate-limit caching. SDKs for .NET, Python, and JavaScript wrap standard OpenTelemetry SDKs, and a plugin system lets providers (OpenAI, Anthropic) and MCP servers plug in their own cost calculations and security rules.

The business model, up front

The MVP — ingestion, packets, and cost rollups — stays free and open source; that's a deliberate bet that the same organic trust a project like the maintainer's own ckeditor5-blazor built up over years is worth more long-term than gating the basics. The parts of the roadmap that are genuinely expensive to run well — the ClickHouse analytics store, the security scanner, multi-tenant SaaS operations — are earmarked for an eventual hosted, managed tier. There's no beta or waitlist yet; that's a future announcement, not a present pitch.

Why this matters

Most of the AI observability tooling available today was built for a world where an LLM call was the whole story. Agentic systems break that assumption — a single user request can now fan out into a dozen tool calls, several LLM round-trips, and one or more MCP server hops, each with its own latency, cost, and attack surface. AgentWire is a bet that this traffic deserves the same category of tooling that network engineers have had for decades: something you can point at the wire, watch the packets go by, and trust to tell you the truth about what actually happened.

It's early — alpha, by the project's own description — but the direction is clear, and the repository is open for anyone who wants to try it, file an issue, or contribute against the sketched-out MVP epics.

Repo: github.com/qmmughal/AgentWire
License: Apache 2.0

SQL RecycleBin: An Undo Button for SQL Server

Qaiser Mehmood — Sun, 26 Jul 2026 06:06:43 +0000

Every DBA has lived this moment: someone runs a DELETE without a WHERE clause on a production table, and the room goes quiet.

Oracle has had an answer for this for years — Flashback Query. SQL Server's answer has basically been: hope your backup chain is intact, or pay for a $2,000 transaction-log forensics tool.

So I built SQL RecycleBin.

It's exactly what it sounds like — a recycle bin for SQL Server. Enable it once per table, and every DELETE or UPDATE gets captured automatically. When something goes wrong, you don't restore a backup and lose every transaction since — you just query it back and undo it.

The core flow

-- Turn on capture for a table (one-time setup)
EXEC rb.Enable @Table = 'dbo.Orders';

-- ...someone runs DELETE without a WHERE clause...
DELETE FROM dbo.Orders;

-- See exactly what was lost, as real typed columns — not raw log bytes
EXEC rb.Deleted @Table = 'dbo.Orders';

-- Put it all back. Done.
EXEC rb.UndoLast @Table = 'dbo.Orders';

No log readers, no downtime, no third-party agent sitting in your pipeline.

A few examples of it in practice

Recovering from a bad UPDATE, not just a DELETE:

EXEC rb.Enable @Table = 'dbo.Customers';

-- A migration script accidentally overwrites everyone's email domain
UPDATE dbo.Customers SET Email = 'unknown@company.com';

-- Inspect before/after values for recent updates
EXEC rb.Updated @Table = 'dbo.Customers', @Top = 50;

-- Revert every captured update since it happened
EXEC rb.UndoLast @Table = 'dbo.Customers';

Rolling back to a specific point in time, across a whole transaction:

-- Find the transaction ID responsible
EXEC rb.Status;

-- Undo everything from that specific transaction, not just the last one
EXEC rb.UndoTransaction @Table = 'dbo.Orders', @TxId = 48213;

-- Or roll a table back to how it looked at a timestamp
EXEC rb.Restore @Table = 'dbo.Orders', @Since = '2026-07-25 09:00';

Excluding capture during bulk jobs or ETL, so you're not paying trigger overhead where you don't need it:

EXEC rb.BypassOn;

-- Nightly bulk load — none of this gets captured
INSERT INTO dbo.Orders SELECT * FROM staging.Orders;

EXEC rb.BypassOff;

Keeping the history store lean:

-- Purge anything older than 14 days (the default retention window)
EXEC rb.Cleanup @KeepDays = 14;

Prefer PowerShell over T-SQL? The same engine is wrapped as a module on the PowerShell Gallery:

Install-Module SqlRecycleBin
Install-SqlRecycleBin -Database "MyDb"
Enable-SqlRecycleBinCapture -Table "dbo.Orders"
Restore-SqlRecycleBinLast -Table "dbo.Orders"

What's actually happening under the hood

rb.Enable generates a lightweight AFTER UPDATE, DELETE trigger on the table.
Changed rows are captured as JSON into a compressed internal store (rb.ChangeLog) — JSON means an ALTER TABLE on your side never breaks the safety net.
Retrieval procs (rb.Deleted, rb.Updated) project that JSON back into real typed columns via OPENJSON, using the table's current schema.
Undo procs handle IDENTITY_INSERT and skip primary key collisions automatically.
All of it is persistent on disk — it survives restarts and failovers, unlike an in-memory cache.

Honest about its limits

TRUNCATE TABLE, DROP TABLE, and minimally-logged bulk operations don't fire triggers, so they aren't captured. This is a safety net, not a backup replacement.
Tables need a primary key.
Trigger capture adds write overhead — measure it on your workload, and use rb.BypassOn around heavy bulk jobs.

Full details are in the README.

Licensing

I'm shipping it as source-available under PolyForm Noncommercial — the complete v1 is free to read, install, and use for personal, educational, and noncommercial work. Commercial use requires a license, and that's what funds the roadmap: a CDC-based capture engine with zero trigger overhead, a Blazor dashboard with a diff viewer and one-click restore, and app-level user identity for who-did-what forensics behind connection pools.

Repo: https://github.com/qmmughal/sql-recyclebin
Live demo + docs: https://sqlrecyclebin.com

If you manage SQL Server databases — or you've ever been the person who had to explain a bad DELETE to your team — I'd love a star, a try, or just your thoughts on what a real "undo" for SQL Server should look like.

SQLServer #DBA #OpenSource #TSQL #DisasterRecovery #DataEngineering