Server Quality Checklist

Tool Scores

• insert_tableC
  2.8/5.0
  Behavior2/5

  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 states the action (adding a table) but doesn't cover critical traits: whether this is a mutation (likely yes, but not confirmed), permission requirements, effects on the document (e.g., overwriting content), error conditions, or response format. For a tool with 5 parameters and no annotations, this is a significant gap in transparency.

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

  Conciseness5/5

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

  The description is a single, clear sentence in Korean that directly states the tool's purpose without unnecessary words. It's front-loaded and efficiently conveys the core action, making it easy for an agent to parse quickly.

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

  Completeness2/5

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

  Given the complexity (5 parameters, no output schema, no annotations), the description is incomplete. It doesn't address parameter meanings, behavioral details like mutation effects or error handling, or output expectations. For a tool that modifies documents, more context is needed to guide effective use.

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

  Parameters2/5

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

  Schema description coverage is 0%, meaning none of the 5 parameters (rows, cols, height, width, section_index) are documented in the schema. The description adds no parameter information beyond implying a table is inserted—it doesn't explain what rows/cols represent, what section_index refers to, or how dimensions affect the table. This fails to compensate for the low schema coverage.

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

  Purpose4/5

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

  The description clearly states the action ('현재 문서에 표를 추가합니다' translates to 'Adds a table to the current document'), specifying the verb (add/insert) and resource (table). It distinguishes from siblings like insert_image and insert_paragraph by focusing on tables. However, it doesn't explicitly differentiate from create_document which might also involve table creation, keeping it at 4 rather than 5.

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

  Usage Guidelines2/5

  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. It doesn't mention prerequisites (e.g., needing an open document), exclusions, or comparisons to siblings like insert_paragraph or create_document. This lack of context leaves the agent with minimal usage direction.

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

• create_documentC
  2.9/5.0
  Behavior2/5

  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 mentions creating a document and optional title/author specification, but lacks critical details: it doesn't specify what happens if a file with the same name exists (though 'overwrite' parameter hints at this), doesn't describe permissions or authentication needs, doesn't mention rate limits or side effects, and provides no information on the return value or success/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.

  Conciseness5/5

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

  The description is a single, efficient sentence in Korean that directly states the tool's purpose and key optional parameters. It's front-loaded with the main action and wastes no words. Every part of the sentence contributes meaning without redundancy.

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

  Completeness2/5

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

  Given the complexity of a document creation tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain behavioral aspects like file handling, error conditions, or what the tool returns. For a mutation tool with significant parameter complexity, more context is needed to guide proper usage.

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

  Parameters3/5

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

  Schema description coverage is low at 25% (only 'name' has a description in the schema). The description adds some value by mentioning 'title' and 'author' as optional parameters, but it doesn't cover 'overwrite' or provide deeper semantics for any parameters beyond what's implied. It partially compensates for the low schema coverage but doesn't fully document all four parameters.

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

  Purpose4/5

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

  The description clearly states the verb ('create') and resource ('HWPX document'), and mentions optional title/author specification. It distinguishes from siblings like 'open_document' or 'save_as' by focusing on creation rather than opening or saving existing documents. However, it doesn't explicitly differentiate from all siblings (e.g., 'insert_paragraph' is about modifying rather than creating).

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

  Usage Guidelines2/5

  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. It doesn't mention prerequisites, when-not-to-use scenarios, or direct comparisons with sibling tools like 'open_document' for existing documents or 'set_workspace' for workspace context. Usage is implied through the action but not explicitly stated.

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

• insert_imageC
  2.9/5.0
  Behavior2/5

  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 mentions that images are 'included in a package,' which adds some context about side effects, but fails to detail permissions needed, whether the operation is destructive, rate limits, or what the response looks like. This is a significant gap for a mutation tool.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that is front-loaded with the core action. There is no wasted language, making it appropriately concise and well-structured for its purpose.

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

  Completeness2/5

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

  Given the tool's complexity as a mutation operation with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, parameter usage, and expected outcomes, making it inadequate for safe and effective use by an AI agent.

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

  Parameters3/5

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

  Schema description coverage is low at 25%, with only 'path' having a description. The tool description does not add meaning beyond the schema, as it doesn't explain parameters like 'alt_text', 'height', or 'width'. However, with 4 parameters and minimal schema coverage, the description doesn't compensate adequately, warranting a baseline score.

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

  Purpose4/5

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

  The description clearly states the action ('inserts local images into documents') and the resource ('documents'), specifying that images are local and will be included in a package. However, it doesn't explicitly differentiate from sibling tools like 'insert_paragraph' or 'insert_table' beyond mentioning images specifically.

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

  Usage Guidelines2/5

  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 like 'insert_paragraph' or 'insert_table', nor are there any prerequisites or exclusions mentioned. The description implies usage for inserting images but lacks contextual direction.

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

