Server Quality Checklist

Tool Scores

• backup_sourceC
  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. It states the action ('backup via Git') but lacks critical details: whether this requires specific permissions, if it's idempotent, what happens on failure, or what the output looks like. For a mutation tool (implied by 'backup' as a write operation), 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 Chinese that clearly states the tool's purpose. It's front-loaded with the core action and includes specific implementation details without unnecessary elaboration. Every word earns its place, making it highly concise and well-structured.

  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 (a Git backup operation with potential side effects), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'backup' entails (e.g., commit, push), success/failure behavior, or return values. For a tool that modifies repository state, this leaves the agent with insufficient context to use it reliably.

  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 100% for the single parameter 'message', which is documented as 'optional Git commit message'. The description adds no parameter information beyond what the schema provides. With high schema coverage and only one parameter, the baseline score of 3 is appropriate—the description doesn't add value but doesn't need to compensate for gaps.

  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 ('backup') and resource ('blog source code') with specific implementation details ('via Git to hexo-source branch'). It distinguishes from siblings like 'deploy_blog' or 'git_status' by focusing on backup rather than deployment or status checking. However, it doesn't explicitly contrast with all siblings, missing some differentiation opportunities.

  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. The description doesn't mention prerequisites (e.g., Git repository setup), timing (e.g., after content changes), or when not to use it (e.g., versus 'deploy_blog' for publishing). This leaves the agent without context for tool selection among the 11 siblings.

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

• create_postC
  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. It states the tool creates a new blog post, implying a write/mutation operation, but doesn't mention permissions required, whether the post is published immediately, what happens on failure, or any rate limits. For a mutation 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 that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple creation tool and front-loads 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 (creating blog posts) with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation (e.g., returns post ID, publishes immediately), error conditions, or how it differs from similar tools like 'quick_publish'. Given the complexity and lack of structured data, more context 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 100%, so the schema already documents all three parameters (title, content, tags) with their descriptions. The description adds no additional parameter information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

  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 ('创建一篇新的博客文章' - create a new blog post) and identifies the resource (blog post). It distinguishes from siblings like 'update_post' or 'delete_post' by specifying creation. However, it doesn't explicitly differentiate from 'quick_publish' which might also create posts, making it a 4 rather than 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 like 'quick_publish' or 'update_post'. There's no mention of prerequisites, timing considerations, or differences from sibling tools. The agent must infer usage from the name alone.

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

• list_postsC
  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. It states it's a listing/filtering operation but doesn't describe return format, pagination behavior, permissions required, rate limits, or whether it's read-only versus destructive. The description is minimal and lacks important behavioral context.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that states the core functionality upfront. There's no wasted verbiage, though it could be slightly more structured by separating listing from filtering capabilities.

  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 listing tool with no annotations and no output schema, the description is insufficient. It doesn't explain what information is returned (post titles, IDs, dates, content snippets?), format, pagination, or error conditions. Given the complexity of blog post listing and the lack of structured metadata, more completeness 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 100%, so the schema already documents the single optional 'keyword' parameter. The description adds marginal value by specifying that filtering applies to '标题和标签' (title and tags), which provides slightly more context than the schema's '可选的过滤关键词' (optional filtering keyword). Baseline 3 is appropriate when schema does most of the work.

  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: '列出所有博客文章' (list all blog posts) with the specific capability '支持按关键词过滤标题和标签' (supports filtering by keyword in title and tags). It uses a specific verb ('列出' - list) and resource ('博客文章' - blog posts), but doesn't explicitly distinguish it from sibling tools like 'search_posts' or 'read_post'.

  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 'search_posts' or 'read_post'. It mentions filtering capability but doesn't clarify if this is for broad listing versus targeted searching, or any prerequisites for use.

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

• quick_publishC
  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 states the tool performs a combination of deploy and backup operations, implying mutation and data handling, but doesn't disclose critical traits like permissions needed, whether it's destructive, rate limits, or error handling. This is a significant gap for a tool with potential side effects.

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

  Conciseness4/5

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

  The description is concise and front-loaded in a single sentence: '一键完成博客发布和源码备份（deploy + backup 组合操作）'. It efficiently conveys the core purpose without unnecessary details. However, it could be slightly more structured by separating key points, but it earns its place as minimal waste.

  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 (a combination tool with potential mutations) and no annotations or output schema, the description is incomplete. It lacks details on behavioral traits, error handling, and what the tool returns. For a tool that likely involves significant operations, more context is needed to ensure safe and correct usage 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?

  The description adds no parameter semantics beyond what the input schema provides. Schema description coverage is 100%, with one optional parameter 'message' documented as '可选的 Git 提交信息' (optional Git commit message). The description doesn't mention parameters at all, so it relies entirely on the schema. Baseline 3 is appropriate when schema does the heavy lifting.

  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: '一键完成博客发布和源码备份' translates to 'one-click completion of blog publishing and source code backup.' It specifies the verb (complete) and resources (blog publishing, source code backup). However, it doesn't explicitly distinguish from siblings like 'deploy_blog' or 'backup_source,' which are mentioned as components but not compared.

  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 mentions 'deploy + backup 组合操作' (deploy + backup combination operation), implying it combines functions of 'deploy_blog' and 'backup_source,' but doesn't specify scenarios, prerequisites, or exclusions. Without explicit when/when-not instructions, usage is unclear.

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

