MCP SSH Manager

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

With no annotations provided, the description carries full burden for behavioral disclosure. 'View SSH command history' implies a read-only operation, but it doesn't specify important behavioral aspects: whether this requires special permissions, whether it shows real-time or historical data, how far back history goes, whether it's paginated, or what format the output takes. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

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 a single, efficient phrase that gets straight to the point with zero wasted words. 'View SSH command history' is perfectly front-loaded and contains no unnecessary elaboration. Every word earns its place in this minimal but complete phrase.

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?

Given that there's no output schema and no annotations, the description provides basic purpose but leaves significant gaps. For a read-only tool with four filtering parameters, users need to understand what the output looks like (list format, fields included, etc.) and any behavioral constraints. The description is complete enough to understand what the tool does at a high level but insufficient for practical implementation without additional context.

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 input schema has 100% description coverage, with all four parameters clearly documented in the schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.

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 'View SSH command history' clearly states the verb ('View') and resource ('SSH command history'), making the tool's purpose immediately understandable. It distinguishes itself from siblings like ssh_execute (which runs commands) or ssh_session_list (which lists sessions rather than command history). However, it doesn't specify whether this shows global history or per-user history, which would make it a perfect 5.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many SSH-related sibling tools (like ssh_execute for running commands, ssh_session_list for active sessions, or ssh_list_servers for server inventory), there's no indication of when this history viewing tool is appropriate versus other SSH monitoring or management tools.

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