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. It does convey that the tool is a read operation ('조회') and that it returns the full text, which is useful. However, it does not mention potential errors, output format, or any permission requirements. For a simple retrieval tool this is acceptable but not rich, so a 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 two sentences long, front-loaded with the primary purpose, and the second sentence provides essential usage context. Every word earns its place with no redundancy or 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?

For a single-parameter read tool without an output schema, the description conveys the core purpose and the required input source, which is largely sufficient. The missing return field details are not critical for a 'get full text' tool, and the sibling context is handled by the 'full text' wording. It falls just short of a 5 because it doesn't explicitly describe the response structure.

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%, and the schema description already explains that the id is the SEQ_HISTORY ID from search_regulations or list_regulations. The tool description repeats this same information, adding no new meaning beyond the schema. With high schema coverage, the baseline is 3, and the description doesn't 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 action ('특정 규정의 전문을 조회합니다' – retrieves the full text of a specific regulation) and identifies the resource as a specific regulation. It also distinguishes itself from sibling tools like search_regulations/list_regulations (which find regulations) and get_regulation_article (which likely retrieves a single article) by emphasizing '전문' (full text).

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 explicitly tells the agent to use an id (SEQ_HISTORY) obtained from search_regulations or list_regulations, providing clear prerequisite context for when this tool should be invoked. It doesn't explicitly contrast with get_regulation_article, but the 'full text' phrasing implies the difference, so it earns a 4 rather than 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?

No annotations are provided, so the description carries the full burden. It discloses the tool only retrieves a specific article, implying a read-only operation, but does not add context about authentication, error behavior, or return format. This is adequate but not rich.

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 concise sentences: the first states the purpose and the second gives input instructions with an example. Every word earns its place, with no wasted 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?

For a simple two-parameter retrieval tool with no output schema, the description is sufficient: it identifies the resource and the exact inputs needed. It does not explain return values, but given the tool's simplicity and the input clarity, this is not a critical 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 coverage is 100%, so the baseline is 3. The description adds a practical example ('제5조') but does not expand on parameter semantics beyond what the schema already provides, so it does not exceed the 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?

The description states a specific verb '조회' (retrieve) and resource '특정 규정의 특정 조항' (specific article of a specific regulation), clearly distinguishing it from siblings like get_regulation which would retrieve the whole regulation.

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 '특정 조항만 조회' implies this tool is for retrieving a single article rather than full regulations, providing implicit context for when to use it. However, it does not explicitly name alternatives or exclusions, 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?

There are no annotations provided, so the description carries the behavioral disclosure burden. It adds value by explaining the default behavior (only latest versions) and the includeOldVersions option, which is beyond the schema. However, it does not disclose potential limitations such as pagination, rate limits, or authentication requirements.

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 at two sentences. The first sentence front-loads the main purpose, and the second adds the key parameter behavior. Every word earns its place, with no fluff or redundancy.

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?

This is a simple tool with one optional parameter and no output schema. The description sufficiently covers the tool's main behavior and the optional version filter. While it could mention the return structure (e.g., list of regulation names/IDs), the simplicity of the tool makes this a minor 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?

The schema already provides a description for the includeOldVersions parameter, so the baseline is 3. The description essentially repeats the parameter's effect (including old versions) without adding further meaning, such as default value implications or edge cases.

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 the entire list of regulations (한성대학교 규정 전체 목록), using a specific verb '반환합니다' and clearly identifying the resource. It distinguishes itself from sibling tools like search_regulations, get_regulation, and get_regulation_article by explicitly indicating it returns the full list.

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 is for retrieving the complete list of regulations, contrasting with search or retrieval tools. It states the default behavior (latest versions only) and the optional parameter to include old versions, giving clear context for when to use it. However, it does not explicitly mention 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, the description carries the full burden. It discloses that search is limited to regulation names and returns a list of matches, which is useful. However, it omits details like matching behavior (case sensitivity, partial matches) and whether the list is paginated.

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 concise sentences, front-loaded with the action, no filler. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter search tool with no output schema, the description sufficiently explains the purpose and return type. Minor omission of output format details is acceptable given the simplicity, but it could mention the structure of the returned 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?

The input schema provides 100% coverage with a clear description of the query parameter, including examples. The tool description adds no additional parameter semantics beyond what the schema already states.

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 'searches' and clearly defines the resource (regulations) and scope (by keyword in regulation names). It distinguishes from sibling tools like list_regulations and get_regulation by focusing on keyword-based lookup.

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 keyword-based searching but does not explicitly contrast with alternatives or mention when not to use it. The context is clear, but it lacks explicit 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.