Server Quality Checklist

Tool Scores

• gk_handoffC
  2.4/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that unknown actions return an allowed list (a useful trait), but it omits what the actual actions do, side effects, or safety implications, leaving the tool's behavior largely opaque.

  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 very short and front-loaded; each sentence provides some information. The third sentence about unknown actions and token savings is arguably unnecessary but still relevant; overall it is concise and easy to scan.

  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?

  Despite having an output schema, the description is incomplete for correct invocation because it never names the 4 actions or explains what 'gates' do. It also fails to differentiate from sibling tools, making the overall context insufficient for confident use.

  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 must compensate. It identifies 'action' and optional 'args' but does not list the valid action values or describe the structure or purpose of args, adding little beyond the raw schema.

  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 says the tool is for 'Spec/feedback handoff gates' and takes an action, which gives a general sense of its role. However, it does not state a specific verb+resource or enumerate the 4 actions, and it does not clearly distinguish it from sibling gk_* tools.

  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 explains how to call the tool ('Pass action= and optional args={}') and hints that unknown actions return an allowed list, but it gives no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites.

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

• gk_evidenceC
  2.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It does reveal that an unknown action returns the allowed list and that this 'saves schema tokens', which is a useful behavioral quirk. However, it does not disclose side effects, permissions, or per-action behavior, leaving significant gaps.

  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 sentence that front-loads the action list and includes a concise note about unknown-action handling. Every phrase serves a purpose, with no fluff. It is efficient though slightly cramped, but structure is clear.

  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?

  The tool has 8 distinct actions, making it fairly complex. The description provides only a list of names and a generic usage pattern, without any per-action details. An output schema exists, which may cover return values, but the description still fails to explain the purpose and arguments of each action, leaving the agent under-informed.

  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 coverage is 0%, so the description must compensate. It tells the agent to pass action= and optional args={} and lists valid action values, which is some help. But it does not explain what args each action expects or map actions to their required parameters, making the parameter semantics incomplete for a multi-action tool.

  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 lists the action names (submit, capture_shot, visual_critic, visual_step, visual_sequence, screenshot, journey, inspect_image) but never states what the tool does overall. It is not a tautology because it provides a specific list, but the lack of a clear verb+resource makes the purpose somewhat vague. It does distinguish from siblings by enumerating unique actions, but that is implicit.

  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 on when to use this tool versus its siblings. The description only instructs how to pass action and args, and mentions that an unknown action returns the allowed list. No alternatives or exclusion criteria are provided, so the agent receives no decision support.

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

• gk_memoryC
  2.7/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It does reveal a useful fallback (unknown action returns allowed list) and mentions 12 actions, but it doesn't explain whether operations are reads or writes, persistence effects, required permissions, or what side effects each action may have.

  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 terse sentence with dense information, front-loading the domain. It could be better structured (e.g., separated lines), but it is efficient and doesn't waste words.

  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?

  The tool appears to be a general memory graph with 12 actions, yet the description lists only five and gives almost no context on what those actions accomplish or how results are returned. Having an output schema helps, but overall the description is too thin for the apparent complexity.

  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 must explain parameters. It says to pass 'action=' and 'optional args={}', and lists some action values, but it doesn't enumerate all 12 actions or provide per-action argument shapes, leaving the args object largely opaque.

  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 identifies the tool as a 'Workflow memory graph' and lists concrete action names (lessons, marathon, query_graph, what_blocked, upsert_episode), giving a clear sense of the resource domain. It lacks an explicit verb like 'manage' or 'access', and doesn't differentiate from siblings, but the action list provides enough to infer its role.

  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 guidance on when to use this tool versus any of the many gk_* siblings. No mention of appropriate contexts or exclusions; the description only explains mechanics, not decision criteria.

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

• gk_taskC
  2.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It reveals that an unknown action returns the allowed list (saving schema tokens), which is a useful behavioral hint. However, it does not mention side effects, permissions, state changes, or the nature of the output, leaving significant behavioral aspects undisclosed.

  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 brief and front-loaded with the domain ('Task lifecycle') followed by the action list and usage hint. Every part contributes, though the list format is compact and could benefit from clearer separation or examples. It is concise without being overly terse.

  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?

  Given the tool has 7 distinct actions and an output schema, the description is underspecified. It does not explain the purpose of each action, expected args, or return behavior. The output schema exists but is not described here, so the description alone is insufficient for reliable use. It feels like a stubbed documentation.

  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 input schema has no descriptions and no enums, so the description adds crucial meaning by enumerating all seven valid action values. It also confirms that args is optional. This is substantial value beyond the schema, though it does not elaborate on what each action does or how args should be structured.

  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 identifies the tool as 'Task lifecycle' and lists seven actions (open, hypothesize, graph, policy, blast_radius, edit_safe, failing_slice), but it does not explain what these actions accomplish or how they relate to a task lifecycle. The purpose is somewhat inferable but vague, and it does not clearly distinguish itself from sibling tools other than by name.

  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 invocation syntax ('Pass action= and optional args={}') and notes that an unknown action returns the allowed list, but it does not specify when to use this tool versus alternatives like gk_code, gk_scan, or gk_phase. There is no explicit guidance on appropriate contexts or exclusions.

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

