Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@procmon-mcp show me processes with network connections"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives AI assistants deep visibility into Windows internals: processes, ETW kernel traces, event logs, services, drivers, minifilters, and static PE analysis. Built for security researchers, reverse engineers, and anyone who wants an LLM that can actually see what Windows is doing.
This is a proof of concept (POC). Use at your own risk.
procmon-mcp interacts directly with sensitive Windows internals: kernel ETW traces, process memory, security event logs, service/driver enumeration, and UAC elevation requests. These operations can affect system stability, expose sensitive data, and require administrator privileges. There are no guardrails beyond what Windows itself enforces. Review the tool list, understand what each tool does, and run this only in environments you control. The authors assume no liability for misuse or unintended consequences.
LLMs are blind to what your OS is doing. Every time you need process info, network connections, or trace data, you're alt-tabbing to Task Manager, Process Monitor, or PowerShell and pasting results back. procmon-mcp eliminates that loop -- your AI assistant can directly query 18 tools covering live process state, kernel ETW traces, PE internals, event logs, services, drivers, and minifilters. Ask a question, get structured data, stay in flow.
Related MCP server: windows-admin-mcp
pip install procmon-mcpOr run without installing:
uvx procmon-mcpOnce connected, try asking your AI assistant:
"What processes are making network connections right now?"
"Start an ETW trace, launch notepad, stop the trace, and show me what happened"
"Analyze the PE imports of C:\Windows\System32\cmd.exe and categorize the APIs"
"Are any non-Microsoft services running? Show me their binary paths"
"Show me recent logon events from the Security log"
"Take a 30-second timed capture of all svchost processes and summarize the changes"
"List all minifilter drivers and their altitudes"
"What AV products does SecurityCenter2 report?"
Processes -- list, detailed metadata (modules, threads, command line, memory), point-in-time snapshots, timed multi-snapshots with optional trigger commands
ETW -- start/stop kernel traces with logman and tracerpt, list providers, preview CSV and summary output
Network -- TCP and UDP endpoint enumeration with owning process filters
Services and drivers -- service listing with binary paths, kernel driver enumeration, fltmc minifilter output
PE analysis -- static import/export extraction with API category tags (Kernel API, Native API, Win32, Driver)
Event logs -- Get-WinEvent queries and a Security log convenience wrapper for audit event IDs (4688, 4624, 4672, 4648)
System -- OS build, AV product snapshot, elevation capability matrix, UAC helper
Presets -- Defender process/service/driver constants and scan trigger helpers
procmon-mcp is the most comprehensive live Windows monitoring MCP server available. With 18 tools spanning processes, ETW kernel tracing, PE analysis, event logs, services, drivers, and minifilters, it covers more ground than any other single MCP server for live Windows internals. Other tools in this space either focus narrowly (process listing only, event logs only) or do offline forensics from Linux. procmon-mcp gives your AI assistant direct, real-time access to the full Windows instrumentation stack.
Add to your MCP settings (.cursor/mcp.json or global settings):
{
"mcpServers": {
"procmon-mcp": {
"command": "procmon-mcp",
"args": []
}
}
}If you installed into a virtual environment, use python -m procmon_mcp:
{
"mcpServers": {
"procmon-mcp": {
"command": "python",
"args": ["-m", "procmon_mcp"],
"cwd": "C:\\path\\to\\your\\venv\\Scripts"
}
}
}Add to claude_desktop_config.json:
{
"mcpServers": {
"procmon-mcp": {
"command": "procmon-mcp",
"args": []
}
}
}Tool | Description | Required parameters |
| Processes with optional name/PID filter | none |
| Modules, threads, command line, memory | none |
| Point-in-time process, module, and network snapshot | none |
| Repeated snapshots over a duration | none |
| Start a kernel ETW trace (requires elevation) |
|
| Stop trace and convert ETL output |
|
| Parse | none |
| TCP/UDP endpoints by process | none |
| Win32 services with paths | none |
| Kernel drivers via WMI | none |
|
| none |
| Static PE imports and exports |
|
| Recursive PE file discovery |
|
|
| none |
| Security log (IDs 4688, 4624, 4672, 4648) | none |
| OS build and AV snapshot | none |
| Capability matrix | none |
| UAC helper for a shell command |
|
All tools accept optional parameters beyond those listed. See tool schemas for details.
Several capabilities require an elevated (administrator) token:
start_etw_trace and stop_etw_trace use logman real-time sessions (-ets).
get_security_events reads the Security log.
Other tools run without elevation but may return partial results when Windows blocks enumeration (protected processes, restricted logs). Use check_elevation for the full capability matrix.
The Defender preset (procmon_mcp.presets.defender) provides constants (DEFENDER_PROCESSES, DEFENDER_SERVICES, DEFENDER_DRIVERS), binary discovery, MpCmdRun resolution, trigger_scan, and get_preset_config. MCP tools stay generic and preset-agnostic.
pip install -e ".[dev]"
ruff check .
pytestSee CONTRIBUTING.md for full guidelines.
This is a POC. The operations performed are sensitive by nature. This tool reads process memory, enumerates kernel drivers, starts ETW trace sessions, queries security audit logs, and can trigger UAC elevation prompts. Run it only on machines you own or have explicit authorization to instrument. Never point it at production systems without understanding the implications. See SECURITY.md for our security policy and responsible disclosure process.
MIT. See LICENSE.
Parse a PE file with pefile: imports, exports, category summary.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states 'Parse a PE file with pefile'. It does not disclose read-only nature, error conditions (e.g., invalid file), or performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) but lacks structure. Every word is used, but the brevity results in loss of important detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at the return format (e.g., parsed data). It only lists categories extracted, leaving the agent to guess the output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not elaborate on the 'file_path' parameter beyond the tool's purpose. It does not specify formatting, accessibility, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool parses a PE file and lists specific outputs (imports, exports, category summary). The verb 'parse' and resource 'PE file' are precise, and the tool is distinct from siblings like get_process_details or list_drivers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. There is no mention of prerequisites, context (e.g., for static analysis), or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Point-in-time snapshot of matching processes: processes, modules, network connections.
| Name | Required | Description | Default |
|---|---|---|---|
| process_names | No | ||
| pids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'point-in-time snapshot,' implying a read-only operation, but with no annotations, it fails to disclose other behaviors such as required permissions, performance impact, or whether the snapshot is destructive. Limited detail is provided beyond the core idea.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It front-loads the key concept but omits necessary details, making it too terse for complete understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and two parameters with zero coverage, the description is severely incomplete. It does not explain the output format, how to interpret results, or how parameters affect the snapshot, leaving the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description has 0% schema description coverage and does not mention the parameters (process_names, pids) or explain how they filter the 'matching processes.' This lack of parameter information makes the tool difficult to invoke correctly without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it captures a point-in-time snapshot of processes including modules and network connections, distinguishing it from siblings like get_network_connections or get_process_details. However, it does not explain the matching criteria based on the parameters, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_network_connections or list_processes. There is no mention of use cases, prerequisites, or when not to use it, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether the server is elevated plus a capability matrix for all tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the output (elevation status and capability matrix) but does not explicitly state that the tool is read-only or non-destructive, though implied by 'check'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool without output schema, the description is fairly complete, though it could detail the capability matrix format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100% trivially. The description adds meaning by specifying the two return components.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if the server is elevated and returns a capability matrix, distinguishing it from siblings like 'request_elevation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'request_elevation' or when to check elevation first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recursively discover PE files under a directory.
| Name | Required | Description | Default |
|---|---|---|---|
| directory | Yes | ||
| extensions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool recurses (behavioral trait), which is useful. However, with no annotations, it lacks details on read-only status, performance implications, file identification method (extension vs magic bytes), and error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. It is front-loaded with the key action. A bit more detail could improve clarity without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema and no annotations, the description is incomplete. It does not specify what PE files are, how they are identified, or the output format (list of paths).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only implicitly references 'directory' but does not explain the 'extensions' parameter's purpose (e.g., filtering by specific extensions).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (discover), resource (PE files), and scope (recursively under a directory). It distinguishes from sibling tools like analyze_pe which analyzes files, not discovers them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., analyze_pe). No mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run fltmc filters and instances and return raw parsed lines.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only briefly notes that it runs fltmc and returns parsed lines. It does not disclose potential side effects, administrative requirements, or the nature of 'raw parsed lines'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, output schema, or parameters, the description is minimally adequate. It could elaborate on what 'raw parsed lines' means or any expected output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100%. The description adds value by explaining the tool's action beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs 'fltmc filters and instances' and returns raw parsed lines, which is specific and distinguishes it from sibling tools like list_drivers or list_processes. However, the jargon may be unclear to agents unfamiliar with fltmc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TCP and/or UDP endpoints with owning process. protocol: tcp, udp, both, all.
| Name | Required | Description | Default |
|---|---|---|---|
| process_name | No | ||
| pid | No | ||
| protocol | No | tcp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It fails to disclose behavioral traits such as whether the operation is read-only, requires elevated privileges, or has performance implications. The description only states what is returned, not how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence plus a fragment) but poorly structured. The fragment after the period ('protocol: tcp, udp, both, all.') reads as an afterthought. While brevity is valued, some organization would improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and low schema coverage, the description is inadequate. It does not specify the output format, fields returned (e.g., local/remote addresses, state), or error conditions. For a tool with this complexity and many siblings, the description fails to provide enough context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only adds meaning to the 'protocol' parameter (listing valid values). The 'process_name' and 'pid' parameters are completely undocumented, leaving the agent guessing their purpose and format. The description does not compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'TCP and/or UDP endpoints with owning process', specifying a verb ('get') and a resource ('network connections'). It also enumerates protocol values (tcp, udp, both, all), making the purpose reasonably clear. However, it does not differentiate from sibling tools like 'get_process_details' or 'list_processes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or context for invocation. Agents have no basis to choose this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deep process details: modules, handle count, threads, command line, memory breakdown. May warn on protected processes.
| Name | Required | Description | Default |
|---|---|---|---|
| pid | No | ||
| name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'May warn on protected processes,' disclosing a behavioral trait beyond the schema. However, without annotations, it fails to disclose other important behaviors such as authentication needs or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with key information front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists returned data types (modules, handle count, etc.) and mentions warnings, but given the complexity and lack of output schema, it omits details like how parameters are used, potential large output, or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (pid, name) both optional, but the description does not explain how they are used or their relationship (e.g., whether one is sufficient). With 0% schema coverage, the description should add meaning but only lists output fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides deep process details including modules, handle count, threads, command line, and memory breakdown. This distinguishes it from sibling tools like list_processes (which likely lists processes without details) and analyze_pe (which focuses on PE files).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when deep process details are needed, but it does not explicitly state when to use it over alternatives, nor does it provide conditions for non-use or prerequisites. No guidance on preventing warnings on protected processes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Security log convenience: IDs 4688, 4624, 4672, 4648 (requires elevation).
| Name | Required | Description | Default |
|---|---|---|---|
| max_events | No | ||
| hours_back | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only states that elevation is required, but does not disclose whether the operation is read-only, what the typical output size is, or any side effects. This is minimal for a tool that fetches security events.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single sentence, front-loading the key purpose and a critical requirement. It could be improved by structuring it with parameter hints or usage notes, but it avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of security event retrieval and the presence of sibling tools like query_event_log, the description is incomplete. It does not explain the return format, output schema, or how the parameters affect results. The agent lacks context to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the two parameters (max_events, hours_back) at all, despite 0% schema description coverage. The schema provides defaults, but the agent receives no guidance on how to use these parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a convenience for specific security event IDs (4688, 4624, 4672, 4648), which distinguishes it from the general query_event_log sibling tool. The verb 'get' and resource 'security events' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a convenience for the listed event IDs, but it does not explicitly state when to use this tool versus alternatives like query_event_log. The mention of 'requires elevation' warns about a prerequisite, but no when-not or alternative conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OS build, architecture, hostname, SecurityCenter2 AV products, PowerShell version.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must bear the full burden. It implies a read-only query by listing output fields, but does not explicitly state it is non-destructive, requires no elevation, or has no side effects. For a zero-parameter tool, this is minimally adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence listing key attributes. It is front-loaded and contains no fluff. Every word earns its place, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should ideally clarify the return format (e.g., JSON object, structured data). It only lists attribute categories, not their types or structure. For a simple tool this may suffice, but it leaves ambiguity about how data is organized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description has no burden to explain them. The schema coverage is 100% by default. The description instead focuses on output fields, which is appropriate. No param information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description lists specific OS and system attributes (build, architecture, hostname, AV, PowerShell version), clearly indicating the tool retrieves system information. The verb 'get' in the name reinforces this. While it distinguishes from sibling tools like 'list_processes' or 'get_network_connections' by specifying these exact fields, it does not explicitly state an action verb like 'retrieves' in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings. It simply lists the data returned. There is no indication of prerequisites, contexts, or alternatives, which is a significant gap given 17 sibling tools with overlapping purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerate kernel drivers via Win32_SystemDriver.
| Name | Required | Description | Default |
|---|---|---|---|
| name_filter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It indicates read-only enumeration (safe), but lacks details on error handling, performance impact, or requirements (e.g., elevation). The mention of WMI class adds some context but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. However, it omits critical information (parameter explanation, output details), making it under-specified. Conciseness is good but sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at return values; it does not. With only one parameter undocumented and no behavioral details, the description is incomplete for effective tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter 'name_filter' with 0% description coverage. The description does not mention or explain this parameter, leaving agents to guess its purpose or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (enumerate) and resource (kernel drivers), using 'Win32_SystemDriver' for specificity. It distinguishes from siblings like 'list_services' or 'get_minifilters' by naming the resource, but does not explicitly differentiate from similar enumeration tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when or when not to use this tool. No mention of prerequisites, limitations, or alternative tools. Implicitly for listing drivers, but no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse logman query providers with optional keyword filter.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, required permissions, or output format. It merely states the action without additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. It is concise, though it could be slightly improved by adding structure such as separating purpose from parameter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's interaction with system ETW providers, the description is too brief. It assumes knowledge of logman and does not explain what the parsed output contains or how the keyword filter works, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage). The description adds 'optional keyword filter' which gives minimal meaning but does not specify what the keyword filters (e.g., provider name) or expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Parse logman query providers', which indicates the tool lists ETW providers using logman, but the verb 'parse' is less direct than 'list' or 'enumerate'. It does specify the resource and optional keyword filter, providing moderate clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling tools like list_processes or get_system_info. The description lacks context on appropriate usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List processes with optional name or PID filter. Returns handles, threads, working set, path, parent PID, start time.
| Name | Required | Description | Default |
|---|---|---|---|
| name_filter | No | Filter by process name | |
| pid_filter | No | Filter by PID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It lists returned fields, giving a basic understanding, but omits potential side effects, performance implications, or permission requirements. Adequate for a simple read operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence with no redundancy. All information is front-loaded and directly useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description covers key aspects: purpose, filters, and return fields. Missing details like error cases or limits, but overall sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description merely restates that filters are optional, adding no new meaning beyond the existing parameter descriptions. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists processes with optional name or PID filters, and enumerates the returned fields (handles, threads, working set, path, parent PID, start time). It distinguishes from siblings like get_process_details by specifying the filter and broad scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives such as get_process_details. The description implies optional filtering but does not discuss scenarios or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerate services via Win32_Service (name, state, start mode, display name, path).
| Name | Required | Description | Default |
|---|---|---|---|
| name_filter | No | Substring filter on name or display name | |
| status_filter | No | Exact Win32_Service.State match, e.g. Running |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the enumeration purpose and returned fields, failing to mention whether the operation is read-only, requires elevation, or has any side effects. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and resource. Every word adds value; there is no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description lists the returned fields. It covers the core functionality but could be enhanced by mentioning the optional filters (name_filter, status_filter) to alert agents to their existence. Still, it is largely complete for a simple enumeration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema for the two parameters, which are already described in the input schema. It does not compensate for any ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Enumerate' and resource 'services', and lists the exact fields returned (name, state, start mode, display name, path), making it clear what the tool does. It is distinct from sibling tools like list_drivers and list_processes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use list_services versus alternatives. The description implies usage for enumerating services, but does not provide context or exclusions, leaving the agent to infer from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query a Windows event log via Get-WinEvent FilterHashtable.
| Name | Required | Description | Default |
|---|---|---|---|
| log_name | No | System | |
| event_ids | No | ||
| max_events | No | ||
| hours_back | No | ||
| level | No | Numeric level if needed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states that the tool queries via Get-WinEvent, but does not disclose behavioral traits such as required permissions, potential errors, performance impact, or whether it can read logs other than System (despite log_name default). The description is too brief to provide adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (single sentence) and front-loaded. However, conciseness comes at the cost of completeness; it does not earn its place by providing value beyond the name. It is not verbose, but it is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters with low schema coverage, no output schema, and no annotations, the description is grossly inadequate. It does not explain the return values, the behavior of parameters, or how this tool fits into the broader set of sibling tools. The description is incomplete for an AI agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only the 'level' parameter has a brief description). The tool description adds no parameter explanations whatsoever. For example, parameters like event_ids, max_events, and hours_back are completely unexplained. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (query) and resource (Windows event log) and mentions the underlying cmdlet. However, it does not differentiate from sibling tools like get_security_events, which may also query event logs. The purpose is specific enough for an agent to understand the basic function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as get_security_events. No prerequisites, when-not-to-use, or context for selection are provided. The description offers no help in deciding between sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch a cmd script via UAC (Start-Process -Verb RunAs) to run the given command.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | ||
| timeout | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions the UAC mechanism but omits side effects like user prompt, blocking behavior, timeout behavior, and error outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Overly brief; a single sentence sacrifices necessary detail for brevity, leaving critical gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks explanation of return value, timeout handling, prerequisite of being run from an elevated context, and error conditions; incomplete for a tool with two parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no semantic detail beyond parameter names; 'run the given command' is vague and timeout is unmentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it launches a cmd script via UAC with elevated privileges, distinguishing it from sibling tools like check_elevation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; lacks context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a kernel ETW trace via logman (requires elevation). providers are Microsoft-Windows-Kernel-* names or GUID strings.
| Name | Required | Description | Default |
|---|---|---|---|
| session_name | Yes | Trace session name | |
| providers | No | ||
| output_dir | No | Directory for ETL output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses elevation requirement, which is a key behavioral trait. However, it does not describe the trace lifecycle (e.g., runs until stopped, creates ETL file) or system impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Information is front-loaded: purpose and elevation first, then provider format. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (3 params, no output schema, no annotations), the description adequately covers purpose, elevation, and provider format. However, it lacks completeness on trace output (e.g., .etl files created in output_dir) and the need to stop the trace with stop_etw_trace.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%. The description adds meaning for the 'providers' parameter by specifying format ('Microsoft-Windows-Kernel-* names or GUID strings'), which is not in the schema. It does not add to session_name or output_dir but partially compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it starts a kernel ETW trace via logman and requires elevation. It specifies the resource and action, and distinguishes from siblings like stop_etw_trace and list_etw_providers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Elevation requirement is noted, but there is no explicit guidance on when to use this vs alternatives (e.g., stop_etw_trace, list_etw_providers). Usage context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop ETW trace, run tracerpt to CSV and summary, return parsed preview (requires elevation).
| Name | Required | Description | Default |
|---|---|---|---|
| session_name | Yes | ||
| output_dir | No | ||
| process_filter | No | Substring filter across CSV columns |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool stops the trace, processes data via tracerpt, and returns a preview. The elevation requirement is also mentioned. However, it does not detail side effects such as session deletion or file cleanup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys all necessary information concisely, with no wasted words. It is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations. The description covers the core action but lacks details on return value format, required permissions beyond elevation, or error conditions. It is adequate but leaves some gaps for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 33%, with only process_filter having a description. The tool description adds no additional meaning to the parameters; session_name and output_dir are left unexplained beyond their names. For a low-coverage schema, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Stop' and the resource 'ETW trace', and further explains that it runs tracerpt to CSV and summary and returns a parsed preview, leaving no ambiguity about the tool's function. It is distinguishable from sibling tools like start_etw_trace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'requires elevation', providing a clear prerequisite for usage. It implies that the tool should be used after starting a trace, but does not explicitly state when not to use it or compare with alternatives, which would have earned a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Repeated snapshots over a duration with optional shell trigger command launched at start.
| Name | Required | Description | Default |
|---|---|---|---|
| process_names | No | ||
| duration | No | Seconds (default 15) | |
| interval | No | Seconds between snapshots (default 3) | |
| trigger_command | No | Optional shell command to launch at start |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose side effects, storage location, or limitations of repeated snapshots. Only mentions optional shell trigger command.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient, front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers basic purpose but lacks return format, error conditions, or prerequisites; adequate for a simple tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds context for duration and interval but 'process_names' is not explained; schema coverage is 75%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Repeated snapshots' and resource 'over a duration' distinguishes from sibling 'capture_snapshot' which is likely a single snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for multiple snapshots but no explicit alternative mention; clear enough for selecting this tool over a single snapshot tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0analyze_pecapture_snapshotcheck_elevationfind_pe_filesget_minifiltersget_network_connectionsget_process_detailsget_security_eventsget_system_infolist_driverslist_etw_providerslist_processeslist_servicesquery_event_logrequest_elevationstart_etw_tracestop_etw_tracetimed_captureMost tools have distinct purposes, but capture_snapshot bundles process listing and network connections that overlap with list_processes and get_network_connections. However, descriptions clarify the composite nature, reducing ambiguity.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., analyze_pe, list_processes, start_etw_trace), with no mixing of conventions.
18 tools cover a broad monitoring domain, slightly exceeding the typical 3-15 range, but each tool addresses a specific need, and no tool feels redundant.
The tool set covers core process monitoring aspects: process listing, deep details, network, security events, ETW tracing, services, drivers, PE analysis, and elevation handling. There are no obvious gaps for its intended scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
An MCP server that integrates with Discord to provide AI-powered features.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/0xhackerfren/ProcMon-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server