Skip to main content
Glama
fbwndrud

vibelore

by fbwndrud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

lore_style_anchor

Idempotent

Locks user-approved canon chapters 1–3 as a novel's style baseline or retrieves the current anchor; never auto-selects the latest chapter.

Instructions

사용자가 좋다고 승인한 정본 1~3화를 작품의 문체 기준으로 고정하거나 현재 기준을 조회한다. 자동으로 최신 화를 기준으로 삼지 않으므로 사용자가 특정 화를 좋다고 말했을 때만 approve한다. action=status(기본)는 읽기 전용이고 기준이 없으면 status=missing. approve는 .vibelore/style-anchor.json의 이전 기준을 새 기준으로 교체하고 {status:active, anchor(revision·발췌·기준 지문)}를 돌려준다. 모델 호출 없음. 초고 요청에서 기준 예시를 빼려면 lore_configure의 disabledDraftSections에 style-anchor를 넣는다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNostatus(기본)=조회, approve=지정 화를 새 문체 기준으로 승인
reasonNo사용자가 이 원고를 선호한 이유. 작품 전체의 새 의무가 아닌 문체 참고로 전달한다.
workIdYes작품 식별자 ([A-Za-z0-9_-]). 한 디렉터리에는 작품 하나만 둔다.
projectNo작품 디렉터리의 절대 경로. 생략하면 서버 실행 디렉터리.
chaptersNoapprove할 정본 화 번호 1~3개

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.4.4
    • changedInput schema / properties / action / description
      Previous value: -"status=조회, approve=지정 화를 새 정본으로 승인"New value: +"status(기본)=조회, approve=지정 화를 새 문체 기준으로 승인"
    • changedInput schema / properties / workId / description
      Previous value: -"작품 식별자 ([A-Za-z0-9_-])."New value: +"작품 식별자 ([A-Za-z0-9_-]). 한 디렉터리에는 작품 하나만 둔다."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Discloses rich behavioral details beyond annotations. It explicitly states that approve swaps the previous anchor in .vibelore/style-anchor.json, confirms no model calls are made, returns a specific object structure, and defines status=missing when no anchor exists. This is critical mutation context that annotations (idempotent, non-destructive) do not cover.

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

Conciseness5/5

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

Front-loads the core purpose, then systematically addresses behavioral restrictions, file side-effects, return values, and cross-tool integration without a single wasted sentence.

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?

Complete for a tool that mutates state and has no output schema. The description provides the return structure, the file mutated, the no-op conditions, and user intent requirements, leaving no ambiguity for the agent.

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 coverage is 100%, so the schema already documents all parameters. The description adds critical semantic context by explicitly stating that action=status is the default (기본), which is helpful, but the rest of the parameter semantics are already handled by the schema descriptions.

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 dual-purpose verb set (승인한 정본을 문체 기준으로 고정하거나 조회) applied to a well-bounded resource. It clarifies the scope constraint (1~3화) and distinguishes itself from the concept of 'latest chapter' behavior.

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?

Explicitly tells the agent when NOT to use the tool's approve action by stating it does not automatically default to the latest chapter; approve should only be called when the user explicitly approves a specific chapter. It also references a sibling tool (lore_configure) for an alternative behavior.

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