How do I use local-network-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@local-network-mcp Check why the Raspberry Pi dropped off the network" 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.

local-network-mcp

by ahmed-hashim-pro

Overview Schema Source Related Servers Discussions Admin

Python

Local

Local Network MCP Server

License: MIT

A Model Context Protocol (MCP) server that allows Claude to interact with your local network, execute local shell commands, monitor system resources, and manage remote devices via SSH.

It turns "can you check why the Raspberry Pi dropped off the network" into a workflow the agent executes itself: scan_network → ping_host → ssh_connect → ssh_execute → diagnosis. Persistent SSH sessions mean the agent connects once and runs multi-step remote workflows (inspect logs, restart a service, verify) in a single conversation.

Demo

Illustrative walkthrough — Claude discovers a device on the local network, opens a persistent SSH session, and diagnoses the fault end to end. Reconstructed for the README; not a recording of a live run.

Related MCP server: ssh-client-mcp-server

Security model

An LLM decides when these tools run, which makes "the operator will be careful" useless as a control. So the three tools that can change or destroy state are off unless you turn them on:

Tool	Can do	Default	Opt in with
`execute_local_command`	run any local shell command	denied	`LNMCP_ENABLE_EXEC=1`
`ssh_execute`	run any command on a remote host	denied	`LNMCP_ENABLE_SSH_EXEC=1`
`kill_process`	terminate a process by PID	denied	`LNMCP_ENABLE_KILL=1`

Everything else — discovery, ping, port checks, system stats, process listing, directory listing, file search — is read-only and always available. Out of the box this server is a diagnostic instrument that cannot change anything.

Disabled tools are also advertised as disabled in the tool listing, so the agent knows not to spend a turn on them. A refusal names the variable that would allow the call:

{
  "success": false,
  "policy": "default-deny",
  "tool": "execute_local_command",
  "error": "execute_local_command is disabled because it can change or destroy state. Set LNMCP_ENABLE_EXEC=1 in the server's environment (the \"env\" block of your MCP client config) and restart the server to enable it."
}

Two properties make this a boundary rather than a suggestion:

The switch is not reachable from a tool argument. It lives in the server's environment, which you set in the client config. execute_local_command does take an env parameter, but that is applied to the child process — passing env={"LNMCP_ENABLE_EXEC": "1"} enables nothing. The agent cannot turn its own guardrails off, and there is a test for exactly that.
The gate sits at each tool's own entry point, not at the dispatch layer, so an internal caller cannot route around it — ssh_execute stays refused even though it is reachable via ssh_connect.

What this does not do

The limits matter more than the feature list:

Once enabled, execute_local_command runs arbitrary shell commands with the permissions of the server process. There is no allowlist and no sandbox. The opt-in is a deliberate per-tool decision, nothing more.
SSH uses AutoAddPolicy, so an unknown host key is accepted on first contact. Convenient on a LAN you own; wrong on a network you do not.
Tool calls are not audit-logged.

Run it against machines you own.

Architecture

flowchart LR
    C[Claude] <-->|MCP / JSON-RPC over stdio| S[network_mcp_server.py]
    S --> G{policy gate}
    G -->|read-only, always on| RO["scan_network, ping_host, check_port<br/>get_system_info, list_processes<br/>find_files, get_directory_listing"]
    G -->|state-changing, opt-in| RW["execute_local_command<br/>ssh_execute, kill_process"]
    RW -. denied unless LNMCP_ENABLE_* .-> C
    RO --> N[(local network / this host)]
    RW --> N
    S -.->|persistent sessions| POOL[(SSH connection pool)]

A single stdio server. list_tools advertises the catalogue and stamps disabled tools; call_tool dispatches by name. Each state-changing function re-checks the policy itself before doing any work. SSH connections are pooled by user@host:port so a multi-step remote workflow authenticates once.

Features

Local System Tools

Execute Local Commands: Run shell commands on your local machine
System Information: Get CPU, memory, disk, and network details
Process Management: List, monitor, and kill processes
Environment Variables: View and filter environment variables
Directory Operations: List, search, and navigate directories
Disk Usage: Monitor disk space usage
File Search: Find files matching patterns
Network Connections: Monitor active network connections

Network Tools

Get Local IP: Find your machine's IP address and network range
Network Scanning: Discover all active devices on your local network
Ping Hosts: Check if specific devices are online
Port Checking: See if specific ports are open on any device
Port Scanning: Scan multiple ports on any device at once

SSH Tools

SSH Connect: Establish persistent SSH connections to remote devices
SSH Execute: Run commands on remote devices via SSH
SSH Disconnect: Close SSH connections
SSH List Connections: View all active SSH sessions

Installation

Python 3.11+.

git clone https://github.com/ahmed-hashim-pro/local-network-mcp.git
cd local-network-mcp

python3 -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate
pip install -e .

A virtualenv is not optional on most systems: a Homebrew or system Python will refuse a bare pip install with error: externally-managed-environment (PEP 668).

Verify the install — this prints the policy state and exits, unlike starting the server, which waits on stdin for an MCP client and will look like it has hung:

python -c "import network_mcp_server as s; print({t: s.is_tool_enabled(t) for t in s.DESTRUCTIVE_TOOLS})"
# {'execute_local_command': False, 'ssh_execute': False, 'kill_process': False}

