SSH MCP Server

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. It successfully communicates authentication requirements (ADMIN role), workflow prerequisites (prior approval), and safety profile (high risk). It omits whether the operation is reversible or if it affects existing SSH sessions.

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

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

Three sentences with zero waste: action definition, permission requirements, and risk warning. Information is front-loaded with the core purpose in the first sentence.

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?

Adequate for a high-risk administrative tool given the existence of an output schema (covering return values), but gaps remain in parameter documentation. With 0% schema coverage, the description should explicitly document all three parameters and their relationships to the approval workflow.

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

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

Schema description coverage is 0%, requiring the description to compensate. While 'key_id' is mentioned explicitly and 'prior approval' loosely implies 'approval_request_id', the 'reason' parameter is completely undocumented. The relationship between the approval workflow and the approval_request_id parameter is not explicitly stated.

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 opens with the specific action 'Revoke / remove' targeting the 'SSH key' resource, using 'key_id' as the identifier. This clearly distinguishes it from sibling tool 'add_ssh_key' and other SSH management operations.

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?

States explicit prerequisites ('Requires ADMIN role and prior approval') and risk profile ('Risk level: high'), which helps determine when the tool is appropriate. However, it doesn't explicitly map the 'prior approval' requirement to the 'approval_request_id' parameter or reference sibling 'approve_request' as the prerequisite step.

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