Server Quality Checklist

Tool Scores

• qa_get_sync_statusC
  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 implies a read-only operation through 'Report' and 'identify', but never explicitly states that it has no side effects, nor does it explain what 'observable' means operationally or what happens when the queue is not observable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no filler, which is efficient. However, it sacrifices clarity by using undefined jargon like 'observable' and 'evidence', making the brevity less helpful than it could be.

  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 and no annotations, so the description alone must explain return values, meaning, and usage context. It only vaguely references server attempt/session evidence and SQLite queue observability, leaving the agent without enough information to reliably interpret the result or know when this tool is appropriate.

  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?

  The schema provides only a limit integer with min/max and no description, and schema description coverage is 0%. The description does not mention limit at all, so the parameter's meaning and effect are entirely unexplained.

  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 names a specific action ('Report') and a resource ('server attempt/session evidence') and adds a distinguishing point: it identifies whether the local SQLite queue is observable. This separates it from siblings like qa_get_attempts and qa_force_offline_queue, though the term 'observable' is somewhat ambiguous.

  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 for when to use this tool versus its siblings. It does not mention prerequisites, whether it should be called before or after other QA tools, or what to do if the queue is not observable.

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

• qa_reset_test_userC
  2.6/5.0
  Behavior2/5

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

  Since no annotations are provided, the description carries the full burden of disclosing behavioral traits. It says 'Reset', implying a destructive operation, but does not explain what gets reset, whether it wipes data, requires confirmation, or has side effects. The required 'confirm' constant is only visible in the schema, not in the description.

  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 concise sentence that front-loads the core action. There is no wasted text, though it lacks supporting details that could make it more helpful.

  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 destructive mutation tool with no annotations, no output schema, and zero parameter documentation, this description is insufficient. An agent cannot determine what happens on reset, what 'local fixture control plane' means operationally, or what response to expect.

  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%, so the description must compensate by explaining the parameters. It does not mention user_id or confirm at all, leaving their meaning and the role of the required 'RESET_TEST_USER' constant entirely to the agent to infer.

  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 ('Reset') and resource ('a test user'), and adds the context 'through the opt-in local fixture control plane'. This is clear and distinguishes it from read-only QA tools like qa_get_usage and qa_get_game_state, though it does not explicitly name an alternative.

  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 sibling mutation tools such as qa_set_subscription, qa_seed_questions, or qa_set_game_level. The phrase 'test user' implies QA use, but there is no explicit context, prerequisites, or exclusion criteria.

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

• qa_set_game_levelC
  2.8/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 indicates mutation ('Set') and a local/opt-in scope, but does not mention side effects on existing configs, whether changes persist, the required confirmation behavior, or what happens after the call.

  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 front-loaded sentence with no filler; every word contributes to the core purpose. It is concise, though the terseness borders on under-specification given the number of required parameters.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 4-required-parameter mutation tool with no output schema and no annotations, the description is far too thin. It omits the confirm protocol, config object expectations, and operational effects, leaving critical context missing.

  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 adds no parameter-level meaning. It does not explain the required confirm token, the structure of config, the game_id enum, or the level range, leaving the agent to infer everything from 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 uses a specific verb and resource, 'Set one test game level config', which clearly identifies the core action. It does not explicitly distinguish this from sibling setters like qa_set_subscription, so it stops short of a 5.

  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 'opt-in local fixture control plane' gives clear context that this is a test-only, locally scoped configuration tool for QA fixture setup. It does not name alternatives or exclusions, but the context is sufficient to route an agent toward this tool for local level-config changes.

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

• qa_seed_questionsB
  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 full burden. 'Seed' suggests a mutating operation and 'opt-in local fixture control plane' hints at a local, gated environment, but the description does not disclose side effects, whether data is added or replaced, idempotency, or what confirmation is required. The required 'SEED_TEST_DATA' confirm const appears only in the schema, not the description.

  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 with no redundancy; it front-loads the action and resource. Every word earns its place, even though the jargon 'opt-in local fixture control plane' is dense.

  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 mutating/seed tool with no annotations, no output schema, and 0% parameter coverage, the description leaves too much unsaid. An agent would not know the purpose of the optional fields, whether confirm is mandatory for execution, or what successful seeding looks like.

  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%, and the description names none of the parameters. It adds little meaning beyond the schema's self-explanatory names and enum for 'game_id', and it does not explain how 'levels', 'game_id', and 'confirm' interact or what values are valid in context.

  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 ('Seed') with a clear resource ('test questions') and places it in an 'opt-in local fixture control plane,' giving the agent a solid idea of what the tool does. It is distinguishable from the many qa_get_* read tools and from qa_reset_test_user, but it does not explicitly identify how it differs from sibling setup/write tools like qa_set_game_level.

  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 phrase 'opt-in local fixture control plane' implies this is for local test-fixture setup, and sibling names suggest it is one of the mutating/setup tools. However, the description gives no explicit when-to-use or when-not-to-use guidance, no prerequisite, and no mention of alternatives.

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