Run the tests (no credentials, no network, no reachable hosts required):

pip install -e ".[dev]"
pytest

Configuration

Add this server to your Claude Desktop configuration:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Windows: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "local-network": {
      "command": "/path/to/local-network-mcp/.venv/bin/python",
      "args": ["/path/to/local-network-mcp/network_mcp_server.py"]
    }
  }
}

That configuration is read-only: the agent can discover and diagnose, but not change anything. To enable a state-changing tool, add it to an env block — and add only the ones you actually want:

{
  "mcpServers": {
    "local-network": {
      "command": "/path/to/local-network-mcp/.venv/bin/python",
      "args": ["/path/to/local-network-mcp/network_mcp_server.py"],
      "env": {
        "LNMCP_ENABLE_SSH_EXEC": "1"
      }
    }
  }
}

(A template is provided in claude_desktop_config.json — update the path to where you cloned the repo.)

Or register with Claude Code:

claude mcp add local-network -- /path/to/local-network-mcp/.venv/bin/python \
  /path/to/local-network-mcp/network_mcp_server.py

After adding the configuration, restart Claude Desktop.

Usage Examples

The first three groups below use tools that are denied by default. See Security model for the opt-in.

Local Command Execution

"Execute 'ls -la' on my local machine"
"Run 'git status' in ~/projects"
"Execute 'npm install' with a 60 second timeout"
"Run 'python script.py' with custom environment variables"

System Monitoring

"What's my system information?"
"Show me CPU and memory usage"
"List all running processes"
"Show me processes using the most CPU"
"What processes are running that match 'python'?"
"Show my environment variables"
"Find all PATH-related environment variables"

Process Management

"Kill process with PID 12345"
"Force kill the stuck process 9876"
"List all Python processes"

Directory & File Operations

"List files in ~/Documents"
"Show me all files in the current directory recursively"
"Find all Python files in my projects folder"
"Search for '*.log' files in /var/log"
"What's the disk usage of my home directory?"
"Show hidden files in my home directory"

Network Monitoring

"Show all active network connections"
"List all TCP connections"
"What ports are currently listening on my machine?"

Network Operations

"What devices are on my network?"
"Is 192.168.1.100 online?"
"Check if port 8080 is open on my server"
"Scan common ports on 192.168.1.50"
"What's my local IP address?"

SSH Operations

"Connect to my Raspberry Pi at 192.168.1.100 with username pi"
"Execute 'df -h' on 192.168.1.100"
"Check disk space on my server"
"List running processes on the remote machine"
"Show all active SSH connections"
"Disconnect from 192.168.1.100"

Available Tools

Local System Tools

`execute_local_command`

Denied by default — opt in with LNMCP_ENABLE_EXEC=1. Execute shell commands on your local machine with full control.

Parameters:

command (required): Shell command to execute
shell (optional): Use shell interpretation (default: true)
timeout (optional): Command timeout in seconds (default: 30)
cwd (optional): Working directory for execution
env (optional): Additional environment variables

Example:

Execute 'git status' in ~/projects/myapp

`get_system_info`

Get comprehensive system information including platform, CPU, memory, disk, and network details.

Example:

Show me my system information

`list_processes`

List running processes with CPU and memory usage, sorted by CPU usage.

Parameters:

filter_name (optional): Filter processes by name
limit (optional): Maximum number of results (default: 50)

Example:

List all Python processes
Show me the top 20 processes by CPU usage

`kill_process`

Denied by default — opt in with LNMCP_ENABLE_KILL=1. Terminate or force kill a process by PID.

Parameters:

pid (required): Process ID to kill
force (optional): Use SIGKILL instead of SIGTERM (default: false)

Example:

Kill process 12345
Force kill process 9876

`get_environment_variables`

View system environment variables with optional filtering.

Parameters:

filter_key (optional): Filter by key name

Example:

Show all environment variables
Find PATH-related environment variables

`get_directory_listing`

List directory contents with detailed file information.

Parameters:

path (optional): Directory path (default: current directory)
recursive (optional): List recursively (default: false)
show_hidden (optional): Show hidden files (default: false)
max_depth (optional): Maximum recursion depth (default: 3)

Example:

List files in ~/Documents
Show all files recursively in my projects folder

`get_disk_usage`

Get disk usage information for any path.

Parameters:

path (optional): Path to check (default: /)

Example:

What's the disk usage of my home directory?
Show disk space for /var

`find_files`

Search for files matching a pattern.

Parameters:

path (required): Starting directory
pattern (required): File pattern (e.g., ".py", "test.txt")
recursive (optional): Search recursively (default: true)
file_type (optional): Filter by "file" or "directory"
max_results (optional): Maximum results (default: 100)

Example:

Find all Python files in ~/projects
Search for log files in /var/log

`get_network_connections`

View active network connections and listening ports.

Parameters:

filter_type (optional): Filter by "tcp" or "udp"

Example:

Show all TCP connections
What ports are listening on my machine?

SSH Authentication

The server supports two authentication methods:

1. Password Authentication

# Claude will prompt for credentials
"Connect to 192.168.1.100 with username admin and password mypassword"

2. SSH Key Authentication

# Using SSH key file
"Connect to 192.168.1.100 with username admin using key ~/.ssh/id_rsa"

SSH Connection Management

The server maintains persistent SSH connections for better performance:

Connections are reused across multiple command executions
No need to reconnect for each command
Automatic connection recovery if a connection drops
Manual disconnect when done

Operational notes

The enforced policy is described under Security model above. These are the operational caveats that sit alongside it:

Enabled commands run with the permissions of the server process. Run it as a user with the least privilege that still does the job — not as root.
You need permission to scan the network you point it at, and scanning may trip intrusion detection on a corporate LAN.
Prefer SSH keys over passwords. Credentials passed as tool arguments are held in memory for the life of the pooled connection and are never written to disk, but a key file that Paramiko reads is still the safer path.
AutoAddPolicy accepts unknown host keys on first contact, so first connection on an untrusted network is trust-on-first-use with no verification.

Common Local Commands

System Information

uname -a - System information
hostname - Get hostname
uptime - System uptime
df -h - Disk usage
free -h - Memory usage (Linux)
top -l 1 - CPU snapshot (macOS)

Process Management

ps aux - List all processes
htop - Interactive process viewer
lsof - List open files

File Operations

ls -la /path - List files
cat /path/to/file - Read file contents
pwd - Current directory
du -sh /path - Directory size
find /path -name "*.txt" - Find files

Network Operations

ifconfig or ip addr - Network interfaces
netstat -an - Network connections
lsof -i - Network files
ping -c 4 google.com - Test connectivity

Development Commands

git status - Git repository status
npm install - Install Node.js packages
python --version - Check Python version
docker ps - List Docker containers

Troubleshooting

Server Issues

Check that Python is in your PATH
Verify the full path in the config file
Check Claude Desktop logs
Ensure you have required permissions
Try running the script manually first
Install missing dependencies: pip install -r requirements.txt

Command Execution Issues

Verify you have permissions to execute the command
Check if the command exists in PATH
Try running the command manually in terminal
Increase timeout for long-running commands
Check working directory is correct
Verify environment variables are set properly

SSH Connection Issues

Verify the host is reachable (ping_host tool)
Check if SSH port (22) is open (check_port tool)
Verify username and credentials
Check SSH server is running on target
Ensure firewall allows SSH connections
For key auth, check key file permissions (should be 600)

Common Error Messages

"Command not found": Command not in PATH or doesn't exist
"Permission denied": Insufficient permissions to execute
"Timeout": Command took too long, increase timeout value
"Authentication failed": Wrong SSH username/password or key
"Connection refused": SSH server not running or firewall blocking

Requirements

Python 3.11+
mcp==1.29.1 — pinned to the 1.x line; 2.x removed the low-level Server.list_tools() / call_tool() decorators this server is built on
paramiko==5.0.0 (SSH), psutil==7.2.2 (system monitoring)
Network access permission for the range you scan
SSH access to target devices, for the remote tools

Example Workflows

Local System Management

1. Check system resources
   "Show me my system information"

2. Monitor processes
   "List all running processes"

3. Find resource-heavy processes
   "Show me the top 10 processes by CPU"

4. Kill problematic process
   "Kill process 12345"

5. Check disk space
   "What's my disk usage?"

Remote Server Management

1. Scan your network to find devices
   "Scan my network"

2. Check if SSH is available
   "Check if port 22 is open on 192.168.1.100"

3. Connect to the device
   "Connect to 192.168.1.100 with username pi"

4. Execute commands
   "Show disk space on 192.168.1.100"
   "List running processes on 192.168.1.100"

5. When done, disconnect
   "Disconnect from 192.168.1.100"

Development Workflow

1. Check project status
   "Execute 'git status' in ~/projects/myapp"

2. Run tests
   "Execute 'npm test' in my project directory with 120s timeout"

3. Monitor logs
   "Find all log files in my project"
   "Execute 'tail -n 50 app.log' in my project"

4. Check processes
   "List all node processes"

Performance Notes

Network scanning can take 30-60 seconds for full range (254 IPs)
Process listing is fast but may return many results
File search with recursive option can be slow on large directories
SSH connections are persistent and reused for better performance
Command timeouts prevent hanging on stuck commands

Roadmap

Command allowlist/denylist mode for execute_local_command, narrowing the current all-or-nothing opt-in
An audit log of every tool call, so an enabled server is reviewable
Strict host-key verification option to replace the AutoAddPolicy default
Structured JSON tool outputs alongside the current text responses
Configurable scan ranges and rate limiting for scan_network
Per-tool timeout and output-size caps
Port the low-level server to the mcp 2.x API (currently pinned to mcp<2)

Why this exists

I wanted an agent that could actually diagnose a device on my LAN rather than tell me which commands to type — "why did the Raspberry Pi drop off the network" answered by scan_network → ping_host → ssh_connect → ssh_execute, with the SSH session held open across the whole investigation instead of re-dialling per command.

Building it surfaced the more interesting problem. An MCP server is a set of capabilities handed to a non-deterministic caller, and the usual answer — document the risk and trust the operator — does not survive contact with that fact: the operator is not the one choosing when rm -rf runs. The design question is which capabilities are safe to expose by default, and what an opt-in has to look like so the model cannot grant it to itself. That is why the switch lives in the server's environment rather than in a tool argument, why the check sits at each function's own entry point rather than at the dispatch layer, and why the tests assert the refusal rather than the execution.

The Security model section is also honest about where the boundary stops: once enabled, execute_local_command is still arbitrary execution. A guardrail worth having is one whose limits you can state precisely.

