registry_get

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

With no annotations, the description carries the full burden and largely meets it: it explains that `staging` is the write-side gate (the formal library is untouched before commit) and that `cost` with `window="run"` requires a prior `registry_upsert(kind="run-start")` marker, plus `closed=true` semantics. It also disclaims that `est_output_tokens` is a rough output-side estimate, not a billing figure. It does not state size/volume limits for the list modes.

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?

The most important instruction (query the registry at task start) is front-loaded before the long `kind` enumeration, and the enumeration is formatted so an agent can scan for the mode it needs. It is long, but the length is justified by 13 modes; the trailing `est_output_tokens` caveat is the one part that reads as extra.

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?

For a six-parameter multi-mode reader with no annotations, the description supplies mode semantics, param prerequisites, the write-gate distinction, and the run-marker dependency. An output schema exists, so return-value explanation is correctly omitted. Minor residual gaps are list-mode volume/pagination behavior.

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 description coverage is 0%, so the description must compensate, and it effectively does: every parameter's role is covered — `mid` ("需 mid"), `bvid` ("需 bvid"), `topic` ("需 topic 名"), `domain` ("可按 domain 过滤"), `window` (`"run"` vs default). It does not state that `kind` defaults to `stats`, nor spell out the valid value set as an enum, but the mode list supplies the semantics.

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?

The opening verb+resource ("读资产库") is followed by a complete enumeration of the 13 `kind` modes, each with a one-line scope note, so an agent knows exactly which sub-resource each call retrieves. It is clearly the read side of the registry, distinguishable from the sibling `registry_upsert` which is named explicitly in the `cost` and `staging` notes.

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 explicit timing guidance ("每次任务开始前先查一遍——已有评级的 UP 主直接沿用") and a concrete motivation for `video`/`sources` lookups (avoid re-analyzing key_findings). It also states the prerequisite for `cost` (`window="run"` requires a run-start marker). It stops short of saying when to prefer sibling tools like `deep_read` or `scan_topic` over a registry read.

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