Hukuk MCP

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, repeatable read. The description adds useful scope by enumerating exactly which backends are probed (Bedesten, AYM, Emsal, resmi karararama, kurum), which is real value beyond the annotations. It does not, however, describe aggregate behavior (e.g., whether one failing source fails the whole call) or timing/timeout traits.

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; every clause (the list of sources) earns its place. It is extremely terse, but nothing is wasted.

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 zero-parameter diagnostic tool with an output schema, the description covers the essential 'what is inspected' information and the output schema can carry the result shape. The only meaningful gap is the absence of any statement about how/when to act on the result.

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 tool takes zero parameters (schema is an empty closed object), so there are no parameter semantics to explain and the baseline of 4 applies. The description correctly implies a no-argument invocation.

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 action (health check / "sağlık kontrolü") applied to a named set of resources (Bedesten, AYM, Emsal, resmi karararama, kurum JSON API). This clearly separates it from the search_*/get_* siblings, which consume those same sources rather than verifying them. It falls short of 5 only because the noun phrase "sağlık kontrolü" does not explicitly say what a "check" returns.

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 never states when to call this versus the many search/get siblings. There is no mention of using it as a pre-flight diagnostic, no failure/retry context, and no exclusions. Usage is only inferable from the 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?

No annotations are provided, so the description carries the full burden. It usefully discloses that the output is a skeleton (not a finished document), that uslup=true injects style from registered local examples, and that the tool itself does not persist anything. It does not state that it reads from a local style folder as a side effect, nor characterize it as a pure read operation.

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 with zero filler: purpose first, then the uslup conditional, then the next-step instruction. Every sentence earns its place and nothing is buried.

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 the return structure need not be explained, and the schema fully documents the parameters. The description covers purpose, the key optional behavior, and the follow-up tool, leaving only minor gaps about how the context fields shape the generated skeleton.

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 eight parameters are already documented, and the description only echoes the tur enum and the uslup behavior that the schema already states. It adds no extra meaning (e.g., how konu/davaci/davali/mahkeme/dosya_no influence the skeleton), so the baseline of 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 and resource ('Dilekçe iskeleti döner') and enumerates the supported petition types (dava, cevap, islah, istinaf, temyiz, icra_itiraz), which maps exactly to the tur parameter. It also distinguishes itself from the sibling udf_yaz, which is where the finished text is saved.

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?

Clearly tells the agent its role in the workflow: this tool only returns a skeleton, the agent writes the actual text, and udf_yaz is the tool that persists it. That is explicit routing to an alternative, but there is no guidance on when this tool is inappropriate or how it relates to uslup_liste/uslup_kaydet.

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?

With no annotations, the description carries the full burden. It usefully discloses that bold, italic, tables and indentation are preserved, which is real behavioral content beyond the schema, but it says nothing about overwrite behavior, error handling for malformed .docx, or file-size limits.

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 tight sentence with the purpose front-loaded and the preservation guarantee appended. No filler, though the preservation clause could arguably be its own detail rather than crammed after a semicolon.

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 100% schema coverage and an output schema present, the description need not explain return values or parameters. It covers the core transformation and its fidelity guarantees, leaving only error/overwrite behavior unaddressed.

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 (docx_path, filename, output_dir) and their defaults are already documented in the schema. The description adds no further parameter detail, so the 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 and resource: converts a Word (.docx) file into a local .udf file, and lists the formatting that survives the conversion. This clearly distinguishes it from siblings like udf_yaz/udf_oku, though it does not name any sibling 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 usage context is implied by the input/output format pair (you have a .docx and need a .udf), but there is no explicit when-to-use statement, no prerequisite conditions, and no mention of alternatives such as udf_yaz. Adequate but leaves the routing 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 and openWorldHint=true, so safety is covered. The description adds nothing behavioral beyond that: it doesn't mention that the returned full text may be long, that the 'page' parameter paginates it, or any rate/auth considerations for an open-world remote fetch.

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 fragments with zero filler, and the resource identity is front-loaded before the input-source hint. It is efficient, though the terseness borders on under-specification rather than being genuinely well-structured 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?

