Static source inference · medium confidence · evidence: structured output
No deprecated protocol patterns detected
Summary
The lrnev server has 42 tools with consistent naming patterns (verb_noun structure), but quality is uneven across the board. Naming is generally good (verb-first, action-oriented), but descriptions vary significantly in quality and depth. Parameter schemas are present for all tools, but many are sparse or incomplete. The server follows a hierarchical domain model (scene → spec → task → gate/adr) which is well-structured, but descriptions often lack guidance on WHEN to use tools, HOW they compose, and what side effects occur. Error handling is declared but not detailed in the tool specs. The codebase shows sophisticated response envelope handling (structuredContent, ModelVisibleContract rendering) but this sophistication is not reflected in tool-level documentation. Most tools fall in the 50-65 range; a few standouts like lrnev_init and governance_report reach 70+, but many utility tools (memory_*, session_*, agent_*) are closer to 40-50.
Minimal descriptions on list/discovery tools (scene_list, task_list, error_list, agent_list, lrnev_hook_list all have 'List X' as description). LLMs cannot determine WHEN to call these vs alternatives or what downstream tools they enable. Descriptions must explain what structure is revealed and when to call first.
No pagination support documented for list tools returning unbounded results. An agent iterating tasks across multiple specs without pagination could blow context window. List tools should accept limit/offset and return total count.
Expand list tool descriptions to explain what data structure they reveal (e.g., 'Returns array of scene objects with metadata for downstream spec/task operations'). Add a dependency hint: 'Call this first to discover available scenes before creating specs.'
Add pagination parameters (limit, offset, sort_by) to all list tools. Document max result size and default page size. Return total_count and next_offset in responses to enable batching.
Document expected output schemas for each tool in the tool definition. Use a structured format: 'Returns {ok: boolean, data: {id, name, status, ...}, errors?: [...]}'.
For optional parameters with constrained values (e.g., filters object keys), enumerate valid enum values in the parameter description. Example: 'filters object may contain scope (string), stage (enum: discovery|design|implementation|review), status (enum: draft|active|completed)'.
Add WHEN guidance to utility tools (memory_*, session_*, agent_*): clarify the governance workflow step each serves and how they compose. Example for memory_record: 'Use to persist learnings during a spec/task lifecycle for later session retrieval. Call before session_commit if capturing discovery learnings.'
Add a dry-run parameter to destructive tools (memory_forget) or split into separate confirm/commit steps. Alternatively, document a recovery tool (memory_list with category=forgotten) for audit trails.
Rename 'doctor' to 'check_workspace_health' or 'run_workspace_diagnostics' for verb_noun clarity.
Score history
Overall score trend
First recorded score · v2 rubric
59/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-23
D
59
2025-06-18+
v2
read onlysource verified50/100
Run Health Check
error_listread only50/100
List Error Entries
error_recordwritesource verified72/100
Record Error Entry
gate_runread only50/100
Run Gate Validation
goal_assessread only50/100
Assess Goal Alignment
governance_mapread onlysource verified67/100
Governance Map
governance_reportread only50/100
Governance Report
lrnev_guideread onlysource verified73/100
lrnev 使用手册
lrnev_hook_disablewritesource verified63/100
Disable Hook
lrnev_hook_enablewritesource verified63/100
Enable Hook
lrnev_hook_listread onlysource verified55/100
List Hook Configurations
lrnev_hook_tail_logread onlysource verified68/100
Tail Hook Logs
lrnev_hook_triggerwritesource verified67/100
Trigger Hook
lrnev_initwritesource verified82/100
Init lrnev workspace
memory_forgetdestructivesource verified62/100
Forget Memory
memory_listread only50/100
List Memory
memory_recordwrite50/100
Record Memory
project_statusread onlysource verified55/100
Project Status
scene_createwritesource verified78/100
Create Scene
scene_getread onlysource verified65/100
Get Scene
scene_listread onlysource verified55/100
List Scenes
session_commitwritesource verified67/100
Commit Session
spec_createwritesource verified78/100
Create Spec
spec_getread onlysource verified65/100
Get Spec
spec_listread onlysource verified65/100
List Specs
spec_updatewritesource verified80/100
Update Spec Status
summarize_savewritesource verified67/100
Save Summary
task_claimwritesource verified62/100
Claim Task
task_createwritesource verified78/100
Create Task
task_create_manywritesource verified70/100
Create Multiple Tasks
task_getread only50/100
Get Task
task_listread onlysource verified65/100
List Tasks
task_releasewritesource verified62/100
Release Task Claim
task_updatewritesource verified73/100
Update Task Status
Utility tools (memory_*, agent_*, session_*) lack context about their role in the governance workflow. An LLM cannot distinguish whether to use memory_record, session_commit, or summarize_save for knowledge capture. No dependency hints or WHEN guidance.
get_* tools (scene_get, spec_get, task_get, adr_get) have vague 40-char descriptions ('Get X'). No guidance on what ID format is expected, what relationships are returned, or when to call list_* first to discover available items.
No output schema documentation visible for any tool. LLMs do not know what fields to expect in responses (e.g., does governance_report return metrics, timeline, status?). Structured responses are declared (structuredContent in adapter) but tool-level schemas are not documented.
Destructive tools (memory_forget) lack confirmation/dry-run patterns. Agent could accidentally clear all agent memories with a single call. No guidance on recovery.
doctor tool name is generic and does not follow verb_noun convention. 'run_health_check' or 'check_workspace_health' would be clearer. 'doctor' could mean many things to an LLM.
doctor
For get_* tools (scene_get, spec_get, task_get), document ID format expectations and whether IDs are globally unique or scoped (e.g., 'task IDs are unique within a spec; provide both scene and spec identifiers'). This prevents lookup failures.
Document error recovery paths in tool descriptions. E.g., 'If spec not found, call scene_get first to verify scene exists, or spec_list to discover available specs.'
Provide per-tool usage examples in the tool description (text only, no code). Example: 'Use when you need to capture a critical decision about tech stack; pair with adr_list to avoid duplicate ADRs.'