Server Quality Checklist

Tool Scores

• lark_cli_runA
  4.2/5.0
  Behavior4/5

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

  Annotations already convey destructiveHint=true and readOnlyHint=false; the description adds that side-effect commands require confirm=true, reinforcing safety expectations. It also mentions argv-style execution, implying arbitrary command behavior, which is useful context beyond the structured annotations.

  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?

  Two sentences front-load the core action and then provide the most critical safety guidance. Every word earns its place with no redundancy.

  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?

  For a generic command runner with an output schema and safety annotations, the description gives essential first-step guidance (schema/help), risk classification, and the confirm gate. It could mention timeout/output limits, but those are already represented in the input schema, so the description is sufficiently complete.

  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 60% and includes useful descriptions for args, intent, and confirm. The description restates the confirm requirement already present in the schema and does not add new parameter-level meaning beyond what the enum and field descriptions already provide.

  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?

  Description states 'Run the official lark-cli with argv-style arguments' with a specific verb and resource, making the action unmistakable. It is clearly distinct from sibling tools like schema/help/auth_status by positioning itself as the actual command executor.

  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?

  Explicitly instructs 'Use schema/help first,' which directs the agent to consult sibling tools before running arbitrary commands. It also clarifies that write/auth_config commands require confirm=true, providing meaningful context for side-effect handling, though it doesn't enumerate specific 'when not to use' cases.

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

• lark_cli_helpA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare the tool as read-only, idempotent, and non-destructive, so the bar is lower. The description adds a non-obvious behavioral trait: shortcuts are discovered via help, which is useful context for the agent. No contradictions with annotations. Output schema covers return values, so no need to describe them.

  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 only two sentences long, front-loaded with the main purpose ('Read help...') and then a concise usage hint. Every sentence earns its place with no wasted words.

  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 simple help-retrieval tool with one well-documented parameter and an output schema, the description covers the essential purpose and usage context. The output schema handles return values, so no further explanation is needed. The description is complete for the tool's complexity.

  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 covers 100% of the parameter semantics, including examples like ['calendar'] or ['im','+messages-send']. The tool description itself does not mention the 'args' parameter, so it adds no extra semantic value beyond the schema. Baseline 3 is appropriate.

  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 explicitly states 'Read help for a service or command,' which is a specific verb+resource action. It distinguishes this tool from siblings (lark_cli_run, lark_cli_schema, lark_cli_auth_status) by focusing on help retrieval. The added note about using before shortcuts clarifies its role in the toolchain.

  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 a clear when-to-use guideline: 'Use before shortcuts because shortcuts are discovered via help.' This tells the agent when to invoke the tool. However, it does not explicitly mention alternatives or when not to use it, but the sibling tool names imply the other use cases.

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

• lark_cli_schemaA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by enumerating the schema aspects inspected, which goes beyond the annotation data. No contradictions are present.

  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 two sentences, front-loaded with the core purpose, and every clause adds value. There is no filler or redundant information.

  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?

  With a full output schema available and clear annotations, the description covers the tool's role completely. It mentions the inspection scope and the importance of calling it before commands, which suffices for this simple one-parameter tool.

  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% because the sole 'method' parameter is documented with an example and the omit-to-list behavior. The description adds no further parameter-specific meaning, so the baseline 3 applies.

  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 uses the specific verb 'Inspect' and names the resource (lark-cli API schema) plus the aspects it covers (parameters, request body, response shape, supported identities, scopes). This clearly distinguishes it from sibling tools like lark_cli_run and lark_cli_auth_status.

  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?

  It explicitly instructs to 'Call this before API commands or risky writes,' providing clear timing and context. It doesn't mention exclusions or alternative tools by name, but the sibling names and the 'before' guidance make the use case clear.

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

• lark_cli_auth_statusA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, establishing the safe, non-mutating nature. The description adds specific context by naming what is checked (granted scopes, active identity), which is valuable beyond the annotations. No contradiction detected.

  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, front-loaded sentence that conveys the essential purpose and usage context without redundancy. Every word earns its place, and it is appropriately sized for a simple tool.

  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?

  Given the tool's simplicity (no parameters), the presence of an output schema, and comprehensive annotations, the description is complete. It covers what the tool does and when to use it, while structured data handles return format and safety details.

  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 zero parameters, so the schema coverage is trivially 100% and there is no parameter ambiguity. Per guidelines, the baseline for 0 params is 4, and the description need not compensate for missing parameter info. It correctly implies no inputs are required.

  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's function with a specific verb ('Check') and resources ('Feishu/Lark login status, granted scopes, and active identity'). It is distinct from sibling tools (run, schema, help), which focus on execution, metadata, and CLI assistance respectively.

  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 phrase 'before calls' provides explicit usage context, indicating when to invoke this tool (prior to other operations). However, it does not explicitly mention alternatives or conditions when not to use it, so it falls short of a 5.

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