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

With no annotations, the description carries the full burden. It discloses the decoder-dropping side effect, but does not mention whether the operation is destructive, irreversible, idempotent, or if it requires specific permissions. The agent is left unaware of potential data loss or error conditions.

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, compact sentence that states the core action and a key side effect. There is no filler or redundancy; every word contributes.

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 is simple, but the description is thin. It lacks context on when to close a session, what happens if the session does not exist, whether the action is reversible, and any error handling. Given the absence of an output schema and annotations, the description is not sufficient for an agent to use it safely and correctly.

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 schema has zero description coverage for session_id, and the description does not mention the parameter at all. No guidance is provided on the format, required context, or what constitutes a valid session ID. The description adds no value beyond 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 clearly states the verb 'Close' and the resource 'a session', and adds the specific effect 'drop any decoder fitted on it', which distinguishes it from open_session and get_session_info. The purpose is unambiguous.

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 given on when to close a session versus alternatives, nor any prerequisites or cleanup scenarios. The agent must infer that closing is a termination step, but the description offers no explicit context 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, the description carries the behavioral burden. It does disclose key behavior: the output is downsampled and shows decoded-vs-true, and the operation depends on a fitted decoder. However, it does not mention side effects, failure conditions, or whether the session must be open, so transparency is only partial.

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 the core action front-loaded and no filler. It loses a point because the brevity also contributes to missing parameter and usage context, but as concise prose it is well structured.

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 tool with four parameters, no output schema, and no annotations, the description is too thin. It omits parameter semantics, prerequisites like an open session or fitted decoder, and a fuller description of the returned preview, so an agent cannot reliably invoke it correctly.

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 the description must compensate for undocumented parameters, but it names none of session_id, t0, duration_s, or max_points. It adds no meaning beyond the raw schema and leaves the agent guessing what each parameter means.

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 names a specific verb ('decode'), a resource ('window'), and clarifies this is a preview ('downsampled decoded-vs-true preview'), which separates it from fitting and plotting tools. It does not explicitly name sibling tools, but the preview phrasing distinguishes it enough to be clear.

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 use after a decoder has been fitted, but it gives no explicit when-to-use guidance and does not contrast against siblings like plot_decoding or evaluate_cross_session. An agent must infer the intended workflow without any exclusions or alternatives.

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 must carry the full burden of disclosing behavior. It mentions the 10 s snippet limit and conditional precision/recall reporting, but does not disclose what the tool returns, whether it modifies any state, or how it behaves without ground truth. The behavioral coverage is thin and incomplete.

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 extremely short with no fluff, using two concise sentences that front-load the core purpose. It is efficiently written, though the brevity contributes to the incompleteness. Conciseness itself is well executed, but structure lacks additional sections.

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 complexity (4 parameters, no output schema, no annotations), the description is grossly inadequate. It does not explain return values, parameter semantics, or provide any usage context. An agent would have no idea how to invoke this correctly or interpret results. This is a serious deficiency.

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 provides no explanation of any parameter. t0, duration_s, session_id, and threshold_sigma are entirely unexplained. The description adds zero value in helping an agent understand parameter meaning or units. This is a critical gap.

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 (detect), resource (spikes), and method (threshold-crossing) on a broadband snippet with an explicit maximum duration. It implies a distinct function from sibling tools like sort_spikes or get_firing_rates, though without naming them. The purpose is clear but not explicitly differentiated from alternatives.

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 the many sibling tools. The only situational hint is the conditional reporting of precision/recall when ground truth exists, but it does not indicate when threshold-crossing detection is preferred over other spike processing tools. Lacks explicit when-to-use or alternatives.

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 discloses that the decoder is 'unchanged' across sessions, that mask restricts which bins are scored, that FALCON files carry eval_mask, and that same-session held-out R² is also reported. This is meaningful behavioral context beyond what the schema shows. It doesn't mention side effects (e.g., whether it writes anything), but the description implies a read/analysis operation, and the disclosed behavior is substantial.

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: the core operation is stated in the first sentence, followed by the benchmark context, prerequisites, and parameter clarifications. Every sentence adds value, and there is no repetition of schema fields or filler.

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 complexity (6 params, 0% schema coverage, no output schema, no annotations), the description covers the essential usage context: what it does, prerequisites, mask semantics, and the extra same-session R² output. It doesn't explain the target parameter or the return format, but the description is strong enough that an agent could likely call it correctly for the primary FALCON use case. A 4 is appropriate; a 5 would require explicit mention of target and output structure.

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 the description must compensate. It explains the mask parameter's semantics ('boolean behaviour signal restricting which bins are scored', 'pass null when sessions have none') and clarifies the relationship between train_session_id and test_session_ids. It also mentions the kind parameter implicitly via 'decoder' and the bin_s parameter via 'bins'. However, it doesn't explain target or bin_s explicitly, so it doesn't fully compensate for the 0% coverage.

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 ('fit a decoder on one session and score it, unchanged, on other sessions') and names the exact resource and operation. It also explicitly references the FALCON benchmark question, which distinguishes it from sibling tools like fit_decoder and decode_window. This is a clear, specific purpose statement.

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 gives clear context for when to use this tool: when benchmarking cross-session decoder survival, as FALCON does. It also specifies prerequisites ('All sessions must be open and share the same units/channels') and explains the mask parameter's role. However, it doesn't explicitly name alternative tools or state when NOT to use it, so it falls just 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.

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It does this well by revealing key non-obvious behaviors: the train/test split, default target selection ('first velocity-like behaviour signal'), skipping of unrecorded gaps, and mask filtering. It does not mention the exact scoring metric or whether any state persists, but the disclosed behavior goes well beyond a generic 'fit decoder' statement.

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 short, dense, and front-loaded, with each sentence adding a distinct behavioral detail: split, default target, gap handling, and mask semantics. There is no filler or repetition of schema 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?

