kurator_lauf

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

No annotations are provided, so the description carries the full behavioral burden. It clearly discloses that the default writes nothing, that scharf=True performs actual withdrawals, that actions are returned with ausgefuehrt=false in dry-run mode, that only injection_suspects at sicherheit='hart' and kind='node' are touched, and that lessons lack a withdraw mechanism. It also characterizes the action as a reversible visibility toggle, not permanent deletion.

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 description is dense and long, but nearly every sentence carries a meaningful constraint: dry-run behavior, safe boundary, category handling, node-only action, and audit-row explanation. Some references such as Hermes curator.py and knowledge_lint.py add context without bloating the core semantics. It is packed rather than padded, and the most important purpose and safety frame appear first.

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 complex tool with no output schema and no annotations, the description covers the main operational details: what is report-only, what can act, when writes happen, and what outputs are returned. It does not fully describe the audit row structure or list all 15 report-only categories, but it points to _KURATOR_KATEGORIEN_OHNE_HANDLUNG for the latter. The agent can invoke it correctly with the dry-run default and scharf switch.

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 already 100%, so the baseline is 3. The description adds significant meaning for scharf by explaining that false means no writes and every potential action is returned with ausgefuehrt=false, while true means actual withdrawal with a stated grund in the audit row. It does not add actor/model/session details, but those are adequately documented 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?

The description identifies a specific agent role and action: a cleanup curator that ACTS via knowledge_zurueckziehen() for only injection_suspects at sicherheit='hart' and kind='node'. It explicitly distinguishes itself from knowledge_lint.py by saying it acts rather than only reports, and it names the human-only alternative endgueltig_entfernen.py. This gives a clear, differentiated purpose beyond the tool name alone.

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 description provides concrete usage context: the default is a dry run, scharf=True is the explicit switch to actually withdraw, and only certain categories/conditions are ever acted upon. It names the human-only removal alternative and explains why lessons are never acted on. It does not explicitly enumerate all when-not-to-use cases, but the safe-boundary and dry-run instructions are strong guidance.

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