• qa_get_app_snapshotB
  3.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden, and it does disclose two useful behavioral traits: the result is 'server-truth' (not cached/client state) and 'bounded' (limited in size). It does not explain the truncation behavior, ordering, or whether max_rows applies per section or to the whole snapshot, but the basics are 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 sentence and front-loads the main action and result. The capitalized list 'Today, Progress' is slightly ambiguous but the overall structure is efficient 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?

  Given the large sibling set, no output schema, and no annotations, the description is too thin. It does not clarify what constitutes 'Today' or 'Progress', how max_rows affects the response, whether this call supersedes the individual qa_get_* tools, or what the returned snapshot shape looks like.

  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%, and the description never mentions max_rows by name or explains how it controls the snapshot. The word 'bounded' only hints at the parameter's effect without mapping it to the actual input, leaving the agent to guess how the limit applies.

  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 ('Fetch') and names a concrete resource: a bounded server-truth snapshot across Today, Progress, entitlement, usage, and account data. It is clear enough that an agent can tell this is an aggregate read tool, though it does not explicitly contrast with the individual sibling getters.

  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?

  Usage context is implied: this tool provides a combined snapshot across several data domains, so an agent can infer it is for cross-domain retrieval. However, there is no explicit guidance about when to use this instead of qa_get_entitlement, qa_get_usage, or other siblings, nor any exclusions.

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

• qa_get_round_detailB
  3.2/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the burden of disclosing behavior. It does reveal the important fallback behavior and the exact-match semantics, which are useful. However, it does not explain what 'bounded' means, what the return shape is, whether the operation is read-only, or what happens when neither parameter is provided.

  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 concise sentence with no filler. It front-loads the primary exact-lookup behavior and then adds the fallback behavior efficiently.

  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 no annotations, no output schema, and 0% schema description coverage, the description is not complete enough. It omits crucial operational detail such as how limit bounds the fallback, whether limit is required in fallback mode, and what the tool returns when no matching attempt exists.

  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 explicitly mentions client_attempt_id and hints at bound via 'bounded attempt', but it never clearly states that limit controls the fallback result or how the two parameters interact when both are provided or omitted.

  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 a specific operation: finding a server attempt by client_attempt_id, with a fallback to the most recent bounded attempt. It names the key resource and identifier, though it does not explicitly distinguish itself from siblings like qa_get_attempts or qa_get_current_round.

  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 two modes of use are implied: exact lookup when client_attempt_id is supplied, and a fallback to the most recent attempt otherwise. However, it does not explicitly state when to choose this tool over sibling tools such as qa_get_attempts, nor does it mention exclusions.

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

• qa_get_current_roundB
  3.3/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. It discloses that this is a read operation and clarifies a non-obvious distinction about which 'round' is being referenced. It does not describe behavior such as what happens if no round is available, whether reading advances the queue, or any response shape, but for a simple getter the core behavioral trait is apparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, both purposeful. The main statement is front-loaded, and the second sentence adds an important nuance without redundancy. 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 tool with one optional enum parameter and no output schema, the description is reasonably complete for invoking the call. Missing elements include usage guidance relative to siblings and any detail about return behavior, but the core purpose is clear enough for a basic read operation.

  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 has only one parameter, game_id, with an enum but no description, and the description adds no parameter information. Since schema description coverage is 0%, the description needed to compensate; it does not. The parameter name and enum values are fairly self-explanatory, but the description provides zero added meaning.

  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 ('Read') and a specific resource ('next server-selected queue round'), which clearly communicates what the tool returns. The clarification that it is 'not a claim about the active UI round' helps distinguish it from round-related observations in the UI, though it does not explicitly name sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

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

  The description implies usage for reading the server-side queue round rather than the UI round, and the negative statement ('This is not a claim about the active UI round') gives an exclusion. However, it does not explicitly state when to prefer this over siblings like qa_get_round_detail or qa_get_game_state, leaving some inference required.

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

