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 does not state whether the tool is read-only, whether it has side effects, what it returns, or how it behaves if the optional school_code is omitted or invalid. 'Check' implies a query but gives no additional 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 short sentence, so it is concise, but it under-specifies the tool's functionality. It does not earn its place because it is too vague to be useful; it is more under-specification than effective brevity.

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 is fundamentally incomplete. Given the tool has no annotations, no output schema, and an ambiguous name, the description must fill many gaps but instead leaves the agent with no understanding of what 'provider readiness' means, what input to provide, or what result to expect. This is inadequate for a tool with any complexity.

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 has one parameter, school_code, with no schema-level description (0% coverage). The tool description does not mention this parameter or explain its meaning, format, or relationship to 'provider readiness.' The description adds no value beyond the raw 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 'Check provider readiness' has a verb ('Check') and a resource ('provider readiness'), but 'provider' is ambiguous and does not clarify whether it refers to a school, teacher, or other entity. It does not distinguish from sibling tools like get_class_day or search_school, which all relate to different aspects of the same domain.

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

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

The description gives no indication of when to use this tool versus the alternatives. There is no mention of context, prerequisites, or situations where this tool would be preferred over 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?

There are no annotations provided, so the description carries the full burden of behavioral disclosure. It only states 'Get a class day schedule' with no information about side effects, read-only nature, authentication requirements, error conditions, or return format. This provides no transparency beyond the bare action.

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 directly states the tool's purpose without any fluff or repetition. It is appropriately sized for a simple get operation and front-loads the key action, making it easy to scan.

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

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

Given the complexity of 4 required parameters and no output schema, the description is severely incomplete. It fails to explain what constitutes a valid date format, how the schedule is structured, what the return value looks like, or any edge cases. There is no distinction between school days and holidays, and no indication of whether multiple classes share schedules. This is far below the minimum viable for reliable 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%, meaning neither the schema nor the description explains the parameters. The description does not add any meaning to 'date', 'grade', 'class_no', or 'school_code' beyond their names. Without descriptions or examples, an agent cannot know expected value formats, date patterns, or how to construct valid requests.

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 'Get a class day schedule' uses a specific verb (get) and resource (class day schedule), clearly distinguishing it from sibling tools like get_class_week (week vs day) and get_teacher_day (teacher vs class). The scope is explicit: it returns a schedule for a specific class on a specific day.

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

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

No explicit guidance is provided on when to use this tool versus alternatives like get_class_week or get_teacher_day. However, the tool name and sibling names imply that this is for day-level class schedules, making usage context inferable but not stated. There is no mention of exclusions or alternative selection criteria.

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 disclose behavioral traits. It only states the operation is to 'get' a schedule, without specifying return format, pagination, or side effects. It fails to provide meaningful behavioral 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, front-loaded sentence with no fluff. It is concise to the point of underspecification, but it earns its place as a basic purpose statement.

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

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

Given the tool has four required parameters, no annotations, no output schema, and sibling tools that overlap, the one-sentence description is inadequate to guide correct invocation. Missing parameter semantics and usage context make it contextually incomplete.

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

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

Schema description coverage is 0%, and the description does not explain any of the four required parameters (school_code, grade, class_no, date). The tool expects the agent to infer meaning solely from parameter names, which is insufficient.

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 action ('Get') and resource ('class week schedule'), distinguishing it from sibling get_class_day by specifying 'week'. However, it does not elaborate on what a class week schedule contains, but the core purpose is clear.

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 no guidance on when to use this tool versus alternatives like get_class_day or get_teacher_week. It does not mention conditions, prerequisites, 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?

No annotations are provided, so the description carries the full burden. The verb 'get' implies a read-only operation, but nothing is disclosed about return format, pagination, or date handling semantics, leaving significant behavioral ambiguity.

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 extremely short — a single sentence. While concise, it is under-specified rather than appropriately sized, providing no front-loaded context or useful elaboration.

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 annotations, no output schema, and a 6-parameter input at 0% schema coverage, this description is completely inadequate. It fails to convey the tool's data source, filtering options, or expected result, making it almost impossible for an agent to use 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?

