Click on "Deploy 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., "@sysinternals-mcp list all processes with more than 100 threads"
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.
FastMCP 3.4 wrapper for 12 Sysinternals CLI tools (+ DIY RAMMap equivalent via WMI) -- autorunsc, handle64, pslist, listdlls, tcpvcon, sigcheck, accesschk, psloggedon, psfile, coreinfo, du, psinfo, rammap.
Stack: Python 3.12+ -- FastMCP 3.4.2 -- uv -- ruff
All 12 tools are confirmed CLI-native. No GUI automation, no fake backends.
First-run auto-downloads each binary from https://live.sysinternals.com/,
verifies the Authenticode signature, and caches it.
Tool | Function | What it does |
|
| Startup/persistence scan -- CSV output via |
|
| Open handles/file locks -- verbose via |
|
| Process list with CPU, thread, handle counts |
|
| Loaded DLLs per process with version info |
|
| TCP/UDP connections + owning process |
|
| Authenticode verification, version, VT lookup |
|
| Effective permissions on files/registry/services |
|
| Logged-on users, local + network |
|
| Remotely opened files on this machine |
|
| CPU topology, NUMA, cache, feature flags |
|
| Directory size breakdown (recursive) |
|
| Physical memory breakdown via WMI (DIY RAMMap, no binary) |
|
| System info: OS, uptime, hotfixes, services |
Related MCP server: Sysinternals MCP Server
git clone https://github.com/sandraschi/sysinternals-mcp.git
cd sysinternals-mcp
uv sync --group dev
uv run sysinternals-mcp # stdio MCP for IDEFirst run auto-downloads binaries and stores them in %LOCALAPPDATA%\sysinternals-mcp\bin\.
Mode | Command |
stdio |
|
HTTP |
|
No EXEs committed to git. Binaries downloaded on first use from live.sysinternals.com.
Authenticode verification: rejects anything not signed by Microsoft / Sysinternals.
EULA: accepted once per machine (marker file in cache dir).
RAMMap -- no CLI export flag exists.
Process Explorer -- GUI-only, no scriptable CLI output.
MIT
Check effective permissions on files, directories, registry keys, or services.
Wraps Sysinternals AccessChk.
{"success": bool, "entries": list[dict], "count": int, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File, directory, registry path, or service name | |
| target | No | User or group to check (omit for effective access) | |
| recursive | No | Recurse subdirectories (-s) | |
| accept_eula | No | Accept EULA (stored once) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure and largely does not meet it. It does not say that AccessChk typically requires elevated privileges, that it may prompt for or require EULA acceptance (left entirely to the accept_eula parameter), or that recursive scans can be slow or noisy. 'Wraps Sysinternals AccessChk' is a mildly useful provenance note but conveys no behavior on its own.
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 short and front-loads the core purpose in the first sentence. The '## Return Format' block is largely wasted space because an output schema already exists and communicates the same shape.
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?
Because an output schema exists, the description is not obligated to explain return values, yet it does so anyway while omitting more valuable context: sibling differentiation from accesschk_service, elevation/EULA requirements, and any note on cost of recursive scans. Adequate but with clear gaps for a privileged Windows inspection 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 all four parameters (path, target, recursive, accept_eula) are already documented with type, default, and semantics in the schema. The description adds no clarification beyond that, so the baseline 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 gives a specific verb and resource set: 'Check effective permissions on files, directories, registry keys, or services.' That is clear and actionable. However, it never distinguishes itself from the sibling accesschk_service, which appears to be a narrower variant of the same capability, so an agent has no basis to choose between 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?
There is no when-to-use guidance, no prerequisites, and no mention of the alternative accesschk_service sibling. The only hint at scope is the enumeration of target types in the first sentence, which is purpose rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check effective permissions on a specific Windows service.
{"success": bool, "entries": list[dict], "count": int}
| Name | Required | Description | Default |
|---|---|---|---|
| service_name | Yes | Service name to check |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, yet it discloses nothing about required privileges (access checks on services typically need elevation), local vs remote targets, or what an 'effective permission' entry contains. The only behavioral detail is a return-format block, which duplicates the declared output schema rather than adding new 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 operative sentence is short and front-loaded with no filler. The appended Return Format block is redundant given an output schema exists, a small amount of wasted space, but the overall size is appropriate.
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?
Because an output schema exists, the description rightly omits return-value detail, but with zero annotations it should still convey the read-only nature and privilege requirements of an access-check tool. Adequate for a single-parameter read, but leaves real gaps.
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% with a single required service_name parameter, so the schema already documents the input fully. The description's phrase 'specific Windows service' adds only marginal framing beyond 'Service name to check', so the baseline 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?
States a specific verb+resource: checking effective permissions on a named Windows service. This is clearly narrower than the sibling accesschk, though the description never explicitly says how it relates to or differs from that broader tool.
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 when-to-use guidance, no prerequisites, and no mention of the sibling accesschk tool that overlaps in scope. An agent must infer from the name alone when this is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan startup programs, scheduled tasks, services, drivers, and browser extensions.
Wraps Sysinternals Autorunsc with CSV output parsing.
{"success": bool, "entries": list[dict], "count": int, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| hashes | No | Include SHA-1 hashes (-h) | |
| verify | No | Verify digital signatures (-v) | |
| all_users | No | Check all user accounts (-a *) | |
| accept_eula | No | Accept EULA (stored once) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it falls short: it doesn't state that the underlying Sysinternals binary requires EULA acceptance on first run (only the schema hints at this), that all_users likely needs elevation, or what side effects scanning has on the host. It adds only the wrapper/CSV-parsing note.
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 compact sentences, front-loaded with the scope. The 'Return Format' block is redundant given an output schema exists but is brief and not wasteful enough to penalize heavily.
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 schema documents all four parameters and an output schema covers the return shape, so the description is adequate. However, for a privileged invocation of an external binary with no annotations, it omits operational prerequisites (EULA, elevated rights) that an agent would need to call it successfully.
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%, with each flag documented alongside its CLI equivalent (-h, -v, -a *), so the baseline is 3. The description adds nothing about parameter meaning beyond what the schema already supplies.
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?
States a specific verb ('Scan') and enumerates the resource set (startup programs, scheduled tasks, services, drivers, browser extensions), plus notes it wraps Sysinternals Autorunsc. It is clear what the tool does, though it never distinguishes itself from the sibling autorunsc_schedule, leaving the agent to infer the split between a one-shot scan and a scheduled one.
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 when-to-use statement, no exclusions, and no mention of alternatives such as autorunsc_schedule or sigcheck for signature verification calls. The use case is only implied by the operation described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan only scheduled tasks autoruns (fast subset).
{"success": bool, "entries": list[dict], "count": int}
| Name | Required | Description | Default |
|---|---|---|---|
| hashes | No | Include SHA-1 hashes (-h) | |
| accept_eula | No | Accept EULA (stored once) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden, yet it only conveys that this is a narrow/fast scan plus a return format. It says nothing about permissions, whether EULA acceptance is required before running (only buried in the schema), or other preconditions, leaving key operational traits undocumented.
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?
Front-loads the core action in a single tight sentence with no filler. The added Return Format block is largely redundant with the existing output schema, so it does not fully earn its place, keeping this just below top marks.
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 two-parameter scan tool with an output schema, the description covers purpose and return shape, so return values need not be re-explained. However, with no annotations it omits preconditions and when-to-use guidance, leaving it only minimally adequate.
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 both parameters (hashes, accept_eula) are already documented in the schema with their CLI flags. The description adds no parameter meaning beyond what the schema provides, making the baseline 3 correct.
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?
States a specific verb and resource ('Scan ... scheduled tasks autoruns') and scopes it as a 'fast subset', which implicitly distinguishes it from the full sibling 'autorunsc'. An agent can tell it narrows the scan to scheduled tasks, though the contrast with autorunsc is only implied rather than named.
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 'only scheduled tasks' / 'fast subset' phrasing implies the use case (a quick targeted scan), but no explicit when-to-use, exclusions, or routing to/from the sibling autorunsc is provided. Usage is inferable but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show CPU topology, NUMA node layout, cache sizes, and feature flags.
Wraps Sysinternals Coreinfo.
{"success": bool, "cpu_topology": list[dict], "features": list[dict], "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| all_features | No | Show all feature flags (default shows deltas) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Show' implies a read-only inspection, but it does not explicitly confirm no mutation, does not mention the admin requirement common to Coreinfo, and gives no side-effect or performance 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?
Tightly structured: the capability sentence is front-loaded, the Sysinternals wrapper note is brief, and the return format is compact with no filler. Slightly more than minimal but every line is 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?
For a one-parameter read-only inspection tool with a return format given, the definition is close to sufficient - an agent knows what it gets back and how to call it. The missing usage context (when to use it, admin requirement) is a minor gap.
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 single all_features parameter is fully documented in the schema ('default shows deltas'). The description adds nothing about this parameter, which is the correct baseline when the schema does the work.
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?
States a specific verb (Show) plus a concrete, enumerated resource set (CPU topology, NUMA layout, cache sizes, feature flags). No sibling (pslist, rammap, listdlls, etc.) touches CPU topology, so an agent can route to it unambiguously.
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 never states when to reach for this tool versus the many sibling diagnostics, nor any prerequisite such as needing elevated privileges (Coreinfo typically requires admin). It only describes what is returned, leaving usage entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show disk usage for a directory tree, broken down by subdirectory.
Wraps Sysinternals DU. Uses verbose (-v) output for per-directory breakdown.
{"success": bool, "directories": list[dict], "total": dict, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Directory path to analyze | |
| n_children | No | Show top N subdirectories by size (-n) | |
| accept_eula | No | Accept EULA (stored once) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden, and it does disclose useful traits: it wraps Sysinternals DU, runs in verbose mode, and implies a one-time EULA acceptance (echoed by accept_eula). However, it omits permission requirements, read-only nature, and any rate/timeout behavior for a filesystem-scanning tool.
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?
Front-loaded purpose sentence followed by a brief notes block and a return-format section; every line is short and earns its place. Minor redundancy with the declared output schema in restating the return shape.
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 simple directory-scanning tool with 100% schema coverage and an output schema, the definition covers purpose, underlying implementation, and return shape adequately. Only the when-to-use guidance versus du_quick is absent.
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%, so all three parameters (path, n_children, accept_eula) are already documented in the schema to the same depth the description offers. The description adds no parameter syntax or default details beyond that baseline.
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?
States a specific verb+resource ('Show disk usage for a directory tree') and adds a scope qualifier ('broken down by subdirectory'). It does not explicitly name or contrast with the obvious sibling du_quick, so sibling differentiation is only implied by the verbose mode note.
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 mention of 'verbose (-v) output for per-directory breakdown' implies a detailed-analysis use case that contrasts with a quick variant, but the description never names du_quick or states when to prefer this over it. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quick disk usage summary for a directory (one level, no recursion into children).
{"success": bool, "directories": list[dict], "total": dict}
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Directory path to analyze |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the key trait that it does not recurse, and the read-only nature is implied by 'summary', but nothing is said about permissions, error cases, symlink handling, or performance limits.
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?
A single front-loaded sentence gives the purpose and scope immediately. The appended 'Return Format' block is somewhat redundant given a machine-readable output schema already exists, costing it a point against a strictly minimal ideal.
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 covers scope, verb, and resource, and the output shape is documented both inline and via an output schema, so an agent has enough to call it correctly. Missing only alternate-tool routing and failure-mode behavior for full completeness.
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?
Only one parameter exists and the schema documents it at 100% coverage ('Directory path to analyze'), so the bar is low. The description reinforces that the path is expected to be a directory, but adds no syntax or format detail beyond the schema, making a baseline-plus score 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?
States a specific verb and resource ('disk usage summary for a directory') plus a meaningful scope qualifier ('one level, no recursion into children'), which implicitly separates it from the recursive sibling du. It does not name the alternative tool, so it stops short of full sibling differentiation.
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 word 'Quick' plus 'one level, no recursion' implies this is for shallow, fast overviews as opposed to a full recursive scan, but no explicit when-to-use or when-not-to-use guidance is given and the sibling du is never mentioned. Usage must be inferred from the scope phrase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List open handles and file locks on the system.
Wraps Sysinternals Handle64.
{"success": bool, "handles": list[dict], "count": int, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | No | Filter handles by name/pattern | |
| verbose | No | Verbose output with handle counts (-v) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 does disclose the return shape, but omits key operational traits for a Sysinternals Handle64 wrapper: that it typically requires elevation, that it is a read-only enumeration of all processes, and what happens when no pattern matches.
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 purpose is front-loaded in one sentence, with supporting details kept brief. The Return Format block is somewhat redundant given an output schema exists, but overall the text is tight and well ordered.
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?
An output schema exists, so the return-value explanation is not strictly needed. What is missing for a tool of this complexity is elevation/privilege expectations and any differentiation from handle64_by_pid, leaving the agent to infer routing.
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 both parameters (pattern, verbose) are already documented in the schema, including the -v flag mapping. The description adds no syntax or matching semantics beyond that, which is the expected baseline when the schema does the work.
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 and resource ('List open handles and file locks on the system') plus the underlying tool it wraps. An agent knows exactly what it produces, though it never distinguishes itself from the sibling handle64_by_pid, which covers the same domain with PID scoping.
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 when-to-use guidance, no prerequisites, and no mention of the obvious alternative (handle64_by_pid). The description implies usage only through its name and the bare statement of purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List open handles for a specific process by PID.
{"success": bool, "handles": list[dict], "count": int}
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | Process ID to enumerate handles for |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full behavioral burden. It usefully discloses the return shape, but says nothing about privilege requirements (handle enumeration typically needs elevated rights), read-only semantics, or failure conditions for an invalid/dead PID.
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?
One sentence of purpose followed by a compact return-format block – front-loaded and free of filler. The inline return format is mildly redundant given an output schema exists, but it costs little.
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 one-parameter read tool with a full output schema, the definition covers what is needed to call it correctly. The remaining omission – the privilege/behavioral profile, which nothing else supplies – keeps it from being fully 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?
Schema coverage is 100% for the single 'pid' parameter, whose schema description already says 'Process ID to enumerate handles for'. The description adds only the phrase 'by PID' and no format/constraint detail beyond the schema, so the baseline 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?
States a specific verb ('List'), resource ('open handles') and scope ('for a specific process by PID'), which separates it from the bare handle64 sibling that presumably enumerates all handles. It never names the sibling explicitly, so the differentiation is inferred rather than stated.
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?
Usage is implied by 'for a specific process by PID' – an agent can infer it should call this when it already has a PID. However, there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. handle64 / pslist) to route the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all loaded DLLs across all processes with version info.
Wraps Sysinternals ListDLLs.
{"success": bool, "processes": list[dict], "count": int, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| verified | No | Only show verified DLLs (-v) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses provenance ('Wraps Sysinternals ListDLLs'), which implies Windows-only, elevated-privilege, read-only behavior, and it documents the return shape. It stops short of stating admin requirements, performance cost on busy hosts, or that some DLLs may be inaccessible without privileges.
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?
Front-loaded one-sentence purpose, then provenance, then return format — no filler. Slightly redundant to restate the return format inline when an output schema exists, but the total length is short and scannable.
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?
An output schema exists, so the return-value section is largely duplicative rather than additive. The definition still omits the most decision-relevant context for an agent: that this is Windows/Sysinternals-specific, privilege needs, and when to prefer listdlls_by_pid over the full sweep.
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% and the single 'verified' parameter is fully documented in the schema, including the (-v) flag mapping. The description adds nothing about the parameter and its phrase 'with version info' does not clarify how it relates to the 'verified' filter, so the baseline 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?
States a specific verb and resource — 'List all loaded DLLs across all processes with version info' — and the phrase 'across all processes' implicitly separates it from the per-process sibling. However, it never names listdlls_by_pid, so the differentiation must be inferred from sibling names alone.
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?
Usage is implied by the scope phrase 'across all processes', which suggests this is the whole-system variant as opposed to a PID-scoped call. There is no explicit when-to-use statement, no exclusion, and no named alternative such as listdlls_by_pid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List loaded DLLs for a specific process by PID.
{"success": bool, "dlls": list[dict], "count": int}
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | Process ID to inspect |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no permission/privilege requirements for enumerating another process's modules, no behavior when the PID is invalid or the process has exited, and no indication that the call is read-only. The Return Format block restates what the output schema already provides rather than adding behavioral 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?
Purpose is front-loaded in one sentence with zero filler. The appended Return Format block is largely redundant given an output schema exists, which is a minor structural inefficiency.
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 single-parameter read tool with an output schema, the description covers purpose and shape adequately. It omits the operational details an agent may need (privilege requirements, failure behavior for a bad PID) and does not position itself against the very similar listdlls sibling.
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% and there is a single pid parameter already documented as 'Process ID to inspect'. The description adds no format, range, or semantics beyond the schema, so the baseline 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?
States a specific verb (List), resource (loaded DLLs), and scope (for a specific process by PID), so an agent can tell it apart from the sibling listdlls at a functional level. It stops short of explicitly naming listdlls as the all-processes alternative, so differentiation is inferred rather than stated.
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 phrase 'for a specific process by PID' implies the usage condition (you must already have a PID), but there is no explicit when-to-use, no when-not-to-use, and no pointer to listdlls or pslist for other cases. Usage is only inferable from the scope wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files opened by remote systems via network shares.
Wraps Sysinternals PsFile.
{"success": bool, "files": list[dict], "count": int, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| accept_eula | No | Accept EULA (stored once) | |
| path_filter | No | Filter by path (optional) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden. It discloses the Sysinternals wrapper (useful context) and the return shape, and 'list' implies a read-only operation, but it says nothing about privilege requirements, remote-access assumptions, or the EULA acceptance the tool depends on.
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?
Very tightly written and front-loaded: purpose first, wrapper note, then return format. The return-format block is somewhat redundant given an output schema exists, which slightly dilutes 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 read-only listing tool with a full output schema and 100% parameter coverage, the description supplies what the structured fields cannot: identity of the underlying utility and the response shape. Only operational prerequisites (privileges, EULA) are missing.
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 both accept_eula and path_filter are already documented in the schema. The description adds no filtering syntax, matching semantics, or meaning beyond what the schema provides, so the baseline 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?
States a specific verb and resource ('List files opened by remote systems via network shares') and identifies the underlying Sysinternals utility, making the scope clear. It doesn't explicitly contrast itself with siblings like handle64 or psfile_close, so an agent must infer the boundary, but the resource framing is precise.
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 when-to-use guidance, no prerequisites, and no mention of the alternative sibling psfile_close or when this beats handle64. The agent is told what it is but not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close a file opened by a remote system.
{"success": bool, "message": str}
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | File ID to close |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It states the operation but omits the safety profile: whether closing a handle is destructive or reversible, what permissions the remote session requires, and what happens if the file is in use. Only the return shape is disclosed.
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 action is front-loaded in a single short sentence with no padding. The appended Return Format block is somewhat redundant given an output schema already exists, but it does not impede 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?
An output schema exists, so the description need not explain return values (and duplicating it adds little). For a mutation-style tool with no annotations, however, the agent is not told about required permissions, side effects, or failure modes, leaving the definition only minimally adequate.
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% and the single required parameter (file_id) is documented in the schema as 'File ID to close'. The description adds no format, range, or provenance detail beyond that, so the baseline 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?
States a specific verb and resource: 'Close a file opened by a remote system', which clearly separates it from the sibling psfile (which enumerates open files). The phrasing 'opened by a remote system' is slightly ambiguous about scope, but the action and target are 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?
No indication of when to use this versus psfile, nor that a file_id must first be obtained from that listing tool, nor any prerequisites. The agent is left to infer the entire workflow from the parameter name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show detailed system information: OS version, uptime, hotfixes, services.
Wraps Sysinternals PsInfo.
{"success": bool, "sections": dict, "raw": str, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| show_hotfixes | No | Show installed hotfixes (-h) | |
| show_services | No | Show running services (-s) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that this wraps Sysinternals PsInfo and gives the return shape, but it omits key traits such as whether administrative rights are required (PsInfo typically needs elevation for hotfixes/services), that it is a read-only operation, and that it may be slow to execute.
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?
Front-loaded with the purpose sentence, followed by the wrapper note and the return format. Compact and free of filler, though the return-format block partially duplicates the existing output schema.
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?
With an output schema present and 100% schema coverage on a zero-required-parameter tool, the description covers purpose and execution backend sufficiently to invoke it. The only meaningful gap is the unaddressed local-versus-remote distinction from psinfo_remote.
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% — both show_hotfixes (-h) and show_services (-s) are fully documented in the schema with their flags. The description adds no parameter meaning beyond that, so the baseline 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?
States a specific verb and resource — 'Show detailed system information' — and enumerates the content categories (OS version, uptime, hotfixes, services), plus names the underlying Sysinternals PsInfo tool. It is clear what the tool does, but it never clarifies that it targets the local host, leaving the split against the sibling psinfo_remote unresolved within the definition itself.
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 explicit when-to-use or when-not-to-use guidance. The presence of the sibling psinfo_remote makes the local-vs-remote choice the single most important routing decision, and the description does not address it at all, nor does it state any prerequisites (e.g. elevation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show system info for a remote computer.
{"success": bool, "sections": dict, "raw": str}
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes | Remote computer name |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it only restates the return shape (already covered by the output schema). For a remote-access tool with zero annotation coverage, it says nothing about network/auth requirements, latency, or failure modes when the host is unreachable.
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 short and front-loaded with the core purpose. The appended Return Format block is arguably redundant given an output schema already exists, which slightly dilutes the 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?
An output schema exists, so return values need not be explained, and the description does convey that this targets a remote host. Still missing is any indication of what 'system info' sections are returned or what preconditions a remote query needs to succeed.
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 single 'server' parameter is fully described in the schema ('Remote computer name'), so schema coverage is 100%. The description adds no extra meaning beyond the schema, which is the expected baseline when the schema does the heavy lifting.
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 states a clear verb and resource ('Show system info') and scopes it with 'for a remote computer', which implicitly distinguishes it from the local 'psinfo' sibling. It stops short of naming that sibling explicitly, so the differentiation is inferred rather than stated.
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 phrase 'for a remote computer' implies the condition under which this tool is chosen over the local psinfo sibling. However, there is no explicit when-to-use guidance, no prerequisites (e.g., network reachability, credentials), and no named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List processes with PID, CPU time, thread count, and handle count.
Wraps Sysinternals Pslist.
{"success": bool, "processes": list[dict], "count": int, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| tree | No | Show process tree (-t) | |
| include_kernel | No | Also show kernel processes (-k) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It implies a read-only listing and documents the return shape (success/processes/count/error), which is useful. However it omits the Sysinternals-specific caveats an agent would care about, such as whether it wraps a local or remote call and any elevation requirements.
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?
Front-loaded with the core purpose in one sentence, then the wrapper note, then a cleanly sectioned return format. It is tight, though restating the return format when an output schema already exists is mildly redundant.
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 two-parameter read tool with full schema coverage and an output schema, the definition is nearly sufficient. The gaps are the missing sibling differentiation (pslist_detail) and the absence of any privilege or scope behavior, which matter for a Sysinternals process tool with no annotations.
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%, so both parameters (tree, include_kernel) are already fully documented with their underlying flags in the schema. The description adds nothing about the parameters, which is acceptable at full coverage but earns only the baseline.
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?
States a specific verb (List) and resource (processes) and enumerates the exact output fields (PID, CPU time, thread count, handle count), which is more informative than a bare 'list processes'. It does not, however, differentiate itself from the very similar sibling pslist_detail, so an agent must guess at the distinction.
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 choose this tool over pslist_detail, psinfo, or the other process-oriented siblings, and no preconditions (e.g. privilege requirements) are stated. The description merely says what it does, not when to reach for it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List details for processes matching a name.
{"success": bool, "processes": list[dict], "count": int}
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Process name to filter (e.g. explorer |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it only repeats a return shape that the output schema already defines. It says nothing about required privileges, remote vs local scope, performance cost, or what 'details' actually contains for each process.
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 core sentence is front-loaded and free of filler. The appended return-format block is somewhat redundant given the output schema, but it stays short and clear.
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 output schema exists, so the return values need not be re-explained, and one fully-documented parameter keeps the input side simple. Still, with zero annotations the description is thin: it never clarifies local vs remote scope or what fields the per-process 'details' include, which matters for choosing against psinfo or pslist.
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?
Single required parameter with 100% schema description coverage, so the schema already documents 'name' as a process-name filter. The description's phrase 'matching a name' adds no syntax (exact match? wildcard? case sensitivity?) beyond what the schema provides, making baseline 3 correct.
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?
States a specific verb ('List') plus resource ('processes') and a scoping filter ('matching a name'), so the operation is unambiguous. However, it never distinguishes itself from close siblings such as pslist or psinfo, leaving the agent to guess which process-listing tool to pick.
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 when-to-use guidance, no prerequisites, and no mention of alternatives, despite several overlapping siblings (pslist, psinfo, psinfo_remote). The agent gets no signal about when this detail view is preferable to the plain listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List users logged on locally and optionally via network connections.
Wraps Sysinternals PsLoggedon.
{"success": bool, "users": list[dict], "count": int, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| local | No | Show locally logged-on users | |
| network | No | Show network logons from this machine (-x) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond the operation itself. It does not mention that PsLoggedon typically requires administrative privileges, that the network mode probes remote hosts (with latency/security implications), or any side effects. The return-format block is largely redundant because an output schema already exists.
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 core sentence is short and front-loaded, and the return-format section is cleanly separated. The return-format block is somewhat wasteful given a dedicated output schema, but the overall structure is tight and readable.
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 two-boolean read tool with an output schema, the description is minimally sufficient. It omits the admin-privilege prerequisite and the local-vs-psloggedon_server distinction, both of which an agent needs to select and run this tool 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 description coverage is 100%, and the schema already documents both booleans, their defaults, and the '-x' flag mapping for network. The description adds no syntax or behavior detail beyond what the schema provides, so the 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?
States a specific verb and resource ('List users logged on') with scope ('locally and optionally via network connections'), so the agent knows exactly what it returns. It does not, however, differentiate itself from the sibling psloggedon_server, which is a likely source of confusion for a remote-vs-local question.
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 explicit when-to-use or when-not-to-use guidance, and the closest alternative, psloggedon_server, is never named. The only usage signal is implicit in the parameter defaults (local=true, network=false), which is inference rather than guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List users logged on to a remote server.
{"success": bool, "users": list[dict], "count": int}
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes | Remote server name to check |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It provides a return shape but says nothing about the remote registry/permission requirements that remote logon enumeration typically needs, nor about failure modes or whether access is read-only. A one-line purpose plus a return format is thin disclosure for a no-annotation tool.
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 purpose sentence is front-loaded and the return format is separated into a labeled block, with no wasted words. The Return Format block is somewhat redundant given an output schema already exists.
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?
This is a simple single-parameter read tool with an output schema, so the description does not need to explain return values. Purpose and the required input are covered; only remote-access prerequisites are missing.
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% and there is only one parameter ('server'), already documented as 'Remote server name to check'. The description adds no format, naming, or addressing detail beyond the schema, so the baseline 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 states a specific verb and resource ('List users logged on to a remote server'), which is clearly understandable on its own. It implicitly distinguishes itself from the local `psloggedon` sibling via the 'remote server' scoping, but never names that sibling explicitly.
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?
'remote server' hints at when this tool is appropriate versus the local variant, but there is no explicit guidance on alternatives, prerequisites, or when not to use it. Usage is only implied through the parameter context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show file-backed page cache summary from system working set.
Reports cached file extensions, top mapped files, and system cache totals. Uses WMI queries against the operating system cache manager.
{"success": bool, "cache_total_mb": float, "sections": list[dict], "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does disclose the underlying mechanism ('Uses WMI queries against the operating system cache manager') and what the output contains. However, it does not state that this is a read-only operation, whether it requires elevated privileges, or any performance cost of running WMI queries.
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 front-loaded with the purpose, followed by a short detail sentence and a return-format block. It is appropriately sized with no filler, though the return-format section repeats type information already implied by the output schema.
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 zero-parameter diagnostic tool with an existing output schema, the description covers purpose, output contents, and data source. It is largely complete, with only the missing read-only/permission context as a minor gap.
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 tool takes zero parameters, so there is nothing for the description to disambiguate beyond the schema. Baseline 4 applies for a parameterless tool.
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 states a specific verb and resource ('Show file-backed page cache summary from system working set') and enumerates what it reports (cached file extensions, top mapped files, system cache totals). It is clearly distinguishable from the sibling rammap_physical/rammap_summary tools by its file-backed cache focus, though it never explicitly names a sibling.
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 the other rammap_* siblings or alternatives. Usage is only implied by the resource name; no conditions, prerequisites, or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show physical memory usage breakdown by category.
RAMMap-style view: active, standby, modified, modified-no-write, transition, zeroed, free, and bad page counts. Also reports total, available, cached, and page-file sizes.
Uses a single PowerShell script that queries WMI and performance counters. No binary download required.
{"success": bool, "categories": dict, "totals": dict, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| detailed | No | Include per-category breakdown with standby list details |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add real behavioral context: it discloses the data sources (WMI plus performance counters), that it runs as a single PowerShell script, and that no binary download is required. It does not explicitly state read-only status, but the operation is self-evidently a read-only view, so the gap is minor.
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?
Purpose is front-loaded in the first line, follow-up details are partitioned under a clear 'Return Format' header, and each sentence conveys distinct information (categories, data source, no-download trait). Slightly long due to the full category enumeration, but nothing is wasted.
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 is a simple read-only view and the description covers purpose, data-source mechanics, and even the return shape, so an agent has what it needs to call it. With an output schema present the return-format text is somewhat redundant, but no critical calling information is missing.
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% and the sole 'detailed' parameter is fully documented in the schema, so the baseline of 3 applies. The description never references or expands on the 'detailed' flag, offering no syntax or effect beyond what the schema already provides.
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?
States a specific verb and resource: 'Show physical memory usage breakdown by category,' and enumerates the exact categories (active, standby, modified, zeroed, free, bad, etc.) plus totals. It clearly conveys scope, but it never explicitly distinguishes itself from the sibling rammap_summary/rammap_processes/rammap_file_backed 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?
Usage is only implied by the purpose ('RAMMap-style view' of physical memory); there is no explicit when-to-use statement and no routing to the closely related rammap_* siblings. An agent can infer the intent, but nothing tells it when to prefer this over rammap_summary or rammap_treemap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show per-process memory usage: working set, private bytes, shareable, pagefile.
RAMMap-style process list sorted by working set descending.
Uses Get-Process with WMI extensions for private working set data. No binary download required.
{"success": bool, "processes": list[dict], "count": int, "total_ws_mb": float, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | Number of top processes to return |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add real behavioral context: sorted by working set descending, sourced via Get-Process with WMI extensions, and no binary download required. It still omits permission/admin requirements and any rate or scope caveats, so it is only partially complete.
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?
Content is front-loaded, with the metric list first and implementation notes after, and it uses a clear Return Format block. The 'No binary download required' line is marginally useful but adds noise for an agent that just needs to call the tool.
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 single-parameter read tool, the definition covers purpose, sort order, data source, and the full return shape, so an agent has enough to invoke it. Only the routing decision against the other rammap/pslist siblings remains unclear.
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 single top_n parameter is already fully documented by the schema. The description never mentions top_n or its default/limit, so it adds no meaning beyond the schema; baseline 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?
States a specific verb (Show) plus resource (per-process memory usage) and enumerates the metrics: working set, private bytes, shareable, pagefile. This distinguishes it from the rammap_summary/physical/file_backed siblings, which cover aggregate or non-process memory. However, it does not explicitly name which sibling to prefer, so it falls short of 5.
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 explicit when-to-use guidance and no named alternative. The phrase 'RAMMap-style process list' implies a context, but an agent is left to infer when this beats pslist or rammap_summary. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Combined memory diagnostic: physical breakdown + top processes + file cache.
One-shot equivalent of calling rammap_physical, rammap_processes (top 10), and rammap_file_backed.
{"success": bool, "physical": dict, "top_processes": list[dict], "file_cache": dict}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that process data is truncated to the top 10 and that three underlying diagnostics are combined, but says nothing about whether the call is read-only, its cost/latency, or any failure modes beyond the 'success' bool.
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 tight sentences front-load the purpose and the sibling equivalence. The '## Return Format' block duplicates what the existing output schema already conveys, which is the only mild redundancy.
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 zero-parameter aggregate tool with an output schema, the description covers what is aggregated and what comes back. It stops short of noting cost (three underlying queries in one call) or read-only safety, but nothing essential to invoking it correctly is missing.
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 tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies; no parameter-level guidance is possible or 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?
States a specific verb and resource ('Combined memory diagnostic') and explicitly enumerates the three sibling tools it consolidates (rammap_physical, rammap_processes, rammap_file_backed). An agent can distinguish it from those siblings without opening any schema.
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 phrase 'One-shot equivalent of calling rammap_physical, rammap_processes (top 10), and rammap_file_backed' tells the agent exactly when to prefer this over three separate calls. It gives no explicit when-not condition, but the aggregation framing makes the tradeoff inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a WizTree-style interactive treemap of process memory usage.
Creates a self-contained HTML file with an embedded D3.js squarified treemap, colored by process category (system, browser, dev, media, etc.) with hover tooltips showing PID, working set, and private bytes.
The HTML is fully self-contained (loads D3 from CDN) and opens in any browser.
{"success": bool, "file_path": str, "processes": int, "total_mb": float}
rammap_treemap(top_n=100, min_ws_mb=0.5)| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | Number of top processes to include in treemap | |
| min_ws_mb | No | Minimum working set in MB to include |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose key traits: it writes a self-contained HTML file, loads D3 from a CDN (network dependency), and opens in any browser. It stops short of stating where the file is written or whether it overwrites existing files, but the side-effect profile is well conveyed.
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?
Purpose is front-loaded in the first sentence, followed by clearly-sectioned Return Format and Examples. The color-category and hover-tooltip details are useful, if slightly decorative; overall it is well organized with little waste.
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?
An output schema exists, so return values needn't be re-explained (though the description does so anyway, harmlessly). For a file-generating visualization tool, the description covers output artifact, format, and dependencies adequately; only the output file location is left unstated.
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%, so both parameters (top_n, min_ws_mb) are already documented in the schema with defaults and bounds. The description's example call adds a usage illustration but no new semantic meaning; baseline 3 applies when the schema does the heavy lifting.
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?
States a specific verb (generate) and resource (interactive treemap of process memory usage), and further specifies the WizTree-style output with D3.js. An agent can tell it produces a visual HTML artifact rather than a text list, distinguishing it from rammap_processes, though it never names a sibling explicitly.
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?
Usage is only implied — an agent infers this is for visual/exploratory memory analysis, but there is no explicit when-to-use, when-not, or reference to rammap_processes/rammap_summary as alternatives. Nothing tells the agent when a treemap is preferable to a plain process listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify file digital signatures, version info, and optionally check VirusTotal.
Wraps Sysinternals Sigcheck with CSV output parsing.
{"success": bool, "files": list[dict], "count": int, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File or directory path to scan | |
| recursive | No | Scan subdirectories recursively (-s) | |
| accept_eula | No | Accept EULA (stored once) | |
| virus_total | No | Look up SHA-256 on VirusTotal (-v) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it wraps an external Sysinternals binary and parses CSV, which is useful context, but omits permission/admin requirements, the one-time EULA acceptance behavior, and any VirusTotal rate limits or network implications.
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 purpose sentence is front-loaded and the return-format block is clearly labeled, with no filler. The return block is slightly redundant given an output schema exists, but overall structure is tight and readable.
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?
An output schema exists so return values need not be explained, and the schema covers all params. However, for a network-touching, external-binary-wrapping tool with no annotations, the description stops short of the operational caveats (EULA, admin rights, VirusTotal limits) that would make it 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?
Schema description coverage is 100%, so the schema already documents all four parameters including the optional VirusTotal lookup. The description only restates that VirusTotal is optional and adds no syntax, format, or precedence details beyond the schema, so baseline 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?
States a specific verb (verify) and concrete resources (file digital signatures, version info, optional VirusTotal lookup), and names the underlying Sysinternals tool. An agent can immediately tell what it does, though it does not explicitly differentiate itself from the many sibling Sysinternals 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?
There is no when-to-use or when-not-to-use guidance and no named alternatives. The word 'optionally' describes a feature flag rather than selecting between tools, so the agent must infer relevant scenarios on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all TCP/UDP connections with owning process.
Wraps Sysinternals Tcpvcon with CSV output parsing.
{"success": bool, "connections": list[dict], "count": int, "error": str | None}
| Name | Required | Description | Default |
|---|---|---|---|
| all_states | No | Show all states, incl. TIME_WAIT (-a) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that it wraps a Sysinternals binary and parses CSV output, which hints at the mechanism, but it omits whether elevated privileges are required, whether enumeration is system-wide, and any side effects. "List" implies a safe read, but that is inference rather than disclosure.
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?
Purpose is front-loaded in one line, followed by a compact implementation note and a return-shape block. Slightly redundant given a formal output schema already exists, but nothing is bloated.
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 single-parameter read tool with an output schema present, the definition covers purpose, mechanism, and return format adequately. The remaining gap is the absence of any privilege or environment requirement, which would matter for a tool that wraps an admin-level Sysinternals utility.
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%, and the single all_states parameter is documented in the schema with its -a flag and default. The description adds no further parameter meaning beyond what the schema already states, so the baseline 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?
Specific verb ("List") plus specific resource ("TCP/UDP connections") plus scope ("with owning process"), and it identifies the underlying implementation (Sysinternals Tcpvcon). No sibling tool in the list covers network connections, so the agent can route to it unambiguously.
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 statement of when to use this tool versus anything else, no preconditions, and no exclusions. It presumes the agent already knows it wants a connection listing; nothing in the text helps it decide.
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.
v0.1.0accesschkaccesschk_serviceautorunscautorunsc_schedulecoreinfodudu_quickhandle64handle64_by_pidlistdllslistdlls_by_pidpsfilepsfile_closepsinfopsinfo_remotepslistpslist_detailpsloggedonpsloggedon_serverrammap_file_backedrammap_physicalrammap_processesrammap_summaryrammap_treemapsigchecktcpvconScored across 26 tools
Most tools target distinct Sysinternals utilities or have clear variant suffixes (local/remote, by_pid, quick, schedule), but some overlap exists (e.g., pslist vs pslist_detail, accesschk vs accesschk_service) where boundaries rely on subtle description cues.
All tool names use consistent snake_case with underscores for variants (e.g., _by_pid, _remote, _service, _quick), and there is no mixing of camelCase or other naming conventions.
With 26 tools, the set exceeds the typical 3-15 range; many are niche variants (e.g., five rammap_* tools, multiple duplicate base operations) making it heavy and potentially overwhelming for an agent to navigate.
The set covers a wide range of Windows diagnostics (processes, DLLs, handles, network, autoruns, memory, disk), but lacks action-oriented tools (e.g., process termination, service control) and some Sysinternals utilities (e.g., pskill, psloglist), leaving minor gaps.
Reasoning, code, anti-deception, memory harness MCP tools. Stdio or HTTPS api.ejentum.com/mcp
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
