A
licenseA
qualityA
maintenanceMCP server for .NET memory profiling with AI-actionable code fix suggestions, powered by JetBrains dotMemory
5
10
MIT
mcp-dotnet-diagnostics
by aayushmdesai
mcp-dotnet-diagnostics
Give your AI assistant real-time visibility into your .NET application's runtime health.
Connect this Model Context Protocol server to Claude Desktop and ask plain questions about any running .NET process — memory leaks, GC pressure, thread starvation, allocation hotspots. Claude calls the right tools, reads real runtime data, and tells you what's actually wrong.
What this looks like in practice
You ask:
"Why does my API have high memory usage? PID is 12345."
Claude calls get_process_info to confirm connectivity, then get_memory_stats, then
get_gc_events — and responds:
"Every GC event in the last 5 seconds was a Gen2 collection triggered by
AllocLarge. Something is continuously allocating objects above the 85KB LOH threshold at ~10.5 MB/s. LOH is never compacted by default — fragmentation is at 55% and growing. The fix isArrayPool<byte>.Shared. Rent a buffer, use it, return it."
You don't tell Claude which tools to call. It figures that out from your question.
Related MCP server: ASPNET Core Debugging MCP Server
Tools
Tool | What it returns | Reach for it when... |
| Name, PID, uptime, .NET version, OS | Starting any investigation — confirms the process is reachable |
| GC heap, LOH size, alloc rate, Gen0/1/2 counts, fragmentation | Memory is high or growing |
| Per-collection timeline — generation, reason, timestamp | GC pauses are affecting latency |
| ThreadPool count, queue depth, completed items, lock contention | Requests are slow or backing up |
| All 27 | You want a broad health overview |
| Runtime config, filtered env vars (no secrets) | Debugging configuration issues |
| Raw EventCounter names and current values | Discovering what's available on an unfamiliar process |
Installation
1. Install the tool
dotnet tool install -g mcp-dotnet-diagnosticsRequires .NET 8 SDK or later. Get it here if needed.
2. Add to Claude Desktop
Open ~/Library/Application Support/Claude/claude_desktop_config.json while Claude Desktop
is fully quit (Cmd+Q — not just the window closed), then add:
{
"mcpServers": {
"dotnet-diagnostics": {
"command": "mcp-dotnet-diagnostics",
"env": {
"TMPDIR": "/var/folders/xx/your-tmpdir/T/"
}
}
}
}3. Reopen Claude Desktop
The dotnet-diagnostics connector appears in the tools menu. Ask it about any .NET process.
macOS: the
TMPDIRstep is not optional.The .NET diagnostics protocol finds processes through a Unix socket. On macOS, that socket lives under
$TMPDIR— not/tmp/where the library looks by default. Without this, every tool call returns "process not found."Find yours with:
echo $TMPDIR
Want to contribute or build from source? See CONTRIBUTING.md for how to clone, build, and add new tools.
Usage
Find the PID of your target process:
dotnet-counters psThen ask Claude naturally: "Do a full health check on PID 12345." "Why is memory climbing on PID 12345?" "Any thread starvation in PID 12345?" "What's the GC situation on PID 12345?"
How it works
The server uses Microsoft.Diagnostics.NETCore.Client to attach to any running .NET process
by PID — the same library that powers dotnet-counters, dotnet-trace, and dotnet-dump.
It streams telemetry directly from the CLR over EventPipe, which means you get the same data
as the official .NET CLI tools, available to Claude as structured tool responses.
The tool descriptions are written to guide Claude's investigation sequence. When you report
high memory, Claude calls get_process_info first (connectivity), then get_memory_stats
(heap overview), then get_gc_events (collection details) — because the descriptions say to.
The chaining is implicit, not hardcoded.
Requirements
.NET 8 SDK or later to build; .NET 10 recommended
Claude Desktop or any MCP-compatible client
A running .NET process to inspect (your app, an API, anything)
Tests
dotnet test src/McpDotnetDiagnostics.Tests34 tests across all 7 tools — unit tests against invalid PIDs, integration tests against the
live test runner process (Environment.ProcessId). Runs in ~17 seconds.
Design decisions
Three decisions shaped this project in ways that aren't obvious from the outside:
ADR-001: C# over TypeScript — the diagnostics library is .NET-native; a TypeScript wrapper would mean shelling out
ADR-002: Target process by PID, not self — the MCP server itself is uninteresting; your API is where the real data lives
ADR-003: .NET 10 EventPipe payload extraction — undocumented payload structure change in .NET 10, discovered through runtime inspection
License
MIT
Available Tools
7 toolsget_environment_infoA
Returns runtime environment information for a target .NET process including .NET runtime version, OS details, processor count, memory, and process configuration. Use this when investigating version mismatches, environment-specific bugs, or unexpected runtime behavior. Call get_process_info first to confirm the process is reachable.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | The process ID (PID) of the target .NET application |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers what is returned but omits potential side effects or permissions. It is generally transparent for a read-only tool, though could note it is non-invasive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with the tool's action, then usage context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lists categories of returned info and a prerequisite, compensating for no output schema. Adequate for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear pid description. The description adds no further parameter details, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Returns runtime environment information for a target .NET process' with specific details (runtime version, OS, etc.), distinguishing it from siblings like get_process_info or get_memory_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios ('investigating version mismatches, environment-specific bugs') and a prerequisite step ('Call get_process_info first to confirm the process is reachable'), offering clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_event_countersA
Returns all available EventCounter metrics from a .NET process including CPU usage, memory, GC, threading, exceptions, and JIT stats in a single call. Use this for a broad health overview when you don't know which specific area to investigate. For deeper analysis, follow up with get_memory_stats or get_thread_stats.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | The process ID (PID) of the target .NET application | |
| sampleSeconds | No | How long to sample in seconds (default: 3) |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the return content but does not explicitly state the tool is non-destructive or read-only. It mentions 'single call' but lacks details on permissions, side effects, or error conditions. Adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first covers purpose and output, second gives usage guidance and alternatives. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description lists categories of metrics (CPU, memory, GC, threading, exceptions, JIT). It does not describe return structure or units, and lacks handling of edge cases (e.g., process not found). Still, for a broad overview tool with sibling tools for depth, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (pid and sampleSeconds). The description adds no additional parameter meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns all EventCounter metrics from a .NET process, listing specific categories (CPU, memory, GC, threading, exceptions, JIT). It distinguishes itself from sibling tools by positioning itself as a broad overview tool, with explicit follow-up recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'for a broad health overview when you don't know which specific area to investigate.' It also names alternatives for deeper analysis: 'follow up with get_memory_stats or get_thread_stats.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_gc_eventsA
Returns recent GC events for a target .NET process including collection generation (Gen0/Gen1/Gen2), duration, pause time, and timestamp. Use this when investigating periodic response time spikes, application pauses, memory that grows without releasing, or when get_memory_stats shows high Gen2 collection counts. Call get_memory_stats first to establish whether GC pressure is the root cause before drilling into individual events.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | The process ID (PID) of the target .NET application | |
| sampleSeconds | No | How long to collect GC events in seconds (default: 5) |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly implies this is a read-only diagnostic action by describing it as 'returns' events. However, it does not mention any potential permissions needed or whether the process must be running. Still, the safety profile is clear enough for typical use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using two sentences: the first to state the tool's purpose and output fields, and the second to provide usage guidance. Every word adds value, and the structure is immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description compensates by listing the output fields (generation, duration, pause time, timestamp). It also covers common use cases and suggests a prerequisite tool. For a diagnostic tool with only two parameters, this is complete and well-rounded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters (pid and sampleSeconds) with descriptions, achieving 100% coverage. The description merely restates the purpose without adding extra meaning beyond the schema. Baseline 3 is appropriate as the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns recent GC events for a .NET process and lists specific data fields (generation, duration, pause time, timestamp). It effectively distinguishes itself from siblings by implying it provides detailed event-level data, while other tools like get_memory_stats provide aggregate stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (investigating spikes, pauses, memory growth) and what prerequisite calls to make (get_memory_stats first). It provides clear contextual guidance, making it easy for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_memory_statsA
Returns current .NET memory usage for a target process including total allocated bytes, GC generation collection counts (Gen0/Gen1/Gen2), Large Object Heap size, and memory pressure level. Use this when investigating memory leaks, unexpectedly high memory usage, frequent GC pauses, or slow application performance caused by garbage collection pressure. Call get_process_info first to confirm the process is reachable.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | The process ID (PID) of the target .NET application | |
| sampleSeconds | No | How long to sample counters in seconds (default: 2) |
TDQS
A3.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It describes what data is returned but does not state whether the tool is read-only, if it has side effects, if it requires specific permissions, or if it might impact performance. The absence of these details limits transparency for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: first defines the output, second gives use cases, third provides a prerequisite. It is front-loaded with the purpose and contains no unnecessary words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description enumerates the return fields (allocated bytes, GC counts, LOH size, memory pressure) in the absence of an output schema, providing good context. It also includes a prerequisite and use cases. However, it could mention whether the tool works on remote processes or if sampling behavior (sampleSeconds) is non-blocking, but overall it is sufficiently complete for a diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already provides clear descriptions for both parameters (pid and sampleSeconds). The tool description does not add additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: returns .NET memory usage for a target process, listing specific metrics (allocated bytes, GC counts, LOH size, memory pressure). It uses a specific verb ('Returns') and resource ('memory usage'), and distinguishes from siblings like get_process_info and get_gc_events by focusing on memory stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool: investigating memory leaks, high memory usage, frequent GC pauses, or performance issues from GC pressure. It also provides a prerequisite: call get_process_info first to confirm reachability. It does not explicitly state when not to use or mention alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_process_infoA
Returns basic information about a running .NET process by PID. Includes process name, uptime, .NET runtime version, OS platform, and CPU core count. Use this as the first step when investigating any .NET application — it confirms the process is reachable and provides baseline context before diving into memory or thread diagnostics.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | The process ID (PID) of the target .NET application |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Describes returned fields (process name, uptime, runtime version, etc.) and implies a safe read operation, but does not explicitly state non-destructive behavior or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences: first states purpose and output, second provides usage guidance. Every word earns its place, no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description fully covers what the agent needs: what it returns, when to use it, and how it relates to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter (pid), with a clear description. The tool description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns basic information about a .NET process by PID, with specific verb and resource. Differentiates from sibling tools like get_memory_stats and get_thread_stats by positioning it as the first step in investigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this as the first step when investigating any .NET application', providing clear context for when to use. Implies alternatives (other diagnostics for deeper dives) but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_thread_statsA
Returns .NET ThreadPool statistics for a target process including worker thread count, available threads, queue length, and completed work items. Use this when investigating slow response times, request timeouts, or deadlocks — high queue length and low available threads indicates thread starvation, which is a common cause of latency spikes in .NET APIs. Call get_memory_stats first — GC pressure is a frequent cause of thread starvation.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | The process ID (PID) of the target .NET application | |
| sampleSeconds | No | How long to sample counters in seconds (default: 2) |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It explains that the tool samples counters over a period (sampleSeconds) and returns specific statistics. While it doesn't explicitly state read-only nature, the context implies no destructive side effects. A perfect score would require explicit safety guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. Front-loaded with the core functionality, then usage context, then a recommended order. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters, 100% schema coverage, no output schema, and moderate complexity, the description is complete: explains return values, use cases, and sequence with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both pid and sampleSeconds. The description adds context around sampleSeconds ('how long to sample counters') but doesn't significantly expand beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns .NET ThreadPool statistics (worker thread count, available threads, queue length, completed work items) for a target process. It distinguishes from siblings by specifying the exact metrics and linking to related tools like get_memory_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'investigating slow response times, request timeouts, or deadlocks.' Also recommends calling get_memory_stats first, giving clear sequential usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_countersA
Lists all available EventCounter names and current values from a .NET process. Use this to discover what metrics are available before calling get_memory_stats.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | The process ID (PID) of the target .NET application | |
| sampleSeconds | No | Sample duration in seconds (default: 3) |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that the tool lists names and current values, implying a read operation, but does not disclose whether it has side effects, performance implications, or authorization requirements. More explicit behavioral info (e.g., 'This is a safe, read-only operation') would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences with no redundant words. The key purpose is front-loaded, and every sentence adds value, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose and provides a usage context. However, it lacks information about the output format (e.g., structure of returned data) and does not mention any limitations. Given there is no output schema, this missing detail affects completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions (pid and sampleSeconds). The tool's description does not add any additional meaning beyond what the schema already provides, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lists') and resource ('EventCounter names and current values') and scope ('all available'). It clearly states the tool's function but does not differentiate itself from the sibling tool 'get_event_counters', which sounds similar, causing potential confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use the tool: 'Use this to discover what metrics are available before calling get_memory_stats.' However, it does not mention when not to use it or provide alternatives for similar tasks, such as using get_event_counters instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4.1/5.0
Disambiguation4/5
Tools are mostly distinct with clear purposes, but there is some overlap between list_counters, get_event_counters, and the specific tools like get_memory_stats. The descriptions provide guidance on when to use each, reducing ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., get_process_info, list_counters). No mixing of conventions.
Tool Count5/5
7 tools is well-scoped for a diagnostics server. Each tool covers a distinct aspect (process info, environment, memory, threads, GC, counters), without being excessive or insufficient.
Completeness4/5
The tool set covers key diagnostic areas (environment, memory, threads, GC, event counters). Minor gaps exist: no dedicated CPU or exception analysis tool, but they are included in the broad health overview.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Live browser debugging for AI assistants — DOM, console, network via MCP.
Monitoring + status pages set up by talking to Claude. Auto-detects 30+ SDKs and your URLs.
The Polar Signals MCP server enables AI assistants to connect directly with performance profiling data, allowing users to analyze application performance through natural language queries. Key capabilities include querying CPU performance and memory usage, exploring profiling metadata like profile types and labels, and providing AI-driven code optimization suggestions directly within development environments like Claude Code or Cursor.
Open-source agent that observes and fixes your application. Query logs, traces, metrics, incidents.
Related MCP Servers
- AlicenseAqualityBmaintenanceMCP server that lets AI agents (Claude, Cursor) debug your .NET / ASP.NET Core app2714MIT
- AlicenseBqualityBmaintenanceEnables AI coding agents to debug .NET applications with breakpoints, stepping, variable inspection, and GUI automation for WPF, WinForms, and Avalonia apps.1356MIT
- AlicenseNot gradedqualityAmaintenanceEnables AI assistants to analyze Windows WPR/ETW traces (.etl files) using natural language queries, with features like auto-summary, CPU sampling, DPC/ISR analysis, and symbol resolution.8MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aayushmdesai/mcp-dotnet-diagnostics'
If you have feedback or need assistance with the MCP directory API, please join our Discord server