Server Quality Checklist

Tool Scores

• calibrateC
  2.4/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavior, but it only says 'capture a baseline.' It does not explain whether the tool is read-only or destructive, whether it requires the device to be worn, or what happens during calibration (e.g., prompts or feedback). The description is too vague.

  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 sentence, which is concise, but it sacrifices informativeness. It could be restructured to front-load the key action and then include brief parameter hints, but currently it is too sparse.

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

  Completeness2/5

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

  Given the tool has two parameters and no output schema or annotations, the description should provide more context about calibration duration, conditions, and expected outcomes. The current description is insufficient for an agent to understand the full scope of the tool.

  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 input schema has two parameters ('seconds' and 'condition') with defaults, but the description does not mention them at all. With 0% schema description coverage, the description should compensate but fails to add any meaning beyond the schema, leaving the agent without guidance on parameter usage.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: to capture a baseline for personalization of focus/calm metrics. It distinguishes from sibling tools like 'get_band_powers' or 'start_neurofeedback' by focusing on calibration rather than real-time data or feedback.

  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 on when to use this tool versus alternatives. For example, it does not specify that calibration should be done before using neurofeedback or that it may need to be repeated. The description lacks context for proper usage.

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

• mark_eventC
  2.4/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 full responsibility to disclose side effects or safety. It only says 'annotate,' implying a write operation, but does not mention persistence, mutability, or any constraints.

  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 sentence with no wasted words. However, it is too brief, lacking essential details. Conciseness should not come at the cost of completeness.

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

  Completeness2/5

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

  Given the tool has one required parameter and no output schema or annotations, the description should provide more context on the live stream state, label semantics, and effect. It fails to fully inform an agent for correct usage.

  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 meaning to the 'label' parameter beyond its type. No examples, allowed values, or context are given for what constitutes a valid label.

  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 action (annotate) and resource (live stream) with a specific output (labeled event marker). It is distinct from sibling tools like 'record' or 'stream_summary', though it does not explicitly differentiate itself.

  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 on when to use this tool versus alternatives. The description only states the function without context on preconditions, use cases, or exclusions.

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

• start_neurofeedbackC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description must convey behavioral traits. It only mentions rewarding time above a target, but does not describe side effects, if it stops existing sessions, or requirements like prior calibration.

  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 front-loading the action. However, it omits important details that could be added without becoming verbose.

  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 session-starting tool with no output schema and two parameters, the description lacks essential context: how to end the session, what happens during it, and return value expectations.

  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 only vaguely references 'metric' and 'target' without explaining valid values, units, or how they affect the session.

  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 ('Begin') and resource ('neurofeedback session'), and clarifies the session's function ('rewarding time spent above a metric target'). It distinguishes from sibling tools like calibrate or connect.

  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 on when to use this tool versus alternatives. Does not mention prerequisites (e.g., connection, calibration) or when not to use it.

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

• get_signal_qualityB
  3/5.0
  Behavior2/5

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

  No annotations. The description implies a read operation but does not disclose side effects, required permissions, or what 'signal quality' entails beyond artifact detection. Lacks behavioral traits like whether it uses current device connection.

  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?

  A single sentence that conveys the core purpose. It is front-loaded with the main action. Could be slightly expanded to cover context, but remains concise.

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

  Completeness2/5

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

  With no parameters, output schema, or annotations, the description is minimal. It does not explain what 'signal quality' metrics are, how artifacts are reported, or how to interpret results. Given sibling tools, more context about when to use this specific signal quality check would improve completeness.

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

  Parameters4/5

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

  The input schema has zero parameters, so baseline 4 applies. The description adds no parameter info because none exist. It implicitly suggests no input needed, but does not clarify that it operates on the current device state.

  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 action ('Get') and the resource ('electrode signal quality and detected artifacts'), with specific examples like blink and railing. However, it does not explicitly distinguish from siblings like get_band_powers or get_brain_state, which have overlapping themes.

  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 on when to use this tool vs alternatives (e.g., get_brain_state or get_band_powers). No exclusion criteria or context about prerequisites or typical use cases.

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