• qa_get_skill_ratingsB
  3.4/5.0
  Behavior3/5

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

  The verb 'Read' implies a non-destructive operation, and 'raw' suggests no processing, but no annotations exist to confirm safety. The description doesn't mention return format, error conditions, or side effects, though the read-only intention is reasonably clear.

  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, tight sentence that front-loads the verb and enumerates the exact data types returned. No filler or redundancy.

  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 simple zero-parameter read tool, the description covers the core purpose, but it lacks enough detail to disambiguate from several similar sibling getters and does not explain what 'score conversion source' means or when to choose this 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 trivially complete and the description has no need to explain parameter meaning. Baseline 4 applies.

  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?

  Description uses a specific verb ('Read') and names concrete resources: raw skill ratings, attempt counts, uncertainty, and the score conversion source. This makes the tool's function clear and helps distinguish it from siblings like qa_get_attempts, though it doesn't explicitly name alternatives.

  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 for when to use this tool versus alternatives. Sibling tools like qa_get_attempts and qa_get_memory_score overlap in purpose, and the description does not clarify which to pick in different contexts.

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

• qa_force_offline_queueA
  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 full burden. It does disclose that this is a state-changing operation ('Toggle') and that it acts on a test fixture via a local control plane, which is genuinely useful behavioral context. But it does not describe side effects, reversibility, whether it affects real queue data, or the meaning of the required confirmation, leaving significant behavioral nuance unstated.

  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 sentence with no filler, front-loads the core action, and adds the important 'opt-in local fixture control plane' context at the end. Every word earns its place.

  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 state-changing tool with no annotations and no output schema, the description is under-specified. It identifies the fixture and the toggle action, but it does not explain what actually happens to the queue, what user_id is for, what a successful response looks like, or why the explicit confirmation constant is required. An agent could guess the basic call, but not with confidence about all behaviors.

  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 for parameter meaning, and it mostly does not. The word 'Toggle' loosely maps to the mode parameter's online/offline enum, but the required confirm value and the optional user_id are never explained, leaving two of three parameters without semantic guidance from the description.

  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 ('Toggle') and a specific resource ('test offline-queue fixture'), making it immediately clear this tool is for switching a queue fixture between online and offline states. It is also distinct from all sibling tools: no other sibling targets an offline-queue fixture, so an agent can tell it apart without opening the schema.

  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 phrase 'test offline-queue fixture' and 'opt-in local fixture control plane' imply this is a QA/test-only tool, which gives useful context. However, the description does not explicitly state when to use it over siblings like qa_set_game_level or qa_reset_test_user, nor does it say when not to use it or what conditions should trigger it.

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

• qa_get_attemptsA
  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 disclosure burden. It states the read-only nature via 'Read', identifies the data source, and notes that raw round details are retained. Still, it does not describe ordering, default limit, or whether the operation is safe/non-mutating beyond the verb.

  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 efficient sentence with no filler. It front-loads the core action and resource, then adds relevant sourcing and retention context without wasted words.

  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 simple tool with one optional parameter, the description covers the resource and source adequately. However, 'recent' is vague, return behavior is unspecified, and there is no guidance about how this relates to sibling attempt/round tools, leaving some gaps for an agent to infer.

  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 only parameter, 'limit', is clearly named and constrained in the schema with min/max values, so the schema carries most of the meaning. The description does not explicitly explain that limit controls the number of attempts returned, which would have compensated for the 0% schema description coverage.

  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 a read operation on 'recent server-owned attempts' from the 'complete account export', which is specific enough to distinguish from round/session/state tools. It does not explicitly name sibling alternatives, but the resource and source are clearly stated.

  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 intended use is implied: call this tool when you need recent server-owned attempts. However, there is no explicit guidance on when to choose this over siblings like qa_get_round_detail or qa_get_game_state, and no exclusions are mentioned.

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

• qa_set_subscriptionA
  3.5/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 full burden of behavioral disclosure. It implies a write operation ('Set') but does not state whether an existing subscription is overwritten, whether the action is reversible, or what side effects occur. This is a significant transparency gap for a mutation 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?

  A single sentence with no redundancy. The action and context are front-loaded, and every word earns its place.

  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 four required parameters, no output schema, and no annotations, the description is too thin for reliable invocation. It omits details about confirmation, return value, idempotency, and prerequisites. The test/local context helps but does not complete the picture.

  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%, yet the description names no parameters and adds no meaning beyond the schema. The schema's enums and const are somewhat self-explanatory, but the description fails to compensate for the complete lack of parameter documentation.

  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: 'Set a test subscription'. It also contextualizes the operation as being 'through the opt-in local fixture control plane', which distinguishes it clearly from sibling getters and from qa_set_game_level.

  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 provides clear usage context: it is for setting test subscriptions via a local fixture control plane. However, it gives no explicit when-to-use vs. alternatives or when-not-to-use guidance, so it stops short of a 5.

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

