Skip to main content
Glama
fbwndrud

vibelore

by fbwndrud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

lore_profile

Destructive

Compiles a story discovery brief into a saved StoryProfile with genre, reading contract, length, POV, and style rules. Returns open design questions for feedback before approval.

Instructions

새 작품 설계의 첫 단계. 작품 발견 인터뷰의 브리프를 StoryProfile(엔진 장르·독서 계약·읽기 난도·이야기 동력·시점·문체 지침·언어·분량)로 컴파일해 .vibelore/story-profile.json에 저장한다. review 결과의 designReview에는 누적된 설계 결정과 최대 5개의 열린 질문이 담긴다. 질문을 사용자에게 모두 보여 주고 답을 feedback으로 넘겨 다시 호출하며, 열린 질문이 없거나 사용자가 승인하면 lore_profile_decide로 확정한다. 호출할 때마다 모델이 새로 생성해 기존 프로필을 교체한다(active였어도 review면 pending으로 돌아가 이후 단계가 막힌다). 생성과 언어 검증에 status=needs_model이 1~3회 나오며 lore_resume으로 답하기 전에는 저장하지 않는다. 기반 생성 뒤에는 언어를 바꿀 수 없다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoreview(기본)=pending으로 저장하고 열린 질문을 돌려준다. auto=질문 없이 즉시 active. 사용자가 "알아서·묻지 말고"라고 한 경우만 auto.
briefYes인터뷰에서 정리한 자연어 브리프 전체(장르·톤·방향·독자 경험). 읽기 난도 답변의 근거로도 쓰인다. 비우면 기존 작품 브리프를 쓴다.
lengthNo화당 분량 계약. unit 은 legacyCodeUnits|graphemes|words, target 은 양의 정수.
workIdYes작품 식별자 ([A-Za-z0-9_-]). 한 디렉터리에는 작품 하나만 둔다.
projectNo작품 디렉터리의 절대 경로. 생략하면 서버 실행 디렉터리.
feedbackNo직전 라운드의 열린 질문에 대한 사용자 답변 원문. 설계 결정으로 누적된다.
languageNo작품 언어 BCP 47 태그(예: ko, en-US, ja, zh-Hant). 생략하면 저장된 계약을 따른다.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.4.4
    • addedInput schema / properties / brief / description
      Added value: +"인터뷰에서 정리한 자연어 브리프 전체(장르·톤·방향·독자 경험). 읽기 난도 답변의 근거로도 쓰인다. 비우면 기존 작품 브리프를 쓴다."
    • addedInput schema / properties / feedback / description
      Added value: +"직전 라운드의 열린 질문에 대한 사용자 답변 원문. 설계 결정으로 누적된다."
    • changedInput schema / properties / length / description
      Previous value: -"화당 분량 계약. unit 은 legacyCodeUnits|graphemes|words."New value: +"화당 분량 계약. unit 은 legacyCodeUnits|graphemes|words, target 은 양의 정수."
    • 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 flag a destructive write (readOnlyHint=false, destructiveHint=true), and the description goes well beyond them: every call regenerates and replaces the existing profile, an active profile reverts to pending and blocks later stages, status=needs_model occurs 1-3 times and nothing is saved until lore_resume answers, and language is locked after base generation. This is exactly the behavioral context an agent needs before calling a destructive tool.

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?

Dense but front-loaded: purpose first, then return structure, then the hold/finalize workflow, then mutation and language-lock constraints. Several clauses are load-bearing, though the workflow explanation is somewhat compressed and could be ordered more cleanly.

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 still explains the return shape (designReview containing accumulated decisions and up to 5 open questions) and the needs_model/resume hold cycle, plus the downstream blocking behavior. An agent has enough to call it and handle the result correctly.

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 mode, brief, feedback, language, length, workId and project. The description reinforces the workflow meaning of feedback and the review/auto semantics but adds little that isn't already in the field descriptions, so 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?

States a specific verb and resource: it compiles an interview brief into a StoryProfile and persists it to .vibelore/story-profile.json. It enumerates the profile dimensions (genre, reading contract, difficulty, momentum, POV, style, language, length), so an agent can distinguish it from siblings like lore_profile_decide and lore_profile_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?

Explicit routing: show open questions to the user, pass answers back as feedback and call again, then finalize via lore_profile_decide when no questions remain or the user approves. mode=review vs auto is tied to a clear condition (only when the user says 'just decide / don't ask').

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