• connectB
  3.1/5.0
  Behavior2/5

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

  Without annotations, the description should fully disclose behavioral traits. It mentions 'start streaming' but does not explain if the operation is blocking, how to stop it, or how multiple connections are handled. This lack of detail limits transparency.

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

  Conciseness4/5

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

  The description is very concise at two sentences with no redundancy. It front-loads the key action. However, additional context could be added without harming conciseness.

  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 single parameter and no output schema, the description is somewhat complete for a simple connection tool, but it lacks context about prerequisites (e.g., device discovery) and the streaming lifecycle, which is important given sibling tools like 'stream_summary' and 'disconnect'.

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

  Parameters3/5

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

  Schema coverage is 0%, so the description must add meaning. It notes 'default is the synthetic brain', which clarifies the default URI value. However, it does not describe the expected format or other possible device URIs, leaving some ambiguity.

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

  Purpose5/5

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

  The description clearly states the action ('Connect to an EEG device') and the result ('start streaming'). It also specifies the default synthetic brain, which distinguishes this tool from siblings like 'disconnect' or 'list_devices'.

  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 on when to use this tool versus alternatives (e.g., 'calibrate', 'list_devices'). There is no mention of prerequisites or best practices, leaving the agent without context for correct invocation.

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

• recordB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden, but it only states the basic action. It does not disclose file overwrite behavior, whether recording is blocking or async, or what happens if parameters are invalid (e.g., seconds=0).

  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?

  Single sentence that is front-loaded with the verb and key resource ('Record the live stream'), no extraneous words, and clear structure.

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

  Completeness3/5

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

  The tool's complexity is moderate (3 parameters, no output schema). The description covers the main action but omits important context like error handling, file overwrite behavior, and return value. It is minimally adequate but not comprehensive.

  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 0%, so description must add value. It explains 'fmt' with formats (npz/csv/edf) and mentions 'seconds' and 'file'; however, it does not detail the 'path' parameter or constraints on 'fmt' values.

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

  Purpose4/5

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

  The description clearly states the tool records a live stream for a specified duration to a file with specific formats (npz/csv/edf). It is distinct from siblings like 'connect' or 'calibrate', though the stream type (e.g., EEG) is implied rather than explicit.

  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 on when to use this tool versus alternatives. Missing prerequisites (e.g., must be connected to a device) and conditions like when recording might fail or should not be used.

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

• stream_summaryB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description bears full burden. It honestly discloses that the `seconds` window is not yet functional and that the tool returns a live reading. This is good but does not cover other behavioral aspects like whether it is read-only or requires authentication.

  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 wasted words. The key information (snapshot, live reading, future seconds) is front-loaded. Highly efficient.

  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 parameter and no output schema, the description explains the current behavior and the future intent of the parameter. However, it lacks details on the output format or what a 'brain-state snapshot' constitutes, which may be insufficient for an agent to fully understand the tool's return value.

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

  Parameters3/5

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

  Schema coverage is 0%, but the description indirectly explains the `seconds` parameter by stating it is intended for rolling stats in a future phase. This adds context beyond the schema, though it does not fully describe the parameter's current behavior or valid range.

  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 it returns a 'current brain-state snapshot' and 'live reading', which clearly identifies the tool's purpose. However, it does not explicitly distinguish from sibling tools like 'get_brain_state', though the snapshot term implies a different level of detail.

  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 on when to use this tool versus alternatives. The note about the `seconds` parameter being for a future phase implies that for rolling stats one should wait, but no alternative tool is mentioned.

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

• get_band_powersB
  3.4/5.0
  Behavior2/5

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

  No annotations provided. The description does not disclose whether reading is instantaneous, requires prior connection, or any side effects. Minimal behavioral context beyond the basic function.

  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?

  Single sentence with no redundancy. Every word is necessary and front-loaded.

  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?

  No output schema exists, so the description should clarify return structure (e.g., units, dictionary keys). It only mentions 'absolute and relative' without further detail, leaving ambiguity.

  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?

  No parameters exist; schema coverage is irrelevant. The description adds meaning by specifying absolute/relative and listing bands, which compensates for the empty schema.

  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 specifies the tool retrieves absolute and relative EEG band powers, listing five standard bands (delta, theta, alpha, beta, gamma). This distinguishes it from siblings like get_brain_state or get_signal_quality.

  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 on when to use this tool versus alternatives like get_brain_state or get_neurofeedback_score. The context does not explain decision criteria.

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

