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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says the key is discarded, which suggests statelessness, but it does not explain what a successful or failed shape check returns, whether any validation errors are raised, or whether outputs differ per input type. This is notably insufficient for a validation tool.

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 refreshingly short, with no filler or redundant clauses. The two sentences are immediately readable and front-load the core verb and resource. The second sentence is somewhat cryptic and overlaps with the schema's repeated 'discarded' notes, but the overall brevity is a strength.

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 tool with nine heterogeneous parameters, no annotations, and no output schema, this description is severely incomplete. An agent cannot determine what value will be returned, which required fields are needed, whether multiple fields are validated simultaneously, or how it differs from the sibling shape/validation tools.

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 parameter coverage is complete, with each of the 9 properties having a description, so the schema does the heavy lifting and earns the baseline of 3. However, the tool description itself adds no parameter-level meaning and never maps which field actually represents the 'Jira issue key' mentioned in the description. This ambiguity prevents a higher score.

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 names a specific verb and resource ('Check a Jira issue key shape'), which is clear enough against pure tautology. However, the tool's schema exposes nine unrelated fields (ref, url, city, feed, host, json, path), so it is unclear whether this tool checks only issue keys or multiple input kinds. 'Key discarded' hints at behavior but does not clarify the actual purpose scope.

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?

No guidance is provided on when to use this tool versus sibling shape-checking tools such as domain-shape, github-repo-shape, figma-url-shape, or normalize-url. The description implies 'use when you need to check a Jira key shape,' but does not state exclusions, prerequisites, or how to choose among alternatives.

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