An output schema exists, so return values need not be explained. Still, for a tool with a pagination parameter and a remote full-text fetch, the description leaves the 'page' semantics and the expected size/shape of the retrieved decision unaddressed.

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 only 50%, and the description merely repeats the schema's own wording for document_url ('search_aym document_url') rather than adding meaning. The 'page' parameter — the one with real semantic ambiguity (pagination of long decisions) — is explained nowhere in the description or schema.

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?

Names the specific resource (AYM karar tam metni = full text of a Constitutional Court decision) and implicitly the retrieval action, and it distinguishes itself from search_aym by naming it as the source of document_url. However, the verb is never stated explicitly ('Get' only appears in the tool name/title), so it reads as a noun phrase rather than a stated action.

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?

It establishes the key workflow prerequisite: document_url must come from search_aym, which tells the agent this is a follow-up call to a search. It offers no guidance on when to use this versus other retrieval siblings (get_karar, get_emsal, get_mevzuat_content) and no exclusions.

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 and openWorldHint=true, so the safety profile is covered. The description adds nothing further — no mention of what happens when a decision_id is missing, retrieval scope, or pagination behavior despite the 'page' parameter.

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 fragments carry no filler, so nothing is wasted, but the telegraphic style is under-specified rather than genuinely concise. It is front-loaded with the resource but lacks any structural signal for the identifier/pagination relationship.

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 values need not be explained. But for a 2-parameter tool where half the schema is undocumented, the description does not provide enough to call the tool confidently — 'page' behavior and identifier provenance remain unstated.

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%: decision_id is documented in the schema and the 'page' parameter has no description anywhere. The description merely repeats the schema's own note ('search_emsal id') instead of compensating for the undocumented pagination parameter.

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 fragment 'Emsal karar tam metni' identifies the resource (an emsal/precedent decision) and the scope (full text), which lets an agent distinguish it from search_emsal. However, it omits an explicit verb and reads as a label rather than a stated action, so the purpose is only implied.

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 phrase 'search_emsal id alanı' hints that a preceding search_emsal call supplies the identifier, which is a weak workflow cue. There is no explicit when-to-use, when-not-to-use, or statement of alternatives versus search_emsal/get_karar.

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 and openWorldHint=true, so the safe-read profile is covered by structured data. The description adds the id format details (bedesten or yargitay:/danistay: prefixed official id), which is genuinely useful context beyond the annotations. It does not, however, disclose pagination behavior despite having a page parameter.

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?

Extremely compact and front-loaded: the resource is stated first, then the required id convention. Nothing is wasted, though the telegraphic fragment style slightly reduces 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?

