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

With no annotations, the description carries the full behavioral burden, yet it discloses almost nothing beyond the operation name. It does not say that plot=true likely writes plot artifacts to disk, what the profile output looks like or where it goes, or whether the target file must already exist — the plot default of true is a side effect left unexplained.

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 waste; scope is stated immediately. It is efficient, though its brevity comes partly at the cost of the missing detail noted elsewhere.

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 tool that produces plots (default on) and involves regression, the description is too thin: no output-schema exists to fill the gap, so what is returned, how max_columns truncates, and what the plotting side effect does are all left unspecified.

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 schema documents none of the 4 parameters. The description only loosely implies 'target' (regression) and 'plot', leaving 'path' and 'max_columns' (a truncation/performance control) entirely unexplained in both places.

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?

'Profile a CSV file' gives a clear verb+resource, and the colon-list ('numeric summaries, correlations, optional target regression and plots') specifies the scope precisely. It does not explicitly distinguish itself from close siblings like describe, describe_file, correlation, or linear_regression, which it arguably bundles.

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 when-to-use or when-not-to-use guidance is given. Since siblings such as describe, describe_file, correlation, and linear_regression overlap heavily with this tool's capabilities, an agent gets no signal for choosing this bundled profiler over the narrower tools.

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 does add genuine value by disclosing that '@<path>' file references are NOT supported for groups (a constraint the schema does not express) and by listing the returned statistics, but it says nothing about assumptions, error behavior, or the shape of the result payload.

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 paragraphs, front-loaded with the operation and its returns, with the parameter constraint called out separately. No filler, though the '@path' note could be tightened.

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 statistical test with no output schema, the description covers inputs and returns adequately but omits the assumptions and alternative-selection context an agent needs to call the right test. It is viable but leaves clear gaps.

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% — the schema only supplies a bare title 'Groups' — so the description must compensate, and it does: it explains that groups is a nested list of samples and explicitly rules out '@<path>' file references, which is exactly the kind of constraint an agent would otherwise guess wrong.

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+resource ('Run a one-way ANOVA') and even names the returned statistics (F statistic, p value, degrees of freedom), so the operation is unambiguous. It does not, however, differentiate itself from near siblings such as t_test or chi2_test, which is the only thing keeping it from a 5.

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 when-to-use guidance at all — nothing tells the agent to prefer this over t_test when comparing more than two group means, or what assumptions (normality, homoscedasticity) apply. The usage is only implied by the tool name.

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 usefully discloses validation constraints not present in the schema ('forecast_steps' 0..10000, 'conf_alpha' in (0,1)), but says nothing about return values, model-fitting behavior, or failure modes for a compute 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 purpose in the first sentence, then adds input-format and constraint details. Every sentence earns its place, though the constraint sentence could be slightly tighter.

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 no output schema, no annotations, and 5 parameters, the description is only partially complete. It covers the series input and two constraints but omits the meaning of 'order'/'seasonal_order' and any indication of what a fit or forecast returns.

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 clarifies the non-obvious 'series' input (inline list vs '@<path>' file reference) and bounds two numeric params, but leaves 'order' and 'seasonal_order' entirely unexplained despite their being the core ARIMA specification (p,d,q).

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: 'Fit an ARIMA model and optionally forecast.' An agent can immediately tell this is ARIMA-specific modeling rather than generic forecasting. However, it does not explicitly differentiate itself from the sibling 'forecast' tool, so it falls short of a 5.

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

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

There is no guidance on when to use this versus alternatives like 'forecast', 'time_series_decompose', or 'stationarity_test'. The 'optionally forecast' phrase implies a use case but no conditions, prerequisites, or exclusions are stated.

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 behavioral burden. It states only what the test does; it does not disclose assumptions (e.g. expected frequency requirements), default handling of the optional expected parameter, or what the test returns.

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 wasted words. It efficiently communicates the tool's scope and the two main variants.

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 statistical test with no annotations, no output schema, and 0% schema description coverage, the description is too sparse. It omits parameter meaning, assumptions, and result interpretation, leaving an agent with insufficient context to call it correctly beyond the basic test name.

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. It hints at data dimensionality for observed but says nothing about the expected parameter, its optional/null default, or the distinction between observed and expected arrays.

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 ('Run') and resource ('chi-square goodness-of-fit test' or 'independence test'), and clarifies the two data-shape variants (1-D vs 2-D table). It does not explicitly differentiate from sibling statistical tests, but the test name itself is 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 when each variant applies by noting 1-D for goodness-of-fit and 2-D table for independence. However, it gives no explicit when-to-use versus alternatives and no exclusions, so the 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?

With no annotations, the description carries the full behavioral burden. Referencing numpy.convolve implicitly conveys standard convolution semantics, but the description says nothing about how the 'mode' affects output length, performance characteristics, or what is returned.

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. It is appropriately sized for a one-line operation, though brevity here shades into under-specification rather than elegance.

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 3-parameter tool with no annotations and no output schema, the description is too thin: it omits the accepted input forms, the meaning of 'mode', and any hint about the returned result. An agent could not reliably invoke it beyond the most literal case.

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 there are three parameters, so the description must compensate. It explains none of them: 'mode' is undocumented (no full/same/valid values), and the fact that signal1/signal2 accept either arrays or strings (implying identifiers or paths) is left entirely unexplained.

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 gives a specific verb ('Compute') and resource ('discrete convolution of two signals') and anchors it to numpy.convolve, so the agent knows the exact operation and library semantics. It does not, however, differentiate itself from adjacent siblings such as filter_signal or fft_analysis.

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 when-to-use guidance, no mention of alternatives (e.g., using FFT-based convolution via fft_analysis for large signals), and no stated preconditions. The agent must infer applicability from the name alone.

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 usefully discloses that x and y accept an inline array or an '@<path>' file reference, which is real behavioral context, but says nothing about length-matching requirements, handling of ties/missing data, or output format.

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

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

Two short sentences, front-loaded with the core purpose, with zero filler. The input-form note is the only additional detail and it 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 3-parameter compute tool with no output schema, the description adequately conveys what is computed (a coefficient and a p value). It omits validation expectations (equal-length inputs) and the return structure, but these are minor for a pure statistical computation.

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 clarifies the dual input form for x and y (inline vs '@<path>'), which the schema does not, and its method list implies the accepted method values. However, it never explicitly maps the three method names to the 'method' parameter or notes the 'pearson' default, leaving a 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 (Compute) and resource (correlation coefficient and its p value) and enumerates the exact supported variants (Pearson, Spearman, Kendall). This clearly distinguishes it from siblings like t_test, anova, and linear_regression.

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 such as linear_regression, and no guidance on which of the three methods to pick or under what conditions. Usage is only implied by the tool's name.

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 and does add real domain constraints: formula holds covariates only, data accepts a mapping or '@path.csv' reference, event indicators must be 0/1, durations must be positive. However, it says nothing about return values, convergence behavior, or failure modes, leaving notable gaps.

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 operation is front-loaded in the first sentence, followed by tightly scoped clarifications of formula, data, and input constraints. No filler sentences; each line adds 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 4-parameter statistical tool with no annotations, 0% schema coverage, and no output schema, the description covers inputs adequately but omits what the tool returns (coefficients/hazard ratios), error handling, and how duration_col/event_col are supplied. Adequate but with clear gaps.

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, and it does so well: it clarifies the formula's scope (covariates only, with an example), the accepted data formats, and the value constraints for the event and duration inputs. It never names duration_col/event_col explicitly, but the constraints clearly map to them.

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 and resource — fitting a Cox proportional hazards regression via statsmodels PHReg — which is a distinct statistical model among siblings like linear_regression, glm, and kaplan_meier. It does not, however, explicitly differentiate itself from related survival/modeling siblings.

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 on when to use Cox PH regression versus alternatives such as kaplan_meier (non-parametric survival) or glm, nor any prerequisite context. The agent must infer usage purely from the model name.

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 states what the tool computes but omits critical context such as whether the computation is symbolic or numeric, what the return value looks like, and any assumptions about the input field or variables.

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 with no wasted words. It is appropriately concise for the core action, though its extreme brevity leaves important details unsaid.

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 required, undocumented parameters, no annotations, and no output schema, the description is incomplete. It does not explain how to structure inputs or what to expect as output, leaving the agent with insufficient information to invoke the tool 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 two required parameters. It provides no information about the expected format of 'field' (e.g., list of component expressions) or 'variables' (e.g., list of variable names). The parameters are entirely undocumented.

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 ('compute') and resource ('curl') with scope ('3-dimensional vector field'). It clearly identifies the operation, but does not differentiate from sibling vector-calculus tools like divergence or gradient, so it falls short of a 5.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no conditions or exclusions. The agent is left to infer that this is the right tool for curl calculations based solely on the name and one-line purpose.

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 and no output schema, the description carries the full behavioral burden and mostly does not meet it. It does not say what is returned (fitted parameters, covariance, residuals), what happens on non-convergence, what default p0 is used, or which scipy method is selected — all things an agent needs before calling a numerical optimizer.

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 well-formed sentence with the core action front-loaded and no filler. Nothing in it is redundant or 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 5-parameter numerical tool with zero schema documentation, no annotations, and no output schema, the description is far too thin. It omits return values, convergence/error behavior, the meaning of the string-accepting data parameters, and the default initial-guess behavior, leaving the agent under-informed for a nontrivial 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 description coverage is 0%, so the description must compensate, and it only clarifies 'model' as a sympy-parsed expression. Nothing explains p0 (initial guess), param_names, or why xdata/ydata accept strings in addition to numeric arrays — the string variant is completely opaque.

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?

