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

With no annotations, the description carries the full burden, and it does disclose a real behavioral trait beyond the schema: with no keyword it returns the 15 most recent upcoming events after today. It says nothing about pagination, ordering beyond 'after today', how many results a keyword search returns, or failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the resource and then the default behavior; nothing is padded. The terseness borders on under-specification, but no sentence 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?

An output schema exists, so return values need not be described, and the default-result rule is covered. Still, with no annotations and an undocumented 'year' parameter, an agent cannot confidently call this with a specific year or know what a keyword search returns.

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 explains 'keyword' well with concrete example values, but 'year' is never mentioned despite its cryptic default of 0 (current year? all years?), leaving a genuinely ambiguous sentinel undocumented.

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?

'학사일정' (academic schedule) names the resource precisely and the second sentence specifies the default retrieval behavior (15 events after today). The verb is implicit and no sibling (e.g., notices, dept_notices, library_hours) is named as an alternative, so an agent can tell what it fetches but gets no explicit disambiguation.

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 keyword examples ('기말', '수강신청', '휴학') implicitly show when to pass a filter versus omitting it, and the no-keyword case is spelled out. There is no explicit when-to-use / when-not-to-use guidance or named alternative tool for related needs like general notices.

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; '찾기' implies a read-only lookup and the empty-keyword fallback to a full list is useful behavioral detail. It does not say whether matching is partial or exact, whether results are ordered or paged, or anything about access constraints – but for a one-parameter lookup on a public campus site these gaps are modest.

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 parameter default behavior appended. Nothing repeats the schema or wastes tokens.

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 takes one optional string, has an output schema (so return values need no explanation), and the description covers both purpose and the empty-parameter case. For a tool of this complexity there is little an agent still needs to know in order to call it 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?

Schema description coverage is 0%, so the description must compensate – and it does, explaining that the keyword can be a number or a name fragment, with four concrete example values, plus the default-empty behavior ('전체 목록'). Only exact matching semantics (substring vs. exact) remain unstated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('캠퍼스 건물 번호·이름 찾기' – find campus building number/name) and gives concrete query examples ('7', '공학', '도서관', '학생회관'). The resource is distinct enough from the sibling list (meal, notices, departments, library_hours) that an agent can identify the tool without opening the schema, though no sibling is named 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?

It provides an explicit empty-input behavior ('비우면 전체 목록' – if blank, return the full list), which is real usage guidance for the single parameter. However, it never states when to prefer this tool over related siblings (e.g., departments or library_hours) or when not to call it, 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?

No annotations are provided, so the description must carry the behavioral burden. It implies a static, parameterless lookup with no side effects, but never states that it is read-only, whether the list is complete or paginated, or that no arguments are required. For a zero-argument listing tool the risk is low, so the gap is modest rather than severe.

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 clauses, zero filler: the resource is stated first and the sibling routing second. Every phrase 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?

With an output schema present, return-value detail need not be described, and the absence of parameters removes input ambiguity. The only remaining gap is the lack of any statement about read-only behavior or list completeness, which matters slightly given there are no annotations.

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, so there is nothing for the description to disambiguate; the baseline for a 0-param schema applies. The description correctly signals that no scoping input is expected.

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 resource: the list of colleges/schools under the 2025 reorganization plus their department/major homepages. It also points at the sibling tool that covers the adjacent domain (track_search). The verb is nominal ('목록'), so it is a clear resource description rather than an explicit action statement.

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 explicitly routes the agent away from this tool for major/track content by naming track_search as the alternative. It does not spell out a positive trigger condition beyond the implied 'when you need the college/department list', but the exclusion is enough to disambiguate.

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 burden alone. It discloses the valuable data quality caveat that newly created 2025 departments may have empty location fields, but doesn't state whether the tool is read-only, what the output table looks like, or coverage 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 sentences, front-loaded with what the tool returns, followed by the caveat and fallback. Every sentence carries signal, though the fallback sentence is slightly compressed and could be clearer.

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?