• gk_codeB
  3/5.0
  Behavior3/5

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

  The description adds valuable context: best-effort caveat for specified actions, and unknown action returns allowed list. But no annotations exist, and the description doesn't disclose potential side effects or authorization requirements.

  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?

  Two sentences, front-loaded with purpose, and no redundant text. The 'saves schema tokens' note is an interesting implementation detail but not directly actionable.

  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 tool dynamic action design with a discovery mechanism partially compensates for the missing action list. However, the description lacks examples or explicit prerequisites, leaving the agent to discover actions at runtime.

  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 description explains the invocation pattern (action + optional args) but doesn't enumerate the 21 actions or describe the expected structure of args for each action. Since schema coverage is 0%, this is a significant gap.

  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 the tool provides code intel helpers for map/search/read, which differentiates it from other gk_* tools. The mention of specific action categories (council/swarm/pipeline/self_heal) adds specificity, but it doesn't explicitly contrast with sibling tools like gk_scan or gk_guard.

  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 implies usage by instructing to pass action and args, and notes that certain actions are best-effort. However, it doesn't provide explicit guidance on when to choose this tool over alternatives, nor does it exclude cases.

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

• gk_modeB
  3.1/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 key behaviors: debug_engine uses static scan and token heuristics (not a live debugger), tool_propose searches but does not install, and unknown actions return an allowed list. These add meaningful context beyond the schema, though it does not cover all side effects or action-specific outcomes.

  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 dense sentence that packs many details: feature list, action pattern, debugger clarification, tool_propose distinction, and unknown-action behavior. It is concise and information-dense, though the heavy use of abbreviations and packed lists might reduce readability slightly.

  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?

  Given the tool's complexity (29 actions, multiple sub-modules) and the presence of an output schema, the description is far from complete. It does not list available actions, explain how each action works, or describe return structures. The unknown-action fallback is helpful, but overall the description leaves major gaps for an agent to operate 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?

  Schema coverage is 0%, so the description must compensate. It mentions 'Pass action= and optional args={}' and explains that unknown action returns the allowed list, but does not enumerate the 29 actions nor describe valid args values. The description adds minimal semantic detail beyond what the schema already shows (action required, args optional with default null).

  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 lists several features (modes/protocols/skills, ultradeep/view, debug_engine, tool_propose, plan_refute) and indicates an action-based interface ('Pass action=...'), but lacks a clear verb like 'execute' or 'manage'. It does mention unique capabilities distinguishing it from siblings, but the primary purpose is not immediately obvious to an agent.

  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 implicit guidance through caveats: debug_engine is 'not a live debugger' (suggesting another tool for that), and tool_propose is 'search≠install' (clarifying it's not for installation). However, there is no explicit statement of when to use this tool versus alternatives, nor any mention of sibling tools.

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

• gk_metaB
  3.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. It discloses a useful behavioral trait: unknown actions return the allowed list, which suggests a safe discovery mechanism. It also implies reading disk configs and facades, but it never states whether actions are read-only or if any have side effects, so transparency is incomplete.

  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, dense sentence that front-loads the core capabilities, then gives invocation syntax and a key behavioral fallback. Every phrase carries information, with no redundant 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?

  For a multi-action dispatcher tool with two parameters and no annotations, the description is incomplete. It omits the list of valid action names and what each does, leaving the agent to rely on the unknown-action fallback. The output schema exists, but the inputs are underspecified, making correct invocation difficult.

  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 coverage is 0% and the description adds only minimal parameter meaning: it repeats that 'action' and optional 'args' are used. It mentions '4 actions' but does not list them, and the 'args' object is not described beyond being optional. This is insufficient for an agent to construct valid arguments without external schema info or trial-and-error.

  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 what the tool does: it provides honesty status (disk MCP configs + real facades), secrets key listing, and a 9-step plan template/validate. Although it lacks a single explicit verb like 'get' or 'run', the capabilities are concrete and the action-dispatch pattern distinguishes it from siblings like gk_code or gk_guard.

  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?

  It gives operational guidance: 'Pass action= and optional args={}' and explains that unknown actions return the allowed list, which helps discover valid actions. However, it doesn't explicitly state when to choose this tool over its siblings, nor does it enumerate the four actions or their intended contexts.

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

• gk_phaseA
  3.5/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 burden and does offer real behavioral details: it blocks illegal phase skips and returns the allowed action list for unknown actions. However, it does not disclose whether actions mutate state, require permissions, or what side effects the assert/claim_done/rubric actions have.

  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 tight sentences, front-loaded with the tool's identity and actions. Every sentence adds information, including the fallback behavior, 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?

  Although there is an output schema, the description leaves the semantics of the three actions vague: what does 'assert', 'claim_done', or 'rubric' do? It also doesn't explain what phases exist or why the phase machine is needed among the many sibling gk_* tools, so an agent would lack sufficient context to invoke it correctly in all cases.

  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 schema has no descriptions or enums, so the description's mention of the three valid actions and the 'args={}' usage pattern adds essential meaning. It also tells the agent what happens on an unknown action, which helps parameter selection even though it doesn't detail individual args.

  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 identifies the tool as a 'Phase machine' and lists the exact actions it supports (assert, claim_done, rubric), giving a concrete sense of its purpose. This distinguishes it from the other gk_* tools, though 'machine' is a bit jargon-heavy and the phase domain is not fully explained.

  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?

  It provides operational direction by instructing to pass 'action=' and 'optional args={}', and it notes that illegal Antigravity phase skips are blocked. It does not explicitly name when to use this tool over siblings or list exclusions, but the action list implies the intended use cases.

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

• gk_scanA
  3.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the best-effort nature, optional semgrep usage, and a notable fallback where unknown actions return the allowed list. These are meaningful behavioral traits beyond what any schema would show, though it does not explicitly state read-only behavior or potential side effects.

  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 long, highly efficient, and front-loaded with the core purpose. It packs purpose, invocation, and a behavioral quirk into a compact form without redundancy. Every clause contributes value.

  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 outlines purpose, invocation, and fallback behavior, but omits the specific action names and arg keys, which are critical for correct use. The unknown-action fallback helps mitigate errors, and an output schema exists, but for a tool with only two actions, listing them would have made it complete.

  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 coverage is 0%, so the description must compensate, but it only restates that action is required and args is optional. It fails to enumerate the two allowed actions or describe the expected structure of args. The note about 'unknown action returns allowed list' provides some insight into action values, but still leaves the actual actions a mystery.

  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 identifies the tool as performing regex-based CWE heuristics, distinguishing it from a professional audit by labeling it as a signal. It references optional semgrep CLI integration, which adds specificity. However, it does not explicitly differentiate from sibling tools beyond the name 'scan'.

  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 suggests using this tool for quick, best-effort heuristic signals rather than a professional audit, which implies context but does not name alternatives. It provides invocation guidance ('Pass action= and optional args={}') but no explicit when-to-use vs. other gk_* tools. There is no explicit exclusion or comparison to siblings.

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

• gk_verifyA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description must disclose behavior. It does reveal that an unknown action returns the allowed action list, and it notes the exact number of actions (11). However, it does not explain side effects, permissions, or what each action actually does, leaving much of the behavioral profile undisclosed.

  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 extremely compact, using two sentences to convey the action list, parameter usage, error behavior, and a design rationale. There is no wasted wording; every phrase adds value. The listing format is easy to scan.

  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?

  While an output schema exists (reducing the need to explain returns), the description is incomplete for selecting among 11 actions. Terms like 'competitor', 'compare', and 'probe' are ambiguous without details. The parenthetical 'short stage_board' for 'exit' is cryptic. The token-saving strategy sacrifices clarity needed for correct action selection.

  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 schema is bare (0% coverage, no enums). The description compensates by instructing 'Pass action= and optional args={}', clarifying that 'args' is an optional object. It also enumerates the accepted action values, which is essential for invoking the tool correctly. It does not detail per-action args, but it adds significant meaning beyond the schema.

  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 starts with 'Verification:' which identifies the tool's domain, then lists 11 concrete actions (bundle, exit, soak, probe, etc.). This provides a clear overview and distinguishes gk_verify from sibling tools like gk_code or gk_scan. However, it lacks a single verb+resource phrase and uses a noun phrase instead of an explicit verb.

  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 'Verification:' prefix implies the tool is for verification tasks, and the action list suggests when to use it (e.g., when you need to bundle or probe). But it provides no explicit guidance on when to choose this tool over siblings, nor does it mention exclusions or alternatives. Usage context is implied rather than stated.

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

• gk_routeA
  4/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 burden of behavioral disclosure. It does reveal a useful behavior: 'unknown action returns allowed list (saves schema tokens).' However, it does not mention side effects, prerequisites, or return format details, leaving transparency partial.

  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 short and starts with the core purpose, making it easy to scan. However, the phrase '1 actions' is ambiguous and 'saves schema tokens' is cryptic, which slightly hurts clarity. Overall it is appropriately sized but not perfectly polished.

  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?

  Given the tool's simplicity and the presence of an output schema, the description covers the essential input parameters and the key edge case of an unknown action. It does not explain the role of the 'args' object in detail, but for a router with a free-form args field, this is acceptable. The description is sufficient 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.

  Parameters5/5

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

  The schema has 0% description coverage and no enums, so the description must compensate. It does so by listing the allowed action values ('/ask|/plan|/debug|/ultradeep|/view|/verify') and clarifying that args is optional with a default of null. This gives the agent everything needed to construct a valid call.

  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: 'Classify intent into /ask|/plan|/debug|/ultradeep|/view|/verify.' It names the specific verb (classify) and resource (intent), and enumerates the allowed target actions. This distinguishes it from sibling tools that likely execute those actions rather than route to them.

  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 explicit invocation instructions ('Pass action= and optional args={}'), which tells the agent how to call the tool. However, it does not explain when to prefer this tool over siblings or mention any exclusions, so the usage guidance is mostly syntactic rather than contextual.

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

• gk_browserA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden and does well: it reveals fallback behavior, the prefer_chrome_devtools return, the override flag, and the unknown-action allowed-list behavior. It omits side-effect details (e.g., whether actions mutate state) but the core routing and discovery behaviors are clearly disclosed.

  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 dense sentences with the critical condition front-loaded ('Playwright fallback ONLY when...'). Every sentence adds unique value, and there is no fluff or repetition of schema fields.

  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?

  Given the output schema exists, the description need not restate return values. It covers the routing condition, peer preference, override, and error/unknown-action behavior. The 7 actions are not enumerated, but the tool self-describes via the allowed-list mechanism, making the description functionally complete for agent use.

  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 0%, so the description must compensate. It only says 'Pass action= and optional args={}' and mentions '7 actions' with unknown-action discovery. This adds basic semantics but doesn't enumerate the 7 actions or explain args structure; the allowed-list mechanism partially mitigates the gap.

  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 identifies the tool as a Playwright fallback and distinguishes it from chrome-devtools, but it never names a concrete verb/resource (e.g., 'navigate', 'click'). It relies on the tool name and the mention of '7 actions' to imply browser automation, which is clear but not fully explicit.

  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?

  Usage is explicitly conditional: use only when chrome-devtools is NOT on the host, and if chrome-devtools is listed, prefer that peer first. It also provides an override mechanism (force_gk_browser=1), making the when/when-not guidance unambiguous.

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

• gk_guardA
  4.5/5.0
  Behavior5/5

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

  With no annotations, description discloses key behavioral traits: one-turn arming, clearing, file-scope limitation, host-hook dependency, and fallback for unknown actions. This goes well beyond minimal requirements.

  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 compact and front-loaded with the purpose. Each sentence adds unique information, though phrases like 'ship default max 1 path' and 'saves schema tokens' are cryptic and could confuse.

  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?

  Covers purpose, actions, conditions, and invocation pattern; output schema exists so return values aren't required. Minor gaps around args formatting keep it from a 5.

  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?

  Description names all three actions (set_paths, end_turn, Ultradeep) and explains that action is required with optional args={}, compensating for the schema's 0% description coverage. It doesn't specify args structure for each action but provides enough orientation.

  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 first sentence 'Write allowlist for host PreToolUse' states a specific action and resource, and subsequent sentences detail the tool's scope. It clearly distinguishes from sibling tools by focusing on guarding/allowlisting rather than code, scan, route, etc.

  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?

  Provides clear context: set_paths arms one turn, end_turn clears, ultradeep syncs current file only, and blocks native Write only when host hook is wired. It doesn't explicitly name alternatives/exclusions, but the action-specific instructions make usage conditions clear.

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