Server Quality Checklist

Tool Scores

• atlas_continuity_recordC
  2.7/5.0
  Behavior3/5

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

  The description adds some behavioral context beyond annotations: it is a write operation, local, compact, and targeted beneath a specific home path. It does not contradict the annotations, but it does not disclose effects like overwriting, appending, or whether the path must 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 a single, efficient sentence with no filler. It is front-loaded with the core action and resource, though the unexplained specialized terminology reduces some of the clarity gained from its brevity.

  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 output schema, minimal annotations, and zero parameter documentation, the description leaves important gaps: what a 'continuity card' is, how the parameters map to the card, and what happens after writing. The location hint is useful but not sufficient for confident invocation.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description provides no explanation of title, summary, or source. The agent is left to infer the meaning of all three required parameters from their generic names alone.

  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 uses a specific verb ('Write') and identifies a unique resource ('local Atlas Cartographer continuity card') plus a target location. It is distinct enough from sibling tools like changelog_intake or personal_git_commit, though jargon such as 'Atlas Cartographer' and 'SHAWN_CORE_CONTINUITY_HOME' is not explained.

  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 alternatives like changelog_intake or orchestrator_context. The description only states what the tool does, not the conditions that should trigger its use.

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

• changelog_intakeC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds operational context by naming the required handoff artifacts, but it does not explain what 'start' actually does, whether it invokes a subprocess, or what observable effects or outputs result. No contradiction with annotations is present.

  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 a single, front-loaded sentence that immediately states the primary action. The list of handoff inputs is compact and likely reflects real prerequisites, though the internal jargon reduces readability. Overall it is appropriately sized with no filler.

  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 output schema, the description should explain what happens after the tool is invoked, but it does not mention return values, follow-up actions, or how the named artifacts are used. The meaning of 'Atlas Cartographer handoff', '@github handoff', and 'Luna execution contract' is left entirely to the agent's prior knowledge. A single required parameter is present, but its relationship to the stated workflow is unclear.

  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?

  The schema provides no description for repo_path (0% coverage), and the description never mentions repo_path explicitly. The phrase 'Git snapshot' hints at repository context, but it does not clarify how repo_path relates to the snapshot, handoffs, or the Luna execution contract. The property name is self-explanatory, but the description does not add the needed semantic bridge.

  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 uses a specific verb-resource pair ('Start the Changelog specialist') and the tool name 'changelog_intake' reinforces that this is the entry point to a changelog workflow. It does not explicitly differentiate from the sibling 'changelog_finalize', though 'start' versus 'finalize' suggests the distinction. The list of handoff artifacts is jargon-heavy, which slightly obscures the purpose.

  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?

  There is no explicit guidance about when to use this tool versus alternatives such as changelog_finalize, personal_git_snapshot, or orchestrator_route. The word 'Start' implies this is the initial step, but no prerequisites, exclusions, or alternative routing conditions are stated.

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

• orchestrator_routeC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict them. It adds a small behavioral detail about waiting for a gate to identify missing capability, but it does not clarify what happens to the task in either branch or whether there are any side effects beyond the routing decision.

  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 one short sentence and leads with the core verb and object, making it efficiently scannable. However, the trailing clause is dense and jargon-heavy ('smoke or validation gate', 'missing capability'), which reduces clarity even though the length is appropriate.

  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?

  There is no output schema, no description of return values, no explanation of what 'route' or 'keep it with Orchestrator' means operationally, and no indication of what the agent should do next based on the result. Given the 1-parameter, no-output-schema complexity, the description is too incomplete for an agent to use the tool correctly.

  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?

  The single task parameter has zero schema description coverage, so the tool description must explain it. It merely says 'Route a task', giving no guidance on expected content, format, length considerations, or how the task string influences the routing outcome. An agent would be guessing about what to put in the parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description has a clear verb ('Route') and a clear object ('a task'), but it does not explain what routing actually entails, where the task is routed to, or how this tool differs from siblings like orchestrator_context. The phrase 'or keep it with Orchestrator' is vague and leaves the core function ambiguous.

  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 this tool is used at a smoke or validation gate to decide whether to route a task onward or retain it, but it never explicitly states when to invoke it, when not to, or which alternative tool might be better. The usage context is embedded in the wording but not made actionable.

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

• changelog_finalizeB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description only needs to add context. It adds 'receipt-backed' and 'end-of-task' scope, but does not explain what 'receipt-backed' means or what the rendered output should look like.

  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 places the most important scope information—'receipt-backed end-of-task'—before the noun, making it easy to parse quickly.

  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?

  For a 3-parameter tool with no output schema and no parameter descriptions, this is too thin. An agent still cannot tell what qualifies as a receipt, why receipts are optional despite 'receipt-backed' language, or what the rendered changelog entry will contain. The annotations cover safety but not the call contract.

  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%, so the description carries the burden for parameter meaning, but it only hints at receipts with 'receipt-backed' and says nothing about title or changes. Title and changes are somewhat self-evident, and the receipt hint provides partial value, but the description is not enough to compensate for the lack of schema descriptions.

  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 states a specific verb and resource: 'Render a receipt-backed end-of-task changelog entry.' The 'end-of-task' qualifier and tool name distinguish it from the sibling changelog_intake, though it does not explicitly name that alternative.

  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?

  'End-of-task' implies this tool belongs at task completion, and 'finalize' signals the final changelog step. However, it does not explicitly say when to use this tool versus changelog_intake or any other sibling, leaving the usage guidance mostly implicit.

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