• read_postC
  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. It states what content is returned but doesn't mention error conditions (e.g., what happens if filename doesn't exist), permissions required, rate limits, or response format. For a read operation 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.

  Conciseness4/5

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

  The description is a single, efficient sentence that communicates the core purpose. It's appropriately sized for a simple read operation, though it could potentially be more front-loaded with key behavioral information given the lack of annotations.

  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?

  For a single-parameter read tool with good schema coverage but no annotations and no output schema, the description is minimally adequate. It states what content is retrieved but doesn't address error handling, return format, or how this differs from similar tools. The description meets basic requirements but leaves the agent to infer important contextual details.

  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 100% with one parameter clearly documented. The description doesn't add any parameter semantics beyond what the schema provides - it mentions '指定文章' (specified article) which aligns with the filename parameter but adds no additional context about format, constraints, or examples. Baseline 3 is appropriate when schema does the heavy lifting.

  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 ('读取' - read) and resource ('指定文章的完整内容' - complete content of specified article), including what content is retrieved (Front-matter and body text). It doesn't explicitly differentiate from sibling tools like 'list_posts' or 'search_posts', but the focus on reading full content of a specific article is reasonably clear.

  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 about when to use this tool versus alternatives. The description doesn't mention prerequisites, when not to use it, or how it differs from sibling tools like 'preview_blog' or 'search_posts'. The agent must infer usage context from the tool name and description alone.

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

• search_postsC
  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 for behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information on search scope (e.g., partial/full matches), result format, pagination, sorting, error handling, or performance characteristics. For a search tool with zero annotation coverage, this leaves significant 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 extremely concise—a single sentence in Chinese that directly states the tool's function. It's front-loaded with the core action and resource, with no wasted words or redundant information. This is efficient and easy to parse.

  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 (search functionality with one parameter) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns, how results are structured, or any behavioral nuances. For a search tool, this leaves the agent guessing about output and usage details.

  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 description adds minimal value beyond the input schema. Schema description coverage is 100%, with the single parameter 'query' documented as '搜索关键词' (search keyword). The description implies the parameter is used for searching titles and bodies but doesn't provide additional syntax, format, or constraint details. Baseline 3 is appropriate when the schema does the heavy lifting.

  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: searching posts by keyword in both title and body content. It uses specific verbs ('搜索' - search) and resources ('文章标题和正文内容' - post titles and body content). However, it doesn't explicitly differentiate from sibling tools like 'list_posts' or 'read_post', which prevents a perfect score.

  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 when search is preferable to listing posts, when to use it versus 'read_post' for specific content, or any prerequisites or constraints. The agent must infer usage from context alone.

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

• update_postC
  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. It states this is a modification tool, implying mutation, but doesn't disclose behavioral traits like whether it overwrites or merges content, what permissions are required, if changes are reversible, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap.

  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 Chinese that directly states the tool's purpose. It's front-loaded with the core action and resource, with no wasted words or redundant information. 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 this is a mutation tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects (e.g., side effects, error handling), usage context, or return values. The agent lacks critical information to use this tool safely and effectively.

  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 100%, so the schema already documents all 4 parameters (filename, content, title, tags) with descriptions. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain format constraints, interactions between parameters, or default behaviors. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 ('修改' meaning modify/update) and the resource ('文章' meaning post/article), specifying it can modify content or metadata. It distinguishes from siblings like create_post (create) and delete_post (delete), but doesn't explicitly differentiate from other modification tools if they existed.

  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 existing post), when not to use it, or how it differs from similar tools like quick_publish or create_post. The agent must infer usage from the tool name alone.

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

• git_statusB
  3.1/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 states the tool views Git status for uncommitted changes, implying a read-only operation, but doesn't specify whether it requires Git installation, authentication, or network access, or describe the output format (e.g., text summary). This leaves gaps for a tool with no annotation coverage.

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

  Conciseness4/5

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

  The description is a single, efficient sentence in Chinese that directly states the purpose without unnecessary words. It's front-loaded with the core action ('view Git status') and includes clarifying scope ('blog project') and detail ('uncommitted changes'). However, it could be slightly more structured by separating scope from action for clarity.

  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 the tool's low complexity (0 parameters, no annotations, no output schema), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits (e.g., output format, dependencies) and usage guidelines. For a simple read tool, this is acceptable but leaves room for improvement in completeness.

  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, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids mentioning any. A baseline score of 4 is given since no parameters exist, and the description doesn't mislead about inputs.

  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: '查看博客项目当前的 Git 状态（未提交的更改）' translates to 'View the current Git status (uncommitted changes) of the blog project.' It specifies the verb ('view'), resource ('Git status'), and scope ('blog project'), but doesn't explicitly differentiate from sibling tools like 'deploy_blog' or 'backup_source' that might also involve Git operations.

  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 a Git repository), exclusions (e.g., not for committed changes), or related tools like 'deploy_blog' that might depend on Git status. Usage is implied only by the purpose, with no explicit context.

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