Given no output schema and no annotations, the description should explain the return or score format; it only says 'score it on held-out data' without specifying what is returned. It also omits kind selection guidance and bin_s semantics. It is complete enough for basic invocation but not fully self-sufficient for an agent choosing among siblings or interpreting results.

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 compensates for target, mask, and train_fraction by explaining their semantics. However, it leaves kind (ridge vs kalman), bin_s, and session_id without added meaning, and bin_s in particular could affect how spike counts are assembled. The description adds value but does not fully cover a six-parameter tool with no schema descriptions.

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 opens with a specific verb and resource: 'Fit a decoder from spike counts to a behaviour signal and score it on held-out data.' This makes the tool's core purpose clear and distinct from plotting or firing-rate tools. It does not explicitly name or contrast sibling tools such as evaluate_cross_session or decode_window, 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?

The description gives clear operational context: training on the first train_fraction and testing on the remainder, with target and mask fallback behavior. However, it never states when to prefer this tool over evaluate_cross_session, decode_window, or other siblings, nor does it give when-not-to-use guidance. The intended use is implied rather than explicit.

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 behavioral burden. It discloses key behaviors: GPFA returns denoised single-trial trajectories and a timescale per factor, PCA is fast but noisier, the fit produces variance_explained_per_factor, and velocity-like signal explanation is reported when present. This is strong behavioral context, though exact output structure and side effects are not spelled out.

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 well-structured: it states the purpose, contrasts the two methods, gives dimensionality-selection guidance, and names the follow-up plotting tool. Each sentence earns its place, and the core operation is 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?

The description provides a solid high-level workflow and names a key output field, but for a 9-parameter tool with no annotations and no output schema, it omits important operational details such as how parameters like event, group_by, bin_s, and t_before/t_after affect the fit. It is minimally viable but not complete.

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 the description must compensate for undocumented parameters. It adds meaning for 'method' by comparing gpfa vs pca, but leaves bin_s, event, units, t_after, group_by, t_before, n_factors, and session_id effectively unexplained. 'Trial-aligned' hints at event timing but does not clarify t_before/t_after or bin_s.

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 opens with a specific verb and resource: 'Fit low-dimensional latent factors to trial-aligned population activity.' It also names the two methods (GPFA and PCA) and explicitly differentiates this fitting tool from the sibling plotting tool plot_latent_factors by saying that tool 'draws the trajectories.'

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 gives practical usage guidance: choose GPFA for denoised trajectories or PCA for a fast baseline, use the elbow in variance_explained_per_factor to judge dimensionality, and then call plot_latent_factors to visualize. It does not explicitly state when not to use this tool versus other analysis siblings like fit_decoder, so it stops just short of full exclusion guidance.

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 present, so the description must carry the behavioral burden. It implies a read/compute operation but never states that it is non-mutating, what data it requires, or what happens with t1=null. It also omits side effects, performance considerations, and error behavior.

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 redundant wording. It is concise, though brevity is achieved by omitting important details like output shape and parameter units.

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 tool with no output schema and no annotations, the description must be self-sufficient. 'Population firing-rate summary' does not tell an agent what the response contains, what units are used, or how the time range relates to session timestamps, leaving too much to guess.

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?

