baseline

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

Annotations declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false, so the safety profile is already given. The description adds real value by explaining that a snapshot file is written, that its path is relative to the knowledgebase, and that `apply=False` only counts rather than writes. It does not say whether an existing snapshot is overwritten or how the file is consumed later.

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 purpose is front-loaded in the first clause, which is good. However, the middle sentence is compressed into near-unparseable shorthand ('same bundle and `all`, and like lint it defaults to where the user is'), trading clarity for brevity and forcing the agent to unpack it.

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?

With four undocumented parameters, no output schema, and only generic annotations, the description needs to be self-sufficient. It covers the write behavior and two parameters reasonably but leaves `all`/`bundle` semantics and the snapshot lifecycle (overwrite behavior, how CI consumes the file) unspecified.

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 carries the burden and only partially discharges it: `path` is explained as relative to the knowledgebase and `apply=False` as count-only, which is genuinely useful. But `all` and `bundle` are explained only by analogy ('same bundle and `all`... like lint it defaults to where the user is'), which is opaque without knowing `lint`'s 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 first clause gives a concrete verb and resource: 'Snapshot today's lint findings so CI fails only on new ones.' It also distinguishes the tool from the sibling `lint` by naming the invocation form `lint baseline=<path>`. The parenthetical is dense and the relationship to `lint` (separate tool vs. flag) is slightly ambiguous, which keeps it from a 5.

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?

'For adopting OKF on a large existing collection' gives a clear adoption scenario for when to reach for this tool, and pointing at `lint baseline=<path>` implies the alternative (running plain `lint`). It stops short of explicit when-not-to-use guidance or naming other siblings like `verify` or `fix`.

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