• get_neurofeedback_scoreA
  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 full burden. It indicates a read operation ('sample'), but does not disclose side effects, latency, or whether it requires a connection. For a zero-parameter tool, the description is adequate but could mention that it returns immediately or is non-destructive.

  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 that front-loads the action and resource. It contains no superfluous words and efficiently conveys the core information.

  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?

  Lacking an output schema, the description partially explains the return value ('in-zone now + cumulative %') but is vague about the format (e.g., separate numbers, object). It does not specify if other data is included. For a simple tool, more clarity on the return structure would complete the description.

  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 no parameters, and schema coverage is 100% (trivial). The description does not need to add parameter details. Baseline score of 4 is appropriate as it provides no additional parameter info 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 clearly states the tool samples the current neurofeedback score, specifying it includes 'in-zone now + cumulative %'. This distinctly identifies the resource and action, differentiating it from siblings like get_band_powers or get_brain_state.

  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 on when to use this tool versus alternatives (e.g., get_brain_state, get_signal_quality). The context of 'sample' vs 'get' is not clarified, and there is no mention of prerequisites or context where 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.

• disconnectA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, and the description only says 'disconnect', failing to disclose behavioral traits like impact on ongoing sessions, required state, or side effects beyond the basic action.

  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 extraneous information, well-suited for a simple action.

  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 tool with no output schema, the description covers the core purpose adequately. However, it could mention that disconnection stops any active data flow or session for completeness.

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

  Parameters4/5

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

  The tool has no parameters, so the description does not need to add parameter-level meaning. The schema coverage is 100%, justifying a baseline score of 4.

  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 verb 'disconnect' and the resource 'current EEG device', making the tool's purpose immediately obvious and distinguishing it from siblings like 'connect'.

  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 when wanting to terminate a connection, but provides no explicit guidance on when to use vs. not use, nor alternatives. It is adequate but lacks depth.

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

• get_brain_stateA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as read-only nature, whether it requires an active connection, or if it has any side effects. The description is too minimal for full 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?

  Single sentence, front-loaded with the verb and resource, efficiently lists components. No wasted words.

  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 tool has no parameters and no output schema. The description provides a high-level summary of the return values. However, it could mention prerequisites (e.g., 'Requires a connected device') to be fully complete.

  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 no parameters, so schema coverage is 100%. The description adds value by listing the components of the brain state, which goes beyond the empty schema. Baseline for 0 parameters is 4, and the description meets it.

  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 gets the current brain state and lists specific components (focus, calm, attention, band powers, signal quality), distinguishing it from sibling tools like get_band_powers and get_signal_quality that are more targeted.

  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?

  No explicit guidance on when to use this tool versus siblings, but the purpose is implied. Lacks instructions on prerequisites like connection status.

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

• list_devicesA
  3.9/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 of behavioral disclosure. It states the tool lists devices/URIs for connection, which is a read-only operation. However, it does not disclose any authentication requirements, formatting of results, or potential limitations (e.g., network constraints).

  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 that directly conveys the tool's purpose with no extraneous words, earning a top score for efficiency.

  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 the tool's simplicity (no parameters, no output schema, no annotations), the description is minimally adequate. However, it lacks details about the return format (e.g., list of strings or objects) and does not help the agent understand how to use the output with sibling tools like 'connect'. More context would improve completeness.

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

  Parameters4/5

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

  The tool has zero parameters and schema coverage is 100% (empty object). The description adds no parameter-specific meaning because there are none, but it correctly implies that no input is needed, matching the schema.

  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 the specific verb 'List' and specifies the resource as 'EEG devices/URIs you can connect to.' This clearly distinguishes it from sibling tools like 'connect' or 'calibrate' which involve actions beyond listing.

  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 that this tool is used for discovering available devices before connecting, but it does not explicitly state when to use it versus alternatives (e.g., before 'connect'), nor does it provide any exclusions or prerequisites.

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