Server Quality Checklist

Tool Scores

• lol_getA
  3.7/5.0
  Behavior3/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. It discloses the return shape and states 'Always allowed', giving a safety hint. However, it does not describe error behavior, rate limits, or consequences of invalid paths. For a simple GET, this is partial coverage.

  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 with no filler. The core action and return format are front-loaded, and the pointer to lol_endpoints is useful. Very efficient.

  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 single-parameter GET tool with no output schema, the description covers the essential aspects: what it does, what it returns, and how to find valid inputs (via lol_endpoints). It could mention error handling, but the delegation to lol_endpoints mitigates the need. Overall reasonably 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 description coverage is 0%, and the description does not explain the 'path' parameter in detail beyond 'any LCU path'. It points to lol_endpoints for discovery, which compensates somewhat, but the description itself adds little semantic detail about the parameter's format or valid values.

  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 (GET), resource (any LCU path), and return shape ({ status, body }). Names a sibling (lol_endpoints) for discovery, which also helps differentiate its scope. The 'Always allowed' adds a constraint.

  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?

  Gives some guidance: use lol_endpoints to discover paths, and 'Always allowed' implies no restrictions. However, it does not explicitly contrast with alternative tools like lol_request (likely for non-GET methods) or specify when not to use this tool. The guidance is implicit rather than explicit.

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

• lol_evalA
  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 full burden. It discloses that evaluation bypasses the write allowlist by construction and is gated by allowEval, which is significant behavioral context. It also implies code execution capabilities. It does not mention error handling or side effects, but the key traits are 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 two sentences with no filler. It leads with the purpose, then adds a crucial behavioral note about bypass and gating. Every word earns its place, and the structure is efficient.

  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 potentially powerful evaluation tool with only 2 parameters and no output schema, the description adequately covers the return value and the prerequisite flag. It does not specify timeout or error behaviors, but those are minor gaps given the simplicity of the interface.

  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 already provides descriptive text for both parameters ('expression' and 'awaitPromise') with 100% coverage, so the description adds no extra parameter-level detail beyond what the schema gives. The recommended baseline of 3 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 clearly states the verb 'evaluate' and the resource 'expression in the client UI's own context', and notes that it returns the value. It also highlights the unique property of bypassing the write allowlist, which distinguishes it from other tools, though it does not explicitly name a sibling.

  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 a gate condition (allowEval config flag) and points to lol_status for checking it, which is useful. However, it does not offer explicit when/when-not guidance relative to siblings like lol_get or lol_request, leaving the agent to infer when this tool is appropriate.

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

• lol_events_pollA
  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 burden of behavioral disclosure. It does an excellent job: it clarifies the cursor semantics, warns about the 'dropped' field indicating data loss from buffer wrap, and explains the 'truncated' field with a concrete remediation path via lol_get. This is strong transparency for a polling tool. It does not, however, state whether polling advances a cursor or clears the buffer (though 'plus the new cursor' implies advancement), and it omits any mention of side effects or read-only guarantees, which keeps it slightly below a perfect score.

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

  Conciseness5/5

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

  The description is two sentences with zero fluff. It front-loads the primary function (return events since cursor), immediately explains the two special output fields (dropped, truncated) with actionable guidance, and stays tightly focused. Every sentence earns its place without redundancy.

  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 polling tool with 3 parameters and no output schema, the description covers the essential elements: the cursor mechanism, the dropped-event warning, and the truncated-data recovery path. It does not specify the full response shape (e.g., whether an empty array is returned when no events exist, or the structure of each event beyond its URI), but given the tool's complexity and the specific edge cases it does address, it is nearly complete for an agent to call correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so each parameter already has a description in the schema. The description adds value by clarifying that 'since' acts as a cursor from the previous poll, aligning with the tool's sequencing logic. However, it does not add extra meaning for 'limit' or 'filter' beyond what the schema provides. Since the schema carries the heavy lifting, a baseline of 3 is appropriate.

  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 concrete verb ('Return') and a specific resource ('buffered events') with a precise condition ('seq greater than since') and explicit output elements (new cursor, dropped, truncated). The name 'lol_events_poll' plus the clear behavior distinguishes it from siblings like lol_events_start/stop, and it even references lol_get for re-fetching truncated entries, reinforcing 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 Guidelines3/5

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

  The description implies usage: it's a poll operation that drains buffered events, and it gives a concrete instruction to re-fetch truncated entries via lol_get. However, it does not explicitly state when to use this tool versus alternatives (e.g., only after starting event capture with lol_events_start), nor does it mention any prerequisites or exclusion conditions. The usage context is mostly inferable from the name and behavior, not explicitly described.

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