• qa_get_game_stateA
  3.6/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 helpfully discloses the sentinel return value 'not_observable' when no sidecar/bridge is configured, and 'Read' implies a non-mutating operation. It does not describe what is returned in the observable case, but the key behavioral quirk is covered.

  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 sentence with the verb and resource front-loaded, followed by the conditional fallback. Every word contributes meaning; there is no redundancy or filler.

  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 simple, parameterless read tool, the description is mostly sufficient. However, with no output schema and no annotations, it leaves a gap by not describing the shape or content of the returned game state when it is observable. The not_observable fallback is explained, but the normal success payload is not.

  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 schema coverage is trivially 100%. Per the rubric, 0 parameters earns a baseline of 4; the description adds no parameter details because none are 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 uses a specific verb ('Read') and resource ('optional instrumented live game state'), making the core action clear. It does not explicitly name or differentiate from sibling tools like qa_get_current_session or qa_get_round_detail, so it stops short of full differentiation.

  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 explicit guidance is given about when to use this tool versus alternatives. The 'optional' and 'not_observable' wording implies it applies only when instrumentation is present, but no when-to-use or when-not-to-use conditions are stated.

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

• qa_get_current_sessionA
  3.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. It clearly indicates a read-only operation ('Read') and hints at returned data, but it does not disclose authentication prerequisites, potential error states, or whether any state is affected. For a zero-parameter read, the basic safety profile is communicated, but details are thin.

  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, focused sentence that front-loads the action and resource. There is no filler or redundant restatement; every part adds information about what the tool returns.

  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 low complexity (no parameters, no nested objects), the description is reasonably complete: it identifies the resource and the key contents of the return value. However, without an output schema, it could be more explicit about the exact shape of 'progress counters' and what 'validity' means, so it is not a perfect 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?

  The tool has zero parameters and the schema already covers 100% of them, so there is no parameter burden for the description to carry. The description adds no parameter-specific details, but none are needed. Baseline 4 for a zero-parameter tool is appropriate.

  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 clear verb ('Read') and resource ('authenticated server session'), and mentions the specific contents (validity and progress counters). It is distinguishable from siblings like qa_get_current_round and qa_get_game_state, though 'from Today' is somewhat ambiguous and not explicitly contrasted with those alternatives.

  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 implicitly suggests this tool is for retrieving the current server session, including validity and progress counters, but it does not explicitly state when to use it over the many sibling getters such as qa_get_current_round, qa_get_game_state, or qa_get_attempts. No exclusions or alternative routing are provided.

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

• qa_get_entitlementA
  3.8/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the behavioral burden. 'Read' and 'server-authoritative' disclose that this is a read-only lookup from the server source of truth, but the description does not mention auth expectations, error behavior, or whether the data may be absent.

  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 front-loaded sentence states the verb and lists the exact data domains with no filler or repetition. Every word adds informational value.

  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 parameterless read tool with no output schema, the description names all the data it returns, which is sufficient for an agent to invoke it. It does not describe return formatting or error cases, but the low complexity of the operation justifies this.

  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 coverage is 100%, so the schema already fully documents the input. The description adds no parameter details, but none are needed; the 0-parameter 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 opens with 'Read' plus a specific resource (entitlement state) and enumerates its data fields: plan, status, billing product identity, and AI credits. Those fields distinguish it from sibling getters like qa_get_usage and qa_health even without naming them.

  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 explicit guidance on when to call this tool versus sibling tools, and no exclusions or alternative suggestions. The only usage signal is the verb 'Read', which is implicit rather than directive.

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