License

MIT — see LICENSE.

Available Tools

18 tools

check_portA

Check if a specific port is open on a host

ParametersJSON Schema

Name	Required	Description	Default
`host`	Yes	IP address or hostname
`port`	Yes	Port number to check

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the behavioral burden; saying 'check if ... is open' communicates a read-only network probe and implies no destructive side effects. It does not disclose protocol (TCP/UDP), timeout behavior, or return format, which keeps it from being fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One short front-loaded sentence with no filler or repeated title content. Every word contributes meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool the description is adequate, but with no output schema or annotations it omits the return contract (true/false) and edge cases like closed or filtered ports. An agent can call it correctly but not know exactly what to expect back.

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

Parameters3/5

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

Schema description coverage is 100%, so the parameters are already fully documented. The description only rephrases host and port without adding 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('check') and resource ('port on a host') and includes the qualifier 'specific,' which distinguishes it from sibling tools like scan_ports and scan_network that imply broader scanning. The purpose is immediately unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The qualifier 'specific' implies this is the right tool for a single port check rather than a scan, so usage context is loosely conveyed. However, it does not explicitly mention alternatives or state when not to use it, leaving the agent to infer routing from sibling names.

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

execute_local_commandA

[DISABLED - set LNMCP_ENABLE_EXEC=1 to enable] Execute a shell command on the local machine. Returns stdout, stderr, and exit code.

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Working directory for command execution (optional)
`env`	No	Additional environment variables (optional)
`shell`	No	Use shell interpretation (default: true)
`command`	Yes	Shell command to execute
`timeout`	No	Command timeout in seconds (default: 30)

TDQS

A3.9/5.0

Behavior3/5

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

The description discloses return values (stdout, stderr, exit code) and the disabled-by-default state, which helps an agent predict outcomes. Missing, however, is a warning about the potentially destructive nature of arbitrary local shell commands, which is especially important with no annotations to fall back on.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the most critical operational constraint, and no filler. The output information and disabled-state notice are both essential and economically stated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

It covers the essential output contract and availability state, and sibling context makes the local-vs-remote distinction evident. It lacks enough guidance on risk, when to choose alternatives, and edge-case behavior for a tool with 5 parameters and no output schema, leaving it merely adequate rather than comprehensive.

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

Parameters3/5

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

Schema description coverage is 100%, and each parameter already has a meaningful description, including defaults for shell and timeout. The tool description adds no paramter detail, which is fine because the schema already carries that burden, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it executes a shell command on the local machine, using a specific verb and resource. The 'local machine' qualifier distinguishes it from remote execution tools like ssh_execute, and the disabled-state notice adds immediate clarity about availability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The disabled notice gives an explicit precondition for use (set LNMCP_ENABLE_EXEC=1), and 'local machine' signals when it applies versus remote alternatives. However, it does not explicitly name an alternative tool for remote execution, so the guidance is clear but not fully explicit.

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

find_filesB

Search for files matching a pattern in a directory

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Starting directory path
`pattern`	Yes	File pattern to match (e.g., '.py', 'test.txt')
`file_type`	No	Filter by type: 'file' or 'directory' (optional)
`recursive`	No	Search recursively (default: true)
`max_results`	No	Maximum number of results (default: 100)

TDQS

B3.3/5.0

Behavior2/5

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

Annotations are absent, so the description must carry the behavioral disclosure burden. It only states the high-level action and does not mention recursion defaults, return format, hidden-file handling, error behavior, or whether matches are paths or full objects. This leaves significant behavioral ambiguity for an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with no redundant words. It front-loads the action and the object, making it easy for an agent to parse quickly. Every word contributes to the core meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and no annotations, the description is minimal but arguably usable for basic cases. It does not explain the result shape, whether paths are absolute or relative, or how recursion and result limits behave beyond what the schema already states. This is adequate for a simple find operation but not complete for confident autonomous invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so the parameters are already well documented. The description adds only the generic idea of matching a pattern and a directory, which maps to path and pattern, but provides no extra semantic detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Search') and the resource ('files matching a pattern in a directory'), which makes the main purpose immediately understandable. It does not explicitly distinguish itself from siblings like get_directory_listing, but the pattern-matching wording provides enough differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: use this tool when you need to find files by pattern. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it compare against the close sibling get_directory_listing. The usage context is clear only at a basic level.

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

get_directory_listingC

List contents of a directory with detailed information

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Directory path to list (default: current directory)	.
`max_depth`	No	Maximum depth for recursive listing (default: 3)
`recursive`	No	List recursively (default: false)
`show_hidden`	No	Show hidden files (default: false)

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only says 'with detailed information,' which is vague and fails to explain whether the operation is read-only, what details are returned, how errors are handled, or how recursion affects output.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with the main action, but the phrase 'with detailed information' adds little substantive value and could mislead by overpromising richness. It is concise but borderline under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description needed to clarify what 'detailed information' means—such as file size, permissions, timestamps, or recursion behavior—but it does not. The parameters are well-documented in the schema, yet the overall tool behavior and return structure remain vague.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema already documents all four parameters with defaults and meanings. The description adds no parameter-level detail, but the baseline of 3 applies because the schema fully handles parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('List contents') and resource ('directory'), which clearly conveys the tool's basic purpose. However, it does not distinguish this from the sibling tool 'find_files', which could overlap with directory listings, so it is not fully differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives. There is no mention of recursive file searching being better served by 'find_files', nor any conditions for choosing this tool.

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

