Skip to main content
Glama

lore_webtoon_render

Complete in-progress webtoon cuts by managing approved image requests, asset imports, lettering and layout review, and approval-gated project output.

Instructions

[deprecated] 진행 중인 컷별 작업 마무리 전용. 새 작업은 lore_webtoon_scene을 사용한다. 승인 계획의 이미지 요청과 조판을 관리한다. 새 계획은 대사·독백·설명·효과음과 사물 글자를 구분한다. 사물 글자는 이미지에 포함하고 실제 읽힘·표면 검토 후 중복 조판하지 않는다. needs_image_choice에서 모델·내장/API·비용을 확인하고 사용자 선택을 작품별로 계속 사용한다. API는 호스트가 실행하고 서버는 모델·참조·반입·승인을 관리한다. 실행 불가는 needs_image_runtime, revisionTarget.kind=lettering은 조판만 수정한다. 후보 파일은 .vibelore/webtoon/에 쓰며 프로젝트 webtoon/에는 lore_webtoon_decide 승인 때만 반영된다. 조판 분석·렌더 검토는 needs_model→lore_resume.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
retryNo실패한 조판 분석 모델 요청을 같은 단계에서 재시도한다.
assetsNo호스트가 생성한 컷 이미지 반입. 같은 shotId는 교체되며 final에서는 룩 승인된 이미지를 바꿀 수 없다.
detailNosummary는 반복되는 계획·참조 상세를 생략한다. jobs·승인 ID·검토 실패는 유지한다.
workIdYes작품 식별자 ([A-Za-z0-9_-]). 한 디렉터리에는 작품 하나만 둔다.
projectNo작품 디렉터리의 절대 경로. 생략하면 서버 실행 디렉터리.
qualityNoreferences=인물·배경 참조 이미지 생성·승인(참조가 없으면 강제), preview(기본)=일부 컷과 조판으로 룩 승인, final=룩 승인 뒤 전체 컷.
feedbackNo선택 컷 수정의 구체적 변경 내용. preview에서 수정 요청서를 발급한다.
revisionNo낙관적 동시성 확인용 현재 revision. 저장된 값과 다르면 STALE_WEBTOON_REVISION으로 거부한다. 생략 가능.
imageModelNo이미지가 없는 승인 계획에서 모델을 제안한다. needs_image_choice를 확인·확정한 뒤 새 계획 승인을 받는다. 이후 같은 선택은 유지한다.
referencesNo호스트가 생성한 참조 이미지 반입. inputHash는 참조 job과 같아야 하며, 참조가 바뀌면 그 참조를 쓴 컷 이미지는 폐기된다.
workflowIdYes대상 컷별 워크플로 id(필수). 장면 워크플로는 USE_WEBTOON_SCENE_TOOL로 거부된다.
reviewAccessNo호스트가 확인한 합성본 열람 가능 여부. false이면 불가능한 검토 호출을 생략하고 미완료 승인 대기로 내린다. true는 검토 완료나 보안 제한 우회 허가가 아니다. 대기 요청/승인 중에는 변경하지 않는다.
continuityPlanNo새 제작은 version:2로 단순 러프→사용자 storyboard 승인→본 작화를 진행한다. scenes:[{id,environmentId,layout,cameraAxis}], shots:[{shotId,sceneId,transition:reset|continue|cut,previousShotId?,anchorShotId?,resetReason?,visibleCharacters?,background?:establish|partial|abstract,blocking,camera,before,after,change,decisiveMoment}]. 모든 컷을 읽기 순서로 포함, 연속 묶음당 최대 6컷. continue/cut은 바로 앞 컷 ID, 첫 컷 이후 reset은 실제 시간·장소 전환 사유 필수. cut은 승인 러프 기준 병렬 생성 후 두 그림 연결 검토, continue/anchor는 선행 작화 검토 후 순차 생성. 승인 러프는 실제 첨부. feedback 필수. v1 기존 동작 유지. 자세한 절차는 docs/reference/WEBTOON_WORKFLOW.md.
imageExecutionNo모델과 실행 경로를 제안. needs_image_choice를 사용자에게 보여준다. API는 별도 과금이며 호스트가 실행한다.
revisionTargetNo그림·대사를 유지하는 조판만 수정. feedback과 함께 preview에서 사용한다.
continuityRoughsNo러프 반입: sceneId,inputHash,path,provenance. 현재 러프 job만 실행.
continuityReviewsNo실제 그림 검토: kind(rough|shot|transition),id,hash,inspectedImages:true,passed:boolean,evidence. v2 rough는 roughReviewJobs의 contextHash, 모든 컷 observations:[{shotId,verdict,evidence}]와 모든 이전 연결 transitions:[{from,to,verdict,evidence}], shot은 composition:{verdict,evidence} 필수. verdict=clear|unclear|contradiction. passed=true는 전부 clear일 때만. transition은 continuity.transitions의 id/hash로 실제 두 그림을 검토. assets와 같은 호출 가능. 호스트 자기보고이며 러프 사용자 승인을 대신하지 않는다.
regenerateShotIdsNopreview 전용. 다시 그릴 컷 id. feedback 필수이며 assets와 함께 쓸 수 없다. 해당 컷과 연속 컷 이미지를 폐기하고 편집 job을 발급한다.
confirmImageChoiceNo사용자가 선택한 현재 imageChoice.id. feedback에 원답을 전달한다. 선택은 같은 작품의 다음 컷·회차에도 유지하며 변경 시 다시 확인한다.
preserveReferencesNo모델 변경 시 승인된 동일 디자인 참조를 재사용한다. 실제 생성 모델·파일 해시·원 승인 이력을 보존하며 새 컷은 새 모델로 요청한다. 사용자 선택에 함께 결합된다. 기본 false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.4.4
    • addedInput schema / properties / assets / description
      Added value: +"호스트가 생성한 컷 이미지 반입. 같은 shotId는 교체되며 final에서는 룩 승인된 이미지를 바꿀 수 없다."
    • addedInput schema / properties / quality / description
      Added value: +"references=인물·배경 참조 이미지 생성·승인(참조가 없으면 강제), preview(기본)=일부 컷과 조판으로 룩 승인, final=룩 승인 뒤 전체 컷."
    • addedInput schema / properties / references / description
      Added value: +"호스트가 생성한 참조 이미지 반입. inputHash는 참조 job과 같아야 하며, 참조가 바뀌면 그 참조를 쓴 컷 이미지는 폐기된다."
    • addedInput schema / properties / regenerateShotIds / description
      Added value: +"preview 전용. 다시 그릴 컷 id. feedback 필수이며 assets와 함께 쓸 수 없다. 해당 컷과 연속 컷 이미지를 폐기하고 편집 job을 발급한다."
    • addedInput schema / properties / revision / description
      Added value: +"낙관적 동시성 확인용 현재 revision. 저장된 값과 다르면 STALE_WEBTOON_REVISION으로 거부한다. 생략 가능."
    • changedInput schema / properties / workId / description
      Previous value: -"작품 식별자 ([A-Za-z0-9_-])."New value: +"작품 식별자 ([A-Za-z0-9_-]). 한 디렉터리에는 작품 하나만 둔다."
    • addedInput schema / properties / workflowId / description
      Added value: +"대상 컷별 워크플로 id(필수). 장면 워크플로는 USE_WEBTOON_SCENE_TOOL로 거부된다."
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare non-readonly, non-idempotent, non-destructive. The description adds genuinely useful behavior beyond that: candidate files land in .vibelore/webtoon/ and only reach project webtoon/ after approval, API execution is host-side with separate billing, needs_image_runtime blocks execution, and lettering-only revisions are scoped by revisionTarget.kind=lettering. No contradiction with annotations.

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

