Server Quality Checklist

Tool Scores

• list_applicationsB
  3.4/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 the full burden. It discloses key behavioral traits: it's a read-only operation (implied by '查看' - view), returns specific data fields (candidate info, match scores, badges, status, cover letters), includes match score interpretation guidelines, and notes pagination support (via page/page_size parameters). However, it lacks details on authentication needs, rate limits, error handling, or data freshness.

  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 well-structured and appropriately sized. It front-loads the core purpose, then lists return information, explains match scores, and adds a note about limitations. Most sentences earn their place by providing useful context, though the match score breakdown could be slightly condensed.

  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 and no output schema, the description does a fair job covering the tool's behavior, return data, and limitations. It explains what data is returned and how to interpret match scores, which compensates for the lack of output schema. However, for a tool with 5 parameters and no annotations, it could benefit from more details on error cases, authentication, or performance characteristics.

  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 parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain 'job_token' or 'status' enums further). However, it implicitly references pagination via 'page' and 'page_size' by listing them as returned data, which slightly reinforces their purpose. Baseline 3 is appropriate given high 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 tool's purpose: '查看收到的职位申请' (view received job applications). It specifies the verb (view) and resource (job applications), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'view_candidate' or 'search_candidates', which might also involve viewing candidate-related data.

  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 stating it's for viewing applications and noting that processing applications (approve/reject) will be in v2, suggesting this is for read-only inspection. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'search_candidates' or 'view_candidate', nor does it mention prerequisites (e.g., needing a session_id from 'register_company').

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

• post_jobB
  3.4/5.0
  Behavior3/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 reveals several important behavioral traits: the job appears in multiple channels, has a 30-day default validity period, and that work experience is converted to days internally. However, it doesn't disclose critical mutation implications like whether this is idempotent, what permissions are needed, or what happens on failure. The description doesn't contradict any annotations since none exist.

  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 appropriately sized and well-structured with clear sections: a purpose statement, three bullet points showing where jobs appear, and a '提示' section with three operational tips. Each sentence serves a purpose, though the third bullet about WonderCV channels could be more specific. The information is front-loaded with the core purpose stated first.

  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 mutation tool with 13 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It covers the basic purpose and some behavioral aspects (where jobs appear, default validity, internal format conversions), but doesn't address error conditions, response format, authentication requirements, or detailed parameter interactions. Given the complexity, it should provide more complete operational 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?

  With 100% schema description coverage, the baseline is 3. The description adds minimal parameter semantics beyond the schema - it only mentions the 'require_ai_fluency' parameter in the tips section to explain its effect ('优先展示给 AI-Agent 熟练的候选人'). It doesn't provide additional context for other parameters like salary ranges, experience conversions, or the session_id requirement from 'register_company'.

  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 ('发布职位' - post job) and target ('ClawHire 招聘市场'), providing a specific verb+resource combination. It distinguishes this from sibling tools like 'list_jobs' or 'search_candidates' by being a creation/write operation rather than a read operation. However, it doesn't explicitly contrast with 'register_company' which is another write operation.

  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 provides some implied usage context by listing where the job will appear (ClawHire search, candidate recommendations, WonderCV channels), suggesting this is for broad job posting. However, it doesn't explicitly state when to use this tool versus alternatives like 'request_outreach' or provide clear exclusions. The '提示' section offers operational tips but not comparative guidance.

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

• list_jobsA
  3.6/5.0
  Behavior3/5

  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 returns job information, application counts, and statuses, which is helpful. However, it lacks details on permissions needed, rate limits, pagination behavior beyond schema hints, or whether this is a read-only operation (implied but not stated). The description adds some behavioral context but leaves gaps for a tool with 4 parameters.

  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 well-structured with clear sections: purpose, return information, and usage scenarios. It's appropriately sized (3 bullet points each for returns and usage) and front-loaded with the core purpose. Minor room for improvement in tightening phrasing, but overall efficient.

  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 and no output schema, the description provides good context on what the tool does and when to use it. However, for a tool with 4 parameters and pagination behavior, it lacks details on error handling, response format beyond high-level fields, or authentication requirements (session_id is documented in schema but not explained in description). It's adequate but has clear gaps.

  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 fully documents all 4 parameters. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain 'status' values or 'page' defaults in more detail). Baseline 3 is appropriate when the schema does the heavy lifting, but no extra value is added.

  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: '查看已发布的职位列表及申请统计' (view published job listings and application statistics). It specifies the verb (view/list) and resource (jobs/positions) with scope (published). However, it doesn't explicitly differentiate from sibling tools like 'list_applications' or 'search_candidates', 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 Guidelines4/5

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

  The description provides clear usage contexts in the '可用于' (can be used for) section: understanding recruitment progress, deciding to refresh/close positions, and jumping to candidate search. It gives practical scenarios but doesn't explicitly state when NOT to use this tool or name alternatives like 'search_candidates' for filtering candidates directly.

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