• token_master_auditB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the core safety profile. The description adds that the tool returns an 'audit contract,' which is useful, but it does not describe contract contents, format, or any additional behavioral nuances.

  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 wasted words. It conveys the essential action and target resource efficiently.

  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?

  With no parameters, simple invocation is clear, and annotations cover safety behavior. However, the description leaves 'Token Master' and 'audit contract' undefined, and with no output schema the agent may not know what the returned contract contains or how to interpret it. Some additional context would improve completeness.

  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 and the input schema is an empty object, so there is nothing to clarify. Schema description coverage is 100%, and the baseline for no parameters is 4; no additional parameter explanation is needed.

  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 states a specific action ('Return') and a specific resource ('Token Master's read-only audit contract'). It clearly identifies what the tool does, though it does not explicitly distinguish it from sibling tools or define what an 'audit contract' is.

  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 gives no guidance on when to use this tool versus siblings like orchestrator_context or personal_git_snapshot. It implies use for retrieving an audit contract, but it does not state conditions, exclusions, or alternatives.

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

• personal_git_commitA
  3.5/5.0
  Behavior3/5

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

  The description adds value beyond the annotations by stating the operation is local and never pushes or publishes. However, it does not explain the critical behavior of the 'execute' flag—what exactly 'plan' means versus 'explicitly create'—and whether the default mode makes no changes at all. Given all annotations are false, this is a meaningful 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 two sentences with no filler. The primary action is front-loaded, and the key constraint—no pushing or publishing—is stated crisply.

  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?

  For a tool with four parameters, no output schema, and no safety annotations, the description is too thin. It covers the local and non-publishing nature but omits the execution semantics of 'plan' vs. 'execute', how paths are treated, and what the agent can expect as a result. This is insufficient for reliable invocation.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description provides no information about any of the four parameters: repo_path, paths, message, or execute. The description does not compensate for the schema's lack of parameter documentation, leaving agents to rely solely on property names.

  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 the specific verb 'create' with a clear resource ('local commit'), and clarifies the dual mode ('Plan or explicitly create'). It also scopes the operation to 'an allowlisted Git root' and explicitly rules out push/publish, which separates it from potential 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 Guidelines4/5

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

  The description gives clear context: use this tool for local commits, and the statement 'This never pushes or publishes' signals when not to use it. It does not name alternatives like personal_git_snapshot, but the scope is sufficiently explicit for selection.

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

• personal_git_snapshotA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'Read' wording is consistent with those. The description adds useful context about the allowlisted repository constraint and what data is read, but does not detail error behavior or edge cases.

  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. Every word adds useful semantic information about the operation and its constraints.

  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 one-parameter read tool with rich annotations, the description covers the key inputs, the operation, and the expected output content ('status and latest commit'). It is slightly light on usage guidance and failure conditions, but overall it is sufficiently complete for an agent to invoke the tool correctly.

  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 provides no description for repo_path, and schema coverage is 0%. The description partially compensates by identifying the parameter as a local Git repository and noting the allowlist requirement, though it does not explain path format, allowlist mechanics, or what happens if the repo is not allowlisted.

  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 ('Read'), the specific resource ('status and latest commit'), and the scope ('from an allowlisted local Git repository'). It is easy to distinguish from the sibling personal_git_commit, which is about committing changes rather than reading state.

  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 this tool is for read-only inspection of a Git repository and mentions the allowlist constraint, but it does not explicitly state when to use it instead of alternatives like personal_git_commit. The usage context is inferable but not directly articulated.

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

• orchestrator_contextA
  4.2/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, so the safety profile is covered. The description adds useful scope context ('public', 'ownership boundaries') without contradicting 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 a single front-loaded sentence with no filler or redundancy. It communicates the essential purpose and scope 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 zero-parameter, read-only tool with strong annotations, the description adequately specifies the returned concept. However, since there is no output schema, slightly more detail about what the registry and ownership boundaries look like could improve completeness.

  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 and schema description coverage is 100%, so there is no parameter burden for the description to carry. The baseline for a zero-parameter tool is appropriately strong.

  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 verb ('Return') and a concrete resource ('public specialist registry') plus the scope ('ownership boundaries'). This clearly differentiates it from sibling tools like orchestrator_route or changelog_intake.

  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 gives no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. Usage is only implied by the resource being returned, which is understandable but not explicitly routed against siblings.

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