The art of simplicity

Note: this is a follow-up to my post on monitoring GitHub Copilot Chat with the Aspire Dashboard. Same idea, different agent. Some developers on the team have switched (part-time) from Copilot Chat to Claude Code for their agentic work. Same question came up again: how much are we actually using it, what does it cost, and where does the time go in a session? Claude Code has its own OTel support, separate from Copilot's, so it needs its own setup — but it plugs into the exact same Aspire Dashboard we already had running. What Claude Code exports Claude Code emits three kinds of OTel signals: Metrics — session counts, token usage, cost, lines of code changed, active time Events — one event per prompt, per API call, per tool result, per permission decision Traces (beta) — a claude_code.interaction span per prompt, with claude_code.llm_request and claude_code.tool spans nested underneath Remark: traces are still beta. Metrics and events are the stable path ...

It didn't take long until skills became a key element in our agentic development workflow. At that moment a skill stopped being "that SKILL.md I keep in one project" and became something we want on every machine, for every teammate, without copy-pasting a folder around. That's the point where you package it into a plugin. A plugin is a container: it bundles one or more skills plus optionally commands, agents, hooks, and MCP servers into a single installable unit with a manifest. Skills are the "what to do", plugins are the "how you get it onto someone else's machine". Our first approach: using git submodules Our first approach was through centralizing all our skills in a separate Git repo and share it between projects by using git submodules. That approach worked but felt more like a hack than a final solution. The better approach: wrap it in a plugin A plugin is just a directory with a manifest and a conventional layout: my-plugin/...

You built an MCP server in C#. It works great on your machine. Now you want to share it with colleagues, publish it to the community, or ship it as part of a product. The problem? Every time someone wants to use a local MCP server, they have to clone a repo, install runtimes, hand-edit a JSON config file, get the path wrong, edit it again... you know the drill. MCP Bundles ( .mcpb ) solve exactly that. They're the .vsix of the MCP ecosystem: a single file that a supporting app (like Claude for Desktop) opens with one click to present a guided install dialog. No terminal, no JSON editing, no "works on my machine." This post walks through taking a C# MCP server binary and packaging it into a distributable .mcpb file from scratch. What's inside a .mcpb file? Before touching anything, it helps to understand what you're building. A .mcpb file is just a ZIP archive with a specific structure: my-server.mcpb (ZIP file) ├── manifest.json ← required: ...