lib_remove_model

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

With no annotations, the description carries the full burden and does a solid job: it discloses that ALL matching implementations are removed, what keep_one changes, that a missing component raises an error, and that zero matches yields removed=0 rather than failing. It stops short of stating permissions required, reversibility/undo, or persistence effects, which for a destructive library mutation would be worth having.

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-loaded with the core action, then structured Args/Returns sections. Efficient overall, though the Returns block largely restates the existing output schema and could be trimmed.

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 4-parameter, no-annotation mutation tool, the description covers action, matching semantics, dedup mode, error behavior, and the result shape. An agent has everything needed to call it correctly without opening the schema.

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 does — all four parameters are explained in the Args block, including that component_name is the LibReference, that model_name matches ModelName exactly, that keep_one is a dedup flag, and that library_path defaults to the focused library. Only minor gaps remain (path format, whether library_path accepts a directory).

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 and resource ('Remove models (implementations) from a SchLib component by name') plus the matching rule (ModelName equality), which lets an agent separate it from siblings like lib_set_model_name or lib_normalize_implementations. It does not name any sibling explicitly, so the differentiation is inferred rather than stated.

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?

The dedup case is spelled out ('keep_one=True it keeps the first match and removes the rest'), which implies one concrete usage scenario, and the error condition is given. But there is no explicit when-not guidance and no pointer to an alternative tool for related tasks such as renaming or normalizing model links.

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