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

No annotations are provided, so the description carries the burden. It clearly states the core effect — clearing the tablet canvas — but does not disclose whether the action is irreversible, whether unsaved content is lost, or whether saved sessions/snapshots are affected. That residual ambiguity keeps this below a 4.

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 short, front-loaded with the action, and includes concrete trigger examples. The unexplained '【递纸】' prefix adds a small amount of noise, but the operational content is still minimal and scannable.

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, no-output-schema tool, the description covers the essential 'what' and 'when'. It is missing side-effect context such as irreversibility or whether saved snapshots are preserved, but these are not strictly required to invoke the tool 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 tool has zero parameters and the input schema is empty, so there are no parameter semantics to add. The baseline for 0-parameter tools is 4, and the description does not need to compensate for any schema gaps.

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 object: 'Clear the tablet canvas', which is unambiguous and immediately distinguishable from the sibling tools (get_handwriting, save_snapshot, export_session, etc.). The included trigger phrases reinforce the exact intent.

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

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

The description explicitly states when to call the tool: when the user says '清空画布', 'clear', or '重新开始'. It does not name alternatives or exclusions, but for a zero-parameter clear action the trigger-based guidance is clear and 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It explains what each format represents (human-readable text, raw logs, stroke replay, Excalidraw compatibility) and the blank-session default. It could mention side effects or the return envelope, but the core behavior is well disclosed.

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 dense sentence with no fluff. It front-loads the action and resource, then packs the format options and default behavior into a compact, easily scannable 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?

For a tool with two optional parameters and no output schema, the description covers the core decisions: which format to choose and which session to export. It does not describe the exact return shape, but that is not required to invoke the tool correctly, and the format semantics provide sufficient operational 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 coverage is 100%, so the baseline is 3. The description adds value by explaining the semantic meaning of each format enum value and confirming the session_id default behavior, which goes slightly beyond the schema descriptions.

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 ('导出') with a clear resource ('手写会话') and enumerates the exact output formats and their purposes. This makes it easy to distinguish from sibling tools like get_handwriting or save_snapshot.

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 clear context for when to use the tool: exporting a handwriting session into one of four formats, with explicit behavior for blank session_id. It does not explicitly name alternatives or state when not to use it, 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?

With no annotations, the description carries the behavioral burden. It discloses that pairing is persistent and the URL can be bookmarked, which helps set expectations. However, it doesn't describe the exact output format or whether the QR code/URL expire, so there is still a moderate gap.

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 compact and front-loaded with the core purpose. The long trigger-phrase list is useful but somewhat repetitive; however, it is directly actionable for an agent.

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 tool with no output schema, the description provides a solid context: when to call it and what to expect in terms of persistent pairing. It stops short of detailing the response fields or security considerations, but the overall guidance is sufficient for straightforward 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?

The tool has zero parameters, so the description naturally cannot add parameter detail. The baseline for zero-parameter tools is 4, and the description adequately explains what to do with the connection info, which is sufficient.

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 function: getting the PassPaper tablet connection URL and QR code image. It uses specific verbs and resources, and the trigger phrase list distinguishes it from sibling tools that deal with handwriting or session 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?

It explicitly says to call this FIRST when the user mentions specific phrases and provides a list of trigger examples. It also conveys that it is the initial connection step, not a handwriting or session operation, which helps an agent choose it 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?

With no annotations, the description carries the behavioral burden. It states this is a read operation, returns a PNG, and has a precondition (user has already written something). It does not describe failure behavior if called prematurely, but the explicit 'only call after' warning makes the main risk visible.

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 front-loaded with the core purpose, then gives return type, precondition, triggers, and an exclusion in compact form. Every sentence adds useful selection or invocation guidance without unnecessary filler.

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

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

For a zero-parameter tool with no output schema, the description adequately covers what the tool does, what it returns, and when it should be called. It could be slightly more complete by contrasting with recognize_handwriting, but the essential invocation context is present.

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 has zero parameters and the schema has no properties, so there is nothing for the description to clarify. The baseline for zero-parameter tools is 4, and the description appropriately says nothing misleading about inputs.

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

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