• preview_blogB
  3.4/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 starts a local preview server but doesn't disclose behavioral traits such as whether it runs in the background, requires specific permissions, has rate limits, or what happens if the server is already running. This leaves significant gaps for a tool that likely involves process management.

  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 Chinese that directly states the tool's purpose and key detail (localhost:4000). It's front-loaded with the main action and has zero wasted words, making it highly concise and well-structured.

  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 the tool likely starts a server process (implied complexity), no annotations, and no output schema, the description is minimal. It covers the basic purpose but lacks details on behavior, output, or error handling. For a tool with potential side effects (e.g., port binding), more context would be helpful, but it's adequate for a simple preview tool.

  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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. Baseline is 4 for 0 parameters, as it avoids unnecessary information.

  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 ('启动' meaning 'start' or 'launch') and the resource ('Hexo 本地预览服务器' meaning 'Hexo local preview server'), specifying it runs on localhost:4000. It distinguishes from siblings like 'deploy_blog' (production deployment) and 'stop_preview' (stopping the server), but doesn't explicitly differentiate from all siblings.

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

  Usage Guidelines3/5

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

  The description implies usage context by specifying it's a local preview server (localhost:4000), suggesting it's for testing before deployment. However, it doesn't explicitly state when to use this vs. alternatives like 'deploy_blog' for production or 'stop_preview' to terminate, nor does it mention prerequisites or exclusions.

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

• delete_postA
  3.7/5.0
  Behavior4/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 explicitly states the operation is irreversible ('不可撤销'), which is crucial behavioral information for a destructive operation. However, it doesn't mention permissions required, error conditions, or what happens to associated data.

  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 extremely concise - a single sentence that communicates both the action and a critical behavioral constraint. Every word earns its place with zero waste or redundancy.

  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?

  For a destructive tool with no annotations and no output schema, the description provides the essential warning about irreversibility but lacks information about permissions, error handling, or confirmation requirements. Given the high-risk nature of deletion operations, more context would be beneficial.

  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 100% with the single parameter 'filename' already documented in the schema. The description doesn't add any additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage.

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

  Purpose5/5

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

  The description clearly states the specific action ('删除' - delete) and resource ('博客文章' - blog post), distinguishing it from sibling tools like create_post, update_post, and read_post. It precisely communicates the tool's function without ambiguity.

  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 about when to use this tool versus alternatives like update_post or when deletion is appropriate. The description mentions the action is irreversible, but doesn't specify prerequisites, conditions, or alternatives for handling blog posts.

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

• deploy_blogA
  3.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 it mentions the three hexo commands that will be executed, it doesn't disclose important behavioral traits like whether this is a destructive operation (likely yes, as it deploys to GitHub Pages), what prerequisites are needed (hexo setup, git configuration), or potential side effects.

  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 front-loads the core purpose ('构建并发布博客到 GitHub Pages') and provides essential technical detail in parentheses. Every element earns its place with zero wasted words.

  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 deployment tool with no annotations and no output schema, the description provides adequate basic information about what the tool does but lacks important context about behavioral characteristics, prerequisites, and what happens after deployment. For a tool that likely modifies production content, more disclosure would be helpful.

  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 baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on the action being performed.

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

  Purpose5/5

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

  The description clearly states the specific action ('构建并发布博客' - build and publish blog) and the target resource ('到 GitHub Pages' - to GitHub Pages). It distinguishes from siblings like preview_blog, create_post, and quick_publish by specifying the full deployment pipeline with hexo commands.

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

  Usage Guidelines4/5

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

  The description implies usage context by mentioning the specific hexo commands (clean, generate, deploy), suggesting this is for final deployment rather than testing. However, it doesn't explicitly state when NOT to use it or name alternatives like preview_blog for testing or quick_publish for simpler publishing.

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

• stop_previewA
  4.1/5.0
  Behavior3/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 stops a running server, implying a destructive action, but doesn't detail effects (e.g., if it terminates processes, frees ports, or affects unsaved data). It adds basic context but lacks depth on behavior like error handling or prerequisites.

  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 Chinese that directly states the tool's function. It's front-loaded with the core action and resource, with zero wasted words or redundancy.

  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 no annotations, no output schema, and a simple 0-parameter tool, the description is minimally adequate. It covers the basic purpose but lacks details on what 'stopping' entails operationally, potential side effects, or confirmation of success. For a destructive tool, more behavioral context would improve completeness.

  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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't mention parameters, which is appropriate. Baseline is 4 for 0 params, as it avoids unnecessary detail.

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

  Purpose5/5

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

  The description clearly states the specific action ('停止' meaning 'stop') and the target resource ('Hexo 本地预览服务器' meaning 'Hexo local preview server'). It distinguishes from siblings like 'preview_blog' (which likely starts the server) and 'deploy_blog' (which publishes).

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

  Usage Guidelines4/5

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

  The description implies usage context—when a Hexo preview server is running—but doesn't explicitly state when NOT to use it or name alternatives. It's clear you'd use this after 'preview_blog', but lacks explicit exclusions or sibling comparisons.

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