Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds the useful behavioral fact that this is an aggregation across six distinct data domains, but says nothing about cost, depth of traversal, or result size for what is clearly a fan-out query.

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 listing the returned domains with no filler. It is terse to the point of being a fragment, but every word carries information and 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?

With no output schema, the description's enumeration of the six returned data domains is what tells the agent what the result looks like, which fills the main gap. For a one-parameter read-only tool with full annotation coverage, little else is required; only traversal depth and result-size expectations 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 the single pid parameter is self-documented. The description confirms the singular scope ('one process id'), matching the schema but adding no format, range, or identity semantics beyond it; the baseline of 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?

The description names a specific verb ('explain') and resource ('one process id') and enumerates the returned data domains (signature, ancestry, children, connections, findings, autostarts). This is far more informative than the title 'Everything about one process', though it does not explicitly contrast itself with siblings like list_findings or list_connections.

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: 'for one process id' signals this is the single-process drill-down aggregating what the list_* siblings return individually. There is no explicit when-to-use vs when-not statement or routing to alternatives for callers who only need one category.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so safety is covered. The description adds genuine behavioral context beyond them: the default output is pruned to agents, MCP servers and network-active processes, which materially shapes what the agent will receive. It stops short of describing ordering, depth limits, or volume characteristics.

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 action and contents, followed by routing guidance and the default-scope caveat. Three sentences, no filler, and the parenthetical product list earns its space by aiding recognition.

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 no output schema, the description fully covers what the returned trees contain and how they are scoped by default, while annotations carry the safety profile. An agent has everything needed to invoke and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter's description already explains the default and the tracing use case. The description's mention of pruning restates the same default rather than adding format or syntax detail, 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 (list) and resource (process trees of running AI agents), then enumerates exactly what each tree contains: the agent, its MCP servers, spawned programs, and network connections. It explicitly contrasts itself with list_connections and explain_process, so an agent can route correctly 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?

Gives a positive trigger ('Use this to see which agent or MCP server a process or connection belongs to') plus two explicit alternatives with their selecting conditions: list_connections for every connection on the PC, explain_process for one process in depth. Nothing 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial behavior beyond the annotations: the 300-entry cap with total/truncated signaling, the meaning of not_checked (System32/SysWOW64 files not verified), default filtering to problems only, and the admin-rights limitation on scheduled-task visibility. These are exactly the operational caveats an agent needs and the annotations do not carry.

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 action and resource in the first clause, then layers constraints in a tight sequence. Every sentence carries distinct operational information (cap, not_checked, admin limitation) with no filler.

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?

There is no output schema, and the description compensates by explaining the aggregate fields (total, truncated, not_checked) and the default filtering behavior. Combined with 100% schema coverage, an agent has everything needed to call and interpret this 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 both parameters are already documented in the schema, including the enum values for kind and the default for problems_only. The description's 'problem entries ... set problems_only to false to see everything' largely restates that schema text, 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?

Names a specific verb (List) and resource (programs set to start automatically), and enumerates the concrete sources it covers: Run keys, Startup folder, services, scheduled tasks, Winlogon. It also states it returns signature status for both the program and its host loader, which no sibling tool could plausibly duplicate.

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?

Explicitly states the use case ('Use this to look for persistence') and cross-references the sibling list_findings for severity-triaged suspicious entries. It does not state a hard when-not-to-use rule (e.g. use list_findings instead when you only want scored findings), so guidance is clear but not fully exclusive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world behaviour, so the safety profile is fully covered. The description adds meaningful content about what is returned (owning process, publishing organisation for the peer IP range), but says nothing about volume limits, pagination, or how connections are ordered, which matters for a potentially large network listing.

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 well-formed sentence that front-loads the core resource and then appends the return-value detail. No filler, no restatement of the tool name or title.

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 small, filter-only read tool with full schema documentation and annotations covering the safety profile, the description supplies the missing return-shape information (process owner, publisher attribution). Only the absence of any guidance on result volume or ordering keeps it from a 5.

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 every parameter (pid, agents_only, include_loopback) is already documented in the schema with defaults. The description adds no filter semantics or constraints 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?

