Get server version

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, and the description adds meaningful behavioral context beyond that: it names the exact reported values (package.json version, short hash, dirty-working-tree indicator, display string) and explicitly states the tool makes no API call. This goes well beyond what annotations alone convey.

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 four sentences with no wasted words. It front-loads the core purpose, then adds the motivating scenario, the version-bump caveat, and the API-call exclusion. Every sentence earns its place and the structure is easy to scan.

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 zero-parameter, no-output-schema diagnostic tool, the description is complete. It fully specifies what the tool returns, why it exists, and what it deliberately does not do, so an agent has everything needed to invoke and interpret it correctly.

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?

The tool has zero parameters, so parameter documentation is unnecessary; the baseline is 4. The description adds no parameter syntax but compensates by clarifying the exact nature of the returned diagnostic data, which is the only semantic content an agent needs.

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 states a specific verb and resource: 'Reports exactly which build of this MCP server is currently running.' It clearly distinguishes this tool from the sibling tools, which all concern iDrive account/file operations, by identifying this as server-level diagnostic information.

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 explains when to use it: to tell a stale, already-running server process apart from the current build because semver alone cannot distinguish them. It also gives an explicit exclusion: it is purely local diagnostic info and does not call iDrive's API, which differentiates it from the surrounding data-oriented sibling tools.

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