• qa_validate_app_contractA
  3.8/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 behavioral disclosure burden. It explicitly states the operation is 'read-only' and 'bounded', which are important safety constraints. It does not describe output or failure semantics, but for a pure validation tool with no parameters the key non-mutation trait is 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?

  A single, tightly worded sentence that front-loads the verb and the critical 'read-only' modifier. Every word contributes to the meaning; no filler or redundant phrasing.

  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 is adequate for invoking a zero-parameter tool and communicates the core purpose and safety profile. However, with no output schema and no annotations, it does not explain what the contract checks actually verify, what the tool returns, or how to interpret a pass/fail result, leaving meaningful gaps.

  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 schema has 100% coverage, so there is nothing for the description to add. The no-parameter baseline of 4 applies.

  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 ('Run bounded read-only contract checks') and a clear resource scope ('health and all authenticated application-truth endpoints'). It distinguishes itself from sibling getters by being a validation pass rather than a single data retrieval, though 'application-truth endpoints' remains somewhat undefined.

  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 intended context is implied: use this tool to validate the health and authenticated endpoints as a group. However, there is no explicit statement about when to prefer this over individual qa_get_* calls, nor any exclusion or alternative guidance.

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

• qa_get_usageA
  4/5.0
  Behavior3/5

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

  The verb 'Read' conveys a non-mutating operation, and 'separate ... ledgers' indicates the response is split by ledger category rather than a single aggregate. With no annotations present, however, the description does not disclose response shape, formatting, or any edge behavior, so it carries only a moderate burden of transparency.

  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?

  One sentence, front-loaded with the action verb, and every word adds information. The ledgers are enumerated compactly with no filler, redundancy, or unnecessary qualification.

  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 getter with a clearly enumerated set of ledgers, the description is largely complete. The absence of an output schema and any detail about response structure is a minor gap, but nothing about invoking this tool is left ambiguous.

  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 there is nothing to document; the rubric baseline for zero-parameter tools is 4. The description adds useful context about what the no-argument call will return without needing to explain parameter syntax or defaults.

  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 ('Read') and names the resource precisely: separate ledgers for AI-credit, rewarded-insight, streak-freeze, and bounded AI activity. It clearly distinguishes this tool from sibling getters like qa_get_entitlement or qa_get_current_session by focusing on usage ledgers.

  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 makes the intended use reasonably clear: call this when you need these specific usage-ledger values. However, it does not explicitly state when not to use it, nor does it name alternative tools for related data, leaving routing largely implicit.

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

• qa_healthA
  4/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 behavioral disclosure burden. It successfully communicates that the operation is read-only and requires no user token, both important safety and authorization traits. It does not describe the exact response shape, but for a zero-parameter health endpoint this is a reasonable level of transparency.

  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 concise clauses with no filler. Both statements add distinct value: read-only behavior and the token requirement, making every word earn its place.

  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, read-only health check with no output schema, the description is sufficiently complete. It states what is checked, that it is safe, and that no authentication is needed. Nothing an agent requires to invoke it correctly is missing.

  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?

  There are zero parameters, so the baseline for parameter semantics is 4. The description needs to add no parameter-level detail because the schema already fully captures the empty input contract.

  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 a health check for the Hugomemo API/database and labels it read-only, which is specific enough to distinguish it from data-fetching siblings. However, it does not explicitly distinguish it from similar status-oriented tools like qa_get_sync_status, so it falls just short of a 5.

  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 statement 'Does not require a user token' provides a useful precondition and implies this can be called without authentication setup. It does not explicitly say when to prefer this over sibling tools or when to use it versus alternatives, so usage context is only implied rather than fully specified.

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

• qa_get_memory_scoreA
  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 behavioral burden. It discloses that the tool performs a read operation, and the 'without inventing zero' clause is a valuable behavioral warning that missing scores should not be defaulted to zero. It also signals optional comparison behavior, though it does not elaborate on error handling or output format.

  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, efficient sentence that front-loads the primary action and then appends the optional comparison behavior. Every phrase earns its place, with no redundant or filler content.

  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 has only two optional parameters and no output schema, the description covers the essential behavior: reading the server memory score and optionally comparing a UI score. It could be more explicit about the return representation or tolerance defaults, but overall it provides enough context for correct invocation.

  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 only ranges and types for ui_score and tolerance, with 0% description coverage. The description adds meaning by identifying ui_score as 'a score observed in the UI' and implying tolerance is used for comparison. However, it does not define the exact comparison logic or what happens when parameters are omitted.

  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-resource pair: 'Read the server memory score.' This clearly identifies a unique resource (memory score) that is distinct from the sibling tools such as qa_get_usage and qa_get_skill_ratings. The phrase 'without inventing zero' also adds a meaningful precision to the tool's intent.

  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 use: read the server memory score, or optionally compare a UI-observed score. It does not list explicit alternative tools or exclusions, but the resource is distinct enough among the siblings that an agent can infer when to use this tool.

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