Skip to main content
Glama
fbwndrud

vibelore

by fbwndrud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

lore_writer_skill

Destructive

Generates three candidate narrative-judgment profiles for novel writing, compares short prose auditions with a judging model, then selects one for approval or auto-save.

Instructions

이 작품을 쓸 WriterSkill(장면 판단·정보 지연·보상 지급·반복 고착 방지 방식)을 서로 다른 후보 3개로 만들고, 후보별 짧은 산문 오디션을 판정 모델이 비교해 하나를 고른다. 표면 문체가 아니라 서술 판단을 설계한다. 순서는 lore_story_decide(approve) 다음, lore_arc_plan 앞이며 기반과 승인된 StorySpine이 필요하다. 문체 예시를 고정하는 lore_style_anchor와는 다르다. 호출할 때마다 기존 WriterSkill을 이력 없이 교체해 .vibelore/writer-skill.json과 world/writer-skill.md에 저장한다. 후보 생성·오디션 판정·언어 검증에 status=needs_model이 약 3회 나온다. 반환은 {skill(선택 후보와 점수), candidates, needsApproval}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoreview(기본)=pending으로 저장하고 사용자 승인을 기다린다. auto=검증 통과 즉시 active로 저장한다. 사용자가 "알아서·묻지 말고"라고 한 경우만 auto.
workIdYes작품 식별자 ([A-Za-z0-9_-]). 한 디렉터리에는 작품 하나만 둔다.
projectNo작품 디렉터리의 절대 경로. 생략하면 서버 실행 디렉터리.
feedbackNo거절 이유나 원하는 서술 방향. 다음 후보 생성에 반영된다.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.4.4
    • addedInput schema / properties / feedback / description
      Added value: +"거절 이유나 원하는 서술 방향. 다음 후보 생성에 반영된다."
    • addedInput schema / properties / mode / description
      Added value: +"review(기본)=pending으로 저장하고 사용자 승인을 기다린다. auto=검증 통과 즉시 active로 저장한다. 사용자가 \"알아서·묻지 말고\"라고 한 경우만 auto."
    • changedInput schema / properties / workId / description
      Previous value: -"작품 식별자 ([A-Za-z0-9_-])."New value: +"작품 식별자 ([A-Za-z0-9_-]). 한 디렉터리에는 작품 하나만 둔다."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=false; the description goes further by stating that each call replaces the existing WriterSkill with no history and writes to .vibelore/writer-skill.json and world/writer-skill.md. It also discloses the ~3 status=needs_model round trips and the return payload, which annotations cannot express.

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 core action is front-loaded in the first sentence and each subsequent sentence carries distinct information (design intent, ordering, alternative, side effects, round trips, return shape). It is dense and slightly long, but nothing is padding.

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?

With no output schema, the description supplies the return shape ({skill, candidates, needsApproval}), the destructive save behavior, the model-status round trips, and placement in the workflow. Nothing an agent needs to invoke this correctly is missing.

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 workId, project, feedback and the mode enum with its review/auto semantics. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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 names a specific verb and resource (generate 3 candidate WriterSkills and have a judging model select one) and explicitly contrasts itself with lore_style_anchor. An agent can distinguish this tool from its siblings without opening any schema.

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?

It gives explicit sequencing (after lore_story_decide(approve), before lore_arc_plan), states prerequisites (base plus approved StorySpine), and names the alternative it is NOT (lore_style_anchor). This is exactly the routing information an agent needs to pick correctly.

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

Deploy Server

Other Tools