Server Quality Checklist

Tool Scores

• release_lockA
  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 adds context that 'The intent is committed to session history' and implies the lock is released, but it does not disclose potential failure modes, ownership checks, or side effects beyond the intent being logged.

  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 three sentences with no fluff: purpose, usage guidance, and a behavioral note. Each sentence earns its place and the structure front-loads the core purpose.

  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 simple lock-release tool, the description covers the core function, when to call it, and a behavioral side effect. It does not cover error cases or the optional agent_name parameter, but these are reasonably handled by the schema and the tool's simplicity.

  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 coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema for parameters; it does not mention agent_name or provide additional detail about filepath that is not already in the schema.

  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 action ('Release') and the resource ('a previously acquired lock on a file'). It distinguishes from siblings by focusing on a single file lock, which contrasts with force_release_all and acquire_lock.

  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 explicit timing: 'Call this after finishing edits to allow other agents to work on the file.' This gives clear usage context but does not mention alternatives or when not to use (e.g., force_release_all).

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

• acquire_lockA
  4.2/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. It discloses the exclusive nature of the lock, the concurrency prevention behavior, and what happens if already locked ('Returns lock status and blocker info if already locked'). It does not cover lock duration or release requirements, but the key behavioral traits are conveyed.

  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 and 37 words, with the primary action and purpose in the first sentence and the return/blocker behavior in the second. Every sentence earns its place with no redundancy or filler.

  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 simple lock-acquisition tool with fully documented parameters and no output schema, the description adequately explains the purpose, exclusivity, and blocker-related return info. It could mention lock release or lifecycle, but the sibling tool release_lock implies the pattern, making the description sufficiently complete for an 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 input schema already provides 100% coverage with descriptions for all three parameters (filepath, agent_name, intent). The tool description adds no parameter-specific information, so the baseline of 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 clearly states the action: 'Acquire an exclusive lock on a file before editing.' It uses a specific verb (acquire) and resource (a file) and distinguishes itself from siblings like release_lock and force_release_all by focusing on acquiring the lock initially.

  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: use it 'before editing' to 'prevent other AI agents from modifying the same file simultaneously.' It does not explicitly name alternatives or exclusions, but the purpose is well-scoped relative to sibling tools.

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

• force_release_allA
  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 discloses that the tool force-releases all locks, which is a broad and forceful action, but it doesn't mention potential side effects like disrupting active lock holders, whether the operation is reversible, or any permission requirements. The description is adequate but not deeply transparent about consequences.

  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, with the first sentence serving as an immediate, urgent call to action ('Emergency: Force-release ALL active locks') and the second clarifying the scope. Every word earns its place—there is no redundancy or filler.

  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 simple, zero-parameter emergency tool, the description covers what it does, when to use it, and its all-encompassing scope. It could add a caution about irreversibility or impact on other agents, but given the simplicity and the emergency context, it is mostly complete.

  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 is empty and coverage is trivially 100%. The description confirms that no input is needed because it operates on all locks. This aligns with the baseline of 4 for zero-parameter tools.

  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 that the tool force-releases ALL active locks, freeing every locked file in the repository. This distinguishes it from sibling tools like release_lock (which targets a specific lock) and acquire_lock. The scope is unambiguous and the verb 'force-release' is specific.

  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 explicitly limits usage to emergency scenarios: 'Use only when agents are stuck or locks are stale.' This provides a clear trigger condition and implies normal lock releases should use release_lock instead, though it doesn't name the alternative explicitly. The 'Emergency:' prefix reinforces the exceptional nature of this tool.

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

• get_repo_stateA
  4.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. It clearly conveys a read-only, informational behavior by saying 'Get' and 'Shows', and provides useful context about the state contents. It does not mention edge cases like staleness or failures, but for a simple state query this is adequate.

  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 concise sentences, front-loaded with the core purpose and followed by a practical usage note. Every sentence earns its place with no redundancy.

  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 (zero parameters, no output schema), the description fully covers what the tool returns, its content, and when to use it. The sibling tools are all mutating lock operations, so the read-only nature is clear in context.

  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 baseline is 4. The description adds no parameter-specific details, but none are needed since the schema already confirms no inputs exist.

  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 'Get' with the resource 'current coordination state of the repository' and lists concrete contents (active locks, working agents, intent history). It clearly distinguishes this read-only state inspection from the sibling mutation tools (acquire_lock, release_lock, force_release_all).

  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?

  Explicitly states when to use: 'Use this before starting work to understand what other agents are doing.' This provides a clear usage context and implicitly differentiates it from the lock-manipulation siblings.

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