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

With no annotations, the description carries full behavioral burden but only restates the 5000-character limit, which is already in the schema. It does not disclose return format, accuracy, whether the operation is read-only, or any side effects or processing traits.

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

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

A single, front-loaded sentence that wastes no words. It is appropriately terse, though the extreme brevity means it omits information needed elsewhere rather than being overly verbose.

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 one-parameter tool with no output schema and no annotations, the description should at least hint at the return format (e.g., what HSK level output looks like) and confirm the read-only nature. It instead provides only the input constraint, leaving key contextual 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% for the single required parameter, so the description must compensate. It adds only that the input should be 'Chinese text (up to 5000 characters),' but the length constraint duplicates the schema and it omits expected format details such as simplified vs. traditional characters or handling of mixed-language text.

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 ('Estimate') and resource ('HSK level of Chinese text'), which clearly identifies the tool's function. It does not explicitly differentiate itself from siblings like get_level_check_link or list_words_by_level, but the purpose is distinct enough for an agent to understand.

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

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

Provides no guidance on when to use this tool versus alternatives such as get_level_check_link or lookup_word. There are no prerequisites, exclusions, or contextual triggers mentioned; usage is only implied by the description.

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

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

No annotations are provided, so the description carries the burden. 'Get... link' implies a read-only retrieval and the description clarifies the link's purpose for learners, though it doesn't state authentication or link permanence. Adequate for a simple link getter.

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 the action, and the second sentence adds purpose without redundancy. No wasted words.

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 no parameters, no annotations, and no output schema, the description explains what is returned (a link) and its intended use. It could specify the link format or that it's static, but that's minor.

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?

There are no input parameters (schema is empty), so per the rubric baseline is 4. The description adds no parameter information because none exists.

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 ('Get') and resource ('HSK Studio level check page link'), making the tool's output clear. It does not explicitly differentiate from sibling check_text_level, which likely performs the check directly, but the learner-sharing purpose implies the distinction.

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 second sentence gives a clear usage scenario: send learners there to check their own text and share the result. No explicit when-not or alternative tool is named, 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?

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses the shape of the payload (text, HSK level, embedded vocabulary), but says nothing about auth, error handling for a missing/invalid id, or response size, which is a real gap for a lookup 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 with no waste; the purpose and return contents are front-loaded, and the id-provenance note follows. Every clause 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 no output schema, the description correctly compensates by naming what comes back, which is what an agent needs for a one-parameter lookup. Minor omissions (error cases, output ordering) keep it from being fully complete.

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

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

The single parameter has 0% schema description coverage, so the description must explain it — and it does, clarifying that the id is a reading id sourced from list_readings rather than a word id or level. It still does not state the id format, so not 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?

States a specific verb ('Get') and resource ('one graded reading') and enumerates the returned fields (text, HSK level, vocabulary). The singular 'one' plus the pointer to list_readings makes it clearly distinct from the sibling list_readings.

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 tells the agent how to obtain the required input: 'Ids come from list_readings', which routes it to the sibling listing tool as the prerequisite step. It does not state a when-not condition or failure behavior for unknown ids, so it stops 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?

No annotations are provided, so the description carries the full disclosure burden. It implies a read-only listing but says nothing about ordering, pagination, result count limits, or whether the HSK level is always present versus computed on demand.

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 sentence with no filler, and the resource and its distinguishing output field are front-loaded. 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 trivial no-parameter list tool the description is nearly sufficient, but with no output schema the agent still lacks any sense of what a 'reading' record contains or how large the listing is. The mention of the computed HSK level is the one piece of return-value context provided.

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 no parameter semantics to document; the baseline for a 0-param tool applies. The description correctly avoids inventing filtering options that the empty schema cannot honor.

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?

Specific verb ('List') plus resource ('graded Chinese readings') with the notable attribute that the result includes a computed HSK level. It is distinguishable from get_reading by the plural/list framing, though it never names that sibling to make the contrast explicit.

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 only implied: an agent can infer this is for enumerating all readings rather than fetching one, but the description offers no explicit when-to-use, no conditions, and no pointer to get_reading as the single-item alternative.

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 contribute one behavioral fact: results come back in syllabus order. However, it is silent on pagination behavior, default limit, and whether the list is exhaustive or capped at 100.

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 well-formed sentence with the resource and level semantics front-loaded and zero filler; every clause adds 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?

There is no output schema and no annotations, yet the description doesn't say what a returned word entry looks like or how limit/offset interact. The core purpose and ordering are covered, but an agent still has gaps for a 3-parameter list 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 schema only gives raw integer bounds with no meaning. The description rescues the most important parameter by defining the level range and the special 7 = HSK 7-9 semantic, but limit and offset (pagination, cap of 100) are left entirely unexplained.

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 (List) plus resource (dictionary words) and scopes it to a single HSK level, so it is distinguishable from lookup_word/list_readings. It also resolves a real ambiguity by explaining that level 7 means the HSK 7-9 band. It stops short of naming the sibling tools to route against.

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 only implied: an agent can infer this is for enumerating a whole level, but the description never states when to prefer it over lookup_word, list_readings, or check_text_level. No prerequisites or exclusions are given.

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

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

No annotations are provided, so the description carries the full burden. It discloses return contents (pinyin, meaning, HSK level, related words), which is useful since there is no output schema, but it says nothing about ambiguous/multi-match behavior, exact vs fuzzy matching, or permission/auth requirements of the dictionary service.

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 tight sentences: the first front-loads purpose and query scope, the second covers returns. No filler, and the ordering puts the most important information first.

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-only lookup with an output-schema-free response, the description covers both input forms and the shape of the result set. It is nearly complete; only edge-case behavior (multiple matches, no match) is unspecified, which is minor at this 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?

Schema description coverage is 100% and there is only one parameter, so the schema already documents the accepted query types. The description restates those same three forms (Chinese word, pinyin, English) without adding format guidance such as tone-mark handling or matching behavior, so baseline 3 applies.

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?

"Look up a Chinese word, pinyin or English word in the HSK Studio dictionary" gives a specific verb (look up), a concrete resource (word/dictionary), and enumerates the accepted query forms. This clearly distinguishes it from sibling browsing tools like list_words_by_level, though it never names them 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 only implied: an agent can infer this is the right tool for resolving a known query into a definition, versus siblings that list or check content. There is no explicit when-to-use, when-not-to-use, or alternative routing (e.g., list_words_by_level for browsing by level).

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