• lol_requestA
  4/5.0
  Behavior4/5

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

  With no annotations given, the description carries the full burden of disclosing behavior. It specifies that GET/HEAD are permitted unconditionally, other verbs must match a write allowlist, and refusals return the exact config line needed to allow the request. This is a valuable behavioral disclosure that goes beyond the schema. It does not cover response format or error handling, but the core restrictions and refusal behavior are clearly stated, making it above average.

  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 and immediately front-loads the core action ('Send any HTTP verb to an LCU path') before explaining the allowlist nuance. There is zero wasted wording, and every clause contributes to the agent's understanding. This is a model of conciseness.

  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?

  Given that the tool has three parameters, no output schema, and no annotations, the description adequately explains the allowlist constraint and refusal behavior. However, it does not mention expected response format, error handling, or the fact that paths are relative to the LCU API. These gaps could lead to incorrect invocations or misinterpretation of results, so while it is serviceable, it is not fully complete for a generic HTTP request tool.

  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 description coverage is only 33% (only 'body' has a description). The tool description adds very little parameter-specific meaning—it mentions 'any HTTP verb' but does not elaborate on acceptable path formats, the meaning of the parameters, or provide examples. Since the description does not compensate for the low schema coverage and fails to clarify the method/path semantics beyond the enum and pattern, it scores a 2.

  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: sending any HTTP verb to an LCU path. This distinguishes it from siblings like lol_get, which presumably only handles GET requests, and lol_status, which likely queries status. The verb 'send' plus the resource 'LCU path' makes the purpose unambiguous.

  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 usage context: GET and HEAD are always allowed, while other verbs require explicit allowlist entries, and it explains the refusal behavior. However, it does not explicitly mention when to use this tool versus a more specific sibling like lol_get, nor does it provide exclusions or alternatives. The allowlist rule essentially defines the usage boundary, earning a 4.

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

