Ortak Alan

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds genuine context beyond that: the upstream source (TCMB EVDS) and the default indicator set applied when the parameter is omitted. It stops short of describing what happens on an unrecognized indicator name or whether all indicators are returned in one payload.

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 sentences, no filler, with the data source and scope front-loaded ahead of the default-behavior clause. The density is high, though the enumerated Turkish phrases are not aligned with the accepted parameter keys, so the compactness partly comes at the cost of operability.

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 one-optional-parameter read-only tool with full schema coverage and strong annotations, the description covers purpose, source, and default behavior adequately. Because no output schema exists, however, nothing explains the shape of the returned data (per-indicator values, date fields, units, error behavior for bad keys), which is the remaining gap an agent would want closed.

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% and the single optional parameter already carries an example array, so the schema does most of the work. The description's enumeration does add one value not in the schema example (sterlin) and clarifies the default set, but it creates mapping ambiguity by naming concepts as "konut fiyat endeksi" and "piyasa katılımcıları anketi" while the schema uses the short keys "konut" and "beklenti" — the description never states which literal string to pass.

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 names a concrete resource set (dolar, euro, sterlin, altın, faiz, enflasyon, konut fiyat endeksi, rezervler, beklenti anketi) served from TCMB EVDS data, which makes the tool's scope unambiguous. No sibling tool (hukuk_terimi, son_yazilar, tarif_bul, yazi_ara, yazi_ozeti) overlaps with this domain, so explicit sibling differentiation is unnecessary and its absence costs little.

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: the reader infers this is the tool for financial/economic figures. The one piece of real guidance is "Varsayılan: dolar, euro, altın, faiz, enflasyon," which tells the agent what happens if it omits the parameter. There is no statement of when NOT to use it, and no mention of how to handle an unsupported indicator name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value beyond them by disclosing the return content: a plain-language definition plus a dictionary link, which is important since no output schema exists. It does not state behavior for unknown or misspelled terms, which is the only notable gap.

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?

A single, front-loaded sentence with no filler: source dictionary, output content, and examples in that order. The nested parenthetical example list is dense but still readable, and nothing in the sentence is redundant.

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 one-parameter lookup tool with no output schema, the description covers the essential pieces: what is looked up, from which source, and what comes back (definition + link). The remaining omissions (not-found behavior, exact-match requirement) are minor for this complexity level.

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 coverage is 0% for the single 'terim' parameter, so the description must carry the burden. It partially does by giving four example term values that illustrate the expected vocabulary, but it never says whether an exact dictionary headword is required or whether free-form phrasing is accepted. Helpful examples without matching rules keeps this at a mid score.

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 names a concrete verb+resource: retrieving the plain-Turkish definition of a term from the 'Ortak Alan Legal Tech' dictionary, plus a link. The parenthetical examples (e-tebligat, KVKK, akıllı sözleşme, e-imza) make the term domain unmistakable. It does not explicitly contrast with siblings, though the siblings (doviz_ve_gostergeler, son_yazilar, tarif_bul, yazi_ara, yazi_ozeti) are clearly different tasks, so confusion risk is low.

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 it should call this when a Turkish legal/Legal Tech term needs explaining. There is no explicit when-to-use or when-not statement, no guidance on what to do if a term is not in the dictionary, and no named alternative tool. Adequate but leaves the routing decision to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds value by listing the fields returned, which matters since no output schema exists. It does not disclose ordering details, whether 'adet' caps at 20, or what happens with an unknown topic label.

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 resource and recency scope, with no filler or repetition. The compression is efficient, though the field list and filter note could have been formatted more scannably.

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 simple two-parameter read tool with no output schema, the description covers purpose, returned fields and the available filter — enough to call it correctly. The remaining gap is not explaining the 'adet' count parameter's effect and not routing among the sibling tools.

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 coverage is 50%: 'konu' is documented in the schema, but 'adet' is bare apart from min/max/default. The description compensates for 'konu' by supplying real example topic values (no enums exist in the schema), which is genuinely useful, but it says nothing about 'adet' semantics — whether it means item count or pagination size.

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 names a specific verb+resource pair ('en son yayımlanan yazılar' — most recently published posts) and enumerates what each item contains (başlık, konu, yazar, tarih, kısa özet, bağlantı). It implicitly separates itself from yazi_ara by emphasizing recency rather than searching, but it never names that sibling, so differentiation is inference-based.

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 optional topic filter with concrete topic examples ('ör. Haber, Girişimcilik, Hukuk, Satış, Araç') gives practical usage context for narrowing results. However, there is no explicit statement of when to choose this over yazi_ara (search) or yazi_ozeti (summary), and no exclusions or prerequisites.

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

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds real value by listing the returned fields, which matters because there is no output schema. However, it says nothing about how many recipes are returned (the `adet` parameter defaults to 5 with a maximum of 10) or about behavior when the ingredient yields no results.

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?

