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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds value by specifying the two tables (Tablo 5.1 mandatory, Tablo 5.2 optional) and the ara filter behavior, but does not go further (e.g., no mention of output size, matching rules, or pagination). Consistent with annotations — no contradiction.

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 purpose first and the filter detail second. Bilingual (Turkish/English) but no redundancy — every clause earns its place. Ideal length for a one-parameter read-only 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?

Complete for a simple, one-optional-parameter, read-only lookup. The output schema exists and documents return values, so the description needn't explain them. The only minor gap is filter matching details, which are parameter semantics rather than overall completeness.

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 `ara` filters by class/Turkish name, adding meaning beyond the bare schema. However, it omits matching semantics (partial vs. exact, case sensitivity), leaving the agent to guess filter behavior.

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 ('Lists') and resource ('the regulation's mandatory and optional IFC classes') with the exact data returned (Turkish names, 3-letter category codes). It's specific enough to distinguish from siblings like model_ozeti or yonetmelik_bilgisi, even without naming them.

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 guidance on when to use this tool versus alternatives. Siblings yonetmelik_bilgisi and yonetmelik_kontrolu are closely related regulation tools, and the description doesn't disambiguate when to reach for this one. Usage context is only implied by the EK-5 IFC-class scope.

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 convey read-only and non-open-world behavior. The description adds useful behavioral context by stating that for an uncoded class it explicitly says so, and it clarifies which annex applies depending on the class type (building elements vs project/person/organization/coordinate). No contradiction with 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 main content is front-loaded in the first Turkish sentence, and the edge-case behavior is a useful second sentence. However, the final English sentence largely repeats the first one, adding redundancy without new 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?

Given the tool's simplicity (one string parameter, output schema present) and read-only annotations, the description covers the essential context: what is returned, scope, annex applicability, and unknown-class behavior. It does not over-explain return values, which is appropriate since an output schema exists.

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?

With 0% schema description coverage, the description must compensate, but it only restates that the input is 'one IFC class,' which is already evident from the parameter name `ifc_sinifi`. It provides no format guidance, examples, or constraints (e.g., must be a valid IFC class name), leaving the agent to guess the expected string shape.

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 specifies the resource (one IFC class) and what is returned (mandatory attributes, property sets, predefined type list) and anchors it to Annex 6/7. It is clear enough to distinguish from siblings like ek5_siniflar or model_ozeti, though it lacks an explicit verb like 'returns' or 'lists'.

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 implies the tool should be used when a user needs the required attributes or property sets for a single IFC class per Annex 6/7, but it does not explicitly mention when to prefer it over siblings or state any exclusions. No alternative tools are named or compared.

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 tool is known to be a safe read operation. The description adds value by stating the output is Markdown and that each row includes Yes/No/Manual and a basis, which is behavioral context beyond annotations. However, it does not discuss any side effects, permissions, or edge cases. Given the annotations cover safety, a score of 3 is appropriate.

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 concise, using two sentences to convey the core function and output structure. It is front-loaded with the main action (generate the form) and then details the row format. No unnecessary fluff or repetition.

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?

While an output schema exists (not shown), the description does not explain how the parameters affect the generated form, nor does it mention any prerequisites or limitations. With 2 parameters and zero schema coverage, the tool is under-specified. The description only covers the output format but leaves input semantics and usage conditions 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 0%, and the description provides no information about the parameters 'dosya' (file) or 'disiplin' (discipline). The agent has no clue what these inputs mean, what formats they expect, or how they influence the output. This is a critical gap since the description must compensate for missing schema details but fails to do so.

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's function: generating the EK-9 Model Quality Control Form as Markdown, specifying the table number (9.1), row count (21), and the structure of each row (Evet/Hayır/Elle with justification). This distinguishes it from sibling tools like ek5_siniflar or ek6_gerekenler, which handle other annexes.

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 explicit guidance is provided on when to use this tool versus the siblings. While the purpose implies it is for the EK-9 form, there is no mention of alternative tools or conditions for selection. The agent must infer usage from the name alone, which is a significant gap.

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 annotation already covers the absence of side effects, and the description adds a useful IFC4X3 schema constraint plus the exact dimensions of the summary. It does not, however, describe behavior when the file is missing, the schema is not IFC4X3, or the file is invalid.

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 short, front-loads the key topic, and organizes the output contents as a list. The Turkish and English sentences are near-duplicates, so the second sentence adds little information, but the overall size is appropriate.

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 read-only tool with an output schema and one parameter, the description covers the main purpose and an important input constraint. It is not fully complete because it lacks input handling details and any pointer to when this summary is useful relative to the compliance-focused 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?

With 0% schema description coverage, the description must carry the parameter meaning, and it does identify 'dosya' as an IFC file and even pins the expected schema version. It does not specify whether the string should be a file path, upload reference, or URL, but for a single parameter this is a workable level of clarity.

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 identifies the tool as producing a summary of an IFC file and enumerates the exact contents: schema, authoring software, spatial structure, and per-class entity counts. It does not use an explicit verb and does not directly contrast with sibling tools, but the resource and scope are unmistakable.

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?

There is no guidance on when to prefer this tool over siblings such as yonetmelik_kontrolu or ek5_siniflar, and no exclusions or prerequisites are stated. The only implicit signal is that a summary is returned, which is not enough for routing.

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=false, so the description does not need to restate safety. It adds value by listing the exact types of information returned (regulation, gazette, calendar, source lines, version), which clarifies the tool's scope beyond the annotations. No contradictions.

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 two sentences and roughly 30 words, which is appropriately concise. However, the second sentence in English ('Which regulation this tool encodes, with the phased deadlines.') largely repeats the first sentence's content, adding redundancy. Still, it is front-loaded with the core purpose and efficient overall.

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 metadata-only tool with no parameters and an output schema present, the description covers the key return elements (regulation, gazette, calendar, source lines, version). It does not detail the output format, but the output schema presumably handles that. The description is sufficient for an agent to understand what information it will receive.

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 has zero parameters, and the input schema is empty with 100% coverage. Baseline for 0 parameters is 4. The description correctly focuses on the output content rather than parameters, since there are none to explain.

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 regulatory metadata: the regulation, Official Gazette date/number, validity, IFC calendar, data source lines, and version. It distinguishes itself from siblings like yonetmelik_kontrolu (regulation check) and model_ozeti (model summary) by focusing on static regulatory information rather than validation or summaries.

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 implies this is a reference/metadata lookup, but it does not explicitly state when to use it versus siblings. There is no mention of conditions like 'use this when you need the regulation basis' or exclusions. The context is somewhat clear from the name and purpose, but no direct guidance is 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?

The description adds valuable behavioral context beyond the annotations: it explains the output format (level, article, EK-9 line, GlobalId list) and the default behavior of the `disiplin` parameter (derived from file name, fallback to MM). This complements the readOnlyHint and openWorldHint annotations without contradiction.

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 informative but somewhat verbose, with the Turkish and English sentences repeating the core purpose. It is structured with a list of checks and a parameter note, but the redundancy and length could be trimmed for clarity without losing essential details.

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 covers the tool's scope, output format, and parameter behavior, and an output schema exists to specify return values. It lacks explicit mention of the `dosya` parameter's exact format and any prerequisites, but overall it is complete enough for an agent to understand how to invoke and interpret the 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?

The description thoroughly explains the `disiplin` parameter (allowed values and default logic), but it does not explicitly define the `dosya` parameter as the IFC file path, though it is implied by the tool's purpose. Given the schema has 0% coverage, the description only partially compensates for the missing parameter documentation.

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 checks an IFC model against the Turkish building-permit BIM regulation, lists specific checks (IFC version, skeleton, EK-5 classes, naming, attribute sets, coordinate system, etc.), and describes the output findings. This is a distinct, comprehensive compliance check that is easily differentiated from the specialized sibling tools.

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 implies usage for a full compliance audit but does not explicitly state when to use it versus alternatives like ek5_siniflar or ek6_gerekenler. It provides context but no exclusions or alternative conditions, leaving the agent to infer the scope.

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