An output schema exists, so return values need not be explained. For a two-parameter getter with annotation coverage, the essentials (which id to pass and its format) are present, but the page parameter and any explicit usage conditions are absent.

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 50%. The description adds meaningful detail on document_id (the accepted prefix formats bedesten, yargitay:, danistay:), which goes beyond the schema's terse "search_karar document_id". However, the page parameter is undocumented in both the schema and the description, leaving half the parameters unexplained.

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+resource: retrieving the full text ("tam metni") of a karar (court decision). It names search_karar as the source of the id, which implicitly distinguishes it from sibling getters like get_mevzuat_content or get_aym. However, it does not explicitly differentiate itself from those similarly named siblings, leaving the reader to infer the resource boundary.

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 reference to "search_karar document_id" implies this tool is used after a search_karar call, which is useful workflow context. But there is no explicit when-to-use statement, no when-not, and no guidance on the page parameter. Usage is implied rather than stated.

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 and openWorldHint=true, so safety is covered. The description adds that the return is the FULL text (vs. a summary/snippet), which is useful behavioral context, but says nothing about the pagination implied by the 'page' parameter or any retrieval limits.

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 fragments with no filler, and the primary output (full text) is front-loaded. But it is so telegraphic that it reads as notes rather than a complete instruction, and the parenthetical document_id note is ambiguous.

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 structure need not be described, and annotations cover the safety profile. Still, for a 3-parameter open-world retrieval tool, the description omits pagination behavior and any failure/not-found semantics, leaving it minimally 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 coverage is 67%. The description adds genuine value by clarifying the document_id format as 'kurum:id veya URL', which the schema only labels as 'search_kurum document_id'. However, the 'page' parameter is left undocumented in both schema and description, and the kurum code list is only in the schema.

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 resource and scope: the full text ('tam metni') of a kurum decision. This distinguishes it from search_kurum, which returns matches rather than full documents. It is clear, though terse and telegraphic rather than a complete sentence.

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 phrase 'search_kurum document_id' implies the intended workflow (search first, then retrieve by document_id), which is adequate implied usage guidance. However, it never explicitly says when to use this vs. siblings or what happens if the id is invalid/expired.

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 and openWorldHint=true, so the safety profile is covered. The description adds that the output is paginated Markdown, which is useful behavioral context. However, it says nothing about pagination limits around the edges (e.g., behavior past the last page) or response size beyond the schema-implied 5000-char page.

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, front-loaded sentences with zero filler. The essential identity (full text by id) and the key constraint (not the law number) are stated immediately.

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 values need not be described, and annotations cover safety. Combined with full schema coverage, the description is sufficient for correct invocation, though the pagination behavior could be marginally more explicit for a paginated full-text tool.

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 the schema already documents both params (page = 5000-char page, mevzuat_id from search). The description adds real value beyond that by emphasizing the id must originate from search_mevzuat and explicitly warning it is not the law number (kanun numarası), a genuinely useful disambiguation.

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+resource: retrieve the full text content of a mevzuat identified by mevzuat_id, delivered as paginated Markdown. It clarifies the id's provenance (comes from search_mevzuat) and disambiguates from using a law number. It does not, however, explicitly differentiate against close siblings like get_mevzuat_madde_tree, get_mevzuat_gerekce, or search_within_mevzuat.

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?

Implies the correct workflow by noting the id comes from search_mevzuat, which tells the agent to search first. The 'not the law number' caveat prevents a common misuse. But there is no explicit when-to-use vs alternatives among the many get_/search_ mevzuat siblings, and no exclusions stated.

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 and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it never mentions the pagination behavior implied by the 'page' parameter, result size, or what the gerekçe payload contains, leaving the behavioral burden unmet.

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 with the resource named first and the prerequisite second; nothing is padded. It is efficient, though arguably terse to the point of under-specification rather than genuinely concise.

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 values need not be explained, but the tool still leaves the undocumented 'page' parameter and the lack of differentiation from sibling mevzuat getters unaddressed. For a lookup tool in a family of near-identical get_* tools, that is a meaningful shortfall.

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%: 'gerekce_id' is documented in the schema (and merely restated in the description), while 'page' has no description anywhere. The description does not compensate for that gap, so it adds no meaning beyond the structured fields.

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 the specific resource ('Kanun gerekçesi') and names the prerequisite input, making the purpose recoverable without opening the schema. It does not, however, distinguish itself from sibling lookups such as get_mevzuat_content or get_mevzuat_madde_tree, so an agent must infer which mevzuat sub-resource this returns.

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 sentence 'search_mevzuat sonucundaki gerekce_id gerekir' implies the intended workflow (search first, then fetch by id), which is genuine usage context. There is no explicit when-to-use vs when-not guidance and no mention of the alternatives among the get_mevzuat_* siblings.

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 and openWorldHint=true, so the safety profile is covered. The description adds only that the output is a table of contents/article tree — effectively restating the title — and since an output schema exists, even that is not new information.

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?

It is a bare noun-phrase label rather than a description; brevity here comes from under-specification, not efficiency. As with a one-word description, the fragment does not carry enough information to earn a higher score.

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 means return values need not be explained, and the single parameter is fully covered by the schema. What is missing for a tool in a crowded mevzuat family (search_mevzuat, get_mevzuat_content, search_within_mevzuat, get_mevzuat_gerekce) is any routing guidance, leaving an agent unable to choose correctly.

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?

There is a single parameter with 100% schema description coverage ('search_mevzuat sonucu mevzuat_id'), so the schema fully documents it. Per the rubric, high coverage with no extra description detail lands at the baseline of 3.

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 phrase names the resource and the shape of the result ('içindekiler / madde ağacı'), so an agent knows it returns a hierarchical TOC of a mevzuat. However there is no verb and no differentiation from siblings such as get_mevzuat_content or search_within_mevzuat, which also operate on mevzuat content.

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?

