Server Quality Checklist

Tool Scores

• check_assembly_statusA
  4.3/5.0
  Behavior3/5

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

  어노테이션이 없어 설명이 행동 특성을 전달해야 하는데, 서버가 내부 대기 후 응답한다는 점을 명시하여 대기 불필요를 알린다. 그러나 반환 형식이나 오류 조건은 설명하지 않아 일부 정보가 부족하다.

  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?

  목적, 사용 시점, 인자 설명으로 간결하게 구조화되어 있으며 잉여 정보 없이 모든 문장이 가치를 지닌다.

  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?

  단순한 툴이고 출력 스키마가 존재하며, 목적·사용 순서·인자 출처가 모두 포함되어 충분히 완결적이다.

  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?

  스키마 설명 커버리지가 0%이지만, session_dir이 extract_segments에서 반환된 경로임을 명시하여 스키마 이상의 의미를 제공한다. 단일 파라미터에 대해 충분히 설명한다.

  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?

  명확한 동사+리소스 'PDF 조립 진행 상황 확인'으로 시작하며, assemble_translated 후 호출하라는 순서까지 제시되어 형제 툴인 check_extraction_status와 차별화된다.

  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?

  assemble_translated 호출 후 이 툴을 호출하라는 명시적 지침과 서버가 내부 대기 후 응답하므로 별도 대기가 필요 없다는 맥락이 포함되어 있다. 다만 대안이나 배제 조건은 없다.

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

• assemble_translatedA
  4.4/5.0
  Behavior4/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. It discloses that the tool runs asynchronously in the background and that the caller must check status via check_assembly_status. This is key behavioral context. It does not detail side effects or error modes, but the async disclosure is valuable.

  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 efficiently structured: a purpose statement, an async note with follow-up instruction, and a concise args list. Every sentence adds information without redundancy or padding.

  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?

  The tool is asynchronous with 2 parameters and an output schema. The description covers the async flow, the two parameters, and the follow-up check step. It does not need to explain return values since an output schema exists. Minor missing context: no explicit prerequisite that translated segments must be saved, but that is implied by the workflow.

  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?

  Schema description coverage is 0%, so the description must compensate. It explains session_dir as the path returned from extract_segments and glossary_json as an optional glossary JSON string created during translation. This adds meaning beyond the bare schema property names and defaults.

  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 'Creates the final PDF with translated segments' – a clear, specific verb+resource combination. It is distinguished from siblings like check_assembly_status (status check) and extract_segments (extraction) by its unique purpose of assembly.

  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 description clearly indicates when to use it: after translating segments, and explicitly instructs to call check_assembly_status with the returned session_dir to monitor completion. It also ties session_dir to extract_segments. While it doesn't explicitly list when not to use it, the workflow context is clear.

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

• extract_segmentsA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses the asynchronous behavior, the returned session_dir, default parameter values, and page-range syntax. It does not cover error conditions or side effects on existing files, but it covers the main behavioral traits comprehensively.

  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 well-structured with an intro, async note, and a clear Args list. It is slightly verbose due to the path warning and examples, but each sentence contributes necessary information.

  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?

  Given the tool's complexity (async, five parameters, output schema), the description covers the essential invocation requirements: what to pass, the async flow with session_dir, and next-step status checking. It omits error handling, but is sufficient for correct tool selection and invocation.

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

  Parameters5/5

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

  The input schema has zero descriptions, but the description fully compensates by detailing every parameter: file with a path example and restriction, lang_in/lang_out with defaults, output_dir behavior, and pages with format examples ('1-7,10', '-5', '3-'). This adds significant meaning beyond the raw schema.

  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 'extracts segments to be translated from a PDF file' and differentiates itself by noting the asynchronous execution and the need to call check_extraction_status for completion. This makes it distinct from sibling tools like save_translated_segments or assemble_translated.

  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?

  It provides explicit guidance to call check_extraction_status after obtaining session_dir, and includes a critical warning about using local file paths instead of attached internal paths. It does not mention exclusions or alternatives explicitly, but the pipeline context is clear enough.

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

• save_translated_segmentsA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the accumulation behavior across calls, which is important. However, it does not mention error handling, validation, or what happens if session_dir is invalid, leaving some behavioral gaps.

  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 concise and well-structured: main purpose, accumulation behavior, sequencing instruction, then a clear Args list. Every sentence earns its place without redundancy.

  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?

  With an output schema present, return values need not be described. The description covers purpose, parameter origins, and workflow sequencing within the sibling tool context. It lacks edge-case behavior, but is complete for the primary use case.

  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?

  Schema description coverage is 0%, so the description compensates by explaining both parameters: session_dir as the path from extract_segments and segments_json as a JSON array string of translated segments. This adds meaning beyond bare names, though format details are not deeply specified.

  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 the tool's purpose: 'Saves translated segments to the session' with a specific verb and resource. It also distinguishes itself from siblings by describing the accumulation behavior and the call to assemble_translated.

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidance: segments accumulate across multiple calls, and assemble_translated should be called after all segments are saved. It also explains that session_dir comes from extract_segments, giving a clear workflow context.

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

• check_extraction_statusA
  4.7/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the internal waiting behavior, return content, and supports chunked fetching. Lacks details about error handling or idempotency, but the core behavior is well described.

  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 well-structured with purpose, usage note, return info, and parameter explanations. It is slightly repetitive (mentions extract_segments twice) but remains tight and front-loaded.

  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 status-check tool in a pipeline, the description covers the essential context: trigger (previous tool), behavior (server waits), return value (segments + instructions), and pagination. Sibling tool names reinforce the pipeline context.

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

  Parameters5/5

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

  Schema coverage is 0%, so the description fully compensates by explaining session_dir as the path returned from extract_segments and offset as the start index for pagination. This exceeds the schema's bare definitions.

  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 'Check segment extraction progress' and explains that it returns segments and translation instructions when complete. It explicitly references the preceding tool extract_segments, distinguishing it from other pipeline steps like check_assembly_status.

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use guidance: call after extract_segments to confirm completion. Also notes that no separate wait is needed because the server waits internally, and mentions the offset parameter for pagination when segments are numerous.

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