Names a specific operation (least-squares curve fitting) plus the exact engines involved (scipy.optimize.curve_fit with a sympy-parsed model expression), which is more specific than a generic 'fit' verb. It does not, however, distinguish itself from nearby siblings such as linear_regression, nonlinear_mixed_lm, global_optimize, or optimize_minimize, so an agent must infer the boundary.

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 over linear_regression, global_optimize, interpolate_1d, or optimize_minimize, nor any prerequisite or constraint. The only implicit signal is that the model is a sympy expression, which hints at nonlinear parametric fitting but is not framed as 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?

With no annotations and no output schema, the description carries the full burden; it does disclose the exact return set (mean, sample std, quartiles, skew, kurtosis), which is genuinely useful. It says nothing about how the alternative string form of the input is interpreted, how missing values are handled, or what happens with empty/constant samples.

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 sentence, no filler, with the statistic list embedded where it is most useful. Nothing could be cut without losing 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?

Return values are covered, but for a tool with no annotations, no output schema, and an ambiguous anyOf input, the definition leaves the input contract undefined. An agent could call it with a wrong string form and have no way to know.

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 single parameter is an anyOf of number-array or string, so the schema alone leaves real ambiguity. The description never clarifies whether the string is a file path, a column name, or delimited values, so it fails to compensate for the coverage 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 (Return) and resource (descriptive statistics) and enumerates exactly which statistics are produced, which is more informative than most sibling stats tools like 'distribution' or 'correlation'. It does not, however, differentiate itself from the near-named sibling describe_file, leaving an agent to guess whether this expects raw data or a file.

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 sample' hints at the intended input, but there is no explicit when-to-use guidance, no prerequisites, and no routing to alternatives such as describe_file, distribution, or analyze_dataset. The agent gets no help choosing this over its several overlapping siblings.

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 disclosure burden. It does not state what statistics or summary is returned, whether the operation is read-only, what happens for missing/non-numeric columns, or any file-size/parsing caveats.

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 with zero filler, and the core scope ('one numeric column') is front-loaded. It is appropriately sized for a short description.

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 file-parsing/statistics tool with no annotations, no output schema, and 0% parameter documentation, the description is far too thin. An agent lacks enough information about column selection, return values, or supported behavior to call 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 must compensate. It only vaguely mentions 'one numeric column' and file types, but never explains that 'column' accepts a name or index, what happens when it is omitted (default null), or what the required 'path' should point to.

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 ('Describe') and resource ('one numeric column of a CSV/TSV/TXT/JSON/NPY file'), which is more precise than the generic sibling 'describe'. However, it does not differentiate itself from that sibling, leaving an agent to guess which one to use.

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 'describe', 'distribution', or 'analyze_dataset'. The only implied usage is inferring from file formats, which is weak context.

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 behavioral burden, yet it discloses almost nothing: no return format, no side effects, no error behavior, no explanation of how 'fit' differs from evaluation. 'By attribute name' is the only real behavioral hint.

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 wasted words. It is efficient, though arguably too terse for a 7-parameter tool.

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 7-parameter tool with 0% schema coverage, no annotations, and no output schema, the one-sentence description is far from complete. An agent cannot determine valid operations, parameter roles, or return values from this definition alone.

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% across 7 parameters. The description hints at the meaning of 'operation' (pdf/cdf/ppf/rvs/fit) and 'dist' (attribute name), but leaves n, x, data, seed, and params entirely undocumented in both schema and description.

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 clear verb+resource: evaluate (pdf/cdf/ppf/rvs) or fit a scipy.stats distribution. The named operations and 'by attribute name' give a reasonably precise picture of what the tool does, though it does not contrast itself with siblings like curve_fit or describe.

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 when-to-use, when-not-to-use, or alternative guidance. The description lists operations but never states which operation to choose under which circumstances or what prerequisites (e.g., data required for fitting, x required for pdf) apply.

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 supplied, so the description carries the full behavioral burden and does not meet it. It says nothing about whether the computation is symbolic or numeric, what form the result takes (a scalar expression vs. an evaluated grid), or how errors are surfaced.

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 or redundancy. It is efficiently written, though its brevity is partly under-specification rather than pure economy.

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 two-required-parameter math tool with no annotations and no output schema, the description omits the return type and the field/variable correspondence. An agent has no way to know the expected input shape beyond the bare array types.

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, and it only loosely maps 'vector field' and 'given variables' onto the two params. It never explains that 'field' is a list of component expressions or how its ordering relates to 'variables', which is essential for a correct call.

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+resource: 'Compute the divergence of a vector field'. The operation is intrinsically distinct from siblings gradient, curl and laplacian, so an agent can identify what it does. It does not explicitly contrast itself with those siblings, keeping it short of a 5.

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

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

No indication of when to choose this over curl, gradient or laplacian, and no prerequisites or operand-type expectations. Usage must be inferred purely from the mathematical name.

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 reveals that the solve is analytic and uses sympy.dsolve, but says nothing about return format, failure modes, assumptions, or whether the input equation must be in a specific syntax.

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 wasted words. The core purpose is stated immediately, and every clause (analytic solve, sympy.dsolve, optional ICs) 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 4-parameter solver with no annotations, no output schema, and 0% schema description coverage, the description is far too sparse. An agent lacks essential context about parameter meanings and expected input formats, making correct invocation uncertain.

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 vaguely alludes to initial conditions (the 'ics' parameter). The roles of 'x', 'y', and 'equation' are left entirely unexplained, and the expected format for equations and ICs is not 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 states a specific verb and resource ('Solve an ODE analytically') and names the implementation (sympy.dsolve). It is clear but does not distinguish the tool from sibling solvers such as symbolic_solve or find_roots, so it falls short of a 5.

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

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