Names a specific resource and qualifier: 'Established TCP connections', which separates it from the sibling list_listening_ports without naming it explicitly. The added detail about owning process and publishing organisation clarifies what the listing contains. It stops short of an explicit sibling comparison, keeping it at a solid 4.

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 qualifier 'Established' — an agent can infer this is for active/outbound connections rather than listening sockets — but the description never says when to prefer this over list_listening_ports, login_activity, or list_agents, and states no exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint/idempotentHint, so the safety profile is covered. The description adds real value beyond that by disclosing ordering (most severe first) and flagging that untrusted_evidence is raw host text, which alerts the agent to treat that field as untrusted data.

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 sentences, zero filler, front-loaded with scope and ordering before the return-shape detail. Every clause earns its place.

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 no output schema, the description usefully sketches the per-finding shape (fixed title, detail, untrusted_evidence), and the schema covers both optional filters with defaults. Minor gaps remain around result volume/pagination, but nothing essential to correct invocation 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 both parameters carry their own descriptions and defaults, so the schema does the heavy lifting. The description never mentions min_severity or include_acknowledged, adding no semantics beyond the schema — 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 ('Every finding from the rules') plus ordering ('most severe first') and return shape, which cleanly distinguishes it from siblings like list_connections, login_activity, and list_listening_ports.

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 resource: an agent can infer this is the enumeration endpoint for findings. However, there is no explicit when-to-use guidance, no mention of how it relates to scan_summary or explain_process, and no indication that min_severity/include_acknowledged narrow results.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only/idempotent safety, and the description adds real behavioral context on top: loopback-only listeners are filtered out, results are one entry per process, and administrator rights determine whether other users' and system processes appear. That permission caveat is the kind of disclosure an agent needs to interpret sparse results correctly.

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?

Three sentences, each doing distinct work: scope and return shape first, the sibling alternative second, the permission caveat last. No filler and the most decision-relevant information is front-loaded.

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, read-only listing tool with no output schema, the description covers the return contents (addresses, signature status, originating agent), the filtering rule, and the permission limitation. Nothing an agent needs to call or interpret it 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 no parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The prose correctly implies an unfiltered global listing rather than suggesting any hidden options.

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 processes accepting inbound TCP connections) and immediately scopes it against the sibling list_connections. The agent can distinguish this from every other sibling without opening a 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?

Explicitly names the question it answers ('what this PC exposes to the network') and routes the alternative case ('for outgoing connections to other machines, use list_connections'). When-to-use and when-to-use-something-else are both stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare a safe, read-only, idempotent, closed-world operation, so the safety burden is lifted. The description adds genuinely useful behavioral context beyond them: it requires administrator rights and degrades gracefully by reporting 'not checked' rather than failing silently, which tells the agent how to interpret a partial result.

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 sentences, no filler. The what/scope comes first and the operational caveat (admin rights, degradation behavior) is placed second, which is the right front-loading order.

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 no output schema, the description carries the return-value burden, and it does describe the content (failed and RDP logons) and the failure mode. It stops short of describing the shape of individual entries or any pagination/volume limits, which is a minor gap for a log-dump 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly spends no space on parameter syntax.

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 resource (Windows Security log), the exact event classes retrieved (failed logons and Remote Desktop logons), and a bounded time window (last 24 hours). This is specific enough that an agent can distinguish it from siblings like list_findings or list_connections without consulting 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 scope ('last 24 hours', 'Windows Security log') implies the situation in which this tool is the right pick, but the description never states when to use it versus alternatives, nor any exclusions. Usage is inferable rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value beyond that by disclosing the shape of the result categories, including the negative case ('what could not be checked'), which helps the agent interpret an incomplete scan.

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 dense sentence that front-loads the action, then lists outputs in priority order, ending with the sequencing directive. No filler and nothing an agent must read twice.

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 no output schema present, the description carries the return-value burden and does so by naming the verdict scale and the result buckets. For a zero-param read-only scan, nothing needed to invoke or interpret it 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?

Zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly implies no input is needed, and the empty schema with additionalProperties:false is consistent.

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 ('scan') and resource ('this PC'), plus an enumeration of what comes back: verdict (ok/review/alert), reportable findings, running AI agents with MCP servers, and unchecked items. This distinguishes it from list_findings and list_agents, which are narrower slices of the same data.

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?

'Call this first' gives an explicit entry-point ordering instruction, which is exactly the context an agent needs to sequence its calls. It does not, however, name when to prefer a sibling (e.g. list_findings) for follow-up, so it stops short of full alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.