Model ayrıntısı

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds genuinely useful behavior: Pro-tier fields are empty on free tier, and missing models trigger similar-slug suggestions. It does not explain force_refresh's behavior, which is a notable gap, but nothing contradicts 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?

Three dense sentences with no filler. The first sentence front-loads the core purpose, the second adds tier-specific behavior, and the third covers search and fallback behavior. Every sentence earns its place.

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?

The description is largely complete: core metric categories, tier-dependent field availability, and lookup behavior are all covered, and the output schema presumably documents the return shape. The main missing piece is the semantics of the optional force_refresh parameter, which keeps it from being fully complete.

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 0%, so the description must compensate. It does explain that the 'model' parameter accepts a slug or name and describes the not-found fallback. However, 'force_refresh' is completely unexplained in both the schema and the description, so only one of the two parameters gains meaningful semantic coverage.

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 starts with 'Tek bir LLM'in tüm ölçümleri', naming the exact resource (a single LLM) and the exact data returned (pricing, speed, benchmark scores). This singular scope clearly differentiates it from sibling tools like list_models, compare_models, and list_providers.

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 makes the intended use clear: fetch all metrics for a single model, searchable by slug or name, with fallback suggestions when not found. It does not, however, explicitly state when to prefer list_models or compare_models instead, so no direct alternatives/exclusions are given.

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