The description offers no when-to-use guidance, no conditions for choosing this tool over alternatives like symbolic_solve or solve_ode, and no prerequisites. 'Optionally with initial conditions' is a capability, not usage 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does implicitly signal that inputs must be real-valued (a genuine constraint, since rfft is used), but it says nothing about the return structure, frequency binning, DC/Nyquist handling, or the effect of sample_rate — significant gaps for a spectral 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 front-loaded sentence with no filler; the purpose is stated immediately. It is efficient, though the extreme brevity is part of why other dimensions suffer.

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, no output schema, and 0% parameter documentation, the description is too thin. It should at minimum describe what is returned (frequency axis plus amplitudes), how units relate to sample_rate, and when to prefer power_spectrum or stft.

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 does so for 'signal' by declaring the real-signal requirement, but 'sample_rate' (with its default of 1) is never mentioned, leaving frequency scaling — a critical semantic — completely undocumented.

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 ('Compute'), a specific output ('single-sided amplitude spectrum'), and a specific input domain ('real signal'), and it even names the algorithm (numpy rfft). This distinguishes it reasonably well from power_spectrum and stft, but it never explicitly contrasts itself with those close siblings, so it falls short of a 5.

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

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

There is no statement of when to use this tool versus power_spectrum, stft, wavelet_transform, or filter_signal, all of which appear in the sibling list. No prerequisites and no exclusions are given; the agent must infer context entirely.

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. It does disclose two real traits beyond the schema: the filter family (Butterworth) and that it is zero-phase (filtfilt, i.e. non-causal, no phase shift) — meaningful for time-series work. However it omits edge/padding behavior, the minimum-length constraint filtfilt imposes, and that the operation is non-mutating.

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 plus a compact parameter block, front-loaded with the operation and method. Every clause carries information; nothing is 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 5-parameter, 4-required tool with no annotations and no output schema, the description covers the two error-prone arguments well but leaves signal's accepted forms, sample_rate's units, and order's effect unspecified. An agent could probably invoke it, but would be guessing on the signal input format and the sampling-rate convention.

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 and it partially does: it enumerates kind's four values and specifies cutoff's units (Hz) and shape (scalar for lowpass/highpass, [low, high] for bandpass/bandstop) — genuinely useful information no schema field provides. It says nothing about signal (array vs. string, i.e. literal path?), sample_rate's units or relationship to cutoff, or order (default 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?

