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

With no annotations, the description carries the burden. It implies a read-only operation via '조회' and adds context on the type of data (sprinkler installation). However, it does not disclose any pagination behavior, required parameters, or response format beyond the literal purpose.

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?

One concise, front-loaded sentence with no filler. Every word earns its place, and the example adds clarity without bloat.

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 no output schema, the description covers the core purpose but lacks any mention of the required 'sido' parameter or the optional buildingName filter beyond schema. It is minimally complete but not richer than necessary.

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 baseline is 3. The description adds an example of facility types but does not clarify any parameter semantics beyond what the schema already provides.

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?

Describes a specific query ('소방시설 현황 조회' - fire facility status inquiry) for a specific resource (특정소방대상물 - specific firefighting targets), with an example (스프링클러 설치 여부). This clearly distinguishes it from sibling tools like search_fire_stats or get_ems_stats.

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. Sibling tools like search_fire_building or search_fire_stats are not mentioned, and no context is given about the preferred scenarios for 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. The verb '조회' (inquiry) indicates a read-only operation, which is a behavioral trait. However, the description does not disclose return format, pagination behavior, or error handling. It adds some value but stops short of full transparency.

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 a single concise sentence that front-loads the purpose and adds a parenthetical clarifying the metric type. There is zero wasted text, making it exceptionally efficient.

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 tool has six parameters, one required, and no output schema or annotations. The description clarifies the domain (traffic accident ambulance stats) and the core metric, but it does not explain pagination, filtering behavior, or how to interpret the results. For a moderately complex stats tool, this is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all six parameters with clear descriptions, including examples for 'sido' and a regex pattern for 'month'. The tool description adds no parameter-specific meaning beyond what the schema already provides, so the baseline score of 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?

The description clearly states the tool's function: it retrieves EMS activity statistics (traffic accident ambulance dispatch and transport counts) broken down by provincial headquarters and fire station. The Korean terms '구급활동' and '교통사고' make it specific and distinguish it from sibling fire-related search 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 does not explicitly state when to use this tool versus alternatives like search_fire_stats. However, the focus on ambulance/EMS activity implies its use case, and the sibling tools are clearly fire-oriented. This is enough for implied usage but lacks explicit alternatives or 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the purpose and fails to mention behaviors like truncation when jo is empty, priority of mst, or return format. The schema covers some behavior, but the description adds no transparency beyond the bare function.

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 a single sentence that front-loads the purpose and includes a concrete example. Every word is useful; there is no waste or irrelevant detail.

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 tool with three optional, well-described parameters, the description is adequate. However, without an output schema or annotations, it could benefit from noting what the response looks like or how it relates to sibling tools. The basic premise is covered, but deeper context 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?

The schema provides 100% coverage of parameter descriptions, including examples. The description's example is redundant and does not add meaning beyond what the schema already states. Baseline of 3 is appropriate since the schema does the heavy lifting.

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 uses a specific verb '조회' (inquiry) and resource '조문 전문' (full text of provisions), clearly indicating the tool retrieves the full text of a specific fire law article. The example with lawName and jo makes the purpose concrete and distinguishes it from sibling search tools like search_fire_law.

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 provides a usage example but does not explicitly state when to use this tool versus alternatives. The schema hints at a workflow (using MST from search_fire_law), but the description itself only implies usage without offering exclusions or alternative guidance.

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 present, so the description carries the full burden of behavioral disclosure. However, it only says 'search' and does not mention read-only behavior, pagination, result format, authentication requirements, or any side effects. It is minimal and not misleading, but it fails to add meaningful behavioral context.

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 a single, concise phrase that immediately conveys the tool's purpose and the primary filter dimensions. Every word earns its place, and there is no redundant filler 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?

With no output schema and only a one-line description, the return value structure, pagination behavior, error handling, and any special conditions are entirely omitted. The description is too sparse to fully prepare an agent for invoking the tool and interpreting results, especially given the search API nature with pageNo and numOfRows 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?