• view_candidateA
  3.9/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well at disclosing important behavioral traits: visibility rules (anonymous vs. complete modes), quota consumption ('每次查看消耗 quota'), and error behavior (404 for company blocklist without information leakage). It doesn't mention authentication requirements, rate limits, or response format details.

  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 well-structured with clear sections (visibility rules, notes) and front-loads the core purpose. Most sentences earn their place by providing important constraints and behavioral information. It could be slightly more concise in the visibility rules section.

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

  Completeness4/5

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

  Given no annotations and no output schema, the description does a good job covering important contextual information: visibility modes, source restrictions, quota consumption, and error behavior. It doesn't describe the response format or what fields are included in the detailed profile, which would be helpful since there's no output schema.

  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 both parameters well. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. The baseline of 3 is appropriate when the schema does the heavy lifting for 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 tool's purpose: '查看特定候选人的详细档案' (view detailed profile of a specific candidate). It specifies the resource (candidate) and action (view detailed profile), but doesn't explicitly differentiate from sibling tools like 'search_candidates' which searches for candidates rather than viewing a specific one's details.

  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 provides clear context about when to use this tool: '仅适用于市场候选人（source=mcp 或 gui_optin）' (only for market candidates with source=mcp or gui_optin) and explicitly states when NOT to use it: '数据库候选人（source=database）无详细档案视图' (database candidates have no detailed profile view). It doesn't explicitly mention alternatives like 'search_candidates' for finding candidates first.

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

• search_candidatesA
  4.1/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 and does so effectively. It discloses key behavioral traits: daily outreach limits for database candidates, visibility settings for market candidates, and sorting behavior with job_token. It also explains contact restrictions and AI proficiency badges, adding valuable context beyond basic functionality.

  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 well-structured with clear sections (market candidates, database candidates, AI proficiency badges, suggestion) and uses bullet points for readability. It is appropriately sized for the tool's complexity, though some redundancy exists (e.g., repeating candidate categories could be streamlined). Every sentence adds value without unnecessary fluff.

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

  Completeness4/5

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

  Given the tool's complexity (14 parameters, no annotations, no output schema), the description is quite complete. It explains candidate types, behavioral constraints, and usage tips. However, it doesn't detail the output format or pagination behavior, which is a minor gap since there's no output schema to rely on, but the overall context is well-covered.

  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 14 parameters thoroughly. The description adds minimal parameter-specific semantics, only mentioning job_token for intelligent sorting. It doesn't provide additional syntax, format, or usage details beyond what the schema offers, meeting 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 tool searches candidate pools with specific categories (market candidates and database candidates), distinguishing it from sibling tools like list_applications or view_candidate. It provides a detailed breakdown of candidate types and their characteristics, making the purpose explicit and differentiated.

  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 includes a suggestion to use job_token for intelligent sorting based on job requirements, which provides clear guidance on optimal usage. However, it lacks explicit when-not-to-use guidance or alternatives among sibling tools like list_applications or view_candidate, though the context of candidate pools is well-defined.

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

• register_companyA
  4.2/5.0
  Behavior3/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 does well by explaining what happens upon success (you get session_id, company account, Alpha permissions) and the automatic account linking behavior. However, it doesn't mention potential errors (e.g., invalid inputs), rate limits, authentication requirements, or what the response format looks like (since there's no output schema).

  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 efficiently structured with three clear paragraphs: (1) the core purpose, (2) the benefits upon success, and (3) the edge-case behavior. Every sentence adds value without repetition or fluff. It's appropriately sized for a registration tool with multiple parameters and behavioral nuances.

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

  Completeness4/5

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

  Given the complexity (registration with 7 parameters, no annotations, no output schema), the description does well by covering the purpose, benefits, and edge-case behavior. However, it doesn't explain the response format or potential error conditions, which would be helpful since there's no output schema. For a foundational tool like this, it's mostly complete but could benefit from more behavioral 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%, so the schema already documents all 7 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain format constraints or provide examples for the optional parameters). The baseline of 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.

  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 ('注册成为 ClawHire 雇主，创建企业账号') and distinguishes this tool from its siblings by explaining it's '使用 ClawHire MCP 的第一步' (the first step to use ClawHire MCP). It explicitly mentions what this tool creates (company account) versus what sibling tools do (list jobs, post jobs, search candidates, etc.).

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use this tool ('使用 ClawHire MCP 的第一步') and what happens in alternative scenarios ('如果该邮箱/手机号已关联 WonderCV 的 HrAccount，将自动关联现有账号'). It clearly positions this as the initial setup/registration tool versus the operational tools (like list_jobs, post_job) that would come after registration.

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

• request_outreachA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full burden and excels at disclosing behavioral traits. It explains the multi-step workflow (how invitations are sent and processed), reveals important limitations (daily quotas, 90-day cooldown, unsubscribe option), and provides practical guidance about response rates. This goes well beyond basic functionality.

  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 efficiently structured with clear sections (工作原理, 限制, 提示) that make information easy to parse. Every sentence adds value - no wasted words. The information is front-loaded with the core purpose, followed by important details.

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

  Completeness5/5

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

  For a mutation tool with no annotations and no output schema, the description provides exceptional completeness. It covers the entire workflow, limitations, practical tips, and expected outcomes. The agent understands not just what the tool does but how it behaves in practice, which is crucial for a tool that initiates external communications.

  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 parameters are well-documented in the schema. The description doesn't add significant semantic context beyond what the schema provides about session_id, candidate_ref, job_token, and message parameters. The 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.

  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 ('发送职位邀请' - send job invitation) and target resource ('数据库候选人' - database candidates), distinguishing it from siblings like search_candidates or view_candidate. It explicitly identifies the candidate type as non-ClawHire WonderCV users, providing precise scope.

  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 provides clear context about when to use this tool (sending invitations to database candidates) and includes practical tips ('建议配合职位使用' - recommend using with specific jobs). However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings, though the context implies it's for outreach rather than viewing/searching.

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