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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false; the description reinforces this with 'Read-only: nothing is published,' which is worth stating explicitly for a versioning tool. The genuinely added context is the semver.inc equivalence, which tells the agent edge-case behavior matches a well-known implementation. Return values are covered by the output schema, so no gap there.

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?

Three compact sentences, front-loaded with the core action. The enumerated release types partially duplicate the schema enum, a minor redundancy, but nothing else is wasted.

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?

Given an output schema, full parameter descriptions, and rich annotations, the description supplies everything else an agent needs: what is computed, the exact semantics to expect, and that nothing is published. No material gaps remain.

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 100%, including an enum on release and a description on preid, so the schema already carries the parameter detail. The description's restatement of the release-type list and prerelease id examples duplicates that. Baseline 3 is appropriate — it adds no syntax or constraint beyond 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 and resource — compute the next version for a given release type — and enumerates the supported release types. The 'exactly like npm version / semver.inc' anchor pins the semantics precisely, so an agent can distinguish it from siblings like compare_versions or check_range without opening a schema.

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?

Clear context for when to use: you have a current semver and want the next one for a release type, optionally with a prerelease id. It also names the equivalent REST surface (GET /api/bump) and the npm analogue. It stops short of explicit exclusions or naming sibling alternatives, so it lands at 4 rather than 5.

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