Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The itmcp server exposes 2 tools (ssh_tool, ping_tool) with partial but incomplete definitions. Both tools have descriptions and input schemas present in the code (src/itmcp/executor.py), but they lack critical details required for production-grade agent tooling. ssh_tool is a high-risk WRITE tool that accepts 5 parameters including identity_file and command, none of the parameters have individual descriptions in the schema. ping_tool accepts 2 parameters with no per-parameter descriptions. The tool descriptions themselves are terse (17 and 26 characters respectively, well below the 50-character minimum for agent clarity). Parameter naming is reasonable (target, user, port, identity_file, command, count) but lack of per-parameter documentation violates the 'every parameter needs a description' rule. No output schemas are documented anywhere in the visible source code. Error handling is absent, there are no recovery guides, input validation messages, or classification of errors as retryable vs fatal. Security concerns are severe: ssh_tool accepts identity_file and command as parameters, which should be server-side injected or pre-configured, not exposed to the agent. The source snippet cuts off at the SSH credentials path definition, so full implementation details are not visible, capping confidence. Based on the visible definitions alone, both tools score in the 25 - 40 range, averaging to 34 for the server.
Tool descriptions are too short (17 - 26 chars). LLMs cannot infer when or why to select these tools. Minimum recommended: 50 - 200 characters describing WHAT the tool does, WHEN to use it, and any prerequisites.
Input parameters lack individual descriptions. Schema defines properties (target, user, port, identity_file, command, count) but provides no per-parameter descriptions in the visible schema. LLMs cannot infer what 'target' means (hostname? IP? FQDN?) or how to format identity_file paths.
ssh_tool exposes identity_file and command as parameters. These are security-sensitive and should be server-side injected or pre-configured in environment/secrets, not exposed to agent control. This violates the secret-injection pattern.
Expand ssh_tool description to at least 150 characters: 'Execute commands on remote hosts via SSH. Accepts target hostname/IP, username, optional port (default 22), and optional identity file path. Returns command output and exit status. Use for remote diagnostics, file operations, or system administration. Commands must be pre-approved; arbitrary execution is not supported.'
Expand ping_tool description to at least 100 characters: 'Test network connectivity to a target hostname or IP address. Sends ICMP echo requests and reports success/failure. Useful for diagnosing network reachability issues. Returns packet loss percentage and latency stats.'
Add per-parameter descriptions to both tools: target (string): 'The hostname or IP address of the target host'; user (string): 'The username for authentication on the remote host'; port (integer): 'SSH port number, typically 22. Default: 22'; identity_file (string): 'Path to private SSH key file. If not provided, uses default SSH agent.'; command (string): 'Command to execute on the remote host. Must be from the allowed command list (see environment variable ALLOWED_REMOTE_COMMANDS).'; count (integer): 'Number of ICMP echo packets to send. Default: 4. Range: 1 - 16.'
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 42 points across a rubric change (v1 → v2)
42/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
42
<=2025-11-25
v2
2026-03-09
F
0
-
v1
No output schemas documented. The agent cannot determine what fields ssh_tool or ping_tool return, making it impossible to chain results to downstream tools or extract relevant data.
No error handling or recovery guidance. If ssh connection fails or ping times out, there is no description of what to do next (retry? ask user? check network?). Error responses should tell the LLM what to do.
ssh_tool accepts an optional 'command' parameter, making it capable of arbitrary command execution on remote hosts. No input validation, no allowlist, no audit trail visible in the schema. This is a severe security risk.
ping_tool description does not indicate whether it is read-only or what happens on timeout. For a network diagnostic tool, this is essential context for agent planning.
ping_tool
Refactor ssh_tool to remove 'command' from parameters. Instead, pre-configure allowed commands in a server-side allowlist (environment variable ALLOWED_REMOTE_COMMANDS already hints at this). Add a separate tool like 'ssh_exec_allowed_command' that accepts command_name (enum of allowed commands) and args (array of strings). This prevents arbitrary command injection.
Add error handling to both tool descriptions: 'Error responses will indicate: connection_refused (check port and firewall), authentication_failed (check credentials), timeout (check network), host_not_found (check hostname spelling), command_not_allowed (command not in allowlist).'
Implement input validation inside the tools: For ssh_tool, validate target against ALLOWED_HOSTS environment variable; validate command against ALLOWED_REMOTE_COMMANDS. Return actionable errors, not stack traces.
Add tool annotations (not yet supported in the schema visible here, but plan for them): mark ssh_tool as destructiveHint=true (it can modify remote systems); mark ping_tool as readOnlyHint=true (it never modifies state).
Document rate limits and timeout behavior. E.g. 'ssh_tool timeout: 30 seconds. ping_tool timeout: 5 seconds per packet. Rate limit: max 10 concurrent SSH connections per server instance.'
Move identity_file and SSH credentials entirely to server-side configuration. Use environment variables or a secrets file (already hinted at by setup_ssh_credentials.sh). Do not expose them as tool parameters.