No when-to-use guidance is given. The description never says to call this before or instead of get_mevzuat_content, nor what condition (e.g., needing document structure vs full text) should select this tool.

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 and openWorldHint=true, so the safety profile is covered. The description's only added behavioral content is that results carry a document_url, which is already implied by the output schema; it says nothing about pagination or what semantik re-ranking does in practice.

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?

Extremely short and front-loaded, which is good, but it is telegraphic to the point of under-specification ('AYM ara.' is a fragment). Nothing is wasted, but the brevity comes at the cost of clarity rather than being efficient compression.

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 task itself is a simple search. Still, for a 4-parameter search tool the description should at least note the search-workflow positioning and pagination/semantic behavior; the current one-sentence-plus-fragments form leaves gaps.

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 75%, so the schema already documents keywords, semantik, and decision_type. The description's restatement of the two decision_type values duplicates the schema rather than adding meaning, and page/keywords/semantik receive no further explanation.

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+resource ('AYM ara' = search the Constitutional Court) and implicitly distinguishes itself from the retrieve sibling by naming get_aym for the follow-up step. It is clear enough to select over search_emsal/search_mevzuat for constitutional-court decisions, though it never says 'decisions' explicitly and drops to telegraphic fragments.

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?

It gives one concrete workflow cue – use the document_url from results with get_aym – which is genuine when-to-use guidance for the retrieval step. It offers no exclusions or criteria for choosing this over search_emsal/search_karar or for picking a decision_type, so the guidance is implied rather than complete.

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 and openWorldHint=true, so safety and scope are covered structurally. The description adds that it targets a public database rather than personal files, but says nothing about authentication, rate limits, or result behavior, leaving gaps beyond the annotation baseline.

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 sentence with zero waste, front-loading the verb and resource before the scope qualifier. It is efficient, though arguably too terse given the tool's 7 parameters.

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 values need not be described, and annotations cover the safety profile. However, for a 7-parameter search tool with date filters and semantic reordering, the description is thin and omits any guidance on the richer 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 86%, so the schema already documents nearly all parameters (keyword, dates, years, semantik). The description adds no syntax or semantic detail for any parameter, so the 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 (ara/search) and resource (UYAP Emsal kamu emsal kararı), and clarifies the scope by excluding personal UYAP files. It does not differentiate itself from sibling search tools like search_karar or get_emsal, so it stops short of full sibling discrimination.

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 parenthetical '(kişisel UYAP dosyası değil)' implies when-not (personal UYAP files) but gives no explicit when-to-use conditions or named alternatives among siblings. Usage is implied rather than stated.

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 and openWorldHint=true, so the safe-read, external-query profile is covered. The description adds only minor operational context (quote syntax for full sentences, source keyword list), and does not mention the 429-to-resmi fallback behavior that actually governs how calls behave.

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?

Telegraphic and front-loaded: purpose first, then source values, then the quote tip, then the follow-up tool. Zero filler. It is terse to the point of being fragmentary, but every element carries information.

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 15-parameter tool the description is thin, but the 93% schema coverage and the presence of an output schema relieve it of documenting parameters and return values. What is missing is any explanation of result ordering/pagination behavior and explicit sibling routing, leaving it adequate rather than 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 93%, so nearly every parameter is already documented in the schema. The description repeats the kaynak values (bedesten | resmi | hepsi) and the quote tip, both of which duplicate schema content, adding no meaning beyond it. Baseline 3 is appropriate.

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 (ara/search) plus the exact resource and the courts covered (Yargıtay, Danıştay, yerel hukuk, istinaf/BAM, KYB), so an agent can tell it apart from search_aym, search_emsal and search_mevzuat. It does not explicitly name those siblings, but the enumerated court scope does the differentiation work.

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 trailing 'Sonra get_karar' establishes a follow-up workflow, which is useful routing context. However, there is no explicit statement of when to prefer this over the sibling search_aym/search_emsal/search_mevzuat tools, so selection guidance is implied rather than stated.

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 and openWorldHint=true, so the safety profile is covered. The description adds search-behavior nuance ('semantik' resets downstream, phrase can hold a decision number or 'Karar Metni'), but does not mention paging limits, throttling, or what happens when a kurum does not support karar_no.

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, front-loaded fragments with no filler; the action comes first and the kurum vocabulary and KİK tip follow. It is arguably cryptic for readers unfamiliar with the domain, but nothing 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?