A single front-loaded sentence that puts the selection basis before the returned fields, with no filler. It is efficient, though the trailing return-field list reads as a colon-delimited inventory rather than integrated guidance.

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 three-parameter, read-only lookup with no output schema, the description covers inputs at a high level and the return shape in detail, which is the main missing piece otherwise. What it omits is the meaning of `adet` and any statement about result limits or empty-result behavior, which an agent would need to call it well.

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 coverage is 67%: `malzeme` and `sure_dakika` are documented in the schema, and the description reinforces their meaning by naming ingredient and time as the selection criteria. The third parameter, `adet`, has no description anywhere and the prose never explains whether it is a recipe count or an ingredient quantity, so the description does not compensate for the coverage gap. Baseline 3 reflects that the schema does most of the work.

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 names a specific verb and resource in "tarif önerisi" (recipe suggestion) and scopes it to a source, "Ortak Mutfak", plus the inputs that drive it ("malzemeye ve süreye göre"). It also enumerates what comes back (name, time, category, description, link). Sibling tools (doviz_ve_gostergeler, hukuk_terimi, yazi_ara) are in completely different domains, so no explicit sibling routing is needed, but that also means there is no affirmative differentiation to earn a 5.

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: the agent can infer it should call this when it has an ingredient and a time budget, since both are mentioned as the selection basis. There is no statement of when not to use it, no mention of what happens if no recipe matches, and no explanation of how the optional count behaves. Adequate but with clear gaps.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds genuinely useful context beyond them: results arrive as title, summary and link, and full text requires following the link — that shapes how an agent should treat the output. It stops short of pagination or result-count behavior.

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 compact sentences with zero filler, front-loading what is searched and then what is returned. Every clause carries information the agent needs.

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 simple three-parameter, read-only search tool with no output schema, the description covers purpose, searched fields, and the shape of results, which is close to sufficient. The relationship between the free-text query 'sorgu' and the 'konu' parameter remains slightly ambiguous.

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 33%, with only 'sorgu' documented. The description compensates partially by framing 'konu' as a searched topic field, adding meaning beyond the bare string type, while 'adet' is left entirely unexplained in the description (though its default/max in the schema is fairly self-evident). This is partial compensation for a real coverage gap.

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 states a specific verb and resource ('Ortak Alan yazılarında ... Türkçe arama') and enumerates the searched fields (başlık, özet, konu, yazar adı), which makes the tool concretely identifiable. It does not name sibling tools like son_yazilar or yazi_ozeti, so differentiation is inferred rather than stated.

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 by the word 'arama' — an agent can infer this is the lookup tool when it has a query, but there is no explicit when-to-use, when-not, or comparison against son_yazilar (recent articles) or yazi_ozeti (article summary). No preconditions or exclusions are given.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds substantive behavior beyond that: exactly which metadata fields come back and the important constraint that no full text is returned, only a link. It does not cover failure behavior for an invalid address, hence not a 5.

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 short sentences, front-loaded with the returned content, then the input, then the delimiting constraint. No filler, though the sentence structure is somewhat list-like rather than prose.

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 read tool with rich annotations and no output schema, the description covers return contents, input forms, and the full-text limitation – which is what an agent needs. Only minor gaps remain, such as what happens with an unresolvable or unknown slug.

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% and the single parameter already documents that a full URL or a slug is accepted, so the schema carries the load. The description restates the same dual-input acceptance without adding format edge cases, normalization rules, or ambiguity resolution between URL and slug – baseline 3 for full schema 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?

Description opens with a specific verb-and-resource statement ("Bir Ortak Alan yazısının başlığı, konusu, yazarı, tarihi ve kısa özeti") and enumerates exactly which fields are returned, so an agent knows it is a per-article summary lookup. It never names sibling tools such as yazi_ara or son_yazilar, so differentiation from them is left to inference.

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 implied by "Girdi: yazının adresi ya da adresteki kısa ad (slug)" – call it when you have an article address. The note "Tam metin verilmez; bağlantı paylaşılır" usefully signals when this tool is NOT enough (full-text retrieval), but no alternative tool or explicit when-not condition is named.

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