Server Quality Checklist

Tool Scores

• glitch_checkA
  3.6/5.0
  Behavior4/5

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

  The description explicitly states 'Reads only', which aligns with the readOnlyHint annotation. It also explains the passing condition and that receipts are returned per passing step, adding behavioral detail beyond the 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?

  The description is compact, with three short sentences that convey the action, the condition for passing, and the return type. It is front-loaded with the primary purpose and contains no extraneous information.

  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?

  The description gives enough context to understand the tool's behavior, including the return format (receipts per passing step) and the passing criteria. However, it does not detail the receipt structure or edge cases, but the simplicity of the tool mitigates this gap.

  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 fully documents the single parameter 'step' with an enum list and description. The tool description does not add additional meaning about the parameter, so it relies on the schema, which is comprehensive.

  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 that the tool runs checks for a step or all steps, with a specific passing condition and a return of receipts. It is specific enough to understand the core functionality, though the term 'check' is not elaborated on.

  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 the sibling tools glitch_status or glitch_ledger_tail. There is no mention of alternatives or conditions for selection, leaving the agent to infer usage context.

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

• glitch_ledger_tailA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds that entries are append-only and superseded entries remain visible, which is valuable beyond annotations. It clarifies the read-only nature and the treatment of supersession.

  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 with no fluff. The core purpose is front-loaded, and the behavior detail is provided efficiently.

  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 read-only tool with one optional parameter and no output schema, the description covers the essential behavior (tail of ledger, supersession handling). It doesn't mention pagination or how to retrieve older entries, but that's not critical for this simple tool.

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

  Parameters2/5

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

  Schema description coverage is 0% as the description does not mention the limit parameter. The schema itself documents it well (default, min, max), but given low coverage, the description should compensate, and it fails to add any meaning beyond 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 it reads the most recent entries from an append-only ledger, specifying the resource and the type of content (requests and responses). It distinguishes itself from siblings by focusing on the ledger tail, though it doesn't name alternatives explicitly.

  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 explains the behavior (supersession reported, not applied) but does not provide explicit guidance on when to use this tool versus glitch_status or glitch_check. It implies it's for reading history but lacks clear alternative selection criteria.

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

• glitch_statusA
  4.4/5.0
  Behavior4/5

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

  Beyond the annotation 'readOnlyHint: true', the description explicitly says 'Reads only' and explains the meaning of a failing step (not yet written file, not a bug). This adds valuable context about expected behavior and error interpretation, going beyond the annotation's simple flag.

  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 succinct, consisting of two clear sentences. The main purpose is front-loaded, and the additional clarification about failing steps is concisely appended. No unnecessary words or digressions are present.

  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 lack of an output schema, the description adequately explains what the tool reports (which practices are installed and which are not) and interprets the meaning of a failing step. This is sufficient for an agent to understand the tool's functionality without further schema details.

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

  Parameters5/5

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

  The tool has no parameters, so there is nothing to explain. The schema is empty and coverage is trivially 100%. The description adds no parameter-related confusion, and the empty parameter list is self-explanatory.

  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 checks which of the six bounded-autonomy practices are installed in the repository. It uses a specific verb ('are installed') and defines the resource (repository) and scope (the six practices), making the purpose unambiguous even without mentioning sibling tools.

  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 interpretive guidance ('a step reported as failing usually means the reader has not yet written their own file'), but does not explicitly state when to choose this tool over the sibling tools (glitch_check, glitch_ledger_tail). It implies usage for status checks but lacks direct comparison or alternative selection criteria.

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