An output schema exists, so return values need no explanation, and 86% parameter coverage fills most gaps. Still, kurum-specific parameters such as karar_turu (with its implicit enum-like values) and extra (GİB law number) are only documented in the schema, leaving the description short of fully orienting the agent.

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 86%, so the schema carries most parameter meaning (baseline 3). The description nonetheless adds value beyond the schema by explaining that for KİK the decision number can be supplied either via karar_no or via phrase, and by naming the accepted kurum codes, which the schema only lists in a generic description.

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 and resource ('Kurum kararı ara') and enumerates the valid kurum codes (kik, rekabet, sayistay, kvkk, bddk, btk, gib, sigorta_tahkim, uyusmazlik), which scopes the tool to institutional decisions. It does not explicitly contrast itself with siblings like search_karar or search_emsal, so the agent must infer the boundary from the enumerated institutions.

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 trailing 'Sonra get_kurum' establishes a clear follow-up workflow and the KİK note indicates how to search by decision number, which is useful implied guidance. However, it never states when to prefer this over search_karar, search_emsal, or search_aym, nor any when-not conditions.

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 and openWorldHint=true, and an output schema exists, so the safety profile is covered. The description adds only the workflow handoff to get_mevzuat_content; it says nothing about result ranking, semantic reordering behavior, or how empty keyword searches behave across the ten filters.

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, zero filler, with the core purpose front-loaded and the follow-up action second. Nothing is wasted and the agent can parse the intent immediately.

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 ten-parameter tool, the description covers the primary input modes and the required follow-up call, while the 100%-covered schema and existing output schema carry the remaining detail. The main gap is the absence of any note on pagination or result volume, which the page parameter implies but the description never addresses.

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 the schema already documents every parameter including the type enum list and date formats. The description's mention of 'kanun no, ad veya metin' loosely maps to mevzuat_no, mevzuat_adi, and phrase, but adds no syntax or semantic detail beyond the schema — 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?

The description names a specific verb and resource ('Mevzuat ara') and enumerates the three lookup modes: statute number, name, or full text. It partially differentiates from siblings by routing follow-up lookups to get_mevzuat_content, though it doesn't distinguish itself from search_within_mevzuat or search_emsal beyond that.

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?

It gives a downstream workflow hint ('Sonra mevzuat_id ile get_mevzuat_content kullan'), which implies this is the entry-point search. However, it offers no explicit when-to-use versus the nearby search_within_mevzuat, get_mevzuat_madde_tree, or search_emsal tools, so usage is only implied.

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 and openWorldHint, so the safety profile is covered. The description adds that queries support AND/OR/NOT and hints at a size-based use case, but says nothing about result shape or limits beyond what the schema carries.

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 with zero waste, leading with the core purpose and following with the usage discriminator.

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 a full output schema, complete parameter descriptions, and annotations, the description only needs to frame purpose and usage, which it does. It could be slightly stronger by naming the cross-legislation sibling explicitly.

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 four parameters are already documented in the schema. The description adds only the boolean-query capability, not syntax or field-level meaning beyond what the schema provides. Baseline 3 is appropriate.

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 (arama) and resource (mevzuat içinde madde) with scope (madde bazında, AND/OR/NOT). This distinguishes it from the coarser search_mevzuat and the full-text get_mevzuat_content siblings, though it never names them directly.

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?