get_disk_usageC

Get disk usage information for a path

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Path to check disk usage (default: /)	/

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Get disk usage information.' It does not mention whether the operation is read-only, what happens for nonexistent paths or permissions errors, how files versus directories are handled, or what form the returned information takes. This is minimal disclosure for a tool with no annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler words. It is appropriately sized for a simple one-parameter tool, though the extreme terseness sacrifices useful context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description needs to convey what the tool returns; it does not. It also fails to clarify what 'disk usage information' includes or how it behaves on edge cases, leaving an agent under-informed when selecting among the many sibling tools.

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

Parameters3/5

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

The input schema already documents the single 'path' parameter with a description and default, so schema coverage is 100%. The tool description adds no meaning beyond what the schema provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Get'), a resource ('disk usage information'), and a scope ('for a path'), making it clear enough to distinguish from siblings like get_directory_listing or get_system_info. It stops short of 5 because 'disk usage information' is vague about whether it returns total, used, free space, or inode details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not say when to prefer this tool over alternatives, nor does it mention exclusions or relationships to sibling tools such as get_system_info or get_directory_listing. The only usage cue is the phrase 'for a path,' which weakly implies path-based checking but provides no real guidance.

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

get_environment_variablesB

Get system environment variables

ParametersJSON Schema

Name	Required	Description	Default
`filter_key`	No	Filter environment variables by key name (optional)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It merely restates the operation implied by the tool name and does not mention whether the operation is read-only, what the return format looks like, or whether all environment variables are returned when no filter is specified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no unnecessary words or filler. It communicates the core operation efficiently and is appropriately sized for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is minimally adequate for a tool with one optional parameter and no annotations: it names the operation, and the schema documents the filter. However, with no output schema, the return structure is not stated, and there is no mention of default behavior when no filter is provided.

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

Parameters3/5

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

The input schema fully describes the sole parameter filter_key, including its purpose and optionality. The description adds no parameter information, but the schema already covers all required semantics, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and a clear resource ('system environment variables'). It directly matches the tool name and is clearly distinct from sibling tools, which all pertain to networking, process, or file operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus any alternative, and no conditions or exclusions are mentioned. The intended usage is only weakly implied by the name and description, with no explicit routing or context provided.

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

get_local_ipA

Get the local IP address of this machine

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden, but 'Get' clearly indicates a read-only operation with no side effects, and 'local IP address of this machine' describes the result. It does not discuss edge cases like multiple interfaces or IPv4/IPv6 selection, but for a zero-parameter read-only tool the core behavior is transparent enough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It states the action and the object directly, and every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only utility with no output schema, the description provides enough information for correct selection and invocation: the agent knows the result will be the machine's local IP address. Potential ambiguities around IPv4/IPv6 or multiple interfaces are minor and do not affect invocation correctness.

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

Parameters4/5

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

The tool has zero parameters and the schema fully covers the input surface, so there is no parameter information the description needs to add. Per the baseline for zero-parameter tools, a score of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Get') and a clearly defined resource ('the local IP address of this machine'). This makes the tool's function immediately understandable and distinguishes it from siblings like scan_network, ping_host, and get_network_connections, which address different networking tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used when an agent needs the machine's local IP address, but it does not explicitly discuss when to prefer it over related tools such as get_network_connections or get_system_info. No exclusions or alternative conditions are provided, so the guidance is only implicit.

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

get_network_connectionsB

Get active network connections and listening ports

ParametersJSON Schema

Name	Required	Description	Default
`filter_type`	No	Filter by connection type: 'tcp' or 'udp' (optional)

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. 'Get' implies a read-only operation, which is transparent enough for a simple informational tool, but the description does not mention potential permission requirements, platform differences, or how 'active' connections are defined.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct sentence with no redundancy. Every word contributes to conveying what the tool does, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one optional parameter, the description is largely sufficient. However, in the absence of an output schema and annotations, a bit more detail about the returned data format or typical use context would make it more complete.

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

Parameters3/5

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

The only parameter, filter_type, is fully described in the input schema with its allowed values ('tcp' or 'udp'). The tool description itself adds no extra meaning beyond the schema, which is acceptable since schema coverage is 100%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies a verb ('Get') and a resource ('active network connections and listening ports'), making the tool's purpose obvious. It is reasonably distinct from siblings like scan_network or check_port, though it does not explicitly state that it refers to local system connections.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives such as check_port, scan_ports, or ssh_list_connections. The description implies it lists local connections, but it does not provide any explicit conditions, exclusions, or comparisons to sibling tools.

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

get_system_infoB

Get comprehensive system information including CPU, memory, disk, and network details

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It states what information is returned but does not mention that gathering 'comprehensive' data may require elevated privileges, may be slow, may behave differently across OSes, or how failures in one subsystem are handled. For a tool with zero annotation coverage, this is a notable gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence where every word earns its place: the action, the scope, and the categories are all stated without redundancy. The category list is the only necessary elaboration and it is compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The complexity is low (zero params, no nested objects), and the description names the broad return domains, which is partially adequate given there is no output schema. But it does not communicate the return shape, units, or how this aggregates/disitnguishes from the many sibling probes that cover the same domains (get_disk_usage, get_networ_connections, list_processes), leaving selection ambiguity unresolved.

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