The input schema provides complete descriptions for all four parameters (sido, pageNo, numOfRows, approvalYear), so the baseline is 3. The description adds only a brief mention of filtering by city/province and approval year, which largely overlaps with the schema. No additional parameter semantics are provided beyond what the schema already defines.

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 action ('search') and the resource ('specific fire-fighting target buildings'), and adds the filter dimensions by city/province and approval year. While it does not explicitly differentiate from sibling tools, the subject matter is distinct enough from stats, law, and precedents searches.

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 usage guidance is provided. The description does not mention when to use this tool versus siblings, nor does it state prerequisites, exclusions, or alternative tools. The agent is left to infer applicability from the tool name alone.

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 of behavioral disclosure. It adds useful details: abbreviation support and the empty-query fallback to a list. However, it does not disclose return format, sorting, pagination, or error behavior, so transparency is only partial.

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 a single compact sentence that covers the core function, source, abbreviation feature, and empty-query behavior. Every clause provides value, with no wasted words 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?

For a simple tool with two optional parameters and no output schema, the description is largely sufficient: it conveys the search scope, source, and what happens when the query is empty. Minor gaps such as exact result fields are acceptable given the sibling get_fire_law_text implies this tool returns a list.

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 100%, with both 'query' and 'display' already described in the input schema. The description essentially repeats the query parameter's behavior (abbreviation support, empty-query listing), adding little beyond what the schema already 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?

The description clearly states the tool's function: searching fire-related statutes (소방 관계 법령 검색) with a source (법제처) and abbreviation support. It distinguishes itself from sibling tools like search_fire_stats and search_fire_precedents by focusing on laws, though it does not explicitly name alternatives.

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?

Provides clear context that this tool is for searching Korean fire statutes and explains empty-query behavior (displays a list of fire statutes). However, it does not explicitly state when to use this tool over get_fire_law_text or other siblings, leaving usage guidance largely 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?

No annotations are provided, so the description must carry the full burden. It discloses the source (법제처) and topical scope, but does not mention output format, pagination, or safety profile. As a read-only search operation, inherent safety mitigates some risk, but details are limited.

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 consists of two concise sentences that front-load the purpose and scope. There is no redundant or unnecessary information, and every sentence adds value.

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 2-parameter search tool, the description sufficiently covers purpose and topical scope. It does not explicitly describe the return format, but given the low complexity and clear search nature, the description is mostly complete. An explicit note on return type would have been beneficial.

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%, with both parameters (query and display) fully documented including examples. The description adds no additional parameter semantics beyond what the schema already provides, so a baseline score of 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?

The description uses a specific verb '검색' (search) and clearly identifies the resource as fire-related legal precedents. It distinguishes from sibling tools like search_fire_stats (statistics) and search_fire_law (laws) by specifying '판례' (precedents).

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 by listing covered topics (소방시설, 위험물, 소방공무원) but does not explicitly state when to use this tool over alternatives. It provides context but no exclusions or direct comparison with 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?

With no annotations, the description carries the full burden. It discloses that the tool returns counts for reception, in-progress, false alarms, and self-extinguishing, giving some insight into the data content. However, it does not mention read-only safety, pagination behavior, rate limits, or error handling, which are important for a search API.

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 highly concise, with two short sentences. The first sentence is front-loaded with the core purpose, and the second adds valuable detail about the data categories. No redundant or filler content.

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 tool has low complexity with 3 well-documented parameters and no output schema. The description sufficiently explains the tool's purpose and the nature of the returned data. However, it could be more complete by noting that results are paginated or that the API is read-only, though these are partly inferable from the schema.

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 fully documents all three parameters (date, pageNo, numOfRows). The description adds no additional parameter-level detail beyond the overall purpose, so it meets the baseline but does not exceed it.

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: '날짜별 화재발생현황 조회' (search fire occurrence status by date), with a specific resource (National Fire Agency national fire information) and data categories (접수, 진행, 오인, 자체진화). This distinguishes it from sibling tools like search_fire_building, which focuses on building-specific information.

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 date-based fire statistics through the date parameter, but it does not explicitly state when to use this tool versus alternatives. It lacks guidance on exclusions or when to prefer sibling tools such as search_fire_building or get_ems_stats.

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