With 0% schema description coverage, the description must compensate. It does clarify that t0/t1 form a time range and that the default is the whole session, but it leaves units unspecified, does not explain session_id, and never states how t1=null is interpreted.

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 identifies a get operation on population firing rates over a time range, which is reasonably distinct from siblings like get_psth and plot_psth. However, 'summary' is vague—it does not specify whether this returns mean firing rate, spike counts, or a rate across neurons over time bins.

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 only usage hint is that the time range defaults to the whole session, which implies t0/t1 are optional. There is no explicit statement of when to choose this tool over get_psth or list_dataset_files, nor any prerequisites such as prior spike sorting or session opening.

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 must carry the burden; it discloses that labels are 'where known' (partial data possible). It does not say whether the call has side effects, how missing contacts are represented, or how max_rows affects results, so transparency is only partial.

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 short sentences, no filler or schema repetition; the content sentence is front-loaded and the usage note earns its place.

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 two-parameter getter this is minimally viable: it says what is returned and how to use the output downstream. But with no output schema, no param descriptions, and no note on max_rows, there are clear gaps for an agent that needs to interpret the response.

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%, and the description does not mention session_id or max_rows; the only parameter-ish term is 'channel', which refers to output, not an input. The description adds no meaning to either input parameter.

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 identifies the returned resource as probe contact geometry and brain-area labels per channel, and the 'where known' qualifier sets scope. It does not explicitly contrast with plot_probe or set_probe_geometry, but the data-vs-plot/set distinction is clear enough.

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 second sentence gives an explicit downstream usage: feed returned channel indices into the units argument of get_psth / fit_latent_factors to analyze one area. It does not state when not to use this tool or name alternatives, but the context is clear.

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 behavioral burden. It discloses meaningful non-obvious behaviors: the default `event` is movement onset, `units` restricts analysis and result unit numbers index into the supplied list, and the return includes the population time course, its peak, and the units that change most. This is strong behavioral disclosure for a read-only analysis tool; nothing contradicts annotations.

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: it defines the term first, then explains the key parameters, then states the return contents. It is slightly dense, but every sentence adds information and there is no filler or repetition of schema defaults.

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 tool with 7 parameters, no annotations, and no output schema, the description covers the central analytical concepts and return contents well. However, it omits explanations of the time-window parameters (`t_before`, `t_after`, `bin_s`) and gives only a high-level summary of the output, leaving some room for misinterpretation despite the self-explanatory parameter names.

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?

Since schema description coverage is 0%, the description must compensate, and it does for the most non-obvious parameters: `event` refers to session event columns, `group_by` uses session group columns, and `units` has special indexing behavior. However, `bin_s`, `t_before`, `t_after`, and `session_id` receive no semantic explanation beyond their names and defaults, so a substantial portion of the parameters remains underdescribed.

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 identifies a specific operation: computing a peri-stimulus time histogram of firing aligned to a trial event and averaged over trials. It also indicates what is returned (population time course, peak, most-changing units), which helps separate computation from plotting siblings like plot_psth. It could more explicitly distinguish itself from get_firing_rates, but the core purpose is unambiguous.

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 gives useful parameter guidance, such as how `event`, `group_by`, and `units` affect the analysis, and why per-unit analysis matters when population tuning cancels out. However, it never explicitly tells an agent when to choose this tool over alternatives like plot_psth or get_firing_rates, so selection guidance is only implicit.

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 of behavioral disclosure. It lists returned metadata fields but does not explicitly state that the operation is read-only, has no side effects, requires special permissions, or how errors are handled. 'Metadata' only weakly implies safe, non-mutating behavior.

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, front-loaded sentence that immediately states the resource and then lists specific metadata fields. There is no filler, repetition, or irrelevant 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?

For a single-parameter metadata getter with no annotations and no output schema, the description partially suffices by listing expected content. However, it omits output shape, types/units, error behavior, and any prerequisites, which are more important given the absence of structured metadata.

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 the description must compensate by explaining session_id. It only says 'a session' without clarifying that session_id identifies the specific session whose metadata is returned. The parameter's meaning is left to the schema title and tool name.

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?

