Show WordPress core version

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is established. The description adds useful output context by mentioning known vulnerabilities and the path-based identifier, but it does not detail response format or any other behavioral traits, so it does not exceed the annotation baseline substantially.

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 concise and front-loaded: the first sentence states the primary purpose and output, and the second gives the essential parameter-source guidance. There is no redundant filler or repetition of the title.

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 two-parameter read-only tool, the description is mostly sufficient, but it leaves the required `username` parameter unexplained and does not describe the return shape despite there being no output schema. These are meaningful gaps for an agent deciding how to call the tool 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?

Schema description coverage is listed at 100%, but the `username` parameter description ('username parameter') is tautological and unhelpful. The description adds meaningful guidance for `software` by explaining it is an installation identifier obtainable from a list endpoint, but leaves `username` semantically unexplained.

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 clearly states the tool 'Shows the WordPress core version for the specified installation' and adds that known vulnerabilities are included. This distinguishes it from sibling tools like hosting_listAvailableWordPressCoreUpdatesV1 or hosting_updateWordPressCoreV1, which are about updates rather than displaying the current version.

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 gives clear context on how to invoke the tool: it requires the WordPress installation identifier in the path and tells the agent where to obtain it (GET /api/hosting/v1/wordpress/installations, the `id` field). It does not explicitly discuss alternatives or when not to use it, but the usage context is clear enough.

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