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

The description frames the tool as a pure read ("Read a support ticket..."), but the annotations declare readOnlyHint=false and idempotentHint=false, which contradict the read-only and naturally-idempotent nature of a get/read operation. This is an annotation contradiction on the safety/idempotency axis, so per rubric the score is 1, even though the "guest receipt credentials are never returned" note is a genuinely useful disclosure.

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?

Two short sentences, front-loaded with the core action and returning the security caveat second. Every sentence contributes; nothing is padded.

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?

An output schema exists, so return-value detail is unnecessary, and the description does summarize the payload. However, the undocumented ticketId parameter, the complete absence of usage guidance, and the read/readOnlyHint mismatch leave clear gaps for a tool with two required parameters.

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 only 50%: widgetId is documented in the schema but ticketId is not, and the description adds no parameter meaning (no format, no relationship between widgetId and ticketId, no scoping). With low coverage the description should compensate and it does not.

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 (Read) and resource (a support ticket) plus the scope of what is returned: messages, diagnostic context, and engineering links. This implicitly separates it from siblings like support_list_tickets (plural listing) and support_reply_ticket (mutation), though it never names those siblings explicitly.

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 no when-to-use guidance, no prerequisites, and never names an alternative tool. An agent cannot tell from the text when to reach for support_get_ticket versus support_list_tickets or support_triage_ticket.

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