States a specific verb and resource ('Filter a signal') and pins down the algorithm ('Butterworth design and zero-phase filtfilt'), which implicitly separates it from siblings like wavelet_denoise, convolve, stft, and fft_analysis. It stops short of naming any sibling outright, but the method detail is enough for an agent to route correctly.

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 never says when to pick this over wavelet_denoise, convolve, or a spectral method, nor does it state prerequisites or exclusions. The only usage signal is the parameter syntax for kind/cutoff, which is configuration rather than 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 provided, so the description carries the full behavioral burden. It says the operation finds local maxima and can filter by height, distance, or prominence, but it does not disclose return format, edge-case behavior, whether the signal string is a file path, or any other operational detail an agent would need before calling.

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, well-structured sentence with zero waste. The core action is front-loaded, and optional filters are clearly appended.

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 four parameters, no output schema, no annotations, and 0% schema description coverage, a one-sentence description is not enough. It omits parameter semantics, return behavior, and usage context, leaving significant gaps for an agent to fill.

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 names three of the four parameters (height, distance, prominence) without explaining their meaning, units, or how they filter peaks. The required 'signal' parameter is implied but its type ambiguity (array versus string) is not addressed.

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 gives a specific verb ('Find') and resource ('local maxima in a signal'), making the core function clear. It also mentions optional filtering criteria, but does not distinguish the tool from siblings like filter_signal or find_roots, leaving sibling differentiation to the agent.

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 explicit guidance on when to use this tool versus alternatives such as filter_signal, find_roots, or peak-related siblings. The presence of optional filters is noted but without context on when those filters matter or what problem they solve.

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 exist, so the description bears the full disclosure burden. It usefully reveals the method-selection logic (bracket vs x0) which is real behavioral context, but it is silent on convergence, failure behavior, or what happens when conflicting/missing method arguments are given.

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 zero filler. Every clause (root type, two methods, their triggering arguments) 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 5-parameter numerical tool with no annotations and no output schema, key information is missing: the expression syntax, the role of params and variable, and mutual exclusivity of bracket vs x0. An agent could invoke it but would be guessing on several required 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 coverage is 0% across all 5 parameters. The description explains the meaning of only bracket and x0 (method routing); it says nothing about expr syntax, params, or the variable default, leaving the majority of parameters undocumented in both schema and prose.

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 ('Find a scalar root of an expression') and even names the numerical methods (brentq, Newton's method), which distinguishes it from symbolic siblings like symbolic_solve. It does not explicitly contrast itself with symbol approach, 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 parentheticals imply the selection rule: supply a bracket to use brentq, supply x0 to use Newton's method. That is useful implied guidance, but it never says when to prefer this tool over symbolic_solve or optimize_minimize, nor any exclusion/precondition.

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 well on methodology: it discloses the default ARIMA order, how seasonal order is derived from seasonal_period, that exponential smoothing uses additive trend/seasonal components, and that ARIMA intervals are analytic while smoothing intervals are a normal approximation. It does not state what is returned (point forecasts plus interval bounds) or how errors are surfaced, which keeps it short of a 5.

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 core purpose and structured into method-specific details with no filler. Slightly dense in places, but every sentence adds substantive 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 6-parameter tool with 0% schema coverage, no annotations, and no output schema, the description should define the remaining parameters and the shape of the result. It covers method mechanics decently but leaves several inputs and the return value unexplained.

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 clarifies `order` (default [1,0,0]) and `seasonal_period` (drives seasonal order / seasonal component) well, but `steps`, `conf_alpha`, and especially `series` (array-of-numbers vs string) are left entirely undocumented in both schema and description.

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 action (forecast) and resource (univariate series) and enumerates the two supported methods plus their configuration. It is clear on its own, but it never differentiates itself from the sibling `arima` tool, which overlaps heavily with the ARIMA path described here.

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 explicit when-to-use or when-not-to-use guidance. The description explains how the two methods behave but never says when to prefer this tool over `arima`, `time_series_decompose`, or `stationarity_test`, nor what prerequisites (e.g., stationarity) apply.

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 exist, so the description carries the full behavioral burden. It does usefully disclose the two accepted data input forms, the validated categorical options for family and cov_struct (which the schema omits), and the return payload (population-averaged coefficients with robust SEs, z and p values). It does not address failure modes, weighting, or parameter estimation details.

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?

Three short paragraphs: purpose first, then input semantics, then return shape. Front-loaded and free of filler, with only minor reStructuredText backtick noise.

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 statistically non-trivial tool with no output schema, the description helpfully covers the return values and most input formats. However the required formula parameter is left completely undefined, and there is no output schema to fall back on, leaving a meaningful gap 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?

Schema description coverage is 0%, so the description must compensate, and it largely does: it explains data (mapping vs '@path.csv' reference), groups (clustering column), family (three allowed values) and cov_struct (three allowed values) — effectively supplying the enums absent from the schema. It omits any explanation of the formula parameter, which is required, so it falls short of full compensation.

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: 'Fit a generalized estimating equation model.' This is clearly distinguishable from generic regression siblings like glm or linear_regression, though the description never names those close alternatives (mixed_lm, glm) explicitly, so the differentiation is implicit rather than stated.

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 a GEE is the right choice versus glm, mixed_lm, or nonlinear_mixed_lm, which are the obvious neighbouring tools. The description only says what the tool does, leaving the selection decision entirely to the agent.

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 does add genuine behavioral context beyond structured fields: the accepted family values (schema declares family as an unconstrained string) and the fact that relative CSV paths resolve against output_dir(). However, it says nothing about what fitting returns, whether a model object or summary is produced, 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 purpose is front-loaded in the first sentence, followed by compact parameter clarifications. Two short paragraphs with no filler, though the trailing path-resolution note is parenthetical detail that could be tightened.

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 no output schema and no annotations, the description should say more about the result of a fit (coefficients, summary, diagnostics) and any modeling assumptions. It adequately covers input shapes but leaves the output side entirely unspecified for a moderately complex modeling operation.

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 fully documents family (enumerating six valid values absent from the schema) and data (two accepted forms: a {column: list} mapping or an '@<path>.csv' reference). But formula is only alluded to as 'a formula' with no syntax or dialect specified, leaving one of three required parameters unexplained.

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 (fit) and resource (generalized linear model) and identifies the required inputs (formula, data table). An agent can distinguish it from sibling regression tools by the model class, though the description never explicitly contrasts it with linear_regression or mixed_lm.

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 explains parameter formats but gives no when-to-use guidance, no prerequisites, and no indication of when to choose glm over siblings like linear_regression, mixed_lm, or gee. Usage is left entirely 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. It usefully discloses the variable-naming convention, per-method input requirements, and the params-injection behavior. It does not cover determinism (seed), convergence/failure behavior, or return shape, which matter for an optimizer.

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?

Short and front-loaded: the purpose leads, then three tight lines covering variable naming, method constraints, and params. Every sentence adds information with no 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 7-parameter tool with no annotations and no output schema, the description covers the inputs that affect correctness but is silent on return values, convergence/iteration reporting, and the role of seed and maxiter. Adequate but with clear gaps.

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 explains the semantics of x0, bounds, method, and params reasonably well, but leaves seed, maxiter, and objective unexplained beyond the generic 'scalar expression' phrase.

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: 'Minimize a scalar expression with a global optimizer.' The word 'global' implicitly distinguishes it from the sibling optimize_minimize, though the sibling is never named explicitly.

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 conditional guidance tied to `method` (DE/dual_annealing need finite bounds, basinhopping needs x0), which tells the agent what inputs are valid per choice. However, it never states when to prefer this tool over optimize_minimize or other optimizers, so alternative selection is left 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?

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether the result is symbolic or numeric, the return form (a vector of expressions), ordering of components, or any error behavior for non-scalar input. For a tool with zero annotation coverage this is a substantial gap.

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 well-formed sentence with the operation front-loaded and no filler. It is appropriately brief, though brevity here edges toward under-specification rather than genuine 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?

With no output schema, no annotations, and 0% parameter documentation, the description should explain the return value (component ordering, symbolic vs numeric) and input constraints. None of that is present, leaving an agent unable to predict the tool's output.

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, and it does partially: 'scalar expression' constrains the expr parameter and 'with respect to the given variables' explains the variables list. However, it adds no detail on expression syntax, whether variables must appear in expr, or ordering of the output, so it only partially covers the 2 undocumented params.

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 mathematical verb+resource ('compute the gradient of a scalar expression') and names the inputs it operates on. An agent can distinguish it from laplacian/divergence/curl by the operator name alone, but the description never explicitly routes among these sibling operators, so it falls short of a 5.

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

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

There is no guidance on when to choose gradient versus the many adjacent symbolic/vector-calculus siblings (laplacian, divergence, curl, symbolic_calculus). No prerequisites, no input constraints, no exclusions are stated.

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. It does disclose the two things reported (module import status, tool surface), which implies a non-mutating read, but says nothing about the report's format, success/failure semantics, or whether it has 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?

A single front-loaded sentence with no filler. The two reported items are stated immediately with zero wasted clauses.

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?

There is no output schema or annotations, so the description must convey the return content, and it does name the two categories of information returned. For a zero-parameter diagnostic this is nearly sufficient, though the format/shape of the status report remains unspecified.

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 defines zero parameters, so there is nothing to document; per the rubric this yields a baseline of 4. The description correctly implies the tool takes no input, so no additional parameter detail 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?

States a specific verb ('Report') and two concrete resources: tool module import status and the current tool surface. It is clearly distinguishable from all computational siblings (fft_analysis, linear_regression, etc.) as a diagnostic, though 'current tool surface' is slightly jargon-y and could be spelled out as 'list of registered tools'.

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 when-to-use guidance is given. The description does not say this should be called to diagnose missing/failed tools, does not mention any prerequisites, and names no alternatives (there are none in the sibling list, but the agent is left to infer the diagnostic context entirely).

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. It usefully discloses default bounds (0 <= x <= inf), the all-integer default for integrality, and that fun is the minimum objective, but says nothing about infeasibility behavior, return shape beyond fun, or solver/method characteristics.

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 core operation and kept to three tight sentences with no padding; the integrality and negation notes earn their place. Slightly under-specified rather than verbose, so conciseness is not the weak point.

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 an 8-parameter, 0%-coverage, no-output-schema tool, the description is incomplete: the constraint matrix/vector parameters that define the actual problem are never explained, so an agent cannot confidently formulate a call from the description alone.

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% across 8 parameters, so the description must compensate. It explains c (objective), integrality, and bounds, but the five constraint/method parameters (a_eq, a_ub, b_eq, b_ub, method) are left entirely undocumented in both schema and description, which is a real gap for a MILP tool.

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+resource (minimize c @ x via scipy milp) and names the problem class (mixed-integer linear programming), which implicitly separates it from the sibling linear_program. It never explicitly routes the agent to linear_program for all-continuous problems, so sibling differentiation is only 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?

There is no explicit when-to-use guidance versus linear_program or optimize_minimize, only the implication carried by 'mixed-integer'. It does offer a useful usage note ('negate c to maximize') and integrality semantics, but nothing on exclusions or which sibling to pick.

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 only that scipy interp1d is used and that linear/quadratic/cubic modes exist, but says nothing about extrapolation behavior, ordering or monotonicity requirements for x, edge handling, or the return shape.

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; the verb and target are stated first and the implementation detail trails. It is efficient, though it errs toward brevity at the cost of 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 4-parameter numerical tool with no annotations, no output schema, and 0% schema coverage, the description is too thin. Missing are the shape/format expectations for x, y, xi (array vs path-like string) and the return value nature.

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, and it largely does not. It implies y is a function of x and that xi are target points, and it enumerates the kind options, but x, y, and xi are only titled 'X'/'Y'/'Xi' in the schema with no documented array-vs-string 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?

States a specific verb (interpolate) and resource (y(x) at points xi) and names the underlying implementation (scipy interp1d), which is enough to differentiate it from numeric siblings like curve_fit or linear_regression. It does not explicitly contrast with any sibling tool, so it stops short of a 5.

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

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

There is no statement of when to use this tool versus alternatives such as curve_fit or a regression tool, nor any exclusions or prerequisites. The agent must infer the use case from the verb alone.

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. It does disclose useful input-handling behavior: values may be inline lists or '@<path>' references, and supplying groups yields one curve per group. However, it says nothing about assumptions (e.g. censoring convention for events), error conditions, or the shape of the returned curves beyond the per-group note.

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?

Three short sentences, front-loaded with the core purpose and then the parameter conventions. No filler, though the backtick-heavy formatting is slightly noisy rather than informative.

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 3-parameter statistical tool with no annotations and no output schema, the description covers inputs reasonably and hints at output ('a separate curve is returned per group'), but leaves the events encoding and result structure underspecified for an agent to call 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 coverage is 0%, so the description must compensate, and it partially does: it explains the inline-vs-'@<path>' duality for durations/events and that groups takes one label per observation. It omits the critical semantics of events (presumably 1=event, 0=censored), leaving a key integer-encoding meaning undocumented.

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 ('Estimate survival curves with the Kaplan-Meier product-limit method'), which is unambiguous and clearly distinct from most siblings. It does not explicitly differentiate from the nearest sibling (cox_regression), leaving the agent to infer the boundary.

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 when-to-use or when-not-to-use guidance is given. The description never mentions cox_regression or any other survival-analysis sibling, nor prerequisites such as data alignment between durations and events. The only usage context is the optional groups behavior.

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. Defining the result as 'the sum of second derivatives' is genuinely useful behavioral context about what is computed, but there is no mention of the coordinate system assumed, whether the result is symbolic, or error behavior for non-scalar input.

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; the operative verb and resource come first and the clarifying definition follows.

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 two-parameter symbolic computation tool with no annotations, no output schema, and no parameter documentation, the description is too thin. It omits what 'variables' controls and what form the returned expression takes.

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 indirectly covers 'expr' via 'scalar expression'. It says nothing about the 'variables' parameter, which determines which variables the derivatives are taken with respect to, leaving half the parameter set undocumented in both schema and prose.

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 (Compute) and resource (the Laplacian of a scalar expression), and even clarifies the mathematical definition. However, it does not differentiate itself from close siblings like gradient, divergence, or curl, which an agent operating in this calculus family would need.

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 on when to use this versus gradient/divergence/curl/symbolic_calculus, nor any prerequisites or exclusions. The agent must infer applicability from the definition alone.

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 it does add one genuinely useful behavioral fact: default bounds are scipy's (0, None), i.e. all variables non-negative, which clarifies what the schema's 'default: null' means. It still says nothing about infeasibility handling, solver failures, or the shape of the returned solution vector, so it is only partially transparent.

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?

Three tight sentences with the objective front-loaded, followed by the maximize trick and the default-bounds caveat. Every sentence carries distinct, non-redundant 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 7-parameter solver with 0% schema coverage, no annotations, and no output schema, the description is too thin. It never defines the constraint-matrix parameters that are the tool's core interface, nor what the return value's structure looks like beyond naming 'fun'.

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% across 7 parameters, so the description must compensate and largely does not. It explains c (objective coefficients) and bounds (default non-negativity), and gestures at 'inequality/equality constraints', but never maps a_eq/a_ub/b_eq/b_ub or the method parameter to their names, leaving most parameters undocumented anywhere.

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 precise verb and mathematical resource: 'Minimize c @ x subject to linear inequality/equality constraints,' which unambiguously identifies a continuous linear-program solver. It implicitly separates itself from integer_program and optimize_minimize via the linear formulation, but never names those alternatives, so sibling differentiation is left to inference.

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 offers a how-to tip ('negate c to maximize') but no when-to-use guidance, no indication of which sibling to prefer for integer or general nonlinear problems, and no prerequisites or exclusions. An agent must infer applicability entirely.

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 genuinely non-obvious behavior: x/y may be inline or '@<path>' file references and x files may be 1D or 2D. However it says nothing about error conditions, output content, or side effects for a statistical fit.

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 tight sentences, purpose front-loaded, and the format conventions follow with no wasted words.

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 annotations and no output schema, with a 3-param tool at 0% schema coverage. The description covers x and y adequately but omits feature_names and any indication of what the reported 'coefficient inference' contains, leaving gaps an agent would need.

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 adds real meaning for x and y (inline vs file reference, 1D/2D array shape for x), but leaves feature_names entirely undocumented and does not clarify required-vs-optional status.

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: 'Fit an ordinary least-squares regression, simple or multiple, and report coefficient inference.' The OLS specification implicitly separates it from glm, mixed_lm, and curve_fit, though it does not name any sibling explicitly.

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?

Usage is implied by the OLS scope, which narrows it within a dense family of regression/statistics siblings (glm, mixed_lm, cox_regression, curve_fit), but there is no explicit when-to-use guidance or statement of what distinguishes it from those 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, so the description carries the full burden. It usefully discloses that the result includes shape, preview, summary and data, but says nothing about read behavior, memory/large-file handling, error cases for unsupported files, or how max_rows bounds the preview.

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 sentence, front-loaded with the action and formats, ending with the return payload. No wasted words, though the terseness contributes to the semantic gaps elsewhere.

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, no annotations, and 0% parameter coverage. The description partially compensates by naming the returned fields, but omits parameter behavior and file-handling caveats for a tool with a required path and two undocumented options.

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% for three parameters. The description's format list loosely supports 'path', but 'column' (string-or-index selection) and 'max_rows' (default 20) are never explained, so an agent must guess their effect.

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?

Specific verb (load) plus the accepted file formats and the four things returned (shape, preview, summary, data). An agent can distinguish it from save_data and describe_file. No explicit sibling callout, but 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 statement of when to use this versus describe_file, analyze_dataset, or describe. Usage is only implied by the name and the data-oriented siblings. No prerequisites or exclusions are given.

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 bears the full behavioral burden but discloses almost nothing: it does not state valid values for 'operation', expected shapes/errors for mismatched 'a' and 'b', whether strings are parsed expressions, or what is returned. Only the vague input shape hint about 'a' and optional 'b' is conveyed.

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 well-formed sentence with the resource and primary parameter front-loaded and zero padding. It is efficiently structured; its problem is thinness of content rather than wordiness.

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 3-parameter compute tool with no annotations, no output schema, and a free-form operation selector, the description is far too sparse. It omits the operation vocabulary, shape constraints, and return behavior — everything an agent needs to 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% and the description adds no meaning beyond the schema: 'a' and 'b' are already visible, and the free-form 'operation' string — the single most important parameter — has no enumeration and no explanation of permitted values anywhere. The agent is left unable to construct a valid call.

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 verb and resource ('perform a dense linear-algebra operation on matrix a'), and the word 'dense' implicitly contrasts with the sibling sparse_compute. However, 'linear-algebra operation' is very broad and the description never names which operations are supported, so an agent cannot tell what the tool actually computes.

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 when-to-use guidance and no mention of alternatives, despite sparse_compute and other numeric siblings existing. The optional 'b' is noted in passing, but nothing tells the agent when this tool is preferred over sparse_compute or run_python.

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 substantial work: it discloses data-source formats (mapping vs '@<path>.csv'), that relative paths resolve against output_dir(), that reml defaults to REML, and it lists the returned quantities (fixed effects, SEs, z/p, random-intercept variance, AIC/BIC, convergence flag). It does not cover error/failure behavior or missing-data handling, keeping it short of a 5.

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?

Well-organized: purpose first, then per-parameter clarifications, then return values. Sentences are dense with information and each earns its place, though the parameter block reads as a run-on list rather than crisp bullets.

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 statistical tool with no annotations and no output schema, the description supplies the parameter semantics and the return contract an agent needs to call it. The one meaningful gap is the absence of any guidance on model-choice context relative to sibling regression tools.

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, and it documents four of five parameters meaningfully: data (mapping or CSV path), groups (grouping column), re_formula (random effects with an example '~1'), and reml (REML vs ML). Only formula is left undescribed, though it is a conventional input.

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: 'Fit a linear mixed-effects model with a random-effects structure.' This is clearly distinguishable from statistical siblings like linear_regression, glm, and nonlinear_mixed_lm. It stops short of explicitly naming the sibling it is not (nonlinear_mixed_lm), so it is clear but not maximally differentiating.

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 explains how to supply parameters but never says when this tool should be chosen over alternatives such as linear_regression, glm, or nonlinear_mixed_lm. There are no exclusions or prerequisites (e.g. required grouping structure), leaving the agent to infer the use case.

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. It usefully discloses that the same seed reproduces identical output, which is a genuine behavioral trait. However it says nothing about cost (n defaults to 10000 samples), what filename/save_histogram do on write, or how invalid distributions/expressions fail.

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?

Short, front-loaded, and free of filler; the nested-variable explanation is placed where it is needed. The reST markup adds mild noise but no wasted sentences.

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 7-parameter tool with nested objects, no annotations, and no output schema, the description covers only the two hardest-to-guess params. Nothing explains n, expression syntax, percentile selection, or file output, so an agent cannot invoke it confidently beyond the happy path.

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% across 7 parameters, so the description must compensate. It explains variables (the nested object) and seed well, but leaves n, expression, percentiles, filename, and save_histogram entirely undocumented in both schema and prose.

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 gives a specific compound verb+resource: sample scipy.stats distributions and evaluate a sympy expression over the samples. That is clearly distinguishable from siblings like symbolic_evaluate or distribution, though no sibling is named explicitly.

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 documents mechanics but never says when to reach for this over alternatives such as run_python, symbolic_evaluate, or distribution. No preconditions (e.g., expression must be a valid sympy string, symbols must match variables keys) are stated.

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 discloses that random-effect variances are not estimated, there is no integration, no standard errors are produced, the objective includes a penalty term, and the response always carries approximation: true plus a note. The random_effect=False branch behavior is also 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 one-line summary is front-loaded before the equation and detail, and nearly every sentence adds substantive information. It is dense with math rather than padded, though the critical approximation caveat sits at the very end where it could be more prominent.

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 9-parameter tool with no annotations and no output schema, the definition covers inputs, optimization behavior, and key return signals (random_effects field, approximation flag, note). It stops short of a full return-shape description, but given there is no output schema this is a reasonable level of detail.

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, and it largely does: model, x, y, groups, p0, data (both mapping and '@<path>.csv' forms), random_effect, and the role of penalty are all explained. Only maxiter is left undocumented, a minor gap for a conventional solver setting.

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 opening sentence states a specific verb (Fit) and resource (nonlinear model with one random intercept per group), and the model equation makes the exact form unambiguous. This cleanly distinguishes it from siblings like mixed_lm (linear) and curve_fit (no random effects).

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 the model form and the important caveat that this is an approximate penalized fit rather than a full NLME, which tells an agent when its results are appropriate. However, it never explicitly names an alternative (e.g., a full mixed-model tool) or states exclusions, so routing is left 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 load and does disclose real behavioral traits: solver fallback logic (SLSQP → L-BFGS-B → BFGS) and exact constraint semantics (ineq means expr >= 0, eq means expr == 0). It omits key traits such as whether the optimization is local, whether it can fail/non-converge, and what is returned.

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 purpose sentence, then two compact paragraphs covering variable naming, default-solver selection, and constraint structure. No filler; every sentence adds information an agent needs.

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 6-parameter, no-annotation, no-output-schema tool, the description covers the unusual semantics well but leaves the return value, bounds format, and failure/convergence behavior unexplained. It is adequate but not complete for an agent that must interpret results or format bounds 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 coverage is 0%, so the description must compensate, and it does for most parameters: x0 ordering/variable naming, the constraint dict shape (kind/expr), and params interpolation into expressions. Bounds format (pair-of-pairs, min/max ordering) and the objective's expected syntax are only implied, leaving a modest 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?

Opens with a specific verb+resource: 'Minimize a scalar expression with scipy.optimize.minimize.' That is unambiguous and action-oriented. It does not, however, distinguish itself from sibling optimizers such as global_optimize, linear_program, or integer_program, so an agent must infer the boundary on its own.

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 explains how the default solver is chosen based on constraints/bounds/method, which is useful selection context, but it never says when to prefer this tool over global_optimize or the LP/IP siblings. Usage is implied rather than stated.

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 usefully discloses the return payload (value, unit, uncertainty), but says nothing about ambiguous matches, no-match behavior, or case sensitivity — the failure modes an agent would actually hit.

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 sentence, front-loaded with the action and resource, ending with the return contract. 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?

There is no output schema, and the description supplies the return shape (value, unit, uncertainty), which covers the main gap. Missing only edge-case behavior for ambiguous or unmatched queries — minor for a simple read-only lookup.

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 schema only labels the field 'Query', so the description must compensate. Listing alias, exact name, and keyword as accepted input forms adds genuine meaning about matching strategy, though it does not specify case handling or fuzzy vs exact precedence.

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?

Specific verb (look up) plus resource (physical constant) plus accepted query forms (alias, exact name, keyword). No sibling tool performs constant lookup — unit_convert and unit_calculate operate on quantities — so the resource alone differentiates 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 names the three query forms, which implies how to invoke it, but gives no when-to-use guidance, no exclusions, and no pointer to alternatives such as unit_calculate. Usage is inferred rather than stated.

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 and discloses little: it implies a file write (PNG), but does not say where the file lands, whether filename controls the path, whether an existing file is overwritten, or what the tool returns. The required nested data object's expected structure is likewise undisclosed.

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 tight sentence with no filler, and the supported chart kinds are front-loaded. It is efficient, though its brevity is partly under-specification rather than true economy.

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 7-parameter tool with a required nested object, no output schema, and no annotations, this one-line description leaves major gaps: data shape, output location, overwrite behavior, and return value are all unspecified. An agent could not reliably invoke this from the description alone.

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% across 7 parameters. The description's list of plot kinds ('line/scatter/hist/bar/errorbar/contour/surface') usefully enumerates valid kind values, but the most important parameter, the required nested data object, is completely undocumented in both schema and prose.

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 gives a specific verb (Render) plus the resource (plot) and enumerates the supported chart kinds, ending with the output artifact (PNG file). It does not, however, distinguish itself from the sibling tool plot_file, leaving it to the agent to infer which one to use.

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 when-to-use guidance and no mention of the alternative plot_file, which is the obvious competing sibling. The agent gets no signal about which plotting tool is appropriate in a given situation.

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 it does disclose the key side effect: a PNG is written to the output directory, which is behavioral information not present in the schema. However, it says nothing about overwrite behavior, filename collisions, return value, or failure modes for unsupported formats/columns.

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 zero filler that states the operation, inputs, and output artifact. It is efficient, though arguably too terse for a 9-parameter tool.

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 9 parameters at 0% coverage, no annotations, and no output schema, the description is far too thin to support correct invocation. It omits which columns x/y select, valid `kind` values, default behaviors, and how the output file is named.

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% across 9 parameters, so the description must compensate and largely does not. It hints that x/y refer to 'columns' and that `kind` relates to file format, but dpi, title, xlabel, ylabel, and filename are left entirely unexplained.

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 gives a specific verb (plot), resource (columns from a file), and result (PNG in the output directory), plus the accepted input formats. It is clear on its own but never distinguishes itself from the sibling tool `plot`, so an agent cannot tell from the text alone which one applies to a file versus in-memory data.

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 when-to-use guidance, no statement of prerequisites, and no reference to alternatives such as `plot` or `load_data`. The only implicit cue is that the input is a file path, which the agent must infer from the schema.

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 supplied, so the description carries the full behavioral burden, and it discloses almost nothing beyond the method name. It does not mention that Welch segments the signal and averages periodograms (which constrains nperseg), what is returned (frequency bins plus PSD values), or any assumptions about the input signal.

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 zero padding or repetition. It is efficiently written, though its brevity is a symptom of under-specification rather than disciplined concision.

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 no annotations, no output schema, and zero parameter documentation, the description leaves an agent missing the return values, the meaning of nperseg, and the signal input contract. For a three-parameter numerical tool this is materially incomplete.

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% for all three parameters, and the description offers no compensating detail. The non-obvious parameter 'nperseg' (segment length for Welch averaging) is left entirely unexplained, as are the accepted forms of 'signal' (array vs. string) and the units of 'sample_rate'.

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+resource ('Estimate the power spectral density') plus the algorithm ('Welch's method'), which is more precise than a generic 'spectrum' label. However, it does nothing to separate itself from adjacent spectral siblings such as fft_analysis or stft, so the agent gets no help choosing among them.

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 when-to-use guidance at all: nothing says when Welch's PSD estimate is preferable to fft_analysis or stft, nor whether a preprocessed/sampled signal is required. The agent must infer the selection criteria from domain knowledge alone.

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 richly: 100k character code limit, 20k stdout/stderr truncation, process-tree termination on timeout, the shape of the error result (partial output plus elapsed_seconds and changed files), the Windows Job Object memory cap, the SCI_MCP_SANDBOX_MEMORY_MB override and its range, the MemoryError failure mode, the silent fallback if the Job Object cannot be created, and the explicit absence of a hard cap on non-Windows. That is exceptional disclosure of limits, failure modes, and platform differences.

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 purpose is front-loaded in the first sentence, followed by clearly delineated paragraphs on resource controls and platform-specific memory behavior. It is long, but given the absence of annotations and output schema, nearly every sentence carries necessary behavioral detail rather than 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 tool with no annotations and no output schema, the description covers the return payload, truncation behavior, timeout semantics, memory-limit behavior per platform, and failure modes. An agent has enough to invoke it correctly and interpret results without further documentation.

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, and it largely does: it explains the code length ceiling (100,000 characters) and the semantics of timeout_seconds (what happens on timeout, process-tree kill, error payload). It stops short of stating the default or units explicitly beyond the schema's own default of 30.

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 opening sentence gives a specific verb and resource: 'Execute Python code in a subprocess and return captured output plus produced files.' An agent immediately understands this is a general-purpose code execution tool. It does not, however, explicitly differentiate itself from the many specialized numeric siblings (fft_analysis, curve_fit, etc.), so it falls short of a 5.

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

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

The description never says when to reach for run_python versus the dozens of specialized sibling tools, nor does it name any alternative. The only guidance is implicit ('rely on timeout_seconds and the caller's own limits'), which is operational rather than a when-to-use/when-not-to-use rule.

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. It discloses the destination ('configured output directory') and formats, but says nothing about overwrite behavior, permissions, return value, or whether the directory must exist.

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; the verb, resource, formats, and destination are all packed efficiently.

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 write tool with no annotations, no output schema, and 0% schema description coverage, the one-line description is insufficient. Key operational details about file writing and parameter meaning are absent.

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 only loosely maps to the 'format' parameter via the format list and implies numeric data, leaving 'filename' and 'column_names' (and the accepted array/dict data shapes) entirely undocumented.

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 (save) and resource (numeric data) plus the supported output formats and destination directory. It is clearly distinguishable from the inverse sibling load_data, though it never names it explicitly.

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 versus alternatives, no prerequisites, no note about the required output directory being pre-configured. The agent must infer everything from the name.

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 behavioral burden and does well: it discloses the explicit scheme, the two stability limits (dt <= dx^2/(2*nu) and CFL dt <= dx/max|u|), the exact error behavior (violation reported as an error with a hint to increase nt), and the side effect of writing the full grid to .npz while returning a downsampled grid. This is unusually complete for a no-annotation 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-loaded with the governing equation, then discretization, boundary conditions, stability limits, and return behavior in tight sequence. Every sentence carries distinct information; there is no 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?

With no output schema, the description correctly explains the return value (grid downsampled to at most 20x20) and the .npz side effect. The remaining gap is that the numerical/domain parameters (nx, nt, t_end, length) are left undocumented for an 8-parameter 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% across 8 parameters, so the description must compensate. It does clarify 'initial' (an expression in x), 'left'/'right' (constant Dirichlet values), and implicitly links nu, dx, and dt through the stability formulas, but nt, nx, t_end, and length are never defined. It covers roughly half the 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 (solve) and resource (Burgers' equation in 1D) and gives the exact PDE u_t + u*u_x = nu*u_xx. This uniquely distinguishes it from siblings like solve_heat_1d, solve_wave_1d, and solve_pde_1d without opening any schema.

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?

Usage is implied by the specific PDE stated, but the description never says when to use this vs the generic solve_pde_1d or the other named solvers. The stability constraints hint at applicability but are not framed as when-to-use guidance, and no exclusions or alternatives are named.

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 and does so richly: the failed-input behavior (unstable r rejected), the ghost-node treatment, the stability-motivated choice to apply Robin at the new time level, the full-grid .npz save, and the downsampling of returned arrays to <=100 spatial / <=50 time points. The explicit sign conventions for flux vs outward-normal derivative are exactly the kind of behavioral detail an agent cannot infer elsewhere.

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 PDE and scheme, then grid, stability, boundary types, sign conventions, implementation notes, and output behavior. It is dense and long, but nearly every clause carries load for a genuinely complex numerical tool; the extended Robin sign discussion is verbose yet defensible because it is error-prone.

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 an 8-parameter, annotation-free tool with no output schema, the description covers the scheme, boundary handling, stability, and even return-value behavior (downsampled arrays + full .npz). The main residual gaps are the undocumented semantics of alpha/length/t_end and, critically, the expected format of `initial`.

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% across 8 params, so the description must compensate. It explains nx ('nx+1 grid points'), nt, and gives full structure for left/right (float vs {dirichlet|neumann|robin} dicts). However alpha, length, t_end, and especially `initial` (a string whose expected format is never stated) are left undocumented, so half the parameters still lack 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 gives a specific verb + resource and the exact mathematical problem: 'Solve u_t = alpha*u_xx with explicit FTCS and configurable ends.' By pinning the constant-coefficient 1D heat PDE and the FTCS scheme, it clearly separates this from siblings like solve_heat_1d_variable, solve_heat_3d, and solve_burgers_1d without the agent needing to open any schema.

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?

Usage is only implied through the mathematical spec and the stability constraint ('r = alpha*dt/dx^2 <= 0.5; larger values are rejected as unstable'), which tells the agent about valid inputs but not when to choose this tool over alternatives. No alternatives (e.g. the variable-coefficient or implicit solvers) are named and there are no explicit inclusions/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 full burden and does well: it discloses the numerical scheme, the stability rejection condition (dt*max(alpha)/dx^2 > 0.5), Dirichlet end conditions, and the return behavior (full grid to .npz, arrays downsampled to 100x50). It omits permission/auth context, but that is minor for a local solver.

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 PDE and scheme are front-loaded, then constraints, then return behavior, with no filler. The math block is dense but each line earns its place; format is slightly heavy for an agent reader but not wasteful.

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 and no annotations, so the description must stand alone. It covers the model, scheme, stability limit, boundary conditions, and output downsampling, which is enough to call the tool correctly, with only minor gaps in per-parameter documentation (length, t_end, initial).

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% across 8 params, so the description must compensate. It meaningfully defines alpha_expr (expression in x, positive on grid), nx (intervals, nx+1 nodes), nt (time steps), and implies left/right via 'constant Dirichlet values', but leaves length, t_end, and initial (only inferable from its sin(pi*x) default) undocumented.

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: solving u_t = d/dx(alpha(x) du/dx) for variable-conductivity heat flow, and names the scheme (explicit flux form). The variable coefficient clearly distinguishes it from the constant-coefficient sibling solve_heat_1d without opening any schema.

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?

Usage is implied by the problem (spatially varying alpha) and the constraint that alpha must be strictly positive, but there is no explicit 'use this instead of solve_heat_1d / solve_pde_1d' routing or statement of prerequisites beyond positivity. The agent can infer the case but is not told it directly.

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 present, the description carries the full burden and delivers: it discloses the stability rejection rule (r <= 1/6), the hard cell-count limit (500,000 cells), and the output behavior (full grid saved to .npz, returned arrays downsampled to 20 points/dim and 20 time steps). These are non-obvious behavioral traits an agent cannot get from the schema.

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 governing equation is front-loaded, followed by parameter meaning, then constraints and return behavior in a logical order. It is dense but every clause is informative; a slight tightening of the return/limit lines would be the only improvement.

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 numerical PDE solver with no output schema and no annotations, the description supplies everything needed: the model, domain, method, parameter meaning, stability and size limits, and return format. Nothing essential for correct invocation 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?

Schema coverage is 0%, so the description must explain all 8 parameters, and it explains most: nx/ny/nz as intervals per axis (with dx = 1/nx), nt as time steps, initial as an expression in x/y/z, and boundary as the constant Dirichlet value. alpha is conveyed implicitly via the equation and t_end is not explicitly defined, leaving minor gaps.

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?

Opens with a specific verb and the exact equation solved (u_t = alpha*(u_xx+u_yy+u_zz)) plus the domain (unit cube) and method (explicit FTCS). This unambiguously distinguishes it from siblings like solve_heat_1d, solve_laplace_3d, and solve_wave_3d.

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 communicates applicability constraints (unit cube, constant Dirichlet on all faces, stability bound r <= 1/6) which tells the agent when the call will succeed or be rejected. However, it never names an alternative solver (e.g. solve_heat_1d or solve_laplace_3d) or states when to prefer this over them, so usage is inferred rather than directed.

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 fully discloses the algorithm (red-black Gauss-Seidel), convergence criterion (max|u_new-u_old| < tol), non-failure on max_iter with converged=False and iterations count, and output handling (full grid saved as .npz, returned grid downsampled to at most 100x100). This gives an agent rich behavioral context beyond the schema.

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 front-loaded with the core purpose, followed by behavior and output details in a compact, well-structured manner. Every sentence adds necessary information without 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?

Given the complexity of a numerical PDE solver with no annotations and no output schema, the description covers the method, convergence failure mode, and return handling. It is nearly complete, though explicit definitions for nx/ny and the edge-parameter mapping would make it fully 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?

Schema coverage is 0%, so the description must compensate. It explains tol and max_iter and implies left/right/top/bottom are Dirichlet edge values, and nx/ny are grid dimensions via 'unit square' and 'grid', but it never explicitly defines nx, ny, or maps each edge parameter, leaving significant semantic gaps.

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 mathematical problem: solving u_xx + u_yy = 0 on the unit square with constant Dirichlet edges. This clearly identifies the verb, resource, and domain, distinguishing it from siblings like solve_laplace_3d and other PDE solvers.

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 equation and domain provide clear context for when to use this tool, and no exclusions are stated. It does not explicitly name sibling alternatives such as solve_laplace_3d or solve_pde_1d, but the mathematical scope makes the intended use unambiguous.

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 names the Jacobi iteration, the convergence criterion max|u_new-u_old| < tol, the non-convergence behavior (still succeeds with converged=False plus iterations), and a hard grid-size rejection above 500,000 cells. It stops short of stating the exact form of the rejection (exception vs. error result) or any runtime expectations.

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-loads the governing equation, then layers behavior and I/O limits in short declarative sentences. Each sentence earns its place; the only slight cost is that grid-dimension semantics are assumed rather than stated.

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?

There is no output schema, so the description must describe returns — and it does: the full (z,y,x) grid saved to .npz, the downsampled return capped at 20 points per axis, and the converged/iterations fields. Combined with the tolerance, iteration cap, and grid limit, this is close to complete, with only the precise return type/shape and rejection mechanism left implicit.

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% across 11 parameters, so the description must compensate. It explains the six boundary-value params (x0/x1/y0/y1/z0/z1 as face values), tol as the convergence threshold, and max_iter's role in the non-convergence path. However, nx/ny/nz are never explicitly defined as grid dimensions nor tied to the 500,000-cell limit, and defaults are omitted.

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 operation (solving u_xx + u_yy + u_zz = 0), the domain (unit cube), and the boundary condition type (Dirichlet faces). This clearly distinguishes it from siblings like solve_laplace_2d and solve_heat_3d, which differ in dimension or PDE.

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?

Usage is implied by the boundary-value framing (use it when you need a Dirichlet Laplace solution on the unit cube), but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as solve_laplace_2d for lower dimensions. Adequate but with clear gaps.

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 discloses the numerical method (FFT spectral Poisson solve, explicit RK2), the stability constraints (nu*dt/dx^2 <= 0.5, max|u|*dt/dx <= 0.5), the error behavior (returns err and asks for larger nt), and hard limits (nx/ny 8..256, nx*ny<=65536, nt<=100000).

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 core purpose is front-loaded in the first sentence, followed by method, constraints, and output details. The embedded PDE/FFT math is relevant to correct invocation, though the block is dense and slightly longer than strictly necessary.

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?

There is no output schema, yet the description covers return behavior thoroughly: the full (t, y, x) vorticity history plus grid and energy/enstrophy series saved to .npz, with returned arrays downsampled to at most 50x50 spatial points and 20 time levels. For a 6-parameter solver with no annotations, this is 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, and it largely does: it explains initial_vorticity as a sympy expression in x and y (no Python eval), the grid spacing 2*pi/nx and 2*pi/ny, dt = t_end/nt, and the nx/ny/nt ranges. nu and t_end are only implied by the equation rather than stated directly, leaving a minor 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 and resource: solving 2D incompressible Navier-Stokes on a periodic [0, 2*pi]^2 domain. It clearly distinguishes itself from sibling PDE solvers (solve_heat_1d, solve_wave_1d, solve_burgers_1d, solve_laplace_2d) by naming the equation and boundary type.

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 specifies the applicable regime (2D incompressible, periodic boundaries) and explicitly bounds scope with 'This is not a general CFD solver.' It does not name a specific alternative sibling to use instead, so it stops short of full when/when-not routing, but the applicable conditions are 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the expression-language conventions (state variable y or y0,y1..., time variable t, params keys injected as constants), but says nothing about return format, error behavior, or solver tolerances.

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 core action, then the two conventions that matter most. Two short paragraphs with essentially no filler, though the backtick-heavy formatting is slightly noisy.

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 6-parameter numerical solver with no annotations and no output schema, the description covers the expression interface but omits t_span/t_eval semantics and what the solver returns. Adequate to attempt a call, but with clear gaps.

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, and it partly does: rhs, y0 ordering, params, and t are explained. However, t_span, t_eval, and method receive no explanation, leaving half the parameters undocumented in both schema and description.

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+resource ("Solve an initial-value ODE system") and names the underlying engine (scipy solve_ivp), which implicitly distinguishes it from the symbolic sibling dsolve_ode. It does not, however, explicitly contrast itself with dsolve_ode or other solvers in the family.

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 when-to-use or when-not-to-use guidance is given. The description never mentions the symbolic alternative dsolve_ode, so an agent must infer from the name alone whether this numerical IVP solver or the symbolic solver 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?

With no annotations, the description carries the full burden and does so richly: explicit Euler scheme, second-order centred interior differences, constant Dirichlet ends, guaranteed stability_note in the output, non-finite detection that halts and returns err(...) with the offending step number, full grid persisted to .npz, and downsampling to ≤100 space / ≤50 time points.

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 equation and scheme, then behaviour, then return caveats. Every sentence does work, though the prose is a touch long for what is essentially a solver contract and could compress the derivative/BC paragraph.

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, the description covers failure modes (err with step number), the stability_note, the .npz side effect, and the downsampled return shape. It stops short of describing the returned array fields, which is the main remaining gap for an agent consuming 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?

Schema description coverage is 0% for 8 parameters, so the description must compensate. It clarifies equation (sympy expression in x, t, u, u_x, u_xx) and left/right (Dirichlet values) well, but nt, nx, t_end, length, and initial are only inferable from their names and defaults, leaving half the surface undocumented.

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?

Names a specific verb ('Solve') and resource (u_t = F(x,t,u,u_x,u_xx)) and pins down the numerical scheme (explicit Euler with centred differences). An agent can immediately separate this general semi-linear solver from the specialized siblings solve_heat_1d, solve_wave_1d, and solve_burgers_1d.