Description identifies the resource (a session) and enumerates concrete metadata fields (duration, channels, sampling rates, behaviour signals, licence, citation), which distinguishes it from siblings like get_signal_quality. It lacks an explicit verb, but the tool name supplies 'get' and the noun-phrase description is unambiguous.

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 use case is implied: call this tool when you need metadata about a session. However, it gives no explicit when/when-not guidance and does not contrast with related tools such as open_session, close_session, or get_signal_quality, leaving selection to 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 transparency burden. It does disclose that this is a snippet-scoped read operation capped at 10 s and enumerates the signal-quality metrics, so an agent can predict the core behavior. However, it does not cover session prerequisites, error behavior, or return structure, which are relevant for a raw-data analysis 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?

A single succinct, front-loaded sentence contains all the high-level information with no filler or redundancy.

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 tool with no annotations and no output schema, the description provides only the output categories and a duration cap; it is missing the meaning of t0, how session_id relates to an open session, and what response shape to expect. This is enough for a rough guess but not a fully informed call.

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 compensate. 'max 10 s' clarifies the intended value of duration_s, but t0 is not explained and session_id is only recoverable from its name; no relationship between t0 and the snippet is given.

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 names specific outputs (noise level, SNR, dead/noisy channels) and the data source (a broadband snippet), which differentiates it from spike-sorting and decoding siblings. The operative verb is only implied by 'get', so it is clear but not maximally 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?

It implies the appropriate use case—checking quality on a snippet when noise/dead channels need assessment—and the 'max 10 s' bound sets a duration constraint. It does not state when to prefer another tool or mention exclusions, leaving alternatives to 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 burden and does disclose the status aspects it reports: buffered data, data arrival, and drops. However, it does not explicitly state that the operation is read-only, what happens for non-live sessions, or the format/units of the reported values.

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 tight clause with no filler. The 'For a live session' opener front-loads the most important context, and every word contributes to describing the tool's purpose.

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 one-parameter getter with no output schema, the description covers the main return concepts but omits parameter explanation and usage guidance relative to similar sibling tools. It is minimally viable but leaves an agent to infer important details about session_id and alternatives.

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 0% description coverage and only provides 'Session Id' as the title for session_id. The description's mention of 'a live session' gives some context, but it never directly explains that session_id is the identifier of the live session to query, nor how to obtain it.

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 what is reported for a live session: buffered signal amount, whether data is still arriving, and drops. This distinguishes it from siblings like get_signal_quality, though it lacks an explicit action verb, relying on the tool name 'get'.

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 phrase 'For a live session' implies when the tool is applicable, but there is no explicit guidance about when to use this versus alternatives such as get_signal_quality or get_session_info. No exclusions or alternative routing are provided.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It hints that the output includes file paths usable with open_session, but it does not state that the operation is read-only, how limit or version affect results, or what the response contains beyond vague file categories.

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 short and avoids verbosity, but it is awkwardly structured: the first sentence is a fragment and the second sentence discusses open_session rather than this tool's own invocation. It is economical but not optimally front-loaded or focused.

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?

With three parameters, no annotations, and no output schema, the description needed to provide substantial context, but it only gives a loose file-category summary and one cross-tool pointer. Parameter semantics, return shape, and practical invocation details are missing, so an agent cannot confidently call 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?

Schema description coverage is 0% and the description never explains dandiset_id, limit, or version. An agent cannot infer the expected ID format, defaulting behavior, or how version controls the listing. The description does nothing to compensate for the undocumented 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 names the resource (DANDI dataset) and the specific file categories (licence, citation, NWB files), which gives a clear sense of what the tool returns and distinguishes it from siblings like list_sources or search_datasets. It lacks a main verb and relies on the tool name for the 'list' action, so it is clear but not fully 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?

There is no statement of when to choose this tool over the list_sources, search_datasets, or open_session alternatives. The second sentence only tells the caller to pass a file path to open_session afterward, which is downstream guidance rather than selection 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 transparency burden. It does disclose that the tool scans the local network and requires the lsl extra, but it does not mention that it waits up to wait_s, what happens when no streams are found, or what the returned data looks like.

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?

One short sentence with no filler; the key subject and constraint are 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?