Output schema exists, so return values needn't be explained, and the data caveat is a helpful addition. However, with zero schema coverage on the sole parameter and no annotations, the description should clarify the input's expected meaning to be 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?

Single parameter 'name' has 0% schema description coverage, and the description never clarifies whether 'name' is the department name or a person's name. The dept_site(dept, ...) reference hints at department names, but this is inferential rather than explicit.

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: department office phone numbers and a professor/staff contact table. An agent can tell it apart from dept_site or departments, though the description doesn't name what distinguishes it from the plain 'departments' sibling.

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?

Gives a concrete fallback rule: for 2025 newly established departments where location may be blank, use dept_site(dept, '찾아오시는길'). That is useful guidance for missing data, but there is no explicit 'use this when X, not Y' for the core lookup versus other 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 behavioral burden, and it does disclose the return payload shape (body text, attachment links, image links). It says nothing about permissions, error behavior for invalid dept/no combinations, or pagination/truncation of long bodies, which leaves meaningful gaps for an unannotated tool.

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 no filler; the content-first statement leads and the parameter caveat follows. It is efficient, though the extreme terseness borders on cryptic for an agent without Korean-language context.

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 prose explanation, and the description correctly focuses on scope and the `board` linkage. Still, for a 3-parameter tool with zero schema descriptions and no annotations, the unexplained required `dept` and `no` parameters leave the definition short of what is needed to call it confidently.

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, and it only explains one of three parameters: `board` must mirror the value obtained from `dept_notices`. The required `dept` and `no` parameters are left entirely undefined — an agent must guess that `no` is a notice identifier and `dept` a department key, and in what format.

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 identifies a specific resource — the body of a department notice plus its attachment and image links — which distinguishes it from the sibling `dept_notices` (the listing tool) and from the generic `notice_detail`. The retrieval verb is only implied, but the resource and returned content are concrete enough for an agent to recognize it as a detail/get tool.

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 note that `board` must be the exact value used in `dept_notices` implicitly signals the intended call order: list first, then fetch detail. However, there is no explicit statement of when this tool should be chosen over `notice_detail` or what happens if it is called without a prior `dept_notices` lookup.

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 implicitly establishes a read-only listing and hints that results carry numbered items ('[번호]') that feed dept_notice_detail. It says nothing about pagination behavior, ordering, or how many results come back per call, which matters for a paginated list tool.

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, each carrying a distinct piece of information (what it lists, how to pick a board, where details go). No filler, and the handoff note is placed last where it belongs.

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 formatting needn't be explained. Still, for a 5-parameter paginated tool with zero schema descriptions, the description leaves keyword/page/limit semantics and the dept-vs-generic-notices distinction unresolved.

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 gives concrete dept examples ('ICT융합학부', '산업경영공학부') and explains what board selects. The remaining three parameters (page, limit, keyword) get no mention at all, leaving half the surface to the bare 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?

