Skip to main content
Glama

lore_workflow_history

Read-onlyIdempotent

Retrieve read-only audit history for vibelore workflows—stage transitions, review findings, approvals, and commit events—by work or workflow ID, optionally including full model exchanges.

Instructions

워크플로의 감사 이력(단계 전환·검토 발견·승인·커밋 이벤트)을 읽기 전용으로 조회한다. 현재 상태만 필요하면 lore_workflow_status를 쓴다. 반환은 {found, workflowId, events, modelExchanges?}. includeModelExchanges=true이면 선택된 이벤트의 실제 모델 요청과 응답 전문까지 돌려주므로 응답이 커진다. 대체된 이전 워크플로도 id로 조회할 수 있다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
laneNoprose(기본)=소설 집필, webtoon=웹툰 제작.
limitNoprose 전용. 최근 이벤트 몇 개를 돌려줄지. 기본 100. webtoon은 전체를 돌려준다.
workIdYes작품 식별자 ([A-Za-z0-9_-]). 한 디렉터리에는 작품 하나만 둔다.
projectNo작품 디렉터리의 절대 경로. 생략하면 서버 실행 디렉터리.
workflowIdNo조회할 워크플로 id. 생략하면 현재 워크플로.
includeModelExchangesNotrue면 이벤트가 참조한 모델 요청·응답 전문을 포함한다. 기본 false. 웹툰 장면 워크플로에서는 무시된다.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.4.4
    • addedInput schema / properties / includeModelExchanges / description
      Added value: +"true면 이벤트가 참조한 모델 요청·응답 전문을 포함한다. 기본 false. 웹툰 장면 워크플로에서는 무시된다."
    • addedInput schema / properties / lane / description
      Added value: +"prose(기본)=소설 집필, webtoon=웹툰 제작."
    • addedInput schema / properties / limit / description
      Added value: +"prose 전용. 최근 이벤트 몇 개를 돌려줄지. 기본 100. webtoon은 전체를 돌려준다."
    • 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. 생략하면 현재 워크플로."
  2. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description isn't burdened there. It adds real behavioral context: the exact return shape, a response-size warning when includeModelExchanges=true, and the fact that replaced/archived workflows remain retrievable by id.

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-loaded with the core purpose, then the alternative, then the return shape, then the size caveat. Each sentence carries distinct, non-redundant information with no filler.

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?

There is no output schema, yet the description supplies the return shape ({found, workflowId, events, modelExchanges?}), the alternative routing, the parameter caveats, and the archival lookup case. An agent has everything needed to call it correctly.

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 coverage is 100%, so the schema carries most parameter meaning (baseline 3). The description adds value by explaining that workflowId can target replaced prior workflows and by reinforcing the includeModelExchanges side effect (large responses, ignored for webtoon scenes) beyond what the schema states.

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 ('워크플로의 감사 이력... 조회한다') and enumerates exactly what the history contains (단계 전환·검토 발견·승인·커밋 이벤트). It explicitly distinguishes itself from the sibling lore_workflow_status, so an agent can route without opening a 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?

Names the alternative (lore_workflow_status) and the exact condition that selects it ('현재 상태만 필요하면'). Also flags the when-not case for includeModelExchanges ('웹툰 장면 워크플로에서는 무시된다'), leaving little to inference.

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