Conciseness3/5

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

Front-loads the deprecation and the replacement sibling, which is good, but the remainder is a single dense paragraph mixing routing, billing, file paths, and per-parameter behavior without structure. Given 20 parameters some density is warranted, but it reads as a wall of text rather than organized guidance.

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?

For a deprecated, 20-parameter, deeply nested tool with no output schema, the description covers the key flows (image request/lettering management, approval gating, host-executed API, retry/review handoff). It is complete enough to invoke safely, with the only gap being that most fine-grained semantics live in the schema.

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?

Schema description coverage is 100%, so the schema already documents all 20 parameters; baseline is 3. The description reinforces a few (image choice continuity, lettering-only revision) but adds little syntax or format detail 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 opening states the scope precisely – '진행 중인 컷별 작업 마무리 전용' (dedicated to finishing in-progress per-cut work) – and names the sibling that handles new work (lore_webtoon_scene). The deprecation is front-loaded, so an agent can immediately tell this is not the tool for fresh jobs. It never quite names the core action as a verb+resource (render/lettering management is only implied).

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?

Explicit routing: new work → lore_webtoon_scene, lettering analysis/render review → needs_model → lore_resume, and candidate files only become real via lore_webtoon_decide approval. That covers when-to-use and several alternatives, though it doesn't enumerate all sibling relationships (lore_webtoon_plan, lore_webtoon_decide).

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