'Büyük kanunlar için tam metin yerine bunu kullan' gives an explicit when-to-use condition (large laws) and steers away from a full-text alternative. No explicit when-not cases are stated, so it falls short of a 5.

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, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it reads a local .udf file and returns Markdown, which tells the agent the input is local and the output is converted content. It does not mention error conditions or file constraints, but for a simple local read that is acceptable.

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 states the action, the input, the output format, and the intent with zero wasted words. It is appropriately sized for a one-parameter read tool.

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 an output schema present, the description need not explain return values. Annotations cover the read-only nature, the schema covers the path parameter, and the description covers purpose and usage context. Nothing essential for correct invocation is missing.

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 the single 'path' parameter is already documented in the schema. The description adds only that the file is a local .udf file, which overlaps with the schema's 'UDF dosya yolu' description and does not add syntax or format details. Baseline 3 is appropriate.

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 ('okur') and resource ('Yerel .udf dosyasını') plus output format ('Markdown olarak'). It is clear what the tool does, but it does not explicitly differentiate itself from siblings like udf_yaz or docx_to_udf, so sibling differentiation is left implicit.

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 parenthetical '(eski dilekçeyi modele göstermek için)' gives a clear usage context: reading an old petition to show to the model. However, it does not state when not to use it or name alternatives such as udf_yaz for writing or docx_to_udf for converting DOCX.

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?

No annotations are provided, so the description carries the full burden. It does disclose useful traits beyond structure — output is a local file, it is unsigned (imzasız), and bold/italic/tables are preserved — but says nothing about overwrite behavior, path/permission errors, or whether the file is created vs. replaced.

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 tight sentence that front-loads the action and packs the two most decision-relevant facts (opens in UYAP Editor, unsigned) plus the formatting guarantee. No filler.

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 values need not be explained, and the description covers the key behavioral facts for a 3-parameter write tool. However, with zero annotation coverage it leaves mutation-critical details (overwrite of an existing .udf, error conditions, signature caveat implications) unstated.

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 filename, markdown, and output_dir are already documented with defaults and meaning. The description adds no syntax, format, or path semantics beyond what the schema states, so the 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+resource pair: writes Markdown text to a local .udf file, and adds the notable outcome that it opens in UYAP Editor unsigned. It is distinguishable from udf_oku (reads) and docx_to_udf (converts DOCX), 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?

Usage is only implied: the agent can infer it should use this when it has a Markdown petition to persist as .udf. There is no explicit when-to-use vs. docx_to_udf or when-not-to-use statement, and no prerequisites 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?

With no annotations, the description carries the full behavioral burden for a write/mutation operation. It does not disclose whether an existing style sample is overwritten, how the file is named/stored, permission requirements, or any idempotency 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?

A single efficient sentence with the verb and resource front-loaded and no filler. It is appropriately short for a simple save tool.

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 values need not be explained, and the schema covers all three parameters. However, for a no-annotation mutation tool, the description omits overwrite semantics and storage/naming behavior, leaving a real gap.

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 the schema already documents path, etiket, and klasor with meanings and defaults. The description adds only the supported input types and default target directory, so it does not meaningfully exceed the schema baseline.

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 (kaydeder = saves) and resource (yerel UDF/DOCX/MD dilekçe as üslup örneği), plus the destination (./uslup). It is clear what the tool does, but it never names the sibling uslup_liste to distinguish the save operation from the list operation.

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 no alternatives. It does not tell the agent how this differs from uslup_liste or when saving a style sample is appropriate versus dilekce_taslagi.

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 readOnlyHint=true annotation already establishes this is a safe, non-mutating read, so the description carries a lower burden — but it adds nothing beyond that: no ordering, no limit, no behavior when the folder does not exist or is empty. It essentially restates the title in one sentence.

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 zero padding — well proportioned for a one-parameter listing tool. It is minimal but not wasteful; there is simply nothing else in it.

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 values need not be explained, and the read-only nature is covered by annotations. What is missing is usage context: when in the style/drafting workflow this should be called and how it relates to uslup_kaydet.

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 'klasor' is fully documented in the schema, including the ./uslup default. The description contributes no additional meaning about the folder parameter, so the 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 ('listeler') and resource ('kayıtlı üslup örnekleri'), so an agent can immediately tell it enumerates previously saved style samples. It does not explicitly contrast with the obvious sibling uslup_kaydet (save), but the listing-vs-saving distinction is inferable from the verb.

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?

No when-to-use, when-not, or alternative guidance at all. The natural companion tool uslup_kaydet is never mentioned, and there is no hint about whether this should be called before saving, before drafting (dilekce_taslagi), or elsewhere in the workflow.

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