Parameters4/5

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

The tool has zero parameters, so the schema (an empty object at 100% coverage) fully documents the input surface. Per the rubric, 0 params gets a baseline of 4; there is nothing more a description could meaningfully add about parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Get') and resource ('comprehensive system information'), and enumerates the covered domains: CPU, memory, disk, and network. This is clear, but it does not explicitly contrast itself with overlapping siblings like get_disk_usage or get_network_connections; an agent must infer from 'comprehensive' that this is the aggregated superset.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The term 'comprehensive' implies this is the broad-strokes overview tool, and the sibling list suggests more targeted alternatives exist. However, there is no explicit when-to-use / when-not-to-use statement, no named alternatives, and no guidance on whether to prefer this over the specific probes (e.g., get_disk_usage, list_processes) when onlyone subsystem is needed.

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

kill_processC

[DISABLED - set LNMCP_ENABLE_KILL=1 to enable] Terminate or kill a process by PID

ParametersJSON Schema

Name	Required	Description	Default
`pid`	Yes	Process ID to kill
`force`	No	Force kill (SIGKILL) instead of graceful termination (SIGTERM)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must carry the full behavioral disclosure burden. It only notes that the tool is disabled by default and that it terminates/kills, omitting the destructive and irreversible nature, permission requirements, and potential side effects on child processes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one concise sentence that front-loads the critical disabled state before the action. There is no filler or redundant wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive process-control tool with no annotations and no output schema, the description is too thin. It omits consequences, error cases, prerequisites, and postconditions, making it insufficient for an agent to call safely.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents pid and force (including SIGTERM vs SIGKILL). The description adds no parameter-level detail beyond 'by PID', so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (Terminate or kill) applied to a resource (process by PID), which is clear and distinct from sibling tools like list_processes or execute_local_command. However it does not explicitly differentiate from alternatives, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, nor are exclusions or prerequisites described. The disabled warning hints at activation requirements but does not help an agent decide when to invoke the tool.

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

list_processesA

List running processes with CPU and memory usage

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of processes to return (default: 50)
`filter_name`	No	Filter processes by name (optional)

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are present, so the description carries the behavioral disclosure burden. It clearly conveys that this is a read-only listing and what the result covers (CPU and memory), but it does not mention sorting, output format, or whether the snapshot is one-time. The behavior is accurately represented but minimally detailed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler: the action and output scope are immediately visible. Nothing in the description is redundant with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read-only tool, the description is serviceable. However, with no output schema and no annotations, it leaves return-shape details such as whether PID/name columns are present and how results are ordered unspecified. The schema covers parameters, but the overall tool context is not fully complete.

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

Parameters3/5

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

Schema description coverage is 100%, so limit and filter_name are fully documented in the structured schema. The description adds no additional parameter semantics beyond the overall purpose, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific action (List) and a concrete resource (running processes), and adds distinguishing output detail (CPU and memory usage). This is enough to tell it apart from siblings such as kill_process, get_system_info, and execute_local_command.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use case is implied: call this when you need to see running processes and their resource usage. However, it gives no explicit guidance on when to prefer this over alternatives like get_system_info or execute_local_command, and it names no exclusions.

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

ping_hostB

Ping a specific host to check if it's reachable

ParametersJSON Schema

Name	Required	Description	Default
`host`	Yes	IP address or hostname to ping

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but not expected behaviors such as timeouts, return format, output details, or whether it relies on standard ICMP. This leaves the behavior noticeably underspecified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one short sentence with no filler or redundant information. It efficiently states the action and purpose, making excellent use of every word.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool, the description is economical, but there is no output schema and the description does not specify what the tool returns (e.g., success/failure, latency, raw ping output). This is a moderate gap for an agent that must interpret the result of the call.

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

Parameters3/5

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

The input schema fully documents the single 'host' parameter, including its type and description, so schema coverage is 100%. The description adds no additional parameter meaning, warranting the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Ping' and names the resource 'a specific host', with the goal 'check if it's reachable'. It clearly conveys the core action, but it does not explicitly distinguish the tool from sibling check_port, which also tests reachability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance or mention of alternative tools like scan_network or check_port. The phrase 'check if it's reachable' implies the scenario of testing host connectivity, but the usage context is only implicit rather than clearly stated.

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

scan_networkC

Scan the local network to discover active devices. Returns IP addresses, hostnames, and open ports.

ParametersJSON Schema

Name	Required	Description
`end_ip`	No	Ending IP address (last octet, default: 254)
`start_ip`	No	Starting IP address (last octet, default: 1)
`network_prefix`	No	Network prefix (e.g., 192.168.1). Leave empty to auto-detect.

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description must carry full weight for behavioral disclosure. It mentions scanning and return data but does not disclose potential side effects, permission requirements, network impact, or performance considerations, which are important for a network 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the main action and outcome. It efficiently conveys the function and return data without unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This tool is the most complex among siblings and has no annotations or output schema, yet the description only covers basic functionality. It lacks important details such as expected runtime, security considerations, and how to interpret results, making it insufficient for complete understanding.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters, including defaults and examples. The description does not add additional semantic detail beyond what the schema provides, which is acceptable given full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool scans the local network to discover active devices and lists the returned data (IP addresses, hostnames, open ports). It is specific enough to understand the main purpose, though it does not explicitly distinguish it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to use this tool versus alternatives, nor any mention of prerequisites like network permissions or limitations. The description only states what it does, leaving usage context to be inferred.

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