• lol_dom_queryA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description bears full disclosure burden. It reveals a key prerequisite (Pengu Loader's remote debugging port), describes the output format (tag, id, className, trimmed text, plus requested properties), and names a failure path. It doesn't explicitly say the operation is read-only, but querySelector semantics imply that.

  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 efficient sentences with the core action front-loaded and the dependency/failure note appended. No filler or repeated schema 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?

  Completeness is good for a 3-param query tool: it specifies the return description format (useful since there is no output schema), the runtime dependency, and the failure fallback. Minor gaps include pagination/limits on matches and the exact shape of returned objects, but nothing blocking a call.

  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 100%, so the schema fully documents all, props, and selector. The description's 'plus any requested properties' aligns with the props param but adds no syntax or format details beyond what the schema already provides. Baseline 3 is appropriate.

  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 precise verb+resource pair: runs document.querySelector(All) inside the client UI and returns match descriptions. This is unambiguous and clearly distinct from siblings like lol_get (generic get) and lol_eval (arbitrary JS execution).

  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 DOM-inspection purpose is self-evident, and it explicitly routes to lol_status as an alternative diagnostic if the remote debugging port fails. It doesn't enumerate when-not-to-use versus siblings like lol_eval, but the querySelector framing makes the intended use clear enough.

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

• lol_statusA
  4.1/5.0
  Behavior3/5

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

  Since no annotations are provided, the description must carry the full burden of behavioral disclosure. It explains what the tool reports (subsystem health, event tap state, config) but does not explicitly state whether it has side effects or is read-only. Given the 'status' nature, it's implied to be non-mutating, but this is not stated outright, leaving some ambiguity.

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

  Conciseness5/5

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

  The description is two sentences with no wasted words. The first sentence front-loads the core function (what health is reported), and the second provides usage guidance. Every word earns its place, and the structure is efficient and clear.

  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 status/diagnostic tool with no output schema, the description adequately covers what is reported (LCU, CDP, event tap, config) and when to use it (first when other tools fail). It omits the exact return format, but that is not explicitly required since there is no output schema. It is sufficiently complete for an agent to invoke it correctly.

  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 description need not elaborate on parameter usage. Per the rubric, a tool with no parameters gets a baseline of 4 regardless of schema coverage. The description does not need to add any parameter-related information.

  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 that the tool reports the health of both LCU and CDP subsystems, event tap state, and effective config. It identifies distinct resources and a clear purpose (health check) that distinguishes it from sibling action-oriented tools like lol_get or lol_eval. However, it lacks an explicit verb like 'get' or 'check', making the action implicit rather than direct.

  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?

  The description explicitly says 'Call this first when another tool fails', providing a precise condition for when to use it. This gives clear contextual guidance and implies it is a diagnostic first step, effectively routing the agent away from alternatives in failure scenarios.

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

• lol_endpointsA
  4.2/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 of behavior. It discloses the case-insensitive substring filter behavior and the fields returned (verb, group, description). It does not specify the exact output format (e.g., array of objects) or pagination, leaving minor gaps.

  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, front-loaded with the primary purpose, and every sentence adds meaningful detail. The filter behavior is explained succinctly without waste.

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

  Completeness4/5

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

  For a simple read-only listing tool with one optional parameter, the description is largely complete. It specifies what is returned (verb, group, description) and filter behavior. The absence of an output schema is partially mitigated by the described table structure, though exact JSON format is not stated.

  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 already provides the filter parameter and examples, but the description adds value by explaining case-insensitivity and the fields it matches (verb, path, group, description). This goes beyond the schema's basic 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 title and description clearly state the tool lists curated LCU endpoints with verb, group, and one-line description. It is distinct from siblings like lol_get/lol_request that execute calls, and the phrase 'this project actually uses' clarifies scope.

  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 implies the tool is for discovering the endpoints the project supports, which separates it from the call-execution tools. However, it does not explicitly mention when to use it vs. alternatives or provide exclusions, so it falls 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.

• lol_events_startA
  4.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 disclosure burden, and it delivers substantial behavior: it discloses the memory-risk side effect ('fills the buffer in seconds'), the ingest-time filtering behavior, and the idempotent re-call semantics (replaces filters, preserves buffer). Minor gaps: it does not state whether the buffer persists after stop or what teardown entails, but the operational warnings and re-call contract are meaningfully beyond what structured fields would convey.

  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?

  Three tightly composed sentences with zero waste. The core action is front-loaded in sentence one, the filter guidance with its safety warning sits in sentence two, and the re-call behavior is the single remaining fact in sentence three. Every sentence earns its place and there is no redundancy with the schema.

  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 single-optional-parameter tool with no output schema and no annotations, the description is nearly complete: it covers the primary action, the parameter semantics with a concrete example, the risk of unfiltered use, and the idempotent re-call behavior. The only shortfall is no mention of return value or failure modes (e.g., LCU not connected), which is minor for a side-effect starter 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?

  Schema coverage is 100% (the filters param is documented with pattern and example), so the baseline is 3. The description adds operational meaning beyond the mechanical definition: 'Filters are URI prefixes applied at ingest' clarifies timing, and the buffer-danger note explains why filters matter. This converts the parameter from a mere format spec into a functional design decision, exceeding the baseline.

  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 precise verb and resource: 'Open the OnJsonApiEvent tap and buffer events in memory.' It clearly identifies this as the start/buffer action, distinguishing itself from siblings like lol_events_poll (retrieval) and lol_events_stop (teardown) without any ambiguity. The resource name and action are concrete and immediately actionable.

  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 explicit guidance on the key usage decision — 'pass filters unless you truly want everything' — and explains the consequence ('the unfiltered firehose fills the buffer in seconds'). It also documents the re-invocation contract: 'Calling this while already running replaces the filters and keeps buffered entries.' It does not explicitly name sibling alternatives for routing, but the filter-or-not guidance and re-call semantics cover the core usage choices for this tool.

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

• lol_events_stopA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description fully discloses the primary behavior (closing the tap) and a key side effect (buffered entries remain readable via lol_events_poll). It doesn't mention idempotency or behavior if called without a prior start, but those are minor for a stop operation. This adds value beyond what would be obvious from the name alone.

  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 short sentences with no filler. The primary action is front-loaded ('Close the event tap'), and the only additional detail (buffered entries remain readable) is essential context. Every word earns 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 tool with no output schema, the description fully covers what the agent needs: what it does and the key consequence. No missing information that would prevent correct usage. The simple nature of the operation means no additional context is required.

  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 description correctly makes no mention of parameters. The schema is empty (100% coverage), and the baseline for 0-parameter tools is 4. The description provides no additional parameter guidance, but none is needed.

  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 ('Close') and a resource ('event tap'), which clearly distinguishes it from siblings like start and poll. It also states the outcome: buffered entries stay readable, removing ambiguity about its effect.

  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 implicitly says 'stop buffering' and notes that buffered entries remain accessible, which tells the agent it's used after events have been started. However, it doesn't explicitly state when not to use it or mention any alternative, though the simplicity of the operation makes this acceptable.

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