The description clearly states the action ('Read the user's CURRENT handwriting from the tablet') and the return type (PNG image). It is specific about the resource and timing, but it does not explicitly distinguish this from the sibling recognize_handwriting, so full differentiation is left to inference.

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 explicit when-to-use conditions ('Only call this AFTER the user has written something and asks you to look'), concrete trigger phrases, and a clear when-not-to-use instruction with the alternative named ('Do NOT call this for initial setup — use get_connection_info first'). This is strong guidance.

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. It discloses non-rendering behavior, lightweight operation, and the specific status fields checked. It doesn't discuss side effects or return format, but 'Check' implies a read-only operation.

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

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

The description is two sentences with the purpose and key constraints front-loaded before usage triggers. Every fragment ('Lightweight', 'Does NOT render an image') adds decision-relevant information without redundancy.

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

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

For a zero-parameter read-only status tool, the description covers what it returns (status fields), what it avoids (rendering), and when to invoke it. No output schema exists, but listing the status fields is sufficient guidance for correct usage.

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 zero parameters, so the schema is vacuously 100% covered. No parameter-specific description is needed, and the baseline for zero-parameter tools is 4.

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 ('Check') and resource ('tablet status') and enumerates the exact status fields: stroke count, revision, connected tablets, new-content flag. It also explicitly distinguishes itself from image-rendering tools with 'Does NOT render an image.'

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 explicit trigger phrases '有更新吗' and '有没有新内容' for when to call. The negative behavior 'Does NOT render an image' and 'Lightweight' help an agent choose it over image-producing alternatives, though no sibling tool is named directly.

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 disclosure burden. It does add useful context: sessions are local, reverse-chronologically ordered, and are text records that can be Git-committed, replayed, and exported. However, it does not mention side effects (or their absence), permissions, or output behavior, leaving part of the behavioral profile undisclosed.

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

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

The description is concise and front-loads the core action and resource. The second sentence adds useful context about what sessions are. The unexplained '【递纸】' prefix is a minor distraction, but the overall structure is efficient.

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 is simple with no parameters, so the description is mostly sufficient for invocation. However, there is no output schema, and the description does not clarify what fields or structure the returned session list will have. It hints at the nature of sessions but not the actual response format, leaving a minor gap.

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

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

The tool has zero parameters, and the schema already covers this fully. The description does not need to explain parameter semantics. The baseline of 4 is appropriate because there is nothing missing for an agent to invoke the tool correctly.

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: '列出本地保存的手写会话' (list locally saved handwriting sessions), with an additional ordering detail (reverse chronological). This clearly distinguishes the tool from siblings like start_session, export_session, and get_handwriting, which concern creation, export, and individual retrieval rather than 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 context is implied: use this tool when you need to see locally saved handwriting sessions. However, the description does not provide explicit guidance about when not to use it or how it compares to related tools such as export_session or get_handwriting. There are no exclusions or alternative routing.

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 that behavior depends on local VLM/OCR configuration, that it may fall back to Agent image inspection, and that results are recorded in the current session for traceability. It does not cover all edge-case behaviors but provides meaningful transparency beyond the bare tool name.

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 compact and front-loaded with the core purpose, then covers fallback and side effects in one dense sentence. However, the leading '【递纸】' is unexplained jargon that could confuse an AI agent, and the single-sentence structure packs several ideas together.

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 tool with no output schema, the description is reasonably complete: it states what the tool produces, when it falls back, and that it persists the result to the session. It could be improved by clarifying prerequisites like whether a handwriting canvas must already exist and what the structured result format looks like, but those are not critical 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?

The tool has zero parameters and the schema description coverage is 100%, so there are no parameter semantics to document. The baseline of 4 applies, and the description appropriately does not try to invent parameter information.

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 identifies the action ('做结构化识别' on the handwriting canvas) and specifies the expected outputs (Chinese text and LaTeX) with a fallback to letting the Agent view the image. This distinguishes it from siblings like get_handwriting, which presumably retrieves the raw canvas, and get_handwriting_status, which checks status.

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 the conditional behavior: use configured local VLM/OCR for structured output, otherwise fall back to Agent direct image viewing. It implies when this tool is appropriate but does not explicitly mention exclusions or directly name sibling alternatives, leaving some inference to the user.

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. It discloses that the tool writes a PNG file to disk and returns a path, but it does not mention overwrite behavior, where the file is stored, or whether an active session is required.

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, with the core operation front-loaded and the usage scenario following immediately. Every part adds useful information, with 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 zero-parameter tool with no output schema, the description covers the main operation, the return value, and the practical use case. Minor gaps around file location and system prerequisites are acceptable at this level of simplicity.

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 parameters, so there is no schema gap to compensate for; this earns the baseline 4. The description adds only relevant context by referring to 'current handwriting'.

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: saving the current handwriting as a PNG file on disk and returning its path. This is specific, uses a clear verb, and is easily distinguished from sibling tools like get_handwriting or get_connection_info.

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 states when to use this tool: when images cannot be received through MCP directly, telling the agent to read the file instead. It does not name a specific sibling alternative, but the fallback scenario 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?

No annotations are present, so the description carries the full burden. It does disclose an important behavioral fact: previous sessions are retained and can be exported. However, it does not say what happens to the current active canvas or whether a new session identifier is returned.

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 no filler. The core action is front-loaded, and the parenthetical adds the most relevant behavioral detail without unnecessary length.

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 tool with no output schema, the description provides the key context an agent needs: starting a new session and reassurance that previous work is preserved. It leaves minor ambiguity about the current canvas state, but this is a low-complexity 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?

The tool has zero parameters and schema coverage is 100%, so the description is not required to explain inputs. The baseline of 4 applies because the empty schema fully documents the invocation 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 states a specific action and resource: 'start a new handwriting session.' The parenthetical that previous sessions are preserved and exportable makes its behavior distinct from siblings like clear_canvas and export_session, so an agent can identify the right 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?

There is no explicit guidance on when to use this tool versus alternatives. The preservation remark hints at a non-destructive use case, but it does not name when to prefer start_session over clear_canvas, save_snapshot, or list_sessions.

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