The input schema has 6 parameters with 0% description coverage in the schema, and the description provides no explanations for any parameter. It does not even clarify the required from_date and school_code parameters, leaving all parameters opaque.

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 ('schedule change events') and a verb ('get'), which is clear at a basic level. However, it does not specify the scope (e.g., by class, teacher, or date range) and only marginally distinguishes from sibling tools that also retrieve schedule data.

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

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

There is no guidance on when to use this tool versus alternatives like get_class_day or get_teacher_week. It does not mention required parameters, date range conventions, or any 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 full burden. It fails to disclose any behavioral traits such as whether the operation is read-only, required permissions, date formatting, or response shape. This is minimal 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?

The description is a single sentence, which is concise, but it is under-specified. While not verbose, it lacks essential details, making it an acceptable but not excellent structure.

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 three parameters and no output schema or annotations. The description does not explain return values, date format, possible filters, or edge cases. For a schedule retrieval tool, this is insufficient context.

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

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

Schema description coverage is 0% and the description does not explain any of the three parameters (school_code, teacher_id, date). The schema only lists names and types, leaving the agent without context for required 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 uses a specific verb ('Get') and resource ('teacher day schedule'), which clearly states what the tool does. It distinguishes from siblings like get_teacher_week and get_class_day by specifying 'teacher' and 'day'.

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 is provided about when to use this tool versus alternatives like get_teacher_week or get_schedule_changes. The description only states the function with no context for selection.

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 must fully disclose behavioral traits. It only restates the fundamental action ('Get a teacher week schedule') without mentioning date format, week definition, return structure, or any error conditions. The read-only nature is implied but not enriched with useful 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, grammatically clean sentence with no filler, but it is under-specified to the point of being nearly tautological. Conciseness is acceptable, but the lack of substance limits its 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 tool with 3 required parameters, no annotations, and no output schema, this one-sentence description is insufficient. It does not explain the return format, how the date parameter defines the week, or when this tool is appropriate given the sibling tools.

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

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

Schema description coverage is 0%, and the description adds no meaning to the three parameters (school_code, teacher_id, date). It does not explain what 'date' represents, what school_code and teacher_id refer to, or how they relate to the schedule retrieval.

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 ('Get') and identifies the resource ('a teacher week schedule'), clearly indicating the tool's purpose. It does not explicitly differentiate from sibling tools like get_teacher_day or get_class_week, but the resource is unmistakably a teacher's weekly schedule.

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 is provided on when to use this tool versus alternatives such as get_teacher_day or get_class_week. There are no context clues, exclusions, or prerequisites beyond the basic purpose.

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 behavioral burden. It discloses one notable behavior: 'redacted by default.' However, it does not explain what redaction entails, whether it affects response format, or any other operational details.

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, front-loaded with the core purpose. It wastes no words and efficiently communicates the primary function.

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

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

Given the tool has three parameters, no output schema, and no annotations, the description is too minimal. It leaves key aspects unaddressed, such as the return format, the meaning of date, and the exact behavior of redaction, making it incomplete for reliable use.

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 for parameter meaning. 'For a school' hints at school_code, and 'redacted by default' clarifies the redact parameter's default, but the date parameter is completely unexplained, offering insufficient semantics.

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 lists teachers for a school, using a specific verb and resource. It distinguishes from siblings by focusing on teacher listing rather than schedule details, 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?

No explicit guidance on when to use this tool versus alternatives. The phrase 'for a school' implies a context but does not clarify prerequisites, exclusions, or when a sibling tool might be more appropriate.

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, and the description only states the action without disclosing search behavior, output format, permissions, or whether it returns partial matches. This leaves significant behavioral aspects unexplained.

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, focused sentence that immediately communicates the action and parameter. No unnecessary words or duplication.

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 search tool, the description covers the input parameter but omits any information about return values, result limits, or error behavior. With no output schema, this is a notable 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 only parameter 'name' is described as 'Korean school name,' which adds semantic meaning beyond the bare schema. However, it does not specify matching rules or expected input 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 uses the specific verb 'Search' with the resource 'schools' and clarifies the parameter as 'Korean school name,' which distinguishes it from sibling tools focused on classes, teachers, and schedules.

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

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

No explicit guidance is provided about when to use this tool versus alternatives. The purpose is implied by the tool name and sibling context, but there is no direct mention of use cases or exclusions.

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