• insert_paragraphC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. While 'insert' implies a write operation, it doesn't disclose permissions needed, whether changes are saved automatically, what happens if no document is open, or error conditions. The description adds minimal behavioral context beyond the basic action.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Korean that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded with the essential information.

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

  Completeness2/5

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

  For a mutation tool with 3 parameters, no annotations, no output schema, and low schema coverage, the description is inadequate. It doesn't explain what the tool returns, how errors are handled, or provide sufficient context about the parameters and their effects on document structure.

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

  Parameters3/5

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

  Schema description coverage is only 33% (only the 'text' parameter has a description). The tool description adds no parameter information beyond what's in the schema. With low schema coverage, the description fails to compensate by explaining what 'char_pr_id' or 'section_index' mean or how they affect paragraph insertion.

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

  Purpose4/5

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

  The description clearly states the action ('insert paragraph') and target ('currently open document'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'insert_image' or 'insert_table' that also insert content into documents, missing sibling differentiation.

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

  Usage Guidelines2/5

  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 'insert_image' or 'insert_table'. It mentions 'currently open document' which implies a prerequisite (a document must be open), but offers no explicit when/when-not instructions or named alternatives.

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

• open_documentC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It states the tool opens a document and loads basic metadata, but doesn't clarify if this is a read-only operation, what happens if the document doesn't exist, whether it locks the file, or what '기본 메타데이터' includes. This leaves significant gaps for a tool that likely interacts with file systems.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Korean that directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what '기본 메타데이터' entails or what the tool returns, which is critical for understanding its behavior. For a tool with potential file system interactions, more context on errors, permissions, or state changes is needed.

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

  Parameters3/5

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

  The schema description coverage is 100%, with the single parameter 'path' documented as '워크스페이스 기준 문서 경로'. The description doesn't add any additional meaning beyond this, such as examples or constraints, so it meets the baseline of 3 where the schema handles the parameter documentation adequately.

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

  Purpose4/5

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

  The description clearly states the action ('열고', '로드합니다') and resource ('HWPX 문서', '기본 메타데이터'), making the purpose understandable. It doesn't explicitly differentiate from siblings like 'get_metadata' or 'create_document', but the verb '열다' (open) suggests an initial access operation rather than creation or metadata retrieval alone.

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

  Usage Guidelines2/5

  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. For example, it doesn't specify if this should be used before editing operations like 'insert_paragraph' or as a prerequisite for 'get_metadata', nor does it mention any prerequisites like needing an existing document.

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

• save_asC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It states the tool saves a document but doesn't disclose behavioral traits like whether it requires specific permissions, what happens on failure (e.g., if path is invalid), if it closes the original document, or any rate limits. The description is minimal and lacks crucial operational context for a mutation tool.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Korean that directly states the tool's purpose. It's front-loaded with no unnecessary words, making it highly concise while conveying the core action. Every part of the sentence earns its place.

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

  Completeness2/5

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

  Given the tool's complexity (a mutation operation with 2 parameters), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't address behavioral aspects, error conditions, or provide sufficient context for safe and effective use. For a 'save as' operation, more detail is needed.

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

  Parameters3/5

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

  Schema description coverage is 50% (only 'path' has a description). The description adds no parameter-specific information beyond what's implied by the tool's purpose. It doesn't explain 'overwrite' behavior or provide context for 'path' format. With low schema coverage, the description fails to compensate, resulting in inadequate parameter documentation.

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

  Purpose4/5

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

  The description clearly states the action ('저장합니다' - saves) and resource ('현재 문서' - current document) with specific scope ('다른 이름으로' - with another name). It distinguishes from siblings like 'create_document' by focusing on saving an existing document rather than creating a new one. However, it doesn't explicitly differentiate from all siblings like 'open_document' or 'set_workspace'.

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

  Usage Guidelines2/5

  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. It doesn't mention prerequisites (e.g., must have an open document), exclusions, or comparisons with sibling tools like 'create_document' for new documents or 'open_document' for loading existing ones. Usage context is implied but not explicit.

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

• set_workspaceC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'sets' a directory, implying a mutation, but doesn't describe what happens if the directory doesn't exist, whether changes are persistent, what permissions are required, or any side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Korean that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly.

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

  Completeness2/5

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

  Given the tool's complexity (a mutation operation with 2 parameters, no annotations, no output schema, and 50% schema coverage), the description is incomplete. It lacks details on behavioral traits, parameter usage, and output expectations, making it inadequate for an AI agent to use the tool effectively without additional context.

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

  Parameters3/5

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

  Schema description coverage is 50% (only the 'path' parameter has a description in the schema). The tool description doesn't mention any parameters, so it adds no semantic value beyond what's in the schema. With partial schema coverage, the baseline is 3, as the description doesn't compensate for the undocumented 'create' parameter.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: '문서를 읽고 쓸 기본 디렉터리를 설정합니다' (Sets the default directory for reading and writing documents). It specifies the verb '설정합니다' (sets) and the resource '기본 디렉터리' (default directory). However, it doesn't explicitly distinguish this from sibling tools like 'open_document' or 'save_as', which might also involve directory operations, so it doesn't reach a 5.

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

  Usage Guidelines2/5

  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. There's no mention of prerequisites (e.g., whether the directory must exist), exclusions, or comparisons to sibling tools like 'open_document' or 'save_as'. It only states what the tool does, not when it should be applied.

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

• get_metadataB
  3.2/5.0
  Behavior2/5

  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 states this is a read operation ('조회합니다'), which is helpful, but doesn't mention what metadata is returned, format of return data, whether it requires specific permissions, or any error conditions. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Korean that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information without unnecessary elaboration.

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

  Completeness3/5

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

  Given this is a simple read operation with 0 parameters and no output schema, the description provides the basic purpose but lacks important context. Without annotations or output schema, the description should ideally specify what metadata is returned or at least indicate the scope of metadata. The description is minimally adequate but leaves the agent guessing about the return format.

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

  Parameters4/5

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

  The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist, which is correct for this case. Baseline for 0 parameters with full schema coverage is 4.

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

  Purpose4/5

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

  The description clearly states the action ('조회합니다' - retrieves/reads) and resource ('현재 열린 문서의 메타데이터' - metadata of currently open document), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'open_document' or 'set_workspace' which might also interact with documents.

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

  Usage Guidelines2/5

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

  The description provides minimal guidance by specifying '현재 열린 문서' (currently open document), implying it should be used when a document is already open. However, it offers no explicit when-to-use guidance compared to alternatives, no prerequisites mentioned, and no discussion of when not to use this tool versus other document-related tools.

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