scan_portsB

Scan multiple ports on a specific host

ParametersJSON Schema

Name	Required	Description	Default
`host`	Yes	IP address or hostname
`ports`	Yes	List of port numbers to scan (e.g., [80, 443, 22, 8080])

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are present, so the description must disclose behavioral details. It only says 'scan multiple ports' without explaining what the tool returns (open vs closed ports), whether it performs a TCP connect scan, timeout behavior, or permission requirements. This is a significant gap for a network 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that communicates the essential action and scope. It contains no filler, is easy to parse, and is appropriately sized for a two-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is straightforward but has no output schema, so the description should at least hint at what the scan results look like or how they are presented. It does not. Additional context about scanning behavior, failure cases, or special host formats would be needed for an agent to fully understand what to expect.

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

Parameters3/5

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

Schema description coverage is 100%, with clear descriptions for both host and ports. The tool description adds no extra parameter meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear action ('Scan') and a specific resource ('multiple ports on a specific host'), which makes the tool's basic purpose obvious. It implicitly differentiates from siblings like check_port (single port) and scan_network (network-wide), but it does not explicitly name or contrast any sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: when multiple ports on a single host need scanning. However, it gives no explicit guidance about when to prefer this over check_port or scan_network, and no exclusion criteria or alternative routing is provided.

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

ssh_connectB

Establish an SSH connection to a remote host. Connection is kept alive for subsequent commands.

ParametersJSON Schema

Name	Required	Description
`host`	Yes	IP address or hostname
`port`	No	SSH port (default: 22)
`password`	No	SSH password (optional if using key)
`username`	Yes	SSH username
`key_filename`	No	Path to SSH private key file (optional if using password)

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description must carry behavioral disclosure. It does add value by stating that the connection persists for later commands, which is a meaningful behavioral trait. However, it does not mention authentication behavior, error conditions, timeouts, session reuse, or what happens to existing connections.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no filler. The core action is front-loaded, and the second sentence adds the essential lifecycle detail without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a stateful, connection-establishing tool with no annotations and no output schema. The description does not explain how the connection is referenced in later commands, what the return value indicates, or what errors or prerequisites matter. These gaps are significant for an agent expected to use this correctly in a multi-step workflow.

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

Parameters3/5

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

The input schema covers 100% of parameters with meaningful descriptions, so the schema does the heavy lifting. The tool description adds no parameter-level detail beyond what is already in the schema, which is acceptable but not extra value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('Establish an SSH connection to a remote host') and clearly identifies the operation. It is distinguishable from siblings like ssh_execute and ssh_disconnect, though it does not name them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Connection is kept alive for subsequent commands' implies this tool is for setup before running commands, providing some usage context. However, there is no explicit statement of when to use this over alternatives, when not to use it, or how it relates to siblings like ssh_execute or ssh_list_connections.

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

ssh_disconnectA

Close an SSH connection to a remote host

ParametersJSON Schema

Name	Required	Description
`host`	Yes	IP address or hostname
`port`	No	SSH port (default: 22)
`username`	Yes	SSH username

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core effect (closing a connection), but does not disclose whether the operation is idempotent, what happens when no matching connection exists, or whether it closes one specific connection among several.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence with no filler and the action verb front-loaded. It earns its place and is appropriately concise for the tool's simple scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter tool with no output schema and no annotations, the description is close to sufficient but leaves out useful context such as preconditions, return behavior, or error handling. A brief additional note about existing connections or failure behavior would make it fully complete.

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

Parameters3/5

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

The input schema provides complete descriptions for all three parameters (host, port, username), so schema coverage is 100%. The description does not add extra parameter semantics, but the existing schema descriptions are sufficient for this simple tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific action verb ('Close') and a clear resource ('SSH connection to a remote host'), so the tool's purpose is immediately understandable. It also differentiates itself from siblings like ssh_connect, ssh_execute, and ssh_list_connections.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: an agent can infer this is the inverse of ssh_connect, but the description gives no explicit when-to-use or when-not-to-use guidance. It also does not mention prerequisites such as requiring an already-established connection.

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

ssh_executeB

[DISABLED - set LNMCP_ENABLE_SSH_EXEC=1 to enable] Execute a command on a remote host via SSH. Will create connection if not exists.

ParametersJSON Schema

Name	Required	Description
`host`	Yes	IP address or hostname
`port`	No	SSH port (default: 22)
`command`	Yes	Command to execute on remote host
`timeout`	No	Command timeout in seconds (default: 30)
`password`	No	SSH password (optional if using key or existing connection)
`username`	Yes	SSH username
`key_filename`	No	Path to SSH private key file (optional)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are present, so the description must carry the full behavioral burden. It does reveal two useful traits: the tool is disabled behind an environment variable, and it will create a connection on demand. But it omits critical behavior for a remote-execution tool: authentication handling, return/output format, connection cleanup, and the potential side effects of arbitrary commands.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and contains no filler; the disabled-state warning is operationally important. The purpose is front-loaded and the auto-connection note earns its place. It could be slightly better structured, but it is appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an SSH command-execution tool with no output schema and no annotations, the description is too sparse. It does not explain what the tool returns, how credentials are provided beyond a password field, or what security implications an agent should consider. An agent selecting and invoking this tool would be guessing about important runtime behavior.

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

