check_assembly_status

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.

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.

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.

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.

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.

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.