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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely new context beyond the annotations: it discloses the return content (error position, or top-level type and size) and that the call is 'pure computation, free' — useful cost/latency information an agent can factor into planning.

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?

One front-loaded sentence that states the action, the return shape, and the cost profile with zero filler. Nothing extraneous and nothing buried.

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 single-parameter pure validator with no output schema, the description covers what it does, what comes back (including the failure case), and that it is free. Only meaningful gap is the absence of any guidance on JSON dialect/strictness expectations, which is minor for this tool class.

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?

There is one required parameter at 0% schema description coverage, so the description must carry the weight. 'Check whether a text is valid JSON' implies the input is the text to validate, but adds no detail on encoding, size limits, or whether whitespace/duplicates are tolerated — adequate but thin.

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: 'Check whether a text is valid JSON'. The added note about what it returns (error position or top-level type and size) makes it clearly distinct from formatting/diffing siblings like bursia_json_format or bursia_json_diff, though those siblings are never named.

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?

Usage is only implied: an agent can infer this is the tool to reach for when it needs to know if a string parses as JSON. There is no explicit when-to-use vs when-not, and no pointer to bursia_json_format for pretty-printing or bursia_json_path for querying.

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