For a tool with one optional parameter and no output schema, the description is near-minimal. It names the resource, but omits wait_s semantics, output shape, and any disambiguation from sibling stream-related tools, so an agent is left to guess those details.

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 is one optional parameter (wait_s) and schema description coverage is 0%, so the description needed to explain it. It provides no information about wait_s; the agent can only infer meaning from the property name and default. This is a clear gap.

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 action ('list') and resource ('Lab Streaming Layer streams') with a clear scope ('visible on the local network'). It doesn't explicitly contrast with sibling tools such as list_sources or get_stream_status, so some disambiguation is left to the name.

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 phrase 'needs the lsl extra' gives a prerequisite signal, and the overall purpose implies use when the agent wants to discover active LSL streams. However, it never states when to prefer this over sibling tools 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?

No annotations are provided, so the description carries the full burden. It indicates a non-destructive list operation and previews the output contents, but it does not mention error conditions, permissions, or whether the list is static or dynamically discovered. This is adequate but not rich.

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 sentence that is front-loaded with the main action and contains no redundant wording. Every phrase adds useful information about scope or output content.

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-argument discovery tool, the description covers the purpose and gives a reasonable indication of the return content. It would be slightly more complete with an example status value or clarification of what 'parameters' includes, but the low complexity makes this definition sufficient for correct invocation.

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 the schema description coverage is 100%, so the schema fully captures all input requirements. The mention of 'parameters' in the description refers to the output information about source types, not input arguments, so no additional input semantics are 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 uses the specific verb 'List' with the resource 'data source types this server can open' and states the returned information (parameters and status). This clearly differentiates it from sibling tools like list_dataset_files and list_lsl_streams, though it does not explicitly name those alternatives.

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 wording implies this tool should be used when an agent needs to discover what data source types the server supports. However, there is no explicit guidance about when not to use it or which sibling should be preferred in related cases, leaving usage selection partly to 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 burden of behavioral disclosure. It mentions the return values and parameter override behavior, but does not disclose side effects of opening a session, whether resources are held, authentication needs, or the need to close the session to clean up.

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-sentence description is tight and front-loads the main action and return value. The second sentence adds a meaningful parameter detail without padding.

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 tool that opens a session in a larger pipeline, the description is incomplete: it doesn't mention lifecycle (close_session), whether opening is required before other tools, or what metadata is returned. It leaves the agent to infer important operational context.

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 compensate. It does clarify that params overrides the source's defaults and directs the agent to list_sources, but it does not explain the source parameter's possible values or how params maps to options.

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 names a clear verb ('open') and resource ('recording session') and states the return value (session_id and metadata). It doesn't explicitly contrast with siblings like close_session or get_session_info, but the action is distinct enough.

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 says params overrides source default_params and points to list_sources, which implies how to set up a session. However, it doesn't say when opening is appropriate, whether it is a prerequisite for other tools, or when to prefer close_session/get_session_info instead.

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 burden. It discloses the max 60 s window constraint and the prerequisite, which is useful. However, it doesn't mention whether the plot is displayed or saved, or any side effects, but for a plotting tool this is acceptable.

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, front-loaded with the core purpose, then prerequisite and usage guidance. Every sentence earns its place.

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 plotting tool with 3 simple params, the description covers purpose, prerequisite, and window selection. It lacks explicit return/output info, but plotting tools typically display figures, and the output schema is absent. The max 60 s constraint is mentioned, which is key.

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 the description must compensate. It explains t0 and duration_s implicitly via 'window (max 60 s)' and mentions session_id contextually. However, it doesn't explicitly map each parameter to its meaning, leaving some ambiguity about duration_s default and max.

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 plots decoded values against actual behavior for a window, with one panel per dimension. It distinguishes itself from siblings like decode_window (which likely returns values) and plot_psth/plot_raster (which plot other data types).

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?

