Skip to main content
Glama
zz11ss11zz

Plugin & Skill Manager

保存技能保留备注

save_skill_note

Save local notes and retention flags for skills without changing files or status; uses fingerprint and revision checks to reject conflicting overwrites.

Instructions

保存用户提供的本地备注和保留标记,不修改技能文件或启停状态。需基于当前文件指纹和备注版本,冲突时拒绝覆盖。

Input Schema

NameRequiredDescriptionDefault
idYes
noteYes
retainYes
fingerprintYes
expectedRevisionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.6

TDQS

A3.6/5.0
Behavior4/5

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

Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false) already declare a safe, local, non-destructive write, so the baseline is low. The description goes further by disclosing the optimistic-concurrency model and the conflict-rejection behavior, which the annotations do not convey. It omits success semantics and any permission/authorization requirements, keeping it at 4.

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?

Two sentences, zero padding: the first front-loads what is saved and what is explicitly out of scope, the second covers the concurrency prerequisite. Nothing redundant. It is terse to the point that the revision requirement is compressed into a clause an agent must parse carefully.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-required-param write tool with no output schema and 0% schema coverage, the description covers purpose, non-effects, preconditions and conflict handling, which is decent. It still leaves `id` undefined, says nothing about the return value or what a successful save yields, and does not mention note-size limits. Adequate but not a complete contract.

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 0% across 5 required params, so the description must carry the load. It glosses 4 of them in prose (备注, 保留标记, 文件指纹, 备注版本) and gives fingerprint/revision their operational meaning. It never explains the `id` parameter or the 64-char hex / <=1000-char constraints, and 版本 vs expectedRevision is left for the agent to map.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (保存备注/保留标记) and bounds scope by naming what is NOT touched: 技能文件或启停状态. An agent can immediately tell this is a metadata-only write, not a skill installer or toggler. It stops short of naming the sibling it defers to (e.g. execute_skill_plan), so a 4 rather than a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence gives a precondition for calling (must hold the current fingerprint and note revision) and the failure policy (refuse to overwrite on conflict), which implies when the tool is valid. However, it never states when to prefer this over a sibling write path or when not to call it. Usage is inferable rather than spelled out.

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