enabiz_get_lab_trend

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

Annotations provide readOnlyHint=true and openWorldHint=true, and the description adds that each data point includes date, result, unit, and reference value. It also specifies that authentication is required and the error if missing. This goes beyond the annotations.

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 four lines long, concise, and front-loaded with the main purpose. It includes necessary details without excess. Slightly more structured formatting could improve readability.

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?

Given the output schema exists (not shown but noted), the description covers return content (date, result, unit, reference value) and authentication needs. It is complete for a straightforward data retrieval tool with sibling context.

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?

The input schema has one parameter with no description or enums (0% coverage). The description explains that the value should be the trend_code from the output of enabiz_list_lab_tests, distinguishing it from the display name. This adds critical guidance.

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 returns the trend of a lab test over time ("Bir tahlil testinin zaman içindeki trendini döndürür"), specifying both the resource (lab test trend) and action (retrieve past measurements). It is distinct from sibling tools like enabiz_list_lab_tests which list tests.

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 explains how to derive the parameter value from another tool's output ("islem_tipi = enabiz_list_lab_tests çıktısındaki bir sonucun trend_code alanı") and warns about the difference between display name and trend_code. It also notes authentication requirements and the error response. However, it does not explicitly state when not to use the tool.

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