Explicitly states the prerequisite 'Requires fit_decoder first' and gives guidance on window selection ('Pick a window in the test split for an honest picture'). This tells the agent when to use it and what to check before calling.

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 burden of behavioral disclosure. It discloses the exact plot contents, visual styling (single trials thin, group means bold), and the dependency on a prior fit. It does not discuss errors or side effects, but as a plotting tool this is a reasonable and transparent summary.

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, front-loads the figure contents, and adds the key prerequisite in a single short final sentence. Every sentence earns its place with no filler or redundancy.

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 description covers what the figure contains and the necessary prerequisite, which is good for a plotting tool. However, with no annotations, no output schema, and no explanation of max_trials_drawn, there are gaps that leave the agent to infer parameter semantics and some usage details.

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 does not explain either session_id or max_trials_drawn. The description's mention of 'single trials' only indirectly relates to max_trials_drawn, and no parameter-level semantics are provided.

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 what the tool produces: a figure with latent factors over time, the first-two-factor trajectory, and variance explained. It does not explicitly differentiate from siblings, though 'Requires fit_latent_factors first' signals it is the post-fitting visualization counterpart.

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 gives clear usage context by requiring fit_latent_factors to have been run first, which is critical for correct ordering. It does not mention alternative tools or exclusion cases, but the prerequisite is a strong and useful guideline.

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 of behavioral disclosure. It honestly states the geometry dependency and the condition that sorted units are marked only after a sort has been run, but it does not mention response/return behaviour or confirm that the tool has no side effects.

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, with the main figure content front-loaded and the prerequisite in a short second sentence. The only minor issue is the awkward 'Figure:' lead-in, but there is no filler or redundancy.

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 straightforward plotting tool, the description covers the displayed content, time window, conditional marking of sorted units, and the geometry prerequisite. It leaves out session-open requirements and explicit mapping of t0/duration_s, which is a gap but not a severe one given the tool's simplicity.

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 the description should compensate, but it only vaguely refers to 'a window' without naming t0 or duration_s, and it never clarifies session_id. The description adds some conceptual meaning but fails to properly explain the three parameters.

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 names a specific output, the array map with contacts coloured by firing rate, and adds detail about area labels and sorted units. This makes it distinguishable from plotting siblings like plot_raster or plot_psth, though it never explicitly states the plotting action or names an alternative.

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 when to use this tool, namely to visualise probe firing rates on an array map, and gives a clear prerequisite: geometry must exist or be set via set_probe_geometry. It does not provide explicit when-not-to-use guidance or compare against plotting alternatives.

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. It discloses the return value ('Returns the PNG path and the image') and the figure composition. However, it does not mention side effects like saving a file to disk, whether it displays the figure, whether it overwrites existing files, or whether an open session is required. This is a moderate disclosure gap for a plotting tool without annotations.

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 compact two-sentence structure: the first sentence describes the figure content, the second states arguments and return value. There is no filler, redundant phrasing, or repetition of schema details. The key information is front-loaded, making it easy for an agent to scan.

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 description explains the return value and the general figure layout, which covers some essentials. However, with no output schema,nor annotations, and 7 parameters all undocumented, the description is incomplete for an agent that needs to correctly set arguments like group_by, units, or event. The cross-reference to get_psth is a partial mitigation but does not make the tool self-contained.

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?

With schema description coverage at 0%, the description must compensate for parameter meanings, but it only says 'Same arguments as get_psth.' This cross-reference does not explain any of the seven parameters (bin_s, event, units, t_after, group_by, t_before, session_id) and adds no semantic value over the bare schema titles. If get_psth's own description is well-documented, the reference could help, but on its own this is insufficient.

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's output: a figure combining a population PSTH per group (mean ± SEM) with a unit-by-time heatmap of change from baseline. This lets an agent distinguish it from siblings like plot_raster or plot_probe, though it lacks an explicit verb like 'plots' (only the tool name implies the action).

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 gives some context by stating 'Same arguments as get_psth,' implying this tool is the plotting counterpart of get_psth)Skip this. It does not explicitly state when to prefer this over alternatives such as plot_raster or plot_latent_factors, nor does it provide any when-not-to-use conditions. The use case is inferable from the figure description but not made explicit.

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 of behavioral disclosure. It usefully reveals the 60-second limit and the shaded unrecorded spans, but it does not state whether the figure is displayed or returned, whether the session must be open, or any side effects such as writing files.

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 short, front-loaded, and contains no filler or redundant phrasing. It earns its place with two concrete details, though it is arguably too sparse for the parameter coverage gap.

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 4-parameter plotting tool with no output schema and no annotations, the description omits parameter meanings, return/output behavior, and when to prefer this plot over sibling plotting tools. An agent would need to inspect the schema and other tools to use it confidently.

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 the description needed to explain what session_id, t0, duration_s, and max_units mean. It only implies a time window via 'max 60 s', offering essentially no parameter-level semantics.

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 identifies a spike-raster figure for a time window and uniquely mentions that unrecorded spans are shaded, which distinguishes it from sibling plot tools like plot_psth or plot_decoding. It is specific about what is plotted, though it uses the noun 'Figure:' rather than an explicit verb.

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?

