Fetch system information from a remote computer by hostname for troubleshooting, audits, and inventory reports.
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 | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does 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.