Parameters3/5

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

The schema provides descriptions for host, port, command, timeout, and password, so the description does not need to repeat those details. However, username is listed as required but missing from the properties block entirely, and the description adds no clarification for it. Overall the description adds little parameter meaning beyond what the schema already contains.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Execute a command') on a specific resource ('a remote host via SSH'). It is clearly distinct from sibling tools like ssh_connect and ssh_disconnect, which handle connection lifecycle, and execute_local_command, which targets the local machine. The additional note about auto-creating a connection further defines its scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The main use case is strongly implied: use this when you need to run a command on a remote system over SSH. The line 'Will create connection if not exists' also hints that a separate ssh_connect call may be unnecessary. However, it never explicitly names alternatives or states when this tool should not be used.

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

ssh_list_connectionsA

List all active SSH connections

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior3/5

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

The description conveys a read-only listing behavior and implies no destructive side effects. However, since no annotations are provided, it carries the full burden and does not clarify what counts as 'active', whether output is scoped to the current user, or how connection status is determined.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is five words and contains no filler. It front-loads the action and resource with maximum efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple parameterless listing tool, the description is mostly complete: an agent knows what the tool does and can invoke it. Minor gaps around output format and the precise scope of 'all active SSH connections' prevent a higher score, but the low complexity makes this acceptable.

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

Parameters4/5

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

This tool takes zero parameters, so the input schema is already complete. The description adds no parameter details, but none are needed; baseline 4 applies for parameterless tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'List all active SSH connections'. It is clearly distinguishable from sibling tools like ssh_connect, ssh_execute, and ssh_disconnect, though it does not explicitly contrast with get_network_connections.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to use this tool instead of alternatives such as get_network_connections or scan_network. The intended use is implied but not stated, and there are no exclusions or conditions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

18 tool updatesv1.1.0Sep 8, 2026
- First observedcheck_port
- First observedexecute_local_command
- First observedfind_files
- First observedget_directory_listing
- First observedget_disk_usage
- First observedget_environment_variables
- First observedget_local_ip
- First observedget_network_connections
- First observedget_system_info
- First observedkill_process
- First observedlist_processes
- First observedping_host
- First observedscan_network
- First observedscan_ports
- First observedssh_connect
- First observedssh_disconnect
- First observedssh_execute
- First observedssh_list_connections

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored 2026-09-08 15:20 across 18 tools

Disambiguation4/5

Most tools have clear, distinct responsibilities, but scan_network, scan_ports, and check_port overlap somewhat in the port-scanning space, and get_system_info includes network details that overlap with get_network_connections. Descriptions are clear enough to resolve most ambiguity.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern, with a clear ssh_ prefix for SSH-related operations. This makes the toolset predictable and easy for an agent to navigate.

Tool Count3/5

At 18 tools, the set is in the borderline-heavy range, and the scope spans network discovery, SSH management, process control, and filesystem inspection. Several disabled tools also inflate the count without providing immediate functionality.

Completeness3/5

Core diagnostic workflows like network scanning, ping, port checks, SSH connection lifecycle, and system info are covered. However, ssh_execute, execute_local_command, and kill_process are disabled by default, creating significant dead ends for management actions, and there are no DNS, traceroute, or network interface configuration tools.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Os Automation Mcp C
io.github.varvararatta
MCP server for OS Automation
OS Automation Command Line
2
James's MCP Server A
io.github.JGPAS
MCP server with quote and live cryptocurrency price tools, local and cloud-deployed transports.
Cryptocurrency Finance
21
KodyOAuth
io.github.kentcdodds
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
Developer Tools Code Execution Command Line
2681
Sensact
io.github.sensact-agents
An authenticated remote MCP server for user-owned devices and one-shot capability invocation.
OS Automation App Automation
2

Related MCP Servers

mcp-ssh
Shell Access Command Line File Systems
zhouxiangjing
A
license
A
quality
D
maintenance
MCP server for remote Linux/Unix server management via SSH, enabling command execution, system monitoring, file operations, and diagnostics through natural language.
Updated 6 months ago (2026-03-18 09:06 UTC)
34
1
MIT
ssh-client-mcp-server
Shell Access Command Line
jordanburke
A
license
Not graded
quality
B
maintenance
A local MCP server that enables LLMs to execute shell commands on remote hosts over SSH with multiple authentication methods.
Updated 14 days ago (2026-09-13 22:55 UTC)
35 npm
3
MIT
jakubs-mcp-tools
Shell Access Monitoring
Jakub2841
F
license
Not graded
quality
F
maintenance
MCP server for infrastructure discovery and remote management, enabling SSH command execution, file transfer, log tailing, and machine/service inventory with a companion web dashboard.
Updated 3 months ago (2026-06-29 13:17 UTC)
2
-
ssh-mcp-server
wijzeu
A
license
Not graded
quality
C
maintenance
SSH-based MCP server that enables remote execution of SSH commands, file transfers, and secure server management via the MCP protocol.
Updated 2 months ago (2026-07-21 20:21 UTC)
ISC