There is no guidance about when to use plot_raster instead of plot_psth, plot_decoding, plot_probe, or other plotting siblings. No prerequisites, session requirements, or alternative-selection criteria are provided.

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 behavioral disclosure burden. It adds one useful behavioral fact—that an empty query yields a curated list of intracortical datasets—which goes beyond the schema. However, it does not state whether the operation is read-only, how limit affects results, or what format the returned datasets take.

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 two short sentences with no filler. The purpose is front-loaded, and the empty-query detail earns its place because it is a meaningful behavioral clarification.

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 is simple, but with no output schema the description should hint at what a typical search returns. It clarifies only the empty-query case, not the behavior of non-empty queries or the role of limit. For an agent embedded in a workflow with many related tools, this is adequate but not complete.

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 the description must compensate for both parameters. It partially explains query by describing the empty-query behavior, but it says nothing about the limit parameter beyond the default value already in the schema. This leaves a significant semantic gap.

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 a specific verb ('Search') and a specific resource ('DANDI Archive datasets'). It also adds a distinctive behavior for empty queries, which helps differentiate it from sibling tools like list_dataset_files that deal with files rather than datasets.

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 when to use the tool (searching for datasets) and even gives a usage hint for the empty query case. However, it never mentions any sibling tools or exclusions, so an agent receives no explicit guidance on when to prefer this over list_dataset_files or other alternatives.

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 behavioral burden. It adds useful behavioral detail: contacts under 100 um apart are sorted jointly, positions are interpreted in channel order, and geometry feeds downstream tools. It does not disclose side effects, persistence, overwrite behavior, or response value for this setter, so it is adequate but not rich.

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 one compact paragraph, starts with the core purpose, and every sentence adds semantics: layout names, parameter mapping, downstream effects, and proximity sorting. There is no filler or repetition of schema defaults.

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 5-parameter configuration tool with no output schema and no annotations, the description supplies the needed layout, parameter, and prerequisite context. It does not mention how to overwrite or clear geometry or what the response is, but those are secondary for invoking this setter correctly.

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 the description must explain the parameters, and it does: it maps each layout enum value to its relevant inputs ('grid' needs n_columns, 'linear' uses pitch_um, 'explicit' takes positions_um in [[x, y], ...] channel order). Only session_id is left to the schema, where its required status is self-evident.

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 first sentence names a specific action ('Tell the server where... contacts are') and the target resource ('the recording's contacts'), with a clear condition ('for sessions whose file does not say'). It stands apart from siblings like get_probe and plot_probe because it is about setting geometry rather than retrieving or visualizing it.

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 gives a clear condition for use ('for sessions whose file does not say') and notes downstream consumers ('Geometry is used by sort_spikes and plot_probe'). It stops short of explicitly naming alternatives or saying when not to use it, but the context is strong enough for an agent to route correctly.

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. It discloses a meaningful side effect (spike times become the sorted units restricted to the window), explains how probe geometry changes sorting behavior, and gives a runtime expectation. It stops short of stating whether existing spike/unit data is overwritten or describing error/failure modes.

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: the main operation and prerequisite come first, followed by the side effect, geometry behavior, and performance expectation. Every sentence adds useful information and there is no filler.

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 five-parameter tool with no annotations and no output schema, the description covers the core operation, side effects, and dependencies well. However, it leaves several parameter semantics (t0, sorter, channels) to be inferred from schema titles/defaults, and it does not describe what the tool returns or how success is communicated.

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 the description must compensate, but it only loosely references 'duration and channel count' and 'window.' It does not explain t0, sorter choices, channels, or session_id semantics beyond what the schema titles/defaults/enum already show. This is only partial compensation for a low-coverage 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 a specific verb ('Spike-sort') and resource ('broadband window'), and clearly states the outcome: session spike times become sorted units restricted to that window. It does not explicitly distinguish itself from siblings like detect_spikes, though the sort-vs-detect distinction is largely implicit.

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 gives clear usage context: it requires the sort extra, relies on probe geometry (optionally set via set_probe_geometry), and produces sorted units that downstream analyses like PSTHs, rasters, and decoders will use. It does not name explicit alternatives or when-not-to-use conditions, but the prerequisites and downstream role are clearly stated.

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