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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full disclosure burden and does a good job: it names the confidence fields, the per-metric confidence, and the status enum including 'warming_up', which warns the agent that early readings are not trustworthy. It omits any mention of latency, rate limits, or whether calling it triggers sampling, but the core behavioral caveats 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.

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

Front-loaded with the verb and resource, then the return payload, then the confidence caveat, then the follow-up pointer. Every sentence adds information an agent needs; nothing is padded or repeated from structured fields.

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

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 must explain the return shape, and it does — metrics, band powers, signal quality, confidence fields, and status values. With zero parameters and no annotations, this is sufficient for an agent to call and correctly interpret the result.

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

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

The tool takes zero parameters, so there is nothing to disambiguate; the baseline for a parameterless tool applies. The description spends no words on irrelevant input discussion, which is appropriate.

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

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

States a specific verb and resource ('Get the current brain state') and enumerates what comes back: proxy metrics, band powers, signal quality. A sibling like get_band_powers or get_signal_quality overlaps with parts of the return payload, and the description never clarifies why an agent would choose this composite read over those narrower tools, so it stops short of full sibling differentiation.

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

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

Gives real conditional guidance: weight metrics by confidence and 'do not interpret an unreliable/low-confidence reading', plus a pointer to get_metric_definitions for interpretation. It does not say when to prefer this tool over get_band_powers or get_signal_quality, so there is no explicit alternative routing.

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

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

With no annotations, the description carries the full burden and does so well: it states that these metrics are heuristic proxies rather than validated cognitive measurements, explains the role of DOIs under references, and warns that caveat sources must never be cited as support. This gives the agent essential trust and citation semantics before use.

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

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

The description is compact and front-loaded, moving from the core purpose to the returned contents and then to the important citation caveat. Every sentence adds useful information without repetition.

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

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

Given the zero-parameter schema, lack of output schema, and absence of annotations, the description is complete enough: it explains what the tool returns (formula, references with DOIs, caveat) and how to interpret the resulting guidance. No critical behavioral or usage detail is missing.

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

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

The tool has zero parameters, so there is no parameter semantics to explain. The baseline for a zero-parameter tool is 4, and nothing in the description needs to compensate for missing schema detail.

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

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

The description uses a specific verb and resource: 'Explain each brain metric' and details that it returns exact formulas, literature with DOIs, and caveats. This clearly distinguishes it from sibling tools such as get_brain_state or get_band_powers, which retrieve live values rather than documentation.

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

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

It gives a direct usage instruction: 'Call this to learn what focus/calm/attention/engagement/fatigue/meditation actually measure and how much to trust them.' It does not explicitly name alternatives or when not to use it, but the documentation role is clear enough for an agent to choose it appropriately.

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

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.

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.

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.

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.

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.

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.

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

No annotations are provided, so the description carries the full burden — and it does well: it discloses the content of the response (method details, limitations, intended use) and the misuse risk it guards against. It stops short of describing the actual return structure or size, which is a minor gap for a static informational tool.

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

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

Front-loads the payload ('What this pipeline can and cannot do') and then itemizes the sections. Dense but every clause carries information — the limitation categories are not padding. The parenthetical list is slightly long, but it preempts an agent's follow-up questions.

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

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

For a zero-parameter, no-output-schema documentation tool, this is exactly what an agent needs: what it returns, when to consult it, and what conclusions it forbids. No output schema means return values aren't required in the description, and nothing material is missing.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline applies. The description correctly implies a parameterless, whole-pipeline-scoped lookup.

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

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

The description states a specific verb+resource — it returns what the pipeline can and cannot do, enumerating the exact analysis method (Welch PSD window, band edges, filters), a plain-English limitations list, and intended use. This is clearly distinguishable from sibling tools like get_metric_definitions or get_band_powers, which return numbers rather than methodological caveats.

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

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

Gives an explicit when-to-use rule ('Read this before drawing any conclusion from the metrics') plus a concrete when-not/misuse prohibition ('do not present them as clinical, diagnostic, or event-level (ERP/spindle) results'). An agent knows both the trigger and the constraint without inference.

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

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

With no annotations, the description carries the full behavioral burden. 'Get' implies a read operation and the artifact list adds useful context, but it does not state whether results are real-time or cached, whether it requires an active connection, or any calibration prerequisites.

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

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

A single front-loaded sentence with no filler. Every clause adds a returned signal or artifact category.

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

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

For a zero-parameter simple read tool, the description sufficiently enumerates what comes back even without an output schema. It could mention the granularity (per electrode vs aggregate) and whether an active device connection is required, but overall it is complete enough to select the tool.

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

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

The tool has zero parameters, so there is no parameter semantics to document. The schema is empty and fully described; baseline 4 applies.

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

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

States a specific verb and resource (get electrode signal quality) and enumerates the key returned signals: confidence and artifact types. It is clearly distinct from siblings like get_band_powers and get_brain_state, though it does not explicitly name that distinction.

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

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

Provides no guidance on when to call this versus alternatives such as get_band_powers or get_brain_state. The agent must infer that this is for electrode-level quality checks rather than neural-state or spectral queries.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.