Server Quality Checklist

Tool Scores

• glm_askA
  4.1/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden of disclosing behavior, and it is exceptionally thorough. It explains thinking-token generation before the answer, reasoning budget ranges, model-specific constraints ('glm-5.3-flash cannot run with reasoning off, so its none is raised to low'), file context placement on the first turn, history consuming character budget, and max_tokens cap behavior including refusals. This is far beyond a basic safety profile.

  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 long but information-dense; every sentence carries either a use-case, a latency lever, or a routing rule. It is front-loaded with the core action and value proposition before diving into details. Some redundancy with the schema's reasoning and model descriptions exists, but for a tool this complex the length is justified.

  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 covers operational nuances such as file globbing behavior, line numbers, message ordering, reasoning constraints, and max_tokens caps. It mentions response notes for unmatched globs and history cuts, which implies a structured return. It does not fully spell out the output format, but for a chat-completion tool 'return its answer' plus the notes mention is reasonably complete given the lack of an output schema.

  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% and each parameter already has rich documentation, so the baseline is 3. The tool description adds high-level guidance about model/reasoning selection, but it mostly reinforces what is already in the parameter schemas rather than introducing new parameter-level meaning. The schema descriptions alone are sufficient for parameter understanding.

  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 opens with a specific verb and resource: 'Send a prompt to a Z.ai GLM model (default GLM-5.3) and return its answer.' It clearly explains the tool's function and even suggests use cases. However, it does not explicitly differentiate from the sibling tools glm_review and glm_models, relying on the tool name and general context to separate them.

  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 for when to use the tool: 'for a genuine second opinion from a different model, for cross-checking reasoning, and for analysing far more source material at once than fits in a normal context.' It also provides detailed routing advice among models and reasoning levels, e.g., 'Route mechanical work (extract, summarise, reformat, classify) to glm-5.3-flash or glm-4.6 at low.' It does not explicitly say when to use glm_review or glm_models instead, so no true alternatives are named.

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

• glm_modelsA
  4.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 behavioral burden. It discloses useful behavior: each model id is annotated with a one-line role, and unknown ids are rendered bare. It does not mention authentication or rate limits, but for a simple read-only enumeration this is not a significant 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?

  A single sentence that front-loads the action and includes only essential details about the output format and the special handling of unknown ids. Every clause adds value 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?

  For a zero-parameter list tool with no output schema, this description is complete: it tells the agent what will be returned, how roles appear, and how unknown ids are presented. Nothing critical is missing for invoking and interpreting the 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 and an empty input schema, so there is nothing for the description to clarify. The baseline of 4 applies because the schema already fully covers parameter semantics.

  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?

  States a specific verb and resource: lists GLM model ids from the configured Z.ai account. It also adds useful output semantics (one-line role, unknown ids listed bare), which makes it clearly distinct from sibling tools glm_ask and glm_review.

  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 makes the context clear: use this tool when you need to enumerate available model ids. It does not explicitly name alternatives or when-not-to-use, but the sibling tool names and the list-oriented wording make the intended usage obvious enough.

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

• glm_reviewA
  4.6/5.0
  Behavior5/5

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

  With zero annotations, the description carries the full burden and discharges it thoroughly: it discloses the exact verdict line grammar, that a bare verdict is returned as an error, that the server never runs git and inspects no repository state, that calls with neither diff nor files are refused, and that the reviewer is explicitly warned against padded/fabricated findings and stubbed/mocked/hardcoded work. This is rich behavioral disclosure well beyond what any structured field provides.

  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 long but front-loaded with the most critical fact — the exact VERDICT contract — before any parameter framing. Every sentence carries real content, from refusal behavior to the reasoning-depth default to the model-advice caveat. It is dense prose rather than concise prose, and a few points repeat what the schema already says, but nothing is filler.

  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?

  For a 7-parameter tool with no annotations and no output schema, this description is nearly complete: it specifies the return contract, error/refusal conditions, default model and reasoning level, cross-tool file-resolution semantics, and both recorded failure modes the reviewer is guarded against. The only deferrals are reasonable ones — glob-ignore overrides and character budgets live in the files parameter schema, and depth beyond routing is delegated to glm_ask's guidance.

  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?

  Schema coverage is 100% and the schema's own parameter descriptions are already unusually detailed, so the baseline is 3. The description adds genuine value on top: the rationale for the diff+spec pairing ('review against intent is what catches silent scope-narrowing') and the model-selection heuristic that a model re-reading its own work under-reports, which appears in no schema field. Some default and reasoning-guidance content is duplicated between description and schema, keeping this at 4 rather than 5.

  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 and resource — 'Review a change with a Z.ai GLM model' — and defines a concrete, distinctive output contract: a reply ending in exactly 'VERDICT: PASS' or 'VERDICT: CHANGES_REQUIRED'. This clearly distinguishes it from siblings glm_ask (asking) and glm_models (listing models) through the review-specific verdict vocabulary and the diff+spec input pairing.

  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 places glm_review within the glm_ask routing guidance ('the depth the glm_ask routing guidance reserves for review and bug-hunting') and gives actionable advice — supply a diff against spec rather than just a diff, and choose a different model than the one that wrote the code. However, it never explicitly states when to prefer glm_review over glm_ask or vice versa; that routing is inferred from the sibling names and the verdict contract rather than stated outright.

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