The description states the resource precisely ('학부·학과 홈페이지 공지 목록') and explicitly hands off detail lookups to the sibling dept_notice_detail. The listing verb is only implied by '목록', but the resource and scope are unambiguous.

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 explains when the optional board parameter matters ('게시판이 여럿일 때') and routes numbered items to dept_notice_detail, which is real routing guidance. However, it never distinguishes this from the generic sibling 'notices' or 'dept_site', which is the main alternative an agent must choose between.

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 exist, so the description carries the full burden; it does disclose the read-only nature and the special behavior of an empty menu (returns the site's menu list). It says nothing about what happens with an invalid dept, whether the target site may be unreachable, or any rate/permission constraints. Return shape is covered by the output schema, which lowers the bar.

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 core action and the menu enumeration are front-loaded, and the sibling routing note is placed last where it belongs. The long example list is dense but each item maps to a real menu value, so it earns its space; a slightly tighter phrasing would reach a 5.

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 two-parameter read tool with an output schema and no annotations, the description covers what is fetched, how to enumerate menus, and where notices belong. The only residual gap (valid dept values) is naturally supplied by the departments sibling.

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, and it largely does for 'menu': the enumerated menu names act as an implicit value vocabulary and the empty-string default behavior is explained. 'dept' is only implied by the tool's domain rather than defined (no guidance on accepted identifiers, presumably from the departments sibling).

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 gives a specific verb+resource ('학부·학과 홈페이지의 다른 메뉴 읽기') and enumerates concrete menu types (찾아오시는길, 교수소개, 교육과정, 학사일정, etc.), so the agent knows exactly what content it fetches. It explicitly routes notice-board content to the sibling dept_notices, but does not differentiate itself from other site-reading siblings such as site_page, site_menu, or departments.

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 states a concrete invocation rule ('menu를 비우면 그 사이트 메뉴 목록') and names the alternative for notices (dept_notices), which is clear contextual guidance. It stops short of exclusions for overlapping siblings like dept_contact (office location is listed here too) or site_page.

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 behavioral burden, and it says nothing about read-only semantics, permission requirements, or error behavior for an invalid identifier. The content enumeration adds some value, but return values are already covered by the output schema.

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 short, front-loaded sentence with no filler; the content list is the most useful information and appears immediately. It is arguably too terse rather than padded.

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 detail-fetch tool the output schema relieves the description of explaining return values, but the critical missing piece is how to obtain `seq` and how this tool relates to `jobs`. With no annotations and 0% parameter coverage, that omission leaves 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 0%, so the single `seq` parameter is completely undocumented in both schema and description. The description never mentions that `seq` is the posting identifier obtained from the `jobs` listing, leaving the caller to infer 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 identifies the resource precisely as the job-posting body and enumerates the kinds of content it contains (qualifications, salary, deadline, submission method), which implicitly separates it from the sibling `jobs` listing tool. It lacks an explicit verb and never states it is the detail counterpart to `jobs`, but an agent can infer the purpose.

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 when-to-use guidance, no statement that this must be called after `jobs` to resolve a posting identifier, and no exclusions or alternatives named. The agent must guess the relationship to `jobs` from the names 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 exist, so the description carries the burden. It usefully discloses the result shape and the 5-page keyword scan limit, but says nothing about page/limit defaults, total result counts, or ordering beyond the field list. Meaningful but incomplete behavioral disclosure.

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?

Very compact, front-loaded with the resource and result shape, then the keyword rule and the detail-tool pointer. The bracketed field notation is dense but each fragment 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?

An output schema exists, so return values need not be re-explained, yet the description still summarizes the fields and adds the paging caveat and sibling pointer. Complete enough for correct invocation; only pagination semantics remain thin.

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

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

Schema coverage is 0%, so the description must compensate. It explains keyword semantics well (filters on company/title, scoped to first 5 pages), but page and limit are undocumented beyond their schema defaults. Partial compensation justifies a mid score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: lists main-campus job postings, and enumerates the returned fields ([번호] 구분 기업 제목 (등록일 ~ 마감일)). It also names the sibling job_detail for body content, so an agent can distinguish list vs. detail without opening either schema.

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?

Explicitly routes to job_detail(번호) for postings' body, and discloses an important usage constraint: keyword only filters over the first 5 pages. Missing an explicit statement of when not to use it (e.g. vs. notices/site_search), but the context is clear.

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 does disclose one meaningful constraint (seat status is out of scope because it requires login). However, it says nothing about whether hours are static or term/holiday-dependent, nor about staleness of the data — relevant behavioral context for a schedule tool.

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, resource identity front-loaded, with the scope limitation placed immediately after. Nothing is wasted and nothing important 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?

A simple read-only, zero-parameter lookup with an output schema that carries the return shape. The description covers what it returns and one exclusion, which is nearly complete; only freshness/term-dependence 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 tool takes zero parameters, so there is nothing for the description to disambiguate; the schema is trivially complete. Baseline 4 applies for a no-arg tool.

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: the central library's 자료실 (collection room) and 열람실 (reading room) operating hours. An agent can distinguish it from library_search (searching materials) and campus_building without ambiguity, though no sibling is named 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 implied by the resource itself (call it to get library hours), and the parenthetical adds a useful scope exclusion — seat availability is not available here due to login requirements. There is no explicit when-to-use guidance or pointer to an alternative tool for seat data.

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 behavioral burden, yet it discloses nothing about result behavior beyond listing fields, nor about limits, permissions, or pagination. It does hint that availability is a returned attribute, which is useful context, but that is the only disclosure.

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 compact sentence with the resource scope front-loaded and no filler. It is efficient, though the brevity contributes to the semantic gaps noted elsewhere.

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 presence of an output schema means return values need not be explained, and the searchable-field list gives basic orientation. However, for a query-driven search tool with an undocumented limit parameter and no usage guidance, the description leaves meaningful 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 0%, so the description must compensate, but it only implies that the query string may match title/author/publication/call number/location/availability. It never states whether matching is keyword, substring, or exact, and says nothing about the 'limit' parameter's meaning or bounds.

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 gives a specific verb and resource ('중앙도서관 소장 자료 검색') and enumerates the searchable fields (title, author, publication, call number, location, availability), so an agent knows exactly what domain this covers. It does not explicitly contrast with sibling tools like library_hours, but the holdings-search scope is distinct enough from the names alone.

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 statement of when to use this versus alternatives (e.g. library_hours, site_search) and no prerequisites or exclusions. Usage is only implied by the verb '검색'.

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 exist, so the description carries the burden alone. It discloses a useful quirk — the student cafeteria has moved to the dormitory cafeteria (무거관) with the same menu — but does not state read-only nature explicitly, nor caching, language, or availability behavior beyond that note.

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, dense sentences with the resource named first and parameter guidance following. Every clause carries information, though the cafeteria-relocation note is slightly tangential to invoking the 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 described. Two optional parameters are fully explained and the hours use-case is routed elsewhere; only the default-parameter behavior and language of results 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 0%, so the description must supply meaning, and it does: it enumerates the accepted date forms and the cafeteria categories (학생·교직원·기숙사). It does not explain the default behavior when parameters are omitted, which keeps it below a 5.

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 opens with '학식 메뉴' (cafeteria menu), a specific resource, and the date/cafeteria values make it clear this retrieves menu listings. It is distinguishable from siblings like job_detail or library_hours, though no sibling is named as a contrast.

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 explicitly tells the agent which date values are accepted (오늘/내일/금요일/YYYY-MM-DD) and which cafeteria values apply, plus routes operating-hours questions to site_page('MN134'). There is no explicit when-not-to-use statement, but the alternative route for hours is clear.

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, and it does establish that this returns content (body + attachment list) rather than mutating anything, which signals a read-only fetch. It does not disclose behavior on an invalid or unknown seq, permission/authentication needs, or whether the attachment list is truncated, so the mutation/error profile remains undocumented.

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 states the two things returned and then the follow-up action in parentheses; there is no filler and no restatement of the tool name. It is appropriately sized for a two-parameter detail 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 the return payload needn't be spelled out, and the description correctly limits itself to saying body plus attachments come back. What is missing for a tool with zero annotation coverage and zero schema description coverage is the meaning of 'seq'/'board' and any failure behavior, leaving real gaps for an agent deciding how to call it.

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% for both parameters: 'seq' is a bare integer with no title beyond 'Seq', and 'board' is a string defaulting to '공지'. The description adds no meaning for either — it does not explain that seq is a notice identifier obtained from the notices list nor what values 'board' accepts, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource pair: the notice body plus its attachment list, and implicitly distinguishes this main-campus detail fetch from the sibling 'dept_notice_detail' via '본교'. It also routes PDF reading to a named sibling, so an agent can separate this from 'notices' (list) and 'read_attachment' (file contents), though it never states the resource verb explicitly (fetch/retrieve).

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 one useful routing hint: attachment PDFs should be read with read_attachment, which tells the agent when to chain into another tool. However, it never says that a notice 'seq' must first be obtained from the 'notices' sibling, nor does it mention any when-not conditions or prerequisites for this being a detail (single-item) call.

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 exist, so the description must carry behavior; it discloses the search field semantics (title-only) and the result-to-detail handoff, which is real added context. It does not say anything about paging behavior, result ordering, or total counts despite the page/limit parameters, leaving a gap for a no-annotation tool.

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?

Front-loaded with the resource and board options before the detail-chaining note, and nearly every clause is load-bearing. It is somewhat run-on, with the long mCode example list sitting mid-sentence and slightly interrupting the read.

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 explanation is unnecessary, and the board taxonomy plus the notice_detail handoff cover the main decision points. The missing pagination guidance is the only real hole, and it is minor for a listing 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 coverage is 0%, so the description must compensate. It explains `board` (enum-like values plus mCode examples) and `keyword` (title search), but `page` and `limit` — both defaulted and central to controlling the result set — are entirely unaddressed in both schema and 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 concrete resource (본교 게시판 목록) with the specific board taxonomy it covers, and explicitly routes non-covered cases elsewhere ('채용공지는 jobs'). An agent can distinguish it from notice_detail (which reads a single post) and jobs without opening a schema.

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?

Names the valid `board` values, points to site_menu for mCode discovery with concrete examples, notes that `keyword` is a title search, and prescribes the follow-up call ('결과의 [번호]를 notice_detail(번호, board)에 넘기면...'). Explicit when-to-use, alternatives, and chaining are all present.

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 the core behavioral trait that PDFs become text while images and HWP return links only. However, it omits truncation behavior tied to max_chars, handling of unsupported formats, and any error/failure semantics for unreachable URLs.

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; the format-support constraint is front-loaded immediately after the action statement. Every sentence 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?

An output schema exists, so return-value explanation isn't needed, and the format caveat is covered. Still, for a two-parameter extraction tool, the undocumented max_chars truncation and incomplete format coverage (no mention of DOCX, TXT, etc.) leave gaps an agent would hit in practice.

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, but it says nothing about either parameter. In particular, max_chars (default 15000) drives output truncation and is entirely undocumented, leaving the agent unaware that long PDFs may be cut off.

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 (read) and resource (Ulsan University site attachments) and names the format scope (PDF). It also clarifies the fallback for images/HWP, so an agent knows exactly what it gets. No sibling tool overlaps with attachment reading, so explicit differentiation isn't required.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: use this to convert a PDF attachment linked from a notice/detail page into text. There is no explicit statement about when not to call it (e.g., for HWP/images, which only return links) or about prerequisites such as the URL needing to come from a prior tool result.

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 exist, so the description carries the full disclosure burden. It does disclose the important behavioral trait that the output is a menu code intended for site_page, but says nothing about read-only nature, what an empty keyword returns, or result size/pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the purpose with a compact example set, then the follow-up workflow. Zero filler and the core identification is front-loaded.

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-format explanation is unnecessary and the description correctly focuses on the workflow handoff to site_page. The only gap is the semantics of an empty or broad search, which an agent might need in practice.

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% for the single 'keyword' parameter, so the description must compensate. The example keywords do convey the expected value domain, but the empty-string default (which presumably lists everything) is never explained.

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: searching the Ulsan University homepage menu/sitemap. Explicitly separates itself from site_page by describing the follow-up handoff ('나온 mCode를 site_page에 넘기면'), so an agent can tell the two apart from the description alone.

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 keyword examples ('장학', '기숙사', '셔틀', '등록금'…) show concretely what kind of queries belong here, and the second sentence defines the downstream step with site_page. It does not, however, contrast itself with the sibling site_search, leaving that distinction 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?

Despite lacking formal annotations, the description discloses behavioral traits about the content returned, such as including tables, attachments, and links. This informs the agent about the richness and complexity of the data it will receive, going beyond mere parameter validation.

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 information is dense, perfectly structured across two sentences, and all components contribute to defining the tool's utility and requirements. There is no unnecessary padding.

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 provides the complete context needed for the input (source and meaning of mcode) and defines the scope of the output (what kinds of content are returned). Given that an output schema exists, this definition is highly complete for a content-fetching 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?

Since the input schema provides no description, the description provides maximal semantic value by defining 'mcode' not just as a string, but as the result of the 'site_menu' and giving real-world examples ('MN243' for Dormitory), which is essential for correct 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?

The description clearly states the tool retrieves the content ('guide page body, including tables, attachments, and links'). It is highly specific and easily distinguishes this content retrieval task from simple site searching or menu listing.

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 is governed by the input 'mcode'. The description explicitly tells the agent that this code must come from the 'site_menu' tool, creating a clear prerequisite workflow for usage.

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, so the description carries the full burden, and it does disclose nontrivial behavior: the search reaches page body and board text, and kind='B' returns 'more' results than info-page-only search. It doesn't mention result limits, pagination, or auth, but the core behavioral shape is clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the search scope, then the kind options, then the result routing. No filler; the parenthetical examples earn their place by disambiguating the tool's reach.

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 needn't be explained, and the description complements it by naming the fields that matter for follow-up calls (mCode, board_seq). Minor gap: no mention of result volume caps or ordering, which matters for a search tool returning 'more' items.

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

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

Schema coverage is 0%, so the description must supply the missing semantics — and it fully defines kind's three values ('', 'C', 'B') with their meaning and the volume tradeoff, which the bare schema does not convey at all. keyword's meaning is evident from the search context.

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 (통합검색 over page bodies and board posts) and explicitly differentiates itself from menu-name lookup by noting it finds words not in menu names. The examples ('근로장학', '교환학생', '전과') make the retrieval scope concrete and distinguishable from site_menu/site_page.

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?

Gives a clear use condition (searching terms absent from menu names) and tells the agent where to take results via the mCode → site_page and board_seq → notice_detail routing. It stops short of an explicit 'use site_menu instead for menu names' exclusion, but the alternative path is strongly 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?

With no annotations, the description carries the full burden. It adds useful behavioral context about the page text format, including that columns are approximate because blank cells are skipped and that the far-right '…module' label is a course bundle name. However, it does not explicitly state read-only behavior, page-range behavior, or how this retrieval relates to the search tool.

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 front-loads the core purpose and then adds relevant layout details. It is compact and mostly earns its sentences, though the phrasing is dense and somewhat opaque for an agent unfamiliar with the source document.

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 an output schema, so return-value details are not required in the description. The description adequately covers page content and text layout, but it omits usage context relative to track_search and does not fully specify page numbering, leaving some gaps for correct invocation.

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

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

Schema coverage is 0%, so the description must compensate for the bare integer 'page' parameter. It does add meaning by indicating that the parameter selects one page of the track introduction and by mentioning pages 2–3 specifically, but it does not clarify page numbering rules or accepted page values.

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 that this tool returns the full text of one page from the track introduction, and it specifies what pages 2–3 contain. It is distinguishable from track_search by its page-oriented retrieval purpose, though it does not explicitly name the search sibling as an alternative.

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 explains page content and layout but gives no explicit guidance on when to use this tool versus track_search or other siblings. There are no stated preconditions, exclusions, or workflow hints such as whether it should follow a track_search call.

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 the search corpus, page-level result granularity, and AND matching across terms, which are genuinely behavioral facts. It says nothing about result ordering, what the limit bounds, or how the downsized excerpts are shaped, leaving meaningful behavioral gaps for an unannotated tool.

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?

Dense but efficient: source document and location first, then scope, then matching semantics, then the escape hatch to track_page. Every clause carries information; only the raw menu ID 'MN355' is opaque without context.

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 behavior need not be restated, and the document scope plus the track_page hand-off give an agent enough to call it correctly. The unexplained limit parameter is the one real omission.

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 keyword semantics (all terms must appear on the same page) but never mentions the limit parameter or its default of 8. Partial compensation earns a middling score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (search inside the 2026 Ulsan University track guide, a 258-page PDF at homepage MN355) and enumerates the covered content: track types, tracks by college, curriculum charts, courses, careers. It also distinguishes itself from the sibling track_page, which returns the whole page.

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?

Explicitly routes the agent to track_page when the full page is needed, and explains that multi-word queries are treated as AND over page contents. It does not address when to prefer this over the generic site_search sibling, which is the remaining ambiguity.

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