record_skill_useLog a batch of applied skills in one call using a unique batch ID and a list of skill names or paths, so each use is counted once and retries reuse the same ID.
采用技能时批量记录。id 为新批次唯一 ID（重试沿用）；skills 为技能名、插件名:技能名或准确路径，可重复，每项计一次。不用于历史补记或仅阅读审计。
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| skills | Yes |
Changes observed during successful MCP inspections.
v0.4.6Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-destructive, closed-world write, so the bar is lower. The description adds genuinely non-obvious behavior: the id is reused on retry (implying idempotent retry semantics) and repeated skill entries each count separately, which is real counting semantics an agent could otherwise get wrong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the action, then parameter semantics, then exclusions in three dense sentences with no filler. Every clause carries information about behavior or routing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A two-parameter write with no output schema needs idempotency, input format, and scope boundaries, all of which are present. It does not say what happens when a skill name is unrecognized (error vs. ignored) or describe the return payload, which are the remaining gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the load, and it does for both parameters: id is the new batch's unique ID, reused across retries; skills accepts plain names, plugin:skill form, or exact paths, is repeatable, and is counted per item. It omits the id's 16-80 character alphanumeric pattern and the 32-item cap, both of which live in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: batch-recording skill adoption, with the trigger condition ('采用技能时') built in. The exclusion ('不用于历史补记') implicitly separates it from import_usage and record_plugin_calls, so an agent can route between them without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear positive trigger (when a skill is adopted) and two explicit negative cases: historical backfill and read-only auditing, which maps onto the import_usage / query_usage siblings. It does not name those siblings directly, so the routing is implied 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.