Skip to main content
Glama

lore_write

Drafts the next novel chapter, runs semantic and logic checks, then commits approved or auto-passing chapters while preserving canon and character state.

Instructions

다음 화의 계획 확인부터 원본 초고 프롬프트, 의미·논리 검사(최대 3회, 그 사이 최소 수정 최대 2회), 검사 영수증, 승인·커밋까지 순서대로 실행하는 기본 집필 도구다. 소설을 이어 쓸 때는 이 도구만 호출한다. 항상 마지막 화의 다음 화를 쓰며 기존 화를 덮어쓰지 않는다. 같은 화의 진행 중 워크플로가 있으면 새로 만들지 않고 이어간다. 모델 작업마다 status=needs_model을 돌려주므로 lore_resume으로 답한다. 준비가 덜 됐으면 status=needs_setup(FOUNDATION_MISSING·PROFILE_NOT_ACTIVE·STORY_SPINE_NOT_ACTIVE·WRITER_SKILL_NOT_ACTIVE·ARC_NOT_ACTIVE), 손수정이 있으면 needs_sync(→lore_sync)를 돌려준다. guided는 검사를 마친 원고를 status=awaiting_approval과 approvalId로 돌려주며 lore_decide로 결정한다. auto는 검사를 통과하면 chapters/·summaries/·상태·스냅숏을 커밋하고 status=completed를 돌려준다. 실패는 clean_fail·validation_incomplete·provider_error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workIdYes작품 식별자 ([A-Za-z0-9_-]). 한 디렉터리에는 작품 하나만 둔다.
projectNo작품 디렉터리의 절대 경로. 생략하면 서버 실행 디렉터리.
autonomyNoguided(기본)=완성 원고 승인 후 커밋, auto=품질 통과 시 자동 커밋. 커밋 여부는 그 호출의 값으로 정해지므로 auto를 원하면 이어 부르는 lore_write에도 다시 넘긴다.
languageNo저장된 작품 언어와 일치하는지 확인하는 인자. 일회성 출력 언어 변경이 아니다.
sharedOnceNotrue면 needs_model 응답에 공통 본문 블록을 sharedBlocks로 한 번만 싣고, 각 request user 맨 앞 promptCache.sharedBlockRef 문자열(줄바꿈 포함)을 그 블록 text로 바꿔 보내게 한다. 요청을 직접 조립하는 호스트용이며 기본값은 자기완결 요청이다.
instructionNo이번 화에 추가할 작가 지시.
modelProfileNo단계별 모델 힌트. 비우면 호스트 기본 모델 하나로 진행한다. 값은 모델 ID 문자열 또는 { provider, modelId, reasoningEffort }. default=기준 모델, light=planning·draft·review에 쓸 가벼운 모델, identity·planning·draft·review·quality·final=단계별 명시. review=advisory 검토(coherence·editorial·character·reader·arc·profile drift), quality=상태를 쓰는 추출·연속성 검사·pattern ledger. 호스트 릴레이에서는 요청마다 힌트로 전달되고, 로컬 모델은 provider "local"일 때만 실제로 바뀐다.
retryValidationNo실패 상태의 보존된 원고를 새 검증 epoch에서 다시 검사한다.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.4.4
    • changedInput schema / properties / autonomy / description
      Previous value: -"guided=완성 원고 승인 후 커밋, auto=품질 통과 시 자동 커밋."New value: +"guided(기본)=완성 원고 승인 후 커밋, auto=품질 통과 시 자동 커밋. 커밋 여부는 그 호출의 값으로 정해지므로 auto를 원하면 이어 부르는 lore_write에도 다시 넘긴다."
    • changedInput schema / properties / workId / description
      Previous value: -"작품 식별자 ([A-Za-z0-9_-])."New value: +"작품 식별자 ([A-Za-z0-9_-]). 한 디렉터리에는 작품 하나만 둔다."
  2. First observed

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare non-readOnly, non-idempotent, non-destructive, and the description adds real value beyond them: it never overwrites existing chapters, resumes in-progress workflows instead of duplicating, discloses retry caps (검사 최대 3회, 수정 최대 2회), and enumerates terminal statuses (completed, awaiting_approval, needs_model, needs_setup, needs_sync, clean_fail, validation_incomplete, provider_error). It does not, however, describe permission/auth requirements or side effects on chapters/ and summaries/ beyond 'commits', leaving some behavioral surface implied.

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?

It is dense and long, but front-loaded with the core purpose and ordered pipeline, and nearly every sentence carries routing or state information rather than filler. The heavy status-code enumeration is justified by the multi-step, multi-tool workflow it governs, though it reads as a single packed block.

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 an 8-parameter, nested-object, no-output-schema tool that orchestrates a multi-step workflow, the description covers the full lifecycle, all handoff tools, and every terminal status an agent must branch on. Nothing needed to invoke or route the call correctly is missing.

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 100%, so the schema already documents workId, project, autonomy, language, sharedOnce, modelProfile, and retryValidation; baseline is 3. The description nonetheless reinforces the autonomy semantics (guided=approval-then-commit vs auto=commit-on-pass) and warns that the value must be re-passed on follow-up calls, adding meaning beyond the field docs.

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?

It names a specific resource ('기본 집필 도구') and enumerates the ordered pipeline it runs (plan check → draft → semantic/logic checks → receipt → approval/commit), which an agent can distinguish from siblings like lore_webtoon_scene or lore_plan. It also states the scope constraint ('항상 마지막 화의 다음 화를 쓰며 기존 화를 덮어쓰지 않는다').

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?

Explicit routing rules: '소설을 이어 쓸 때는 이 도구만 호출한다', use lore_resume on needs_model, lore_sync on needs_sync, lore_decide on awaiting_approval, and it lists the exact needs_setup reason codes. When-to-use, when-not, and the alternative tool are all named.

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