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

With zero annotations, the description carries the full behavioral burden and meaningfully addresses the main safety concern of an auth-related tool: '不返回或显示任何 Cookie' (does not return or display any Cookie). This reassures the agent the call is safe and won't leak credentials. The only gap is that it doesn't describe what the successful response contains.

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 front-loads the purpose and appends the safety qualifier. There is no redundancy, no restatement of the tool name, and 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?

For a zero-parameter status check, the description covers purpose, platform scope, and the key safety behavior. The only real gap is the return format — there is no output schema, so an agent doesn't know whether the result is a boolean, enum, or object. Given the tool's simplicity, this is a minor omission rather than a critical one.

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

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

The schema has zero properties, so there are no parameters to document; per the 0-parameter baseline, a 4 applies. The description's no-Cookie clause is behavioral information, not parameter semantics, and the schema already fully covers the (empty) argument surface.

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 (检查/check) and resource (登录状态/login status), and further narrows scope to LeetCode 中国站 (China site). This clearly distinguishes it from siblings like login and logout, which mutate auth state, and get_problem/get_submissions_by_date, which retrieve other 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?

The role of the tool — verifying whether a session exists — is implied by the description and the sibling set (login/logout), but there is no explicit guidance on when to call it versus alternatives ('use login if no session', 'call before authenticated requests'). An agent can infer the usage, but nothing is stated outright.

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: no login required, multiple query identifier types accepted, and language selects a code template. It does not disclose what happens with include_hints, output shape, or failure behavior, leaving notable transparency gaps.

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 compact sentences with no filler. The primary behavior and query formats are front-loaded, and the login note is a single efficient clause. Every sentence adds value.

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

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

The tool has 3 parameters, no output schema, and no annotations. The description covers query and language semantics, but include_hints is left undefined and the return value is not characterized. For a simple read tool this is adequate but not fully complete.

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

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

Since schema description coverage is 0%, the description must compensate. It gives meaningful meaning for query (possible identifier formats) and language (python3, cpp, java, typescript code templates), but it does not explain the include_hints parameter at all, and the language list is only illustrative.

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 a specific verb and resource: retrieving problem information by Chinese site problem number, title, titleSlug, or URL. It does not explicitly differentiate itself from sibling tools, but the resource scope (problems vs. auth/submissions) is 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?

The description implies when to use the tool (whenever problem info is needed) and provides the helpful note that login is not required. However, it does not mention when not to use it, nor does it compare against the sibling tools such as get_submissions_by_date.

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 disclosure burden and does reveal non-obvious behavior: the Asia/Shanghai timezone default, YYYY-MM-DD date format, inclusion of both AC and failed submissions, and the 'current user' scope. However, it omits auth requirements, pagination behavior, and what happens with invalid or missing login.

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 dense sentence conveys the core action, scope, default date, timezone, format, and inclusion set with no filler. All content 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 basic use (just a date), the description plus schema defaults are sufficient. But with no output schema and 0% parameter coverage, the description under-specifies pagination, filter values, and authentication-state behavior, so it is not fully complete for advanced 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 description coverage is 0%, so the description should compensate. It adds meaning for date (default, timezone, format) and timezone, but says nothing about limit, cursor, status, or language, leaving most parameters semantically underspecified.

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'), identifies the resource (current logged-in user's LeetCode China submissions), and scopes it to a calendar date. This clearly distinguishes it from siblings like auth_status, get_problem, login, and logout.

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 clear context: the tool targets the current logged-in user and defaults to Asia/Shanghai today. It does not explicitly name alternatives or when-not-to-use conditions, but there are no directly competing siblings, so the context is sufficient.

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 behavioral disclosure burden. It usefully reveals that the Cookie is persisted to the keychain and deliberately kept out of the model context, which is a significant security-relevant behavior. However, it does not explain what happens if the user is already logged in or whether the operation is destructive.

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

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

The description is a single concise sentence that front-loads the action and purpose, then adds a key privacy detail. No word is wasted and all content is relevant.

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 login tool, the description covers the main purpose and an important security behavior. Yet it misses the meaning of the only parameter, force, and gives no guidance on when a forced re-login might be needed or how to verify auth state.

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 by explaining the force parameter, but it never mentions force at all. The parameter is entirely unexplained, leaving the agent unable to infer the effect or meaning of force.

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 a specific action (login to LeetCode China) and its key outcome (saving the Cookie to the system keychain). It is easily distinguished from siblings like auth_status, logout, and data-retrieval tools.

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

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

The description does not say when to use login versus auth_status or logout, nor does it mention prerequisites. It implies authentication is needed but gives no explicit usage context or alternatives.

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

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

With no annotations provided, the description carries the full burden of disclosing side effects. It clearly states that the tool deletes credentials from the system keychain, which is the core behavioral trait. It does not mention whether remote sessions are invalidated, but for a credential-removal operation this is reasonably transparent.

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 with no filler or redundant information. It front-loads the action and resource without unnecessary context or repeated tool name.

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 parameterless tool with no output schema, the description sufficiently explains what the tool does and where it operates. It could add a note about the result or idempotency, but the core behavioral contract is complete enough for an agent to select and invoke 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?

The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics; it appropriately focuses on what operation the tool performs. There is no gap here.

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 ('删除' / delete) and states the exact resource affected: LeetCode China credentials stored in the system keychain. This clearly distinguishes logout from siblings like login and auth_status, as it is the only one that removes stored credentials.

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 intended usage is implied by the tool name and description: it should be called when the user wants to clear the saved LeetCode China credentials. However, there is no explicit guidance about when to use this instead of auth_status or login, nor any 'when not to use' conditions.

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