magaza__iap_teshis

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context by enumerating exactly what is checked (products live, priced in the requested country, subscription active) and noting the optional token verification. It stops short of describing what the diagnostic output looks like or any rate/scope limits, so it earns only a mid score against an already-covered annotation set.

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?

Three sentences, front-loaded with the symptom this tool addresses, then the scope of the check, then the optional token path. Nothing is padded, though the middle sentence's colon-list is slightly dense and the closing sentence partly restates the schema's play_token description.

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?

With no output schema, the description carries the burden of explaining what the agent gets back, and it does not – it describes what is inspected but not the shape or content of the diagnostic result, which is the entire value of a diagnosis tool. The input side is fully covered by the schema and the usage trigger is present, so the gap is real but localized.

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 100%, so all three parameters (ulke, uygulama, play_token) are already documented in the schema. The description reinforces the role of play_token as an optional addition but adds no format, syntax, or constraint detail beyond what the schema states, so baseline 3 applies.

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 (teşhis eder / diagnoses) and a specific resource (the app's purchase setup across both stores), framed around a concrete symptom ('user paid but can't see premium'). This clearly distinguishes it from the sibling listing tools like play__urunler or appstore__iap_urunler, which enumerate rather than diagnose.

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 opening sentence gives a clear trigger condition – purchase-related complaints – which tells the agent when to reach for this tool. However, it never names the closest alternative (play__satin_alma_dogrula, which also verifies Play purchases) or states when not to use it, leaving the boundary between the two to inference.

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