Server Quality Checklist

Tool Scores

• ssh_connectC
  2.8/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. It states the tool creates a new SSH session, implying a network operation that may involve authentication and session management, but lacks details on critical behaviors such as error handling (e.g., connection failures), security implications (e.g., password transmission), session persistence, or rate limits. This is inadequate for a tool with potential side effects.

  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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action, making it easy to parse, and every part contributes essential information, earning a top score for brevity and clarity.

  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?

  Given the complexity of SSH operations (involving network connectivity, authentication, and session management), no annotations, no output schema, and low parameter coverage, the description is incomplete. It fails to address key aspects like return values (e.g., session ID or status), error conditions, or behavioral nuances, making it insufficient for safe and effective use by an AI agent.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate by explaining parameters, but it adds no semantic information beyond what the schema provides. The schema lists host, password, port, session_name, and username with basic types, but the description doesn't clarify their roles (e.g., host as IP/domain, password for authentication, port defaulting to 22, session_name for identification), leaving parameters largely unexplained.

  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 ('SSH 서버에 연결하여 새 세션 생성' translates to 'Connect to SSH server to create new session'), specifying the verb (connect), resource (SSH server), and outcome (new session). However, it doesn't explicitly differentiate from siblings like ssh_execute (which might execute commands) or ssh_list_sessions (which lists existing sessions), keeping it from a perfect score.

  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 alternatives. It doesn't mention prerequisites (e.g., needing valid credentials), when not to use it (e.g., if a session already exists), or refer to sibling tools like ssh_execute for command execution or ssh_close_session for termination, leaving usage context vague.

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

• ssh_executeC
  2.8/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions execution but doesn't disclose critical traits like whether it's read-only/destructive, authentication needs, error handling, or output format (e.g., stdout/stderr). This is inadequate for a command execution 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, efficient sentence in Korean with no wasted words. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.

  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?

  Given the tool's complexity (executing commands over SSH), lack of annotations, no output schema, and 0% schema coverage, the description is insufficient. It doesn't cover behavioral aspects, parameter meanings, or output expectations, leaving significant gaps for an AI agent.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate but adds no parameter details. It doesn't explain what 'session_id' refers to (e.g., from ssh_connect), what 'command' entails, or 'timeout' implications. The description fails to provide meaningful context 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 'SSH 세션에서 명령 실행' clearly states the action (execute command) and resource (SSH session) in Korean, which translates to 'Execute command in SSH session'. It's specific about what the tool does, though it doesn't explicitly differentiate from siblings like ssh_connect or ssh_session_info.

  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 alternatives. It doesn't mention prerequisites (e.g., needing an active SSH session via ssh_connect first) or contrast with siblings like ssh_list_sessions. Usage is implied but not explicitly stated.

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

• ssh_session_infoC
  2.8/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. It states the tool is for 'retrieving detailed information' (상세 정보 조회), implying a read-only operation, but doesn't specify what information is returned, whether it requires authentication, if there are rate limits, or how errors are handled. This is a significant gap for a tool with zero annotation coverage.

  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, efficient sentence in Korean that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with zero waste, 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.

  Completeness2/5

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

  Given the tool's complexity (a read operation with one parameter), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain return values, error conditions, or parameter details, leaving critical gaps for the agent to understand how to use the tool effectively.

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

  Parameters2/5

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

  The schema description coverage is 0%, so the description must compensate for the undocumented parameter 'session_id'. However, it adds no meaning beyond what the schema title ('Session Id') implies—it doesn't explain what a session ID is, how to obtain it, or its format (e.g., from 'ssh_list_sessions'). This fails to compensate for the low 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's purpose as 'retrieving detailed information about a specific SSH session' (특정 SSH 세션의 상세 정보 조회), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'ssh_list_sessions' (which likely lists multiple sessions) or 'ssh_execute' (which executes commands), so it misses full sibling differentiation.

  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 alternatives. It doesn't mention prerequisites (e.g., needing an active session), exclusions, or comparisons to siblings like 'ssh_list_sessions' for broader queries or 'ssh_execute' for command execution, leaving the agent with no usage context.

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

• ssh_close_sessionC
  2.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. It states the action ('종료') but doesn't clarify whether this is destructive (e.g., terminates active processes), requires specific permissions, has side effects, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits undocumented.

  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, efficient sentence in Korean that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with no wasted verbiage, making it easy to parse quickly.

  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?

  Given the tool's complexity (a mutation operation with no annotations, no output schema, and 1 undocumented parameter), the description is insufficient. It doesn't cover behavioral aspects like effects, error conditions, or return values, leaving the agent with significant gaps in understanding how to use the tool effectively.

  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 description doesn't add any parameter-specific information beyond what the input schema provides. With 0% schema description coverage and 1 parameter, the baseline is 3 since the schema already documents the parameter's existence and type, but the description fails to compensate by explaining what 'session_id' represents or where to obtain it.

  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 ('종료' meaning 'close' or 'terminate') and the resource ('SSH 세션' meaning 'SSH session'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'ssh_close_all_sessions' or 'ssh_list_sessions' beyond the implied specificity of closing a single session.

  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 alternatives. It doesn't mention prerequisites like needing an active session ID, nor does it contrast with 'ssh_close_all_sessions' for bulk operations or 'ssh_execute' for ongoing session use. Usage is implied but not explicitly stated.

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

• ssh_close_all_sessionsB
  3.1/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. It states the action (close all sessions) but doesn't describe what 'close' entails (e.g., graceful termination vs force kill), whether it requires specific permissions, if it's reversible, or what happens to active connections. For a potentially destructive operation with zero annotation coverage, this is inadequate.

  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, efficient phrase ('모든 SSH 세션 종료') that directly states the tool's purpose with zero wasted words. It's appropriately sized for a zero-parameter tool and front-loaded with the essential action.

  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 tool that performs a bulk operation on SSH sessions (potentially affecting multiple connections), the description is insufficient. With no annotations, no output schema, and no behavioral details, it lacks critical context about safety, permissions, effects, or return values. The agent cannot understand the full implications of using this tool.

  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 schema description coverage is 100% (empty schema is fully described). The description doesn't need to explain parameters, so it meets the baseline expectation. No additional parameter semantics are required or provided.

  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 '모든 SSH 세션 종료' (Close all SSH sessions) clearly states the action (close/terminate) and target resource (all SSH sessions). It's specific enough to understand the tool's function, though it doesn't explicitly differentiate from the sibling 'ssh_close_session' which likely closes individual sessions.

  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 alternatives like 'ssh_close_session' (for individual sessions) or 'ssh_list_sessions' (to view sessions first). There's no mention of prerequisites, warnings, or appropriate contexts for this bulk operation.

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

• ssh_list_sessionsB
  3.3/5.0
  Behavior2/5

  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. While '목록 조회' (list/retrieve) implies a read-only operation, it doesn't explicitly state whether this requires special permissions, what data format is returned, whether results are real-time or cached, or if there are rate limits. For a monitoring tool with zero annotation coverage, this is insufficient.

  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, efficient Korean sentence that immediately conveys the core functionality. Every word earns its place: '모든' (all) establishes scope, '활성' (active) provides important context, 'SSH 세션' (SSH sessions) identifies the resource, and '목록 조회' (list/retrieve) specifies the action.

  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?

  Given this is a monitoring tool with no annotations and no output schema, the description should do more to explain what information is returned (session IDs, user names, connection times, etc.) and any behavioral considerations. The current description is too minimal for an agent to understand what to expect from this tool's execution.

  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 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist, earning a baseline 4 for not creating confusion about non-existent 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 clearly states the verb ('목록 조회' - list/retrieve) and resource ('모든 활성 SSH 세션' - all active SSH sessions), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like ssh_session_info (which likely shows details of a specific session), but the 'all active' scope provides some implicit distinction.

  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 context through '모든 활성 SSH 세션' (all active SSH sessions), suggesting this is for monitoring current connections rather than historical data. However, it provides no explicit guidance on when to use this versus alternatives like ssh_session_info (for specific session details) or ssh_close_all_sessions (for termination).

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