Server Quality Checklist

Tool Scores

• create_new_quire_projectB
  3.3/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 behavioral burden. It adds location context but does not disclose filesystem side effects, whether an existing folder is reused or overwritten, whether directories are auto-created, or how the starterTemplate parameter affects the resulting project.

  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 with no filler. It immediately states the action and the location scope, and every word earns its place.

  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 creation tool with no output schema and no annotations, the description plus schema gives the essential call shape. However, it never states what a successful creation returns, whether the project folder must already exist, or how this tool fits into the preview/build workflow implied by the sibling tools.

  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 documents all three parameters with 100% coverage, so the baseline is 3. The description adds only a slight nuance about 'current directory' versus the folder parameter, but it does not explain projectName or starterTemplate beyond what the schema already provides.

  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 opens with a specific verb and resource: 'Create a new Quire project.' It also states the location scope ('current directory or specified folder'), which makes the tool's purpose concrete and clearly distinct from the sibling tools, which are all about previewing, building, or stopping previews.

  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 given about when to use this tool versus the siblings. The usage context is only implied by the word 'create,' and there are no prerequisites, follow-up steps, or exclusions mentioned.

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

• build_quire_projectB
  3.4/5.0
  Behavior3/5

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

  Annotations are absent, so the description carries full responsibility. It does disclose the main behavior (running a build and generating HTML site files), which implies a write/side-effect operation, but it does not mention whether existing output is overwritten, whether a project must already exist, or what a successful run returns.

  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?

  A single sentence that communicates the action and outcome with no filler. The key verb 'Runs' is front-loaded and the purpose follows immediately.

  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?

  With no annotations and no output schema, this minimal description leaves important context unstated: the project must already exist, the build may overwrite html output, and there is no mention of expected errors or success signals. For an agent deciding whether and how to invoke this mutation-like tool, the description is incomplete.

  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 baseline is 3 even though the description adds no parameter-specific detail. The schema's parameter descriptions are present, though somewhat awkwardly worded, so the description itself does not need to compensate.

  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 states a specific action ('Runs the Build command') and its purpose ('generate html site files'), making it clear this tool compiles a Quire project into static HTML. This naturally distinguishes it from siblings that create, preview, or stop previews.

  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 create_new_quire_project, preview_quire_project, or stop_quire_preview. The agent must rely on sibling names and inference rather than any explicit when-to-use or when-not-to-use guidance.

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

• preview_quire_projectA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It does disclose two meaningful side effects: generating HTML files and starting a local server on port 8080. However, it omits whether the server runs continuously, blocks the command, or needs to be stopped explicitly, which is important for a server-starting tool.

  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 one tightly written sentence with no filler. It front-loads the core action ('Runs the Preview command') and adds the two most useful details: generated output and the local server port.

  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?

  The description covers the core action and even mentions the port, which is helpful. However, it lacks lifecycle context: the server presumably keeps running and should be stopped with stop_quire_preview, and there is no mention of what success looks like. Given the simple schema and sibling visibility, this is adequate but not fully 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 100%, so the baseline is 3. The description adds no parameter-level detail beyond the schema, but it does not need to because the schema already explains projectName and projectPath reasonably well.

  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 states a specific action ('Runs the Preview command') and its concrete effects: generating HTML site files and starting a local server. It also gives a distinguishing detail ('Typically port 8080') that separates it from build_quire_project, which would not start a server.

  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 does not say when to choose this tool over its siblings, nor does it mention stop_quire_preview as the way to halt the server it starts. The intended use is implied by the name and action, but no explicit guidance or exclusions are provided.

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

• stop_quire_previewA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure burden. It clearly states the action and the idempotent edge case ('if any'), which is valuable. It does not detail termination semantics or side effects, but for a zero-parameter stop command that is a minor 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 one short, front-loaded sentence with no filler. Every word contributes to specifying the action, the target resource, and the conditional behavior.

  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 no-parameter, no-output-schema command, the description is nearly complete: it states what happens and the no-process case. It could mention return behavior or effects on the underlying process, but those are low-value details for this simple 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 tool has zero parameters, so the schema is effectively exhaustive. The description does not need to explain parameter behavior, and the baseline of 4 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 a specific verb ('Stops') and a specific resource ('the currently running quire preview process'), which clearly states the tool's purpose. The 'if any' qualifier adds scope, and the action is clearly distinct from sibling tools like preview_quire_project or build_quire_project.

  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 'currently running ... if any' gives a clear precondition: invoke this only when a quire preview process exists, and it is safe to call even if none is running. It does not explicitly name alternatives or exclusion scenarios, so it is slightly below full routing guidance.

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