Server Quality Checklist

Tool Scores

• spss_arimaC
  2.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the SPSS dependency and the syntax used, but does not explain whether the tool writes output, modifies files, requires specific permissions, or has other side effects. This is insufficient for a model-fitting tool.

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

  Conciseness4/5

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

  The description is compact, front-loaded with the model type and syntax, and uses short clauses for the key parameters. It avoids filler, though a bit more structure around parameter groups would slightly improve scannability.

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

  Completeness2/5

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

  The tool has 9 parameters, no annotations, 0% schema description coverage, and only a brief description. The output schema helps with return values, but the description leaves core invocation details, parameter meanings, and usage context underspecified. An agent would struggle to call this tool correctly in many realistic cases.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It usefully explains p/d/q orders and log_transform values, but says nothing about file_path, dependent_variable, independent_variables, constant, or max_iterations. The partial coverage is not enough for a 9-parameter tool.

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

  Purpose4/5

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

  The description clearly identifies this as a Box-Jenkins ARIMA time-series model and even shows the SPSS syntax form 'ARIMA depvar /MODEL=(p,d,q)'. It is distinct from the many other statistical-analysis sibling tools, though it lacks an explicit verb like 'fit' or 'estimate'.

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

  Usage Guidelines2/5

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

  The description says the tool 'Requires IBM SPSS Statistics' but gives no guidance on when to choose ARIMA over alternative analysis methods, nor does it mention exclusions or prerequisites like stationarity or data preparation. Usage context is largely left to inference.

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

• spss_cluster_hierarchicalC
  2.7/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full burden. It discloses only that SPSS must be installed and that multiple linkage/distance options are supported; it does not say whether the operation reads the input file only, creates output artifacts, or has side effects on the file.

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

  Conciseness4/5

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

  Three short sentences with the main action first and no filler. The SPSS prerequisite is useful, though 'with dendrogram' partly duplicates the dendrogram parameter's default behavior.

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

  Completeness2/5

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

  For a 6-parameter statistical tool with no schema descriptions and no annotations, this is too thin. The output schema covers returns, but missing parameter semantics, selection guidance, and behavior mean an agent cannot confidently invoke or configure it beyond guessing from property names.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It adds a general hint that method relates to linkage and measure relates to distance, but it never explains file_path, variables, id_variable, or dendrogram semantics, and the enum values are left entirely to their names.

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

  Purpose4/5

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

  The description names an exact statistical procedure ('hierarchical cluster analysis') and mentions the dendrogram output, so an agent can identify what the tool does. It does not explicitly contrast with the sibling clustering tools spss_twostep_cluster and spss_quick_cluster, but the method name itself is specific enough to be distinguishable.

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

  Usage Guidelines2/5

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

  No guidance about when to choose hierarchical clustering over the sibling twostep_cluster or quick_cluster tools, and no exclusions or preconditions beyond the SPSS installation note. The intended use is only implied by the tool's name and the verb 'Run'.

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

• spss_nonparametric_testsC
  2.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool runs tests and requires SPSS, but it does not disclose whether executing a test modifies data, creates output artifacts, or has side effects in the SPSS session. This is a thin behavioral profile for a command-style tool.

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

  Conciseness5/5

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

  The description is two sentences with no filler. The first sentence front-loads the action and test options, and the second adds a relevant prerequisite. Every sentence earns its place.

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

  Completeness2/5

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

  The existing output schema reduces the need to explain return values, but this is still a five-parameter tool with conditional parameter requirements and no annotations. The description leaves an agent unable to correctly shape the variables, grouping_variable, and group_values arguments for the selected test type.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not compensate by explaining any of the five parameters. It does not clarify that Wilcoxon uses two variables, that Mann-Whitney and Kruskal-Wallis require grouping_variable and group_values, or what file_path and variables should contain. The enum list merely repeats the test_type schema values.

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

  Purpose4/5

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

  The description uses a specific verb ('Run') and a clear resource ('common nonparametric tests in SPSS'), and it names the three supported tests. It distinguishes the tool from parametric sibling tools by the word 'nonparametric,' though it does not explicitly contrast it with a sibling.

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

  Usage Guidelines2/5

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

  The only usage-related information is the prerequisite that IBM SPSS Statistics must be installed. There is no guidance about when to choose this tool over t_test, anova, or other siblings, and no guidance about when each of the three nonparametric tests is appropriate.

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

• spss_variable_labelsC
  2.7/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavioral traits itself. It reveals the mutation action and the SPSS requirement, but does not state whether the file is modified in place, what output_path does when null, whether existing labels are overwritten, or what the response contains.

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

  Conciseness4/5

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

  At roughly three short clauses, it is brief and front-loaded with the core command. The syntax example and labels shape earn their place, though the structure is fragmentary rather than a clean prose definition.

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

  Completeness2/5

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

  Given no annotations and no schema descriptions, the description is too sparse to let an agent invoke this reliably. It omits file_path semantics, output handling, and overwrite behavior, while only partially addressing labels.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description needed to document all three parameters; it only clarifies labels as {variable: label}. file_path and output_path remain unexplained in either schema or description.

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

  Purpose4/5

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

  States a concrete operation ('Set variable labels') and identifies the resource with the exact SPSS syntax. However, it does not explicitly distinguish itself from the sibling spss_value_labels, so differentiation rests on the tool name and syntax rather than the description.

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

  Usage Guidelines2/5

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

  No guidance on when to choose this tool over spss_value_labels or other transformation siblings. The only context is the prerequisite 'Requires IBM SPSS Statistics,' which is an environment constraint rather than usage guidance.

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

• spss_discriminantC
  2.8/5.0
  Behavior2/5

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

  No annotations exist, so the description must carry the behavioral transparency burden. It discloses an external dependency and mentions stepwise/cross-validation support, but it does not state whether the tool modifies files, what outputs it produces, or any side effects/errors. This is insufficient for an 8-parameter statistical tool.

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

  Conciseness5/5

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

  Three short sentences, all front-loaded and free of filler. Each sentence adds some useful signal (action, capabilities, prerequisite), so it scores high on conciseness despite being light on detail.

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

  Completeness2/5

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

  For a complex tool with 8 parameters, no annotations, and no parameter documentation, this description is not sufficient to guide correct invocation. The output schema exists but does not compensate for missing parameter semantics, usage conditions, and behavioral caveats; the description needs additional context.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate, but it only loosely maps to parameters: groups/predictors via the classification phrasing and stepwise via the method enums. It leaves group_range, priors, save_class, save_scores, and file_path unexplained.

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

  Purpose4/5

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

  The description uses a specific verb ('Run') and identifies the exact analysis ('discriminant analysis') with its goal ('classify cases into groups'). It is clear and, by naming the classification purpose, helps set it apart from related statistical tools such as regression or MANOVA, though it does not explicitly name an alternative.

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

  Usage Guidelines2/5

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

  No guidance is given on when to choose discriminant analysis over sibling tools (e.g., logistic_regression, manova) or which method/enum to select for stepwise vs. direct entry. The only operational context is the external SPSS prerequisite, which is useful but not usage direction.

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

• spss_genlinC
  2.8/5.0
  Behavior2/5

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

  With no annotations, the description must carry the burden of explaining behavior, but it only states that IBM SPSS Statistics must be installed and lists supported distributions. It does not disclose execution side effects, failure behavior, or what happens to the output/data.

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

  Conciseness5/5

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

  The description is two short sentences with the primary action front-loaded and no filler. Every sentence adds relevant information about the model family or runtime prerequisite.

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

  Completeness2/5

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

  For a complex model-fitting tool with 8 parameters, no annotations, and no parameter descriptions, this is incomplete. The output schema covers return values, but the description still omits essential call context such as variable role requirements and categorical handling.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate, but it only hints at distribution and link-function concepts. Core parameters like file_path, dependent, predictors, scale, and save_predicted remain unexplained.

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

  Purpose4/5

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

  The description uses a specific verb and resource: 'Run generalized linear model (GENLIN)' and clarifies flexible distribution/link support. It is clear, but it doesn't explicitly differentiate this from siblings like spss_logistic_regression or spss_genlinmixed.

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

  Usage Guidelines2/5

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

  There is no guidance on when to choose GENLIN over alternatives such as spss_regression or spss_logistic_regression, and no exclusion criteria are given. The only contextual note is the SPSS installation requirement, which is a prerequisite, not a usage rule.

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

• spss_mixedC
  2.8/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of disclosing behavior. It mentions support for nested/crossed random effects and repeated measures structures, but does not describe side effects, output format, error conditions, or whether any data is modified. The only operational detail is the requirement that SPSS be installed.

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

  Conciseness4/5

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

  The description is concise and front-loaded with the core action. It wastes no words and adds meaningful context about the type of model and prerequisite. It is appropriately sized for a tool of this complexity, though it could be structured slightly better by separating capabilities from requirements.

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

  Completeness2/5

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

  This is a complex model-fitting tool with 9 parameters, no annotations, and zero schema coverage. The description does not explain how to specify random effects, fixed effects, subject/repeated terms, or covariance structures, making it difficult for an agent to invoke correctly without additional external knowledge. The output schema exists but cannot compensate for missing parameter and usage context.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description does not mention any of the 9 parameters, including the required ones like file_path, dependent, and fixed_effects. The description must compensate for the lacking schema documentation but does not, leaving an agent with no semantic understanding of how to populate the fields.

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

  Purpose5/5

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

  The description clearly states the specific action ('Run') and the resource ('linear mixed-effects model'), and further clarifies it as a multilevel model with random effects. This distinguishes it from many siblings that run other analysis types, such as spss_anova or spss_regression.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus close alternatives like spss_genlinmixed, spss_repeated_measures_anova, or spss_glm_univariate. It implies use for multilevel/repeated measures data, but does not state when not to use it or what distinguishes it from these siblings.

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

• spss_formatsC
  2.9/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden of behavioral disclosure. It correctly clarifies that this changes display formats rather than data values, and it mentions the SPSS dependency, but it does not state whether the file is modified in place, how output_path relates to the operation, whether changes are reversible, or what side effects may occur. This is a meaningful gap for a mutating tool.

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

  Conciseness5/5

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

  The description is compact and front-loaded, with the key purpose in the first phrase. Every sentence earns its place: purpose, syntax, example format mapping, and prerequisite. There is no padding or irrelevant context.

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

  Completeness2/5

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

  For a tool with three parameters including a nested object, no annotations, and no schema-level parameter descriptions, the description is incomplete. An agent still lacks clarity about what file_path points to, whether output_path is required for saving, and what effect the operation has on the source file. The presence of an output schema does not compensate for missing input semantics.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must explain parameters, and it does explain the 'formats' parameter well with a concrete mapping example. However, it provides no semantic detail for file_path or output_path, which are important for actually invoking the tool. The formats explanation is useful but the compensation for the other parameters is incomplete.

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

  Purpose4/5

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

  The description clearly states the action and resource: 'Change variable display formats' using the FORMATS command. It gives concrete examples that make the purpose unambiguous. However, it does not explicitly contrast itself with sibling tools like spss_variable_labels or spss_value_labels, so it misses the last bit of differentiation.

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

  Usage Guidelines2/5

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

  The description provides syntax and a prerequisite ('Requires IBM SPSS Statistics') but gives no guidance on when to use this tool versus alternatives. An agent is not told when FORMATS is appropriate compared to variable labels, recoding, or other SPSS transformation tools. The implied use case from the first sentence is the only signal.

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

• spss_graph_histogramC
  2.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It does disclose that normal_curve=True overlays the normal curve and that IBM SPSS Statistics is required, which adds useful behavioral context. However, it does not mention whether the tool creates a new output file, modifies anything, or how it behaves if the variable is invalid.

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

  Conciseness4/5

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

  The description is extremely short and front-loads the key concept ('Histogram'). Both sentences provide useful information without redundancy. It is appropriately concise, though it sacrifices explanatory depth.

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

  Completeness2/5

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

  Given the low schema coverage and absent annotations, this definition is not complete enough for an agent to confidently invoke it. The description omits file_path semantics, title meaning, and any indication of the output behavior, even though an output schema exists.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for undocumented parameters. It explains normal_curve behavior and references the variable through the syntax, but it does not explain file_path or title at all, leaving two parameters semantically under-specified.

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

  Purpose4/5

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

  The description clearly identifies the tool as producing a histogram and even gives the exact SPSS syntax ('GRAPH /HISTOGRAM[(NORMAL)]=var'). It is distinguishable from sibling graph tools like spss_graph_scatter, spss_graph_boxplot, and spss_graph_bar by name and the histogram-specific syntax, though it does not explicitly contrast itself with those siblings.

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

  Usage Guidelines2/5

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

  No guidance is given about when to choose this tool over alternatives such as spss_frequencies or spss_graph_bar. The only practical note is 'Requires IBM SPSS Statistics,' which is an environment requirement rather than usage guidance.

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

• spss_save_fileC
  2.9/5.0
  Behavior2/5

  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 the core saving operation and the rename/keep/drop options, but does not disclose whether an existing output file is overwritten, whether the active dataset is modified, what happens with compression, or the relationship between file_path and output_path. This is a meaningful gap for a persistence operation.

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

  Conciseness4/5

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

  The description is compact and front-loaded: the main action and syntax appear in the first sentence, and the optional parameter semantics follow in a clear list. It earns its length without excess prose, though it could be slightly clearer with examples or explicit parameter labels.

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

  Completeness2/5

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

  For a six-parameter tool with no annotations and only partial parameter documentation, the description is not complete enough. It explains the optional transformation arguments but leaves core required parameters unexplained and omits behavioral details like overwrite semantics and the role of compressed. The output schema helps with return values but does not compensate for these operational gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It explains rename, keep, and drop, but does not define file_path, output_path, or compressed. The names file_path and output_path hint at source and destination, but the description never clarifies whether file_path is the current dataset or a source file, leaving required parameters ambiguous.

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

  Purpose5/5

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

  The description names a specific verb and resource: 'Save the active dataset', and immediately anchors it to the SPSS syntax 'SAVE OUTFILE'. The optional rename/keep/drop behavior further clarifies the tool's purpose and distinguishes it from the many analysis, transformation, and export sibling tools.

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

  Usage Guidelines2/5

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

  The description states what the tool does but gives no guidance on when to choose it over alternatives, no prerequisites beyond requiring SPSS, and no exclusions. It does not mention that this is for persisting the working dataset rather than exporting output, nor when not to use it.

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

• spss_sort_casesC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core operation but does not reveal whether sorting modifies the input file in place, writes to output_path, or returns a sorted dataset. Side effects are completely unspecified, which is a critical gap for a transformation tool.

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

  Conciseness5/5

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

  The description is one efficient sentence plus two clarifying fragments. Every word earns its place: the core action, the sort_keys format, and the SPSS prerequisite. It is front-loaded with the main purpose and contains no fluff or repetition.

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

  Completeness2/5

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

  Although an output schema exists (so return values need not be described), the description misses essential invocation details. It does not explain how file_path relates to the data being sorted, whether output_path defaults to overwriting the source, or what happens if output_path is null. For a data mutation tool with no annotations, these gaps make the definition incomplete.

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

  Parameters3/5

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

  The description adds meaningful structure for sort_keys ('list of {'variable': name, 'order': 'A'|'D'} dicts'), which the schema leaves as generic objects. However, with 0% schema coverage, it fails to explain file_path or output_path, especially the critical default-null behavior of output_path. Partial compensation for the main parameter but not the full parameter set.

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

  Purpose4/5

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

  The description uses a specific verb and resource ('Sort cases by one or more variables'), which clearly distinguishes it from sibling tools like spss_rank or spss_flip. It does not explicitly name a sibling alternative, but the action is unambiguous. A 4 is appropriate rather than 5 because no explicit differentiation from similar transformation tools is provided.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives, such as spss_run_syntax or spss_aggregate. The only contextual note is 'Requires IBM SPSS Statistics,' which is a prerequisite, not a usage guideline. There are no mentions of preconditions, output_path behavior, or when sorting is appropriate.

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

• spss_star_joinC
  2.9/5.0
  Behavior2/5

  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, but it only states the join intent and software requirement. It does not disclose whether an output file is created, whether existing output_path is overwritten, what join semantics apply (e.g., inner vs. outer), or what happens on key mismatches.

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

  Conciseness5/5

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

  Two tight sentences deliver the operation, syntax pattern, key parameter semantics, and a prerequisite without filler. The core join behavior is front-loaded, and every sentence earns its place.

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

  Completeness2/5

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

  The description is too thin for an 8-parameter tool with no annotations and no schema property descriptions. Even though an output schema exists, the description omits important operational context like join direction, output file behavior, alias purposes, and constraints on key variables, making it inadequate for confident invocation in edge cases.

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

  Parameters3/5

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

  The description adds genuine meaning for base_key/join_key as matching variable names and for select_fields with a concrete alias-qualified example. However, schema description coverage is 0%, and the description leaves base_file, join_file, output_path, base_alias, and join_alias to inference from names/defaults, so it only partially compensates for the schema gap.

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

  Purpose4/5

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

  The description clearly identifies a specific operation—an SQL-style join of two .sav files using STAR JOIN syntax—so an agent can tell what resource it acts on. It stops short of a 5 because it does not explicitly differentiate itself from the closely related sibling spss_match_files.

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

  Usage Guidelines2/5

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

  No guidance is given about when to choose this tool over alternatives such as spss_match_files or spss_add_files. The only contextual signal is the prerequisite 'Requires IBM SPSS Statistics,' which addresses environment constraints rather than use-case selection.

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

• spss_computeB
  3/5.0
  Behavior3/5

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

  The description discloses the main mutating behavior—overwriting an existing target variable—and notes the external dependency on SPSS. However, with no annotations, it leaves important behavioral details unstated, such as what happens to the input file when output_path is omitted and whether the operation modifies the file in place.

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

  Conciseness5/5

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

  The description is concise and front-loaded with the core action. The two sentences plus examples contain no filler, and the most important parameter semantics are presented efficiently.

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

  Completeness2/5

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

  For a tool with no annotations and no parameter descriptions in the schema, the description only partially covers what is needed to call it correctly. It explains expression and the overwrite caveat, but omits file_path and output_path semantics and how this tool differs from its many transformation siblings; the presence of an output schema does not fill those gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for all four parameters. It adds useful meaning for expression with examples and implies target_variable's role, but file_path and output_path are left unexplained, and target_variable has no explicit constraints or naming rules.

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

  Purpose4/5

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

  The description clearly states the tool's action: creating a new variable or overwriting an existing one with a computed expression. It names the resource (variable) and provides concrete examples, but it does not explicitly differentiate itself from overlapping siblings like spss_compute_scale_score or spss_if_transform.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus nearby alternatives such as spss_compute_scale_score, spss_if_transform, or spss_recode. The only operational note, 'Requires IBM SPSS Statistics,' is a prerequisite rather than a selection rule.

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

• spss_genlinmixedB
  3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full behavioral disclosure burden. It only states that the tool 'runs' a model and requires SPSS to be installed; it does not disclose whether the operation modifies data, writes files, or produces specific outputs. The behavioral traits of execution are left largely unspecified.

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

  Conciseness4/5

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

  The description is short and front-loaded, with the model type in the first sentence and the key prerequisite in the final clause. It is concise and well-ordered, though it uses its brevity to omit substantive guidance.

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

  Completeness2/5

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

  For a complex modeling tool with 7 parameters and multiple sibling model types, the description is materially incomplete. It does not clarify parameter roles, when to select this over spss_genlin or spss_mixed, or what running the model implies operationally. Although an output schema exists, the missing parameter and usage context makes the definition insufficient for correct invocation.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description mentions no parameters by name or semantic role. It never explains file_path, dependent, fixed_effects, random_effects, link, subject, or distribution, so it does not compensate for the lack of schema-level documentation at all.

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

  Purpose5/5

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

  The description uses the specific verb 'Run' with the resource 'generalized linear mixed model combining GLM with random effects.' It explicitly identifies the model type and distinguishes it from sibling tools like spss_genlin and spss_mixed by noting it combines GLM with random effects, making the purpose clear and differentiated.

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

  Usage Guidelines3/5

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

  The phrase 'Supports non-normal outcomes with hierarchical structure' implies when the tool is appropriate, but it does not explicitly state when to use this tool over spss_genlin, spss_mixed, or other modeling siblings, nor does it mention any exclusions. Usage context is implied rather than directly guided.

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

• spss_glm_univariateB
  3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the installation prerequisite and supported analysis features, but does not disclose side effects such as whether 'save_predicted' modifies data files, whether SPSS is launched in batch mode, or what operational constraints apply.

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

  Conciseness5/5

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

  The description is three short, purposeful sentences: action first, capabilities second, environment prerequisite third. It is front-loaded, avoids redundancy with the tool name, and contains no filler.

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

  Completeness2/5

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

  For an 8-parameter statistical tool with no annotations and no schema descriptions, the description is too sparse to enable confident invocation. It leaves unclear how to specify variables, what file formats are expected, which parameters are optional or mutually exclusive, and how this GLM tool relates to nearby siblings like spss_anova.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only loosely hints at factors, emmeans, and posthoc parameters without explaining their formats or relationships. It adds no meaning for file_path, dependent, covariates, posthoc_method, or save_predicted, so parameter semantics remain largely underdocumented.

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

  Purpose4/5

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

  The description states a specific action ('Run univariate general linear model') and a clear scope ('factorial designs'), while mentioning distinctive capabilities like estimated marginal means, contrasts, and post-hoc tests. It does not explicitly differentiate from close siblings such as spss_anova or spss_manova, but the univariate/factorial framing provides adequate orientation.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool: for univariate GLMs with factorial designs and optional post-hoc/emmeans analyses. However, it gives no explicit when-not-to-use guidance or alternatives among the many SPSS analysis siblings, leaving routing largely to the agent's inference.

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

• spss_autorecodeB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It does not state whether the original file is modified, whether new variables are created, what new_names and output_path do, or how failures or existing values are handled.

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

  Conciseness5/5

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

  Two tight sentences with no filler. The core transformation and order default are front-loaded, and the SPSS prerequisite is a useful one-line addition.

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

  Completeness2/5

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

  For a five-parameter tool with zero schema descriptions and no annotations, this is incomplete. The agent lacks essential details about required inputs, optional outputs, and side effects, though the output schema provides some structural return information.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It explains only the order parameter and its default, leaving required parameters file_path and variables, plus new_names and output_path, completely undocumented.

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

  Purpose5/5

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

  States a specific action and outcome: 'Automatically recode string/categorical values into consecutive integers.' This clearly distinguishes it from generic recoding or transformation tools among the siblings, and the order parameter is described.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool instead of related tools such as spss_recode, spss_compute, or spss_value_labels. The only contextual note is the prerequisite 'Requires IBM SPSS Statistics,' which does not help with tool selection.

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

• spss_correlationsB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden, but it only reports that SPSS must be installed. It does not disclose whether the operation is read-only, whether it writes outputs or modifies the dataset, or what conditions cause it to fail. 'Compute' weakly implies analysis, but side effects and limitations are left unspecified.

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

  Conciseness5/5

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

  Two short sentences pack the core purpose and a key prerequisite. The key action is front-loaded, and there is no filler or repetition of schema fields.

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

  Completeness2/5

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

  Although an output schema exists and reduces the need to explain return values, the tool still lacks usage context and parameter semantics. For a statistical analysis tool with many siblings and four parameters, this sparse description does not give the agent enough to invoke it correctly without additional probing.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only adds meaning to the method parameter by naming Pearson and Spearman. The required file_path and variables, plus two_tailed, are not explained; the agent must infer their semantics from parameter names alone. The description does not compensate for the schema gap.

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

  Purpose5/5

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

  The description states a specific command ('Run SPSS CORRELATIONS') and a concrete outcome ('compute Pearson or Spearman correlation matrix'), which precisely identifies the tool's role among the many SPSS siblings. The method choices reinforce the scope without ambiguity.

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

  Usage Guidelines2/5

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

  No when/when-not guidance or alternatives are given. The only contextual note is the installation prerequisite, which is an environment constraint rather than guidance for choosing this over, say, spss_regression or spss_crosstabs. The intended use must be inferred from the tool's name and purpose.

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

• spss_flipB
  3.1/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full burden. It mentions two parameters but does not disclose whether the original file is modified, how output_path is handled, or whether the operation is reversible. The 'Requires IBM SPSS Statistics' note describes the environment, not the behavior of the operation.

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

  Conciseness4/5

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

  The description is compact and front-loads the core purpose. It packs the two important parameter explanations into one sentence without waste, though it is somewhat terse and would benefit from a clearer parameter list.

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

  Completeness2/5

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

  Given the large sibling family of transform tools and the presence of an output schema, the description still misses essential context: it doesn't say whether the transform writes to output_path or mutates the source file, and it fails to differentiate from spss_cases_to_vars/spss_vars_to_cases. An agent lacks enough information to invoke it correctly and safely.

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

  Parameters3/5

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

  Schema property descriptions are entirely absent (coverage 0%), so the description must compensate. It usefully explains 'variables' (subset to flip, default all) and 'newnames_variable' (values become column names), but it omits any semantics for the required file_path and for output_path, leaving those parameters under-specified.

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

  Purpose5/5

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

  The description states a precise transformation—'Transpose rows and columns'—and names it as the SPSS FLIP command. This clearly distinguishes it from sibling data-shaping tools like spss_cases_to_vars and spss_vars_to_cases.

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

  Usage Guidelines2/5

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

  No guidance is given about when to choose FLIP over alternative reshaping tools. The only qualification is the environmental requirement 'Requires IBM SPSS Statistics,' which is a prerequisite, not a usage selector. An agent receives no instructions on when to use this vs siblings.

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

• spss_ordinal_regressionB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears the full burden. It mentions a runtime prerequisite and the parallel lines test capability, but it does not disclose side effects, whether data is modified, what happens with saved predictions, or what output behavior is expected beyond what the output schema might provide.

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

  Conciseness5/5

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

  The description is compact and front-loaded, with each sentence contributing meaningful information: what the tool does, what capabilities it has, and a key prerequisite. There is no filler or redundant restating of the tool name.

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

  Completeness3/5

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

  The description covers the core purpose, typical use case, and a key external dependency, while an output schema exists to document return values. However, given a 7-parameter tool with no annotations and near-zero schema description coverage, it lacks guidance on parameter semantics, data prerequisites, and alternative tool selection, making it adequate but not fully complete.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It adds context for the 'link' parameter ('multiple link functions') and 'test_parallel' ('parallel lines test'), but required parameters like file_path, dependent, and predictors are not explained, leaving the agent to infer their meaning from names alone.

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

  Purpose4/5

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

  The description states a specific action ('Run ordinal regression (PLUM)') and the target scenario ('ordered categorical outcomes'), making the tool's purpose clear. It distinguishes itself from siblings like spss_logistic_regression by naming PLUM and the ordered-outcome use case, though it does not explicitly compare against alternatives.

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

  Usage Guidelines3/5

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

  The phrase 'for ordered categorical outcomes' implies when this tool should be used, and the prerequisite 'Requires IBM SPSS Statistics to be installed' is a useful condition. However, it does not explicitly say when to prefer this over spss_regression, spss_logistic_regression, or spss_genlin, nor does it state when not to use it.

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

• spss_aggregateB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the IBM SPSS Statistics requirement and shows the generated syntax, but it does not mention file creation/overwrite behavior, handling of missing values, or what happens when break_variables is null.

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

  Conciseness4/5

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

  The description is compact and front-loaded with the tool's purpose, followed by syntax and a precise aggregation list format. Every sentence contributes useful information, though the SPSS syntax shorthand is terse for non-SPSS users.

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

  Completeness3/5

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

  The core call shape is present: BREAK variables, aggregation functions, source variables, and the SPSS dependency. The output schema presumably covers return values, but side effects such as output file behavior and null break_variables semantics are left ambiguous, making the description adequate rather than complete.

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

  Parameters3/5

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

  Schema description coverage is 0%, but the description adds valuable semantics for the aggregations parameter, including new_var, function enum, and source. It does not explain file_path, output_path, or the null break_variables case beyond the SPSS /BREAK syntax, so compensation is only partial.

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

  Purpose4/5

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

  The description opens with 'Group-wise summaries' and provides the SPSS AGGREGATE syntax plus an enumeration of supported functions, making the tool's purpose unambiguous. It differentiates itself from sibling analysis/transform tools by describing an aggregation operation, though it does not explicitly name a sibling it is not.

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

  Usage Guidelines3/5

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

  The phrase 'Group-wise summaries' implies the intended use case, but the description gives no explicit guidance about when to choose this tool over alternatives such as descriptives or frequencies. No exclusions or when-not-to-use conditions are provided.

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

• spss_cox_regressionB
  3.2/5.0
  Behavior3/5

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

  With no annotations available, the description carries the burden of behavioral disclosure. It provides useful context by naming the external installation requirement and describing supported analyses. It does not disclose side effects, failure behavior, or whether the operation writes files or modifies the input dataset, which leaves some behavioral ambiguity.

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

  Conciseness5/5

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

  The description is two sentences with no filler. The action and domain are front-loaded, followed by capability and prerequisite details that are relevant for invocation.

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

  Completeness2/5

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

  The tool has 9 parameters, 5 required, with zero schema descriptions, and the description does not explain how to populate core fields beyond the procedure name. An agent cannot confidently determine status_event_value semantics, categorical variable treatment, or method choice from this definition. The presence of an output schema reduces return-value ambiguity but does not fill the invocation gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate, but it only alludes to stratification and time-dependent covariates. It does not clarify required parameters such as status_event_value, the method enum values (ENTER/FSTEP/BSTEP), categorical handling, or save_survival. The parameter names are somewhat self-explanatory, which prevents a score of 1.

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

  Purpose4/5

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

  The description identifies a specific procedure ('Cox proportional hazards regression') with a clear verb ('Run') and domain ('survival analysis'). It advertises distinctive capabilities like time-dependent covariates, stratification, and diagnostics, which separates it from most siblings by analytic method. It does not explicitly contrast with spss_kaplan_meier, but the named technique is unambiguous.

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

  Usage Guidelines3/5

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

  The phrase 'for survival analysis' establishes the appropriate data context, and the IBM SPSS prerequisite tells the agent when the tool cannot be used. However, it does not explicitly state when to prefer this tool over survival-adjacent siblings like spss_kaplan_meier or over regression alternatives such as spss_logistic_regression. The usage guidance is implied rather than explicit.

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

• spss_declare_variablesB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of disclosing behavior. It says the tool declares new empty variables, but it does not state whether this modifies the file in place, whether existing variables are affected, whether output_path controls a new file, or what happens to the dataset after declaration. The IBM SPSS prerequisite is the only non-obvious behavioral detail.

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

  Conciseness4/5

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

  The description is compact and front-loaded: the core action comes first, followed by the parameter shape and a one-line prerequisite. Every sentence contributes, though the last sentence about IBM SPSS Statistics is more of a system requirement than an action guideline.

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

  Completeness3/5

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

  For a simple declaration tool this is mostly adequate, but with 4 parameters and no annotations, the description should clarify what file_path refers to and what output_path controls. The presence of an output schema reduces the need to describe return values, but the missing I/O semantics and lack of usage guidance leave noticeable gaps.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It does explain the two main dictionaries, numeric_vars and string_vars, with the expected {name: format} shape and examples. However, it does not explain file_path or output_path, including what output_path=null means or whether file_path is the input .sav file.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Declare new empty variables', and immediately clarifies the two supported kinds (NUMERIC and STRING) with example formats. This clearly differentiates the tool from siblings like spss_compute or spss_recode, which transform existing variables rather than declaring new empty ones.

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

  Usage Guidelines2/5

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

  The description states a prerequisite ('Requires IBM SPSS Statistics') but gives no guidance on when to choose this tool over alternatives such as spss_compute, spss_recode, or spss_variable_labels. There is no mention of when not to use it or what distinguishes this declaration step from other variable-manipulation tools.

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

• spss_logistic_regressionB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully notes that IBM SPSS Statistics must be installed, but it does not state whether the tool writes or modifies files, whether it has side effects, what happens when SPSS is unavailable, or what errors or outputs to expect. This is a significant gap for an execution tool.

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

  Conciseness4/5

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

  The description is concise and front-loaded, with each sentence serving a purpose: what it does, what it supports, and what it requires. It could include more parameter guidance without becoming bloated, but as written it is tight and free of filler.

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

  Completeness2/5

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

  Given eight parameters, no annotations, and no schema-level descriptions, the description leaves key usage details unexplained. While an output schema exists, the tool still lacks guidance on parameter semantics, side effects, and relationship to sibling regression tools, making it incomplete for an agent to invoke confidently.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for parameter meaning. It hints at 'stepwise selection' and 'categorical predictors,' which map to method and categorical, but it provides no explanation of required params like file_path, dependent, and predictors, or optional params like contrast, print_options, and save_predicted. The compensation is insufficient.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with a specific verb ('Run') and resource ('binary or multinomial logistic regression'). It also distinguishes the tool from siblings like spss_regression and spss_ordinal_regression by naming the exact model family and scope.

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

  Usage Guidelines3/5

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

  The description implies use for logistic regression tasks, which gives basic context. However, it does not explicitly state when to choose this tool over sibling alternatives, nor does it provide exclusions or conditions where another regression tool would be more appropriate.

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

• spss_quick_clusterB
  3.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry behavioral context. It discloses that save_cluster_variable creates a new variable and print_anova adds an ANOVA table, and it notes the SPSS requirement. However, it does not explain side effects on the dataset, missing-data handling, or failure behavior.

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

  Conciseness4/5

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

  The description is compact and uses a terse syntax-style format that conveys the core command and key options without excessive prose. The required-SPSS note is useful context, though the parameter explanations are embedded in a slightly scattered way.

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

  Completeness3/5

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

  Given six parameters, no annotations, and an output schema, the description gives a usable but incomplete picture. It covers the main purpose and optional behaviors, but omits details like variable type requirements, missing data behavior, and guidance for selecting between cluster methods, leaving the agent to infer too much.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It adds meaning by mapping n_clusters and max_iterations to CLUSTER(k) and MXITER(n), and it explains save_cluster_variable and print_anova. However, file_path and variables rely entirely on their self-explanatory names, with no further detail.

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

  Purpose4/5

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

  The description clearly identifies the tool as performing K-means clustering and mentions the SPSS QUICK CLUSTER command. It explains what save_cluster_variable and print_anova do, but it does not explicitly differentiate this from sibling cluster tools like spss_cluster_hierarchical or spss_twostep_cluster.

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

  Usage Guidelines2/5

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

  The description provides the SPSS requirement and a command template but gives no guidance on when to choose this tool over alternative clustering methods. It does not state prerequisites such as numeric variables or when k-means is appropriate versus hierarchical or two-step clustering.

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

• spss_t_testB
  3.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose the important external dependency that IBM SPSS Statistics must be installed, and it states the supported test modes. However, it does not mention side effects, output behavior, or data requirements, which is a notable gap for an execution tool.

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

  Conciseness5/5

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

  Two tightly constructed sentences with no filler. The purpose is front-loaded, the supported types follow, and the installation requirement is a necessary and distinct fact.

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

  Completeness2/5

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

  For a tool with 5 parameters, no annotations, and 0% schema description coverage, this definition is too sparse. The output schema reduces the need to describe return values, but the description still leaves critical parameter semantics and variant-specific requirements unexplained, making correct invocation uncertain.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate, but it only sheds light on test_type. It does not explain file_path, variables, test_value, or grouping_variable, nor the per-test-type parameter relationships such as test_value being relevant for one_sample and grouping_variable for independent t-tests.

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

  Purpose4/5

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

  The description opens with a specific verb and resource — 'Run SPSS t-test' — and enumerates the supported test types (one_sample, independent, paired), making the core purpose clear. However, it does not explicitly contrast this tool with statistical siblings like spss_anova or spss_nonparametric_tests, 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.

  Usage Guidelines3/5

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

  The description implies this tool should be used when a t-test is needed and lists the supported variants, but it gives no explicit when-to-use or when-not-to-use guidance relative to alternatives. An agent must infer selection from the tool name and sibling names.

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

• spss_anovaB
  3.3/5.0
  Behavior2/5

  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, but it only mentions that the tool runs SPSS and requires installation. It does not explain what the tool returns, whether it modifies any files, how errors are surfaced, or how missing/invalid data is handled, leaving significant behavioral uncertainty.

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

  Conciseness5/5

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

  The description is very short and front-loaded with the main action. Every sentence provides useful information: what the tool runs, the optional post-hoc enhancement, and a required environmental prerequisite.

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

  Completeness2/5

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

  Although an output schema exists, the overall definition is incomplete for an agent trying to call the tool correctly: required parameter meanings are absent, usage guidance versus sibling tools is missing, and post-hoc value formats are underspecified. The description covers only a small fraction of what an agent would need.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate, but it only adds examples for the post_hoc parameter (TUKEY, BONFERRONI, LSD). It does not define file_path, dependent, or factor, leaving critical required parameters undocumented beyond their names.

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

  Purpose5/5

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

  The description names a specific statistical procedure ('one-way ANOVA (ONEWAY)') and clearly distinguishes it from the many sibling analysis tools, including repeated measures, MANOVA, and t-test. It also states the optional post-hoc capability, making the purpose unambiguous.

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

  Usage Guidelines3/5

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

  The description implies when one-way ANOVA is appropriate by naming the procedure, but it does not explicitly contrast it with alternatives like t-test, repeated measures ANOVA, or regression, nor does it state conditions such as group count or assumptions. The only clear prerequisite is that IBM SPSS Statistics must be installed.

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

• spss_descriptivesB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full disclosure burden. It does reveal the returned statistics (N, mean, std deviation, min, max) and the system requirement, which is useful. But it does not disclose whether the operation modifies files, how it handles invalid variables, or any error behavior, leaving gaps for a read-only-looking analysis command.

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

  Conciseness5/5

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

  The description is three concise sentences with no filler. It front-loads the action and scope, then gives output and environment context. Every sentence earns its place.

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

  Completeness3/5

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

  The presence of an output schema helps explain return structure, and the description lists key statistics, but the bare input schema and lack of parameter guidance make the definition incomplete. Key details about file_path and statistics options are missing, and no differentiation from siblings is offered.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate. It adds some meaning by specifying that variables are numeric and that statistics are optional, but it does not explain file_path at all, nor does it provide any hint about what values the statistics parameter accepts. An agent would likely struggle to correctly construct the parameters.

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

  Purpose4/5

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

  The description clearly states the operation: 'Run SPSS DESCRIPTIVES for numeric variables' and lists the statistics produced. It is specific about the procedure and scope, but does not distinguish it from similar siblings like spss_frequencies or spss_crosstabs, so it loses a point.

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

  Usage Guidelines3/5

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

  The description gives a scope condition ('for numeric variables') and a prerequisite ('Requires IBM SPSS Statistics to be installed'), which implies appropriate usage. However, it does not explicitly say when to choose this tool over alternatives such as spss_frequencies, nor does it state any exclusions.

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

• spss_graph_scatterB
  3.3/5.0
  Behavior3/5

  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 that IBM SPSS Statistics is required and reveals the exact syntax and optional paneling behavior. However, it does not describe side effects on files, output details, or any limitations.

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

  Conciseness5/5

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

  The description is extremely compact and front-loaded with the chart type. The SPSS syntax and software prerequisite each add useful information without redundant prose.

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

  Completeness2/5

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

  Even with an output schema present, the definition lacks enough context for reliable invocation. The meaning of file_path is not specified, optional parameters are only implied by syntax, and there is no guidance on variable requirements or when to choose this tool over related analyses.

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

  Parameters2/5

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

  Schema property coverage is 0%, so the description must compensate. It maps y_variable, x_variable, and panel_variable to positions in the SPSS syntax, but it says nothing about the required file_path or the optional title, leaving key parameters undocumented.

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

  Purpose5/5

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

  The description states this creates a scatterplot and gives the exact SPSS command structure, 'GRAPH /SCATTERPLOT(BIVAR)=y WITH x [BY panel]'. This clearly distinguishes it from sibling chart tools like histogram, boxplot, and bar.

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

  Usage Guidelines2/5

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

  The description provides no explicit when-to-use or when-not-to-use guidance. It only notes the SPSS requirement and does not mention alternatives such as correlation or regression, nor when the optional BY panel parameter should be used.

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

• spss_if_transformB
  3.3/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden. It reveals the formula and IBM SPSS dependency but says nothing about whether it modifies the input file in place, what output_path does, or any side effects. For a transformation tool that likely writes or overwrites data, this is a meaningful gap.

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

  Conciseness5/5

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

  Three short sentences deliver the formula, an example, and the environment requirement. The purpose is front-loaded and there is no filler.

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

  Completeness2/5

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

  For a tool with four required parameters, the description still lacks the file/output semantics needed to call it correctly, particularly in-place modification vs saved output. The example helps, but the overall operational contract is incomplete.

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

  Parameters2/5

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

  The input schema has 0% description coverage, so the description must compensate. It clarifies condition, target_variable, and expression with the IF formula and example, but leaves file_path and output_path unaddressed. This is partial compensation but not enough for a tool with required file and optional output parameters.

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

  Purpose5/5

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

  The description names the exact operation ('Conditionally assign a value') and shows the SPSS IF syntax with a concrete example. This makes the tool's purpose unambiguous and distinguishes it as the conditional-assignment counterpart to siblings like spss_compute.

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

  Usage Guidelines3/5

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

  It implies use whenever a conditional assignment is needed and gives a concrete condition example, but it does not state when to prefer spss_if_transform over spss_compute, spss_recode, or spss_select_if. No exclusions or explicit alternative guidance are provided.

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

• spss_proximitiesB
  3.3/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the burden. It does disclose the underlying SPSS command, the result type, and the IBM SPSS requirement, which is useful; however, it remains silent on casewise handling, how id_variable is used, and whether standardize alters the matrix before computation.

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

  Conciseness5/5

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

  The text is compact and front-loaded: the operation appears first, followed by concise option enumerations and the environment requirement. Every clause contributes without repetition or filler.

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

  Completeness2/5

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

  Although an output schema exists, the tool still has six parameters with no schema descriptions and no usage context. Missing semantics for id_variable and standardize, plus no guidance about when a proximity matrix is appropriate, leave the definition incomplete for an agent that must call it independently.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must explain the six parameters. It covers measure and view with value lists, but leaves file_path, variables, id_variable, and standardize semantically unexplained; an agent cannot determine valid values for standardize or the role of id_variable from the text.

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

  Purpose5/5

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

  The description leads with 'Distance/similarity matrix' and shows the exact SPSS PROXIMITIES command, so an agent immediately knows this computes a proximity matrix. The measure and view options further distinguish it from correlation, cluster, and factor siblings.

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

  Usage Guidelines2/5

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

  There is no guidance about when to choose this tool over alternatives such as spss_correlations or spss_cluster_hierarchical. The description lists measures and orientations but does not state prerequisites, analytical intent, or exclusion conditions.

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

• spss_select_ifB
  3.3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses that the operation is permanent and that output_path can save the filtered result as a new .sav file, which is useful. However, it does not clarify the exact behavior when output_path is null—whether the original file is overwritten or modified in place.

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

  Conciseness5/5

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

  Three short, purposeful sentences. The core behavior is front-loaded, output_path usage is explained, and the SPSS dependency is stated without any redundant filler.

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

  Completeness3/5

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

  For a three-parameter tool, the description covers the core behavior and the optional output parameter, and an output schema is present. Still, it lacks explicit detail about what happens without output_path, how file_path is used, and when to choose this over sibling tools.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It explains the condition parameter as an SPSS SELECT IF condition and explains output_path as the destination for a new .sav file, but file_path is left to inference and not explicitly described.

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

  Purpose4/5

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

  The description clearly states the action ('Permanently keep only cases matching a condition') and the SPSS command it corresponds to ('SELECT IF'), with a clear resource (cases in a data file). It is distinct enough in meaning but does not explicitly name any sibling tool it differs from, such as spss_filter.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives like spss_filter or spss_if_transform. 'Permanently' implies a contrast with temporary filtering, but no explicit exclusions or alternatives are provided.

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

• spss_value_labelsB
  3.3/5.0
  Behavior3/5

  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 command format, the expected value_labels structure, and the SPSS dependency. However, it does not state whether the original file is modified when output_path is null, whether existing value labels are overwritten, or what happens on invalid values.

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

  Conciseness5/5

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

  The description is compact and front-loaded: action, syntax, example, and dependency are each expressed in the minimum number of words. Every sentence adds information and there is no filler.

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

  Completeness3/5

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

  For a 3-parameter tool with no annotations, the description is adequate for invoking the tool but leaves a meaningful gap around output_path behavior and file mutation semantics. It provides a concrete example and names the required dependency, but an agent cannot fully predict whether the tool edits in place or writes a new file.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It does explain value_labels thoroughly with the nested variable->value->label example, but file_path and output_path are left entirely to name-based inference. This is partial compensation only.

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

  Purpose4/5

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

  The description opens with a clear imperative 'Set value labels' and immediately shows the SPSS VALUE LABELS syntax plus an example dictionary, so an agent can tell what the tool does. It does not explicitly distinguish itself from the sibling spss_variable_labels, though the command syntax and value-level example make the distinction inferable.

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

  Usage Guidelines2/5

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

  There is no guidance about when to prefer this tool over alternatives such as spss_variable_labels, spss_formats, or spss_recode. The only usage-related context is 'Requires IBM SPSS Statistics', which is a prerequisite rather than a selection rule.

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

• spss_vars_to_casesB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description bears the full burden of behavioral disclosure. It reveals the underlying SPSS transformation and the requirement for SPSS, but it does not state whether the original file is modified, whether a new file is written, what happens to unspecified variables, or how count_variable/index_name affect output. These are material behavioral gaps for a restructuring operation.

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

  Conciseness4/5

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

  The description is compact and front-loaded with the main purpose. Each clause adds useful information: the transformation direction, the SPSS command form, parameter formats, and the SPSS requirement. It is efficient, though a bit telegraphic.

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

  Completeness2/5

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

  For a 6-parameter transformation tool with no annotations and zero schema description coverage, the description is incomplete. It does not explain count_variable or output behavior, and an agent would not know whether the operation overwrites the input or writes to output_path. The presence of an output schema does not cover these gaps.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It explains make_specs, index_name, and id_name clearly. However, it omits file_path, output_path, and count_variable, all of which have meaning the schema alone does not convey. It partially compensates but not completely.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Restructure wide → long format' with the exact SPSS command ('VARSTOCASES /MAKE newvar FROM varlist'). This clearly distinguishes it from sibling tools like spss_cases_to_vars and spss_flip, making the operation unambiguous.

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

  Usage Guidelines3/5

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

  The description clearly indicates the use case (wide-to-long reshaping) and a prerequisite ('Requires IBM SPSS Statistics'). However, it does not explicitly say when not to use it, nor does it name alternative tools or conditions for choosing them. The guidance is implied through the wide-to-long semantics rather than explicit.

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

• spss_factorB
  3.4/5.0
  Behavior3/5

  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 the analysis is run and what output it includes, and that SPSS must be installed. However, it does not mention side effects, failure behavior, or whether the operation is read-only, though for an analysis tool the disclosed information is reasonably informative.

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

  Conciseness5/5

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

  The description is two sentences with no filler. The main action is front-loaded, followed by output highlights and a necessary dependency statement.

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

  Completeness3/5

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

  The description gives the core purpose and an external prerequisite, and an output schema exists to describe return values. However, with five parameters and no schema-level descriptions, it lacks enough context about how to configure the analysis, especially method, rotation, and factor count.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description should compensate. It only alludes to method choices ('principal components or principal axis factoring') and rotation indirectly via 'rotated factor matrix', but it never explains file_path, variables, or n_factors.

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

  Purpose5/5

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

  The description clearly states a specific action and resource: 'Run SPSS FACTOR analysis'. It also lists key outputs like eigenvalues, variance explained, and rotated factor matrix, and the tool name plus sibling list make it distinct from other SPSS analysis tools.

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

  Usage Guidelines2/5

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

  No guidance is given on when to choose factor analysis over alternative procedures, nor does it mention any exclusions or sibling tools. The only contextual hint is the prerequisite that IBM SPSS Statistics must be installed, which is environmental rather than a usage criterion.

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

• spss_ratio_statisticsB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the underlying SPSS command structure and that IBM SPSS Statistics is required, which is useful, but it does not mention side effects, data prerequisites, output behavior, 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.

  Conciseness5/5

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

  The description is compact and front-loaded, packing the essential syntax template, statistic options, and a system requirement into a few lines with no redundancy. Every sentence contributes information.

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

  Completeness3/5

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

  For a moderately complex tool with no schema parameter descriptions and no annotations, the description is useful but incomplete. It conveys the command shape and optional statistics but omits file_path semantics, data requirements, and any expectation of the returned output beyond what an output schema might cover.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It maps parameters to SPSS syntax positions (num, den, BY group), lists accepted statistics values, and clarifies the optional group variable. However, it does not describe the file_path parameter at all.

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

  Purpose4/5

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

  The description identifies the tool as computing ratio statistics and provides the SPSS syntax template, making the operation clear. It is distinguishable from sibling statistical tools by the explicit 'RATIO STATISTICS' command and the statistic options listed, though it lacks a direct verb phrase like 'computes'.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternative SPSS procedures such as descriptives, frequencies, or regression. Usage context is only implied by the tool name and the command syntax, with no exclusions or selection criteria.

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

• spss_recodeB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It usefully discloses the rule grammar, the 'preserves originals' effect of into_variables, the optional output_path, and the dependency 'Requires IBM SPSS Statistics.' However, it never states whether the original .sav file is modified in place, what happens when output_path is omitted, or how unmatched values are handled beyond an 'ELSE' clause.

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

  Conciseness5/5

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

  Three sentences: a front-loaded purpose statement, compact rule grammar, and a one-sentence prerequisite note. Every sentence provides necessary information without repetition or filler.

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

  Completeness3/5

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

  The description gives enough to attempt a basic recode and the output schema covers return values. However, recoding has subtle semantics that are not addressed: rule evaluation order, whether ranges are inclusive, whether ELSE must be last, and default handling if output_path or into_variables are omitted. For a complex transformation tool, this is a meaningful gap.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must compensate, and it does for the non-obvious parameters: rules, into_variables, and output_path. The rule object structure with old/new values, ranges, lists, ELSE, COPY, and SYSMIS is precisely specified. file_path and variables are only named, not defined, but their meaning is reasonably inferable from the tool purpose.

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

  Purpose4/5

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

  The lead sentence names a specific verb and resource: 'Recode variable values in a .sav file.' That is clear and unambiguous. It does not differentiate from the closely named sibling spss_autorecode or other transform tools, so it doesn't earn a 5.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to choose this tool over siblings such as spss_autorecode, spss_compute, or spss_if_transform. It provides rule syntax but no use-case conditions or exclusions, so an agent must infer applicability.

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

• spss_get_method_schemaA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It strongly implies a read-only introspection action ('Get the JSON schema', 'before execution'), but it does not explicitly state that the method is not executed, what happens for invalid tool names, or whether the method must already exist in the registry.

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

  Conciseness5/5

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

  The description is two concise sentences with no redundancy. The action and resource are front-loaded, and the usage context follows directly. Every word earns its place.

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

  Completeness3/5

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

  For a simple one-parameter schema-retrieval tool with an output schema, the description covers the purpose and usage adequately. However, it omits parameter semantics and does not mention how to discover valid method names, leaving an obvious gap for an agent preparing to call it.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explicitly explain that tool_name is the SPSS method name or how valid values can be discovered. An agent can infer the meaning from context, but the description should have pointed to spss_list_supported_methods for valid tool names.

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

  Purpose4/5

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

  The description states a specific verb ('Get') and resource ('JSON schema for a registry-backed SPSS method'), making the tool's purpose clear. It is implicitly distinct from siblings like spss_get_method_support, but it does not explicitly differentiate itself by naming alternatives.

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

  Usage Guidelines4/5

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

  The second sentence provides explicit usage context: 'useful for structured orchestration and parameter inspection before execution.' This tells an agent when to use it, though it does not mention when not to use it or name alternative tools.

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

• spss_manovaA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden and does disclose the main behavior: running multivariate tests and providing univariate follow-ups. It also adds the environmental prerequisite that IBM SPSS Statistics must be installed. It does not, however, mention potential side effects, output behavior, or whether any data is modified.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary action, and every sentence contributes either the procedure's purpose or a necessary external requirement. There is no filler or repetition.

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

  Completeness2/5

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

  For an 8-parameter tool with no annotations and no per-parameter descriptions, this is too sparse. The output schema may cover return values, but the agent still lacks guidance on parameter semantics and on choosing MANOVA over the many related statistical siblings. A simple call could be constructed from defaults, but non-default configurations remain ambiguous.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only loosely connects to dependents and factors, and it says nothing about file_path, covariates, factor_ranges, method (UNIQUE vs SEQUENTIAL), or the print flags. The parameter names and enum provide some structure, but the description adds almost no semantic detail.

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

  Purpose5/5

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

  The description states a specific verb ('Run'), a specific statistical procedure (MANOVA), and its defining condition ('multiple dependent variables'). It also distinguishes itself from siblings like spss_anova by emphasizing multivariate analysis and univariate follow-ups.

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

  Usage Guidelines3/5

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

  The description gives a clear application context: MANOVA for multiple dependent variables with factors. However, it offers no explicit guidance about when not to use it or which sibling tools (e.g., spss_anova, spss_glm_univariate, spss_repeated_measures_anova) to prefer in other scenarios.

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

• spss_reliability_alphaA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully states that the tool returns scale reliability and item statistics and that IBM SPSS Statistics must be installed. However, it does not explain what happens when SPSS is absent, whether any files are written, or other runtime behaviors.

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

  Conciseness5/5

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

  The description is two sentences with no filler. The core action is front-loaded, and the prerequisite about IBM SPSS Statistics is useful supporting information. Every sentence earns its place.

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

  Completeness2/5

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

  Although an output schema exists and the tool is narrowly scoped, the description omits essential parameter guidance and leaves model options and scale_name undefined. An agent would likely need additional inference or external knowledge to call this correctly with all optional parameters.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description compensates for none of the four parameters. It does not explain file_path, variables, the model ALPHA/OMEGA distinction, or scale_name. The mention of Cronbach's alpha only hints at the default model but does not clarify the parameter semantics.

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

  Purpose5/5

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

  The description clearly identifies the tool's action ('Run SPSS RELIABILITY analysis'), the specific method (Cronbach's alpha), and the domain (psychometric workflows). It is distinct from the many sibling analysis tools and leaves no ambiguity about what the tool does.

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

  Usage Guidelines4/5

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

  The phrase 'for psychometric workflows' provides clear context for when this tool is appropriate, and the specificity of Cronbach's alpha implies its use case. It does not explicitly name alternative tools or exclusions, but the niche scope makes the usage context reasonably clear.

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

• spss_add_filesA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It does disclose that the operation stacks cases, writes to an output_path, and requires IBM SPSS Statistics. However, it does not mention whether input files are modified, whether an existing output file is overwritten, or how conflicts between variable definitions are handled, which are meaningful behavioral gaps.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the core action, followed by a concise parameter breakdown and the external prerequisite. Every clause adds information and there is no filler or redundant restatement of the tool name.

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

  Completeness3/5

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

  The description covers the primary workflow and essential parameters, and an output schema is available for return-value understanding. However, it omits drop/keep semantics and lacks guidance on edge cases such as variable mismatches across files or how BY variables affect stacking, leaving an agent with noticeable uncertainty for non-trivial usage.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must explain all parameters. It meaningfully clarifies file_paths ('>=2 .sav files'), key_variables ('optional BY variables'), and output_path ('stacked result file'). However, drop and keep are completely undocumented in both schema and description, leaving their semantics ambiguous in a context where they could refer to cases or variables.

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

  Purpose5/5

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

  The description immediately states a specific action and resource: 'Stack cases from multiple files', with the clarifying synonym '(concatenate/union)' and the SPSS command 'ADD FILES'. This clearly differentiates the tool from nearby siblings like spss_match_files, which merges variables/columns rather than appending cases.

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

  Usage Guidelines3/5

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

  The description makes clear that this tool is for stacking/concatenating cases, implying it is the right choice when the goal is a row-wise union of .sav files. However, it does not explicitly state when not to use it, nor does it point to an alternative such as spss_match_files for variable-wise joining. Usage context is present but alternatives/exclusions are left implicit.

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

• spss_frequenciesA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It communicates the return value and the IBM SPSS installation requirement, but it does not explicitly state whether the operation is read-only or whether it can modify the dataset.

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

  Conciseness5/5

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

  The description is two focused sentences with no filler. It front-loads the command and outcome, then adds a necessary prerequisite. Every sentence earns its place.

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

  Completeness3/5

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

  The output schema covers return-value structure, but with no annotations and sparse parameter descriptions, the description leaves gaps around accepted statistics values, file_path semantics, and variable requirements. It is adequate for a simple frequency call but incomplete for nuanced usage.

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

  Parameters2/5

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

  The schema contains no descriptions for any parameter, so the description must compensate. It clarifies that variables are one or more and that statistics are optional, but it does not define which statistic values are accepted, the file_path format, or variable type constraints.

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

  Purpose5/5

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

  The description names the exact SPSS command ('FREQUENCIES') and the resource ('one or more variables'), and clearly states the output as frequency tables with counts, percentages, and optional statistics. This distinguishes it from siblings like descriptives, crosstabs, and regression.

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

  Usage Guidelines3/5

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

  The description implies the tool is for generating frequency distributions, which is a clear context. However, it does not explicitly state when to prefer this over descriptives or crosstabs, nor does it provide exclusions such as continuous variables or missing data handling.

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

• spss_normality_outliersA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It transparently states that the tool invokes SPSS EXAMINE and requires IBM SPSS Statistics to be installed, and it notes that plots are optional. It does not explicitly state whether the operation modifies data or is read-only, though the verb 'check' suggests an analytical rather than mutating action.

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

  Conciseness5/5

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

  Two sentences convey the procedure, purpose, variable scope, optional behavior, and a critical prerequisite. There is no filler, and the most important information is front-loaded.

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

  Completeness3/5

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

  The description covers the main purpose, the underlying SPSS command, the prerequisite installation, and the optional plots. However, it lacks explicit guidance on file_path semantics and on how to choose this tool over closely related sibling statistical procedures, even though the modest parameter complexity and existing output schema reduce the overall gap.

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

  Parameters2/5

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

  The schema has 0% description coverage, so the description must compensate. It clarifies that variables should be numeric and that plots are diagnostic, but it leaves the required file_path parameter as just a string with no indication of the expected file format or SPSS dataset context. The variables array item type is also unspecified in both schema and description.

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

  Purpose5/5

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

  The description clearly states a specific verb and resource: it runs SPSS EXAMINE to check normality and outliers for numeric variables. It also mentions optional diagnostic plots, which distinguishes it from the many sibling statistical and data-management tools.

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

  Usage Guidelines3/5

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

  The description implies the appropriate use case: checking normality and outliers for numeric variables. It does not explicitly contrast this with sibling tools such as spss_descriptives or spss_graph_boxplot, nor does it state when not to use it, though the SPSS prerequisite is mentioned.

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

• spss_regressionA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It discloses the SPSS installation requirement and summarizes the returned statistics, but it does not mention side effects, failure modes, data mutation risks, or the effect of the diagnostics flag.

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

  Conciseness5/5

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

  Three short sentences, front-loaded with the action, and no filler. Each sentence contributes useful information: the operation, the inputs, the outputs, and the environment requirement.

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

  Completeness3/5

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

  The core operation and required inputs are covered, and the output schema presumably handles return details. However, with five parameters and zero schema coverage, the description omits meaningful semantics around method and include_diagnostics, leaving an agent to guess valid values and behavior.

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

  Parameters2/5

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

  The schema has no parameter descriptions (0% coverage), so the description must compensate. It mentions dependent and predictors, but leaves file_path, method (e.g., ENTER vs stepwise), and include_diagnostics unexplained. The description only partially compensates for the schema gap.

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

  Purpose5/5

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

  The description uses a precise verb ('Run') with a specific resource ('SPSS linear regression') and the qualifier 'linear' clearly separates it from the many regression siblings like spss_logistic_regression or spss_ordinal_regression. It states exactly what the tool performs.

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

  Usage Guidelines3/5

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

  The description implies when to use it (when a linear regression is needed) and provides a key prerequisite (SPSS must be installed). However, it gives no explicit guidance about when not to use it or which alternative tool should be chosen instead, such as logistic regression for binary outcomes.

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

• spss_run_syntaxA
  3.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It discloses a key side effect ('persists .spv and .sps files'), a prerequisite ('Requires IBM SPSS Statistics to be installed'), and the data_file prepend behavior. It does not warn that arbitrary syntax can mutate data, but the word 'arbitrary' partially conveys that risk.

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

  Conciseness4/5

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

  The description is three concise sentences with the primary purpose front-loaded. No filler or repetition; each sentence adds relevant information. Slightly more parameter-specific detail could be added, but the structure is clean and efficient.

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

  Completeness2/5

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

  Despite an output schema, the tool accepts 6 parameters and none are documented in the schema. The description does not clarify select_if, filter_variable, or the saving flags, and does not provide routing guidance toward the many specialized siblings. An agent would likely need additional schema inspection or examples to use it fully.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It only explains data_file; syntax, select_if, filter_variable, save_syntax_file, and save_viewer_output are left to be inferred from their names. This is insufficient for a 6-parameter tool with zero schema descriptions.

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

  Purpose5/5

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

  The description states a specific verb ('Execute') and resource ('arbitrary SPSS syntax commands'), plus the output format ('Markdown'). The word 'arbitrary' clearly distinguishes it from the many specialized SPSS sibling tools, and 'return the output as Markdown' clarifies what the agent gets back.

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

  Usage Guidelines3/5

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

  The description implies this is a generic fallback tool for arbitrary syntax, but it never explicitly says 'use this when no dedicated sibling tool fits' or names alternatives. The guidance is mostly implicit rather than prescriptive.

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

• spss_crosstabsA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of explaining behavior. It discloses the operation, optional statistics, and the software installation requirement. It does not state whether the command modifies the data file, writes any files, or requires a running SPSS instance, so some side-effect/execution behavior remains unspecified.

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

  Conciseness5/5

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

  Two compact sentences front-load the core purpose and then list optional features and a prerequisite. Every sentence earns its place with no filler.

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

  Completeness3/5

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

  The description is sufficient for selecting the tool, and the presence of an output schema means return values do not need detailing. However, for a 6-parameter tool with no annotations and 0% schema coverage, important execution details are missing (expected file format, defaults, whether data is modified). It is minimally adequate but not complete.

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

  Parameters3/5

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

  The schema has 0% description coverage, so the description must compensate. It clarifies that row_variable and column_variable are categorical and that the boolean flags correspond to chi-square and row/column percentages. It does not explain file_path (e.g., expected .sav format) or confirm the default-true behavior, leaving only partial compensation for the missing schema descriptions.

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

  Purpose4/5

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

  The description states a clear action ('Run SPSS CROSSTABS') and object ('contingency table between two categorical variables'), which separates it from univariate procedures like spss_frequencies. It also mentions optional chi-square and percentages, making the tool's scope easy to grasp. However, it never references a sibling tool by name, so differentiation relies on inference rather than explicit routing.

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

  Usage Guidelines4/5

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

  The description provides a clear condition for use—when a contingency table between two categorical variables is needed—and adds a prerequisite (IBM SPSS Statistics installed). It does not explicitly state when to prefer an alternative tool such as spss_frequencies or spss_custom_tables, nor does it give when-not-to-use guidance. This is enough for common cases but leaves the 'vs alternatives' question unanswered.

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

• spss_export_outputA
  3.7/5.0
  Behavior4/5

  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 critical behavioral trait: the batch engine lacks a GUI Viewer, so OMS is used instead of OUTPUT EXPORT, and this is 'verified live'. It also notes that the tool operates on procedures already run in the same job. It omits overwrite/append behavior, but the most important runtime constraints are exposed.

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

  Conciseness3/5

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

  The description is reasonably compact and front-loads the purpose and usage. However, the format list appears twice (the FORMAT= enumeration and the parenthetical mapping), which is redundant, and the 'verified live' aside could be considered extra. It reads well but is not maximally efficient.

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

  Completeness2/5

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

  The tool has four parameters with no schema descriptions and no annotations, yet the description only explains export_format and the high-level ordering requirement. It fails to define file_path, output_path, or procedures_syntax, and does not describe what the returned output schema contains. An agent would struggle to construct a correct invocation without making unstated assumptions.

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

  Parameters2/5

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

  Only export_format receives explicit semantics (DOC, XLS, HTML, SPV). The required parameters file_path, output_path, and procedures_syntax are left completely unexplained; the description does not clarify what each path refers to or what should be placed in procedures_syntax. With 0% schema description coverage, this is a significant gap.

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

  Purpose5/5

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

  The description opens with a specific verb+resource pair ('Export procedure output directly to a file') and explicitly names the SPSS command (OMS /DESTINATION FORMAT=...). This makes the tool's purpose unmistakable and distinguishes it from siblings like spss_save_file (data export) and spss_run_syntax (generic execution).

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

  Usage Guidelines4/5

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

  It explicitly states when to use the tool: 'Runs inside the same job as the procedures' and gives ordering guidance ('call any analysis tools first, then this'). It also explains why the alternative OUTPUT EXPORT command is unsuitable in batch via the GUI Viewer note. It does not name a specific sibling tool as an alternative, but the guidance is clear enough.

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

• spss_graph_barA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden and does usefully disclose that the tool relies on IBM SPSS Statistics and will issue a GRAPH command. However, it does not state side effects, read-only status, or whether a chart/file is returned or written, leaving behavioral impact partially undisclosed.

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

  Conciseness5/5

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

  Two dense sentences front-load the core syntax and defaults with no filler. Every clause contributes command details or a requirement.

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

  Completeness3/5

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

  The description is adequate for an expert who recognizes the GRAPH syntax, and the presence of an output schema covers returned values. It is less complete for an agent that needs guidance on file_path semantics, when to use bar charts, and what side effects, if any, occur.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate; it does document style, statistic choices, variable, and BY variable reasonably well. But key parameters such as file_path and title are not explained, so the coverage is incomplete.

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

  Purpose5/5

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

  The description names the exact SPSS command (GRAPH /BAR) and chart type, making the operation concrete and distinguishable from sibling graph tools such as spss_graph_scatter, spss_graph_histogram, and spss_graph_boxplot. Even without a natural-language verb, 'Bar chart: GRAPH /BAR...' states the resource and action unambiguously.

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

  Usage Guidelines3/5

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

  The syntax 'BY catvar' and statistic options imply it is intended for categorical bar charts with optional grouping or summary statistics, but the description never explicitly says when to choose this over the other graph tools. The usage context is present but must be inferred.

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

• spss_match_filesA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It discloses the IBM SPSS Statistics requirement, the minimum file count, and the sorting prerequisite, which are useful. But it does not describe matching behavior for unmatched cases, overwriting behavior, or consequences of incorrect input, leaving important behavioral details unspecified.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the core operation ('Combine variables across files (join by key)'), followed by concise parameter guidance and a required-environment note. Every sentence contributes useful information without repetition or fluff.

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

  Completeness3/5

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

  The description covers the essential operation and key parameters, and an output schema exists. However, the undocumented keep/drop parameters, lack of distinction from spss_star_join, and absence of join-semantics details make it incomplete for an agent choosing and invoking this tool confidently in all reasonable scenarios.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It explains file_paths, key_variables, and output_path reasonably well, but it completely omits the semantics of the 'keep' and 'drop' parameters, which are part of the schema and could materially affect the merge result.

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

  Purpose4/5

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

  The description states a specific operation and resource: 'Combine variables across files (join by key)' naming the SPSS MATCH FILES command. It is clear and unlikely to be confused with basic data-reading tools, but it does not explicitly distinguish itself from similar siblings like spss_star_join or spss_add_files.

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

  Usage Guidelines4/5

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

  Provides clear context for when to use the tool: when combining variables across .sav files by key. It also gives prerequisites such as requiring at least two files, using BY variables, and that files must be sorted on those variables. However, it does not explicitly state when not to use it or name alternative tools.

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

• spss_read_dataA
  3.7/5.0
  Behavior3/5

  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 discloses genuinely useful traits: output as a Markdown table, optional variable filtering, row-count limiting, and no SPSS installation requirement. However, it does not mention value-label behavior even though apply_value_labels defaults to true, and it never explicitly confirms the read-only safety profile.

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

  Conciseness5/5

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

  Three short sentences with the core function front-loaded. Every sentence adds information — no filler, no repetition of schema defaults. Appropriately sized for the tool's low-to-moderate complexity.

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

  Completeness3/5

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

  For a low-complexity read tool the description covers the essentials, and the presence of an output schema handles return-value documentation. But with no annotations and 0% schema coverage, the undocumented apply_value_labels parameter and the lack of routing guidance against spss_read_metadata leave meaningful gaps. Adequate, but an agent could still misfire on value-label expectations.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It translates two parameters into plain language ('filter to specific variables' → variables, 'limit row count' → max_rows) and implies file_path is the .sav path. However, apply_value_labels is documented nowhere in either the schema or description, leaving one of four parameters completely unexplained.

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

  Purpose5/5

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

  States a specific action with resource and output format: 'Read rows of data from an SPSS .sav file as a Markdown table.' The 'rows of data' phrasing clearly distinguishes it from the close sibling spss_read_metadata, which reads metadata rather than data. An agent can tell this is the data-reading tool among many analysis siblings without opening schemas.

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

  Usage Guidelines3/5

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

  The description implies when to use it — whenever actual data rows from a .sav file are needed — but never contrasts it with alternatives like spss_read_metadata, spss_list_variables, or spss_file_summary. The 'Does not require SPSS to be installed' note is useful context but not usage routing. No explicit when-not-to-use guidance is present.

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

• spss_twostep_clusterA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the disclosure burden. It usefully states that IBM SPSS Statistics must be installed and that cluster numbers are determined automatically. However, it does not disclose side effects, return behavior, or failure modes beyond the prerequisite.

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

  Conciseness5/5

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

  Three short sentences each earn their place: purpose, capability, and prerequisite. The most important information is front-loaded with no filler or repetition.

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

  Completeness2/5

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

  For a 7-parameter SPSS analysis tool with no parameter descriptions and no annotations, the description is under-specified. It gives no guidance on the required file_path format, how continuous/categorical variables are specified, or how num_clusters interacts with max_clusters and automatic determination.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explain file_path, continuous, categorical, distance, max_clusters, num_clusters, or outlier_handling. 'Mixed variable types' and 'automatic cluster number determination' are weak hints toward the categorical/continuous and cluster-count parameters but do not define them.

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

  Purpose5/5

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

  The description states a specific action, 'Run two-step cluster analysis', and adds distinguishing capabilities: automatic cluster number determination, large dataset handling, and mixed variable type support. This differentiates it from sibling clustering tools like spss_cluster_hierarchical and spss_quick_cluster.

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

  Usage Guidelines4/5

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

  It gives clear context for when to use the tool: when automatic cluster-number selection is desired and when data are large or mixed-type. It does not explicitly name alternative tools or state exclusions, so it stops short of full routing guidance.

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

• spss_get_method_supportA
  3.8/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden. It makes the read-only nature clear ('Get support metadata') and specifies what information is returned, so an agent can infer this is a non-mutating lookup. It does not cover error behavior or auth requirements, which is the only 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.

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler. Every phrase earns its place by specifying the target and the returned metadata categories.

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

  Completeness4/5

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

  For a one-parameter tool with an output schema, the description is nearly complete: it identifies the input's semantic domain and the shape of the returned metadata. It could be more explicit about how to discover supported method names and what happens for non-registry-backed methods, but neither is essential for basic invocation.

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

  Parameters3/5

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

  The only parameter, tool_name, has 0% schema description coverage. The description adds the meaning 'registry-backed SPSS method name,' which helps, but it does not tell the agent where to find valid values (e.g., from spss_list_supported_methods) or define the expected identifier format. It partially compensates for the bare schema.

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

  Purpose5/5

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

  The description states a specific action ('Get support metadata') on a specific resource ('a registry-backed SPSS method') and enumerates the payload categories (command family, support tier, coverage assertions, documentation tags). This clearly distinguishes it from siblings like spss_get_method_schema or spss_list_supported_methods.

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

  Usage Guidelines2/5

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

  The description only defines what the tool does; it gives no conditions for when to prefer it over alternatives such as spss_get_method_schema or spss_list_supported_methods, and no prerequisites like the need to obtain a valid method name from the registry. Usage context 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.

• spss_kaplan_meierA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral burden. It discloses an important prerequisite (IBM SPSS Statistics must be installed) and describes the produced results. It does not discuss side effects or failure behavior, but for an analysis command the read-only nature is reasonably implied.

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

  Conciseness5/5

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

  Three short sentences with no filler. The action and outputs are front-loaded, the prerequisite is placed at the end, and nothing repeats the schema's structural information.

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

  Completeness3/5

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

  The output schema covers return values, but the description still leaves gaps around parameter semantics, especially status_event_value and optional strata/percentiles. For a well-known statistical method, the description is minimally adequate, though it could be more useful with explicit guidance on event/censoring coding and comparison methods.

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

  Parameters2/5

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

  Schema description coverage is 0%, yet the description adds almost no parameter-level meaning. It does not explain status_event_value, strata, percentiles, or compare_method beyond what the names and enum already suggest, so it fails to compensate for the schema's lack of descriptions.

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

  Purpose5/5

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

  The description names the exact statistical procedure ('Kaplan-Meier survival analysis') with a clear verb ('Run') and states the main outputs: survival curves and group comparison. This distinguishes it from sibling tools like spss_cox_regression and other analysis procedures.

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

  Usage Guidelines4/5

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

  The description gives clear context by specifying survival analysis with a log-rank test and group comparison. It does not explicitly mention when to choose it over alternatives like cox_regression, but the statistical context is clear enough for an informed agent.

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

• spss_list_filesA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of explaining behavior. It clearly says the tool lists .sav files in a directory and is for dataset discovery. However, it does not mention how the 'recursive' parameter affects behavior, what happens with invalid directories, or whether only .sav files are returned. Basic behavior is clear, but edge-case behavior is undeclared.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the core action and followed by a practical usage note. No filler or redundant restatement. Every sentence earns its place.

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

  Completeness3/5

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

  The tool is simple and has an output schema, which reduces the burden on the description. Still, the description omits any guidance on the recursive parameter and does not clarify whether the tool filters strictly to .sav files. It is adequate for basic use but not fully complete for nuanced calls.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It implies the 'directory' parameter through 'in a directory,' but does not explain what values are valid or how the 'recursive' parameter changes results. The description adds minimal semantic value beyond the schema's bare parameter names.

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

  Purpose5/5

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

  States a specific verb and resource: 'List SPSS .sav files in a directory.' The purpose is unambiguous, and the distinction from siblings like 'read_data' or 'file_summary' is reasonably clear because this tool is about discovering files, not reading or analyzing them.

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

  Usage Guidelines4/5

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

  Provides explicit usage context: 'Useful for discovering available datasets when the user hasn't specified a file path.' This tells an agent when to reach for this tool. It does not explicitly name alternative tools or exclusion conditions, so it stops short of a 5.

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

• spss_read_metadataA
  3.8/5.0
  Behavior4/5

  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 well: 'Read' clearly indicates a non-mutating operation, 'Returns a detailed Markdown report' sets output expectations, and 'Does not require SPSS to be installed' adds an important environment requirement. It does not explicitly state 'does not modify the file', but the read verb makes that reasonably clear.

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

  Conciseness5/5

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

  Two concise sentences with no filler. The core operation and output format are front-loaded, and the environment requirement is a useful final note.

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

  Completeness4/5

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

  For a simple one-parameter read-only tool with an output schema, the description is largely complete: it names the input file type, the metadata returned, the output format, and the lack of SPSS dependency. The main missing piece is explicit routing among sibling metadata tools, but that is more of a usage-guideline gap than a contextual completeness gap.

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

  Parameters3/5

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

  The schema provides zero description for the file_path parameter, so the description must compensate. It adds that the file is an SPSS .sav file, which gives the parameter semantic context, but it does not explicitly explain path requirements, accessibility, or expected format beyond that.

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

  Purpose4/5

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

  States a specific action ('Read') with an unambiguous resource ('SPSS .sav file') and enumerates the metadata types returned. The description is clear and would distinguish it from spss_read_data, but it does not explicitly differentiate it from sibling metadata tools like spss_list_variables or spss_value_labels.

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

  Usage Guidelines3/5

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

  Intended use can be inferred from the description: call this when you need file structure metadata like variable names and value labels. However, there is no explicit guidance about when to use this over sibling tools such as spss_file_summary or spss_list_variables, and no exclusions or when-not-to-use cases.

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

• spss_weightA
  3.8/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden and does disclose the key behavioral trait: the weighting persists for subsequent procedures on the same file. It also explains how to turn weighting off via weight_variable=None. It does not mention edge cases like missing or negative weights, but the core statefulness is covered.

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

  Conciseness5/5

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

  Three short sentences with each adding value: core operation, persistence semantics, and environment requirement. The most decision-relevant information, the off switch and statefulness, appears early.

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

  Completeness4/5

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

  For a two-parameter stateful tool, the description covers the essential call semantics and the persistence behavior that affects downstream procedures; the output schema covers return values. File path format and variable reference conventions are left implicit, but the tool is simple enough that the agent can proceed.

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

  Parameters3/5

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

  Schema has no parameter descriptions (0% coverage), so the description must compensate. It explains weight_variable's meaning and None sentinel, but leaves file_path to be inferred from its name and does not specify expected format or how variables are referenced.

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

  Purpose4/5

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

  The description clearly identifies the action ('Weight cases') and the resource (a variable), plus the ability to turn weighting off. It is distinguishable from sibling analysis tools like spss_frequencies, but it does not explicitly name a comparable alternative or contrast with it.

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

  Usage Guidelines3/5

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

  It states that the effect applies to subsequent procedures on the same file, which implies use before analyses that should account for weights. It does not explicitly say when not to use it or suggest alternatives such as spss_filter or spss_select_if for case selection.

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

• spss_cases_to_varsA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It explains that a restructured result file is written to output_path and that SPSS is required, but it does not say whether the input file is modified, how duplicates or missing index combinations are handled, or what the output file contains beyond being 'restructured.'

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

  Conciseness5/5

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

  The description is compact and front-loaded with the core action, includes the SPSS command form for grounding, and adds only essential parameter notes and a prerequisite. There is no filler.

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

  Completeness3/5

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

  The core operation is clear and an output schema exists, but the description is incomplete for a 5-parameter tool with no annotations and 0% schema description coverage. Missing parameter explanations for file_path and fixed_variables, plus no caveats about case ordering or duplicate IDs, leave meaningful gaps.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It provides useful meanings for id_variables, index_variables, and output_path, but omits file_path and fixed_variables entirely, leaving two of five parameters underspecified.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Restructure long → wide format' via CASESTOVARS. This clearly distinguishes it from spss_vars_to_cases and other data-management siblings without needing to inspect the schema.

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

  Usage Guidelines4/5

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

  The transformation direction is explicit ('long → wide'), which gives an agent clear context for when to select this tool. It does not explicitly contrast with the wide-to-long sibling, but the purpose is specific enough to imply the main use case.

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

• spss_compute_scale_scoreA
  3.9/5.0
  Behavior3/5

  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 discloses the computation method (SUM/MEAN), optional reverse coding, and minimum valid item count, which are useful behavioral details. However, it does not disclose side effects such as whether the file is modified in place or whether a new variable is added, nor does it mention prerequisites about variable existence.

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

  Conciseness5/5

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

  Two sentences with no wasted words. The core function and key options are front-loaded, followed by the environmental requirement. Every sentence adds value.

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

  Completeness3/5

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

  For a tool with 8 parameters and no annotations, the description gives a solid high-level overview but omits operational details like how reverse coding determines values, how min_valid interacts with missing data, and whether the result is written to the file or returned. The presence of an output schema mitigates return-value ambiguity, but the reverse coding and file-mutation behavior remain underspecified.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It meaningfully maps to parameters: 'SUM or MEAN' covers the method enum, 'multiple item variables' covers items, 'optional reverse coding' covers reverse_items/reverse_min/reverse_max, and 'minimum valid item count' covers min_valid. It leaves file_path and new_variable implicit, but these are self-evident from their names.

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

  Purpose5/5

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

  The description states a specific verb ('Compute') and resource ('scale score') with the SUM/MEAN methods and optional reverse coding and minimum valid item count. It clearly distinguishes this tool from generic spss_compute and analysis tools like spss_reliability_alpha by focusing on scale scoring from item variables.

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

  Usage Guidelines3/5

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

  The description implies the use case (computing scale scores from multiple item variables) but does not explicitly state when to prefer this over siblings such as spss_compute or spss_recode, nor does it mention exclusions or alternatives. The only contextual guidance is the IBM SPSS Statistics requirement, which is a prerequisite rather than a usage comparison.

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

• spss_custom_tablesA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden and discloses several non-obvious operational traits: statistics can only be placed on row variables, MEAN on a categorical variable is rejected by SPSS, and the Custom Tables module must be installed. It does not describe side effects or output, but an output schema exists to cover 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.

  Conciseness5/5

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

  Four short, information-dense segments with no filler. The purpose and syntax are front-loaded, and each constraint earns its place.

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

  Completeness4/5

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

  For a complex SPSS syntax tool, the description covers the key syntax pattern, parameter roles, an important SPSS-specific rejection, and the module prerequisite. The output schema handles return values. The only notable gap is the lack of a full list of allowed statistics, softened by 'statistics: COUNT, MEAN, MEDIAN, etc.'

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must compensate. It explains the role of rows and columns via CTABLES syntax, clarifies that the statistics parameter applies to row variables only, and gives example values (COUNT, MEAN, MEDIAN). It does not explain file_path or title, but those are self-explanatory from context.

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

  Purpose4/5

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

  The description opens with 'Custom pivot tables' and provides the CTABLES syntax, so an agent can tell this is for building custom pivot tables rather than standard crosstabs or frequencies. It lacks an explicit verb like 'creates', but the syntax and examples make the purpose unambiguous.

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

  Usage Guidelines3/5

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

  The description implies use for custom pivot tables and spells out key constraints (statistics attach to rows only; MEAN on a categorical is rejected) plus the Custom Tables module requirement. It does not explicitly say when to prefer this over spss_crosstabs or spss_frequencies, so the guidance is implied rather than explicit.

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

• spss_rankA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the behavioral burden. It discloses the underlying SPSS command, the dependency on IBM SPSS Statistics, and several transform options. However, it does not state side effects such as whether the input file is modified, whether output_path writes a new dataset, or how new rank variables are named.

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

  Conciseness5/5

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

  The description is one dense, efficiently structured statement that front-loads the core action ('Rank cases') and then packs the syntax and option meanings into compact parentheticals. Every element earns its place without redundancy.

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

  Completeness3/5

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

  For a 10-parameter tool with no annotations and no schema descriptions, the description covers the main ranking options well but leaves gaps: parameter compatibility, exact output_path/file_path semantics, rank variable naming, and whether by_variables combines with other options. It is adequate for common ranking requests but not fully complete for edge cases.

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

  Parameters4/5

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

  Despite 0% schema description coverage, the description compensates for most parameters by embedding them in SPSS syntax: order is (A|D), rank_into is shown in '/RANK INTO var', and ntiles, percent, normal, fraction, and by_variables are all explained. file_path and output_path are not described, but their names and the surrounding context make their roles reasonably inferable.

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

  Purpose5/5

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

  The description opens with the specific operation 'Rank cases' and then gives the exact SPSS syntax 'RANK VARIABLES=vars (A|D) /RANK INTO var', making the tool's function unmistakable. This clearly distinguishes it from transformation siblings like spss_sort_cases, spss_recode, or spss_compute.

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

  Usage Guidelines3/5

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

  Usage is implied through the syntax and option list: the tool is for creating rank variables from specified variables. However, it does not explicitly state when to prefer this tool over alternatives such as sort, recode, or compute, nor does it mention any when-not-to-use conditions.

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

• spss_graph_boxplotA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It adds valuable context: boxplots must use EXAMINE, not GRAPH, and categorical_variable=None yields a single-variable boxplot. However, it does not disclose side effects, error conditions, or how invalid inputs are handled, so behavioral transparency is only partial.

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

  Conciseness5/5

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

  Two focused sentences convey purpose, syntax, version-specific behavior, and an edge case. The note about SPSS 27 is relevant and earned; there is no filler or redundant restatement of the schema.

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

  Completeness4/5

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

  Given that an output schema exists to document return structure, the description is largely sufficient for invocation. It explains the core command, the essential parameter behavior, and a significant platform quirk. Missing guidance about when to choose sibling graph tools is the main gap.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must carry parameter meaning. It maps variable and categorical_variable directly to the EXAMINE syntax (var BY catvar) and clarifies that None disables grouping. While file_path and title are not explicitly explained, they are conventional and the critical parameter behavior is well covered.

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

  Purpose5/5

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

  The description clearly identifies the tool as producing a boxplot, optionally grouped by a categorical variable, and specifies the exact SPSS command (EXAMINE ... /PLOT BOXPLOT). It even distinguishes from the GRAPH command family by noting the missing /BOXPLOT subcommand, which separates it from sibling graph tools.

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

  Usage Guidelines3/5

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

  The description gives useful context about how boxplots are generated in SPSS 27 and explains the None case for categorical_variable. However, it does not explicitly say when to prefer this tool over sibling alternatives like spss_graph_histogram or spss_descriptives, leaving usage boundaries 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.

• spss_list_variablesA
  4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly signals a read-oriented listing operation, describes the file source, the optional search filter, and the no-SPSS-installation requirement. It does not explicitly state that the file is never modified, but 'List' strongly implies read-only behavior.

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

  Conciseness5/5

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

  Two sentences with no filler. The primary purpose is front-loaded, followed by the optional search behavior and the environment note. Every sentence earns its place.

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

  Completeness4/5

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

  For a simple tool with two parameters and an output schema, the description covers the essential calling context: the file source, optional filter, and runtime dependency. It could be slightly more complete if it explicitly stated that the operation is read-only and clarified the search scope, but overall it is largely sufficient.

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

  Parameters3/5

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

  The schema has 0% property-description coverage, so the description must compensate. It adds meaning for file_path as an SPSS .sav file and for search as an optional filter term. However, it leaves ambiguity about whether search matches variable names, labels, or both, and does not elaborate on the required file_path beyond the schema structure.

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

  Purpose5/5

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

  The description uses a specific verb, 'List', names the exact resource ('variable names and their labels'), and explicitly mentions the source as an SPSS .sav file. It also distinguishes itself from sibling tools by clarifying it lists variables, not files or methods.

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

  Usage Guidelines3/5

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

  The description implies when to use it—when you need variable names/labels with optional search filtering—and adds a useful runtime note that SPSS need not be installed. However, it does not explicitly contrast this with sibling tools like spss_read_metadata or spss_file_summary, nor does it state exclusions or when-not-to-use conditions.

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

• spss_missing_valuesA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full transparency burden. It does disclose the core behavior: it issues MISSING VALUES, and an empty string clears missing values with NONE, plus the SPSS dependency. It does not state whether the original file is overwritten or what output_path controls, which matters for a mutating operation.

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

  Conciseness5/5

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

  The description is compact and front-loaded: it states the command, the parameter shape, concrete examples, the clearing behavior, and the external dependency in four short sentences with no filler.

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

  Completeness4/5

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

  For a tool with a nested required parameter and an output schema present, the description covers the syntax and semantics needed to construct a valid missing_spec. The only notable omission is output_path semantics—whether the result is written to a new file or the input is modified—which prevents a perfect score.

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

  Parameters4/5

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

  Schema coverage is 0%, but the description richly defines the hardest parameter, missing_spec: it gives the object shape, valid syntax, and examples including the empty-string clearing case. It leaves file_path and output_path unexplained, but these are relatively conventional and the required complex parameter is fully covered.

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

  Purpose5/5

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

  The description names the exact SPSS operation ('MISSING VALUES') and the resource it acts on ('var (spec)'), and explains it as declaring user-missing values. It is clearly separable from siblings like spss_value_labels or spss_recode because it is framed around missing-value declarations.

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

  Usage Guidelines3/5

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

  The intended use case is implied by the command and examples ('age': '99', 'LOWEST THRU 0; 99'), and the note about clearing with an empty string adds context. However, there is no explicit statement of when to choose this over alternative SPSS tools or any exclusions, so the guidance is implied rather than explicit.

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

• spss_validate_syntaxA
  4/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the behavioral burden. It explicitly discloses that the tool does not execute syntax, only checks for basic syntax errors, and requires IBM SPSS Statistics to be installed. It does not describe the shape of validation results, but an output schema exists to cover that.

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

  Conciseness5/5

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

  Two short sentences front-load the core behavior and the non-execution guarantee, then state the installation prerequisite. Every sentence earns its place with no repetition or fluff.

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

  Completeness4/5

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

  For a one-parameter validation tool, the description covers safety (no execution), scope (basic syntax errors), and prerequisite (SPSS installed). With an output schema present, the lack of return-value detail is acceptable; only explicit guidance versus spss_run_syntax is missing, but that is already reflected in usage guidelines.

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

  Parameters3/5

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

  The schema has a single 'syntax' string property with no description, so the description must compensate. It does identify the parameter as SPSS syntax, which disambiguates the bare schema. But it provides no detail on expected formatting, length limits, or how invalid syntax is reported.

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

  Purpose5/5

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

  States a specific verb ('Validate'), a specific resource ('SPSS syntax'), and an explicit non-execution guarantee. This clearly separates it from sibling tools like spss_run_syntax. 'Checks for basic syntax errors' further defines the scope.

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

  Usage Guidelines3/5

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

  The 'without executing it' phrasing implies this tool should be used when a syntax check is wanted rather than execution, especially before spss_run_syntax. However, it never explicitly names an alternative tool or states when not to use it, leaving the routing to inference.

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

• spss_repeated_measures_anovaA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description must carry behavioral disclosure. It usefully states that IBM SPSS Statistics must be installed, an important external dependency, and 'Run' implies an analysis rather than a data mutation. However, it does not describe error behavior, variable type constraints, or what the returned output represents.

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

  Conciseness5/5

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

  Two sentences, each earning its place: the first identifies the operation and the required input pattern, and the second gives the prerequisite. The essential information is front-loaded and there is no filler.

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

  Completeness3/5

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

  For a complex statistical tool with no annotations and 0% schema description coverage, the description covers the core invocation (factor, levels, variables) but omits behavior around include_pairwise and any assumptions about the data/variables. An output schema exists, but the description alone is only minimally complete.

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

  Parameters4/5

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

  Schema description coverage is 0%, so this description compensates for the key required parameters by saying to provide the within-factor name, number of levels, and one variable per level. file_path is self-evident, but the optional include_pairwise parameter is not explained despite having a default value.

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

  Purpose5/5

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

  The description uses a specific verb ('Run') and names the exact analysis ('SPSS repeated-measures ANOVA'), clarifying it is the within-subject GLM. This distinguishes it from sibling tools such as spss_anova or spss_manova.

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

  Usage Guidelines4/5

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

  The phrase 'repeated-measures ANOVA (within-subject GLM)' gives a clear statistical context for when the tool applies. It does not name alternatives or state when not to use it, but the repeated-measures framing and 'Requires IBM SPSS Statistics' prerequisite provide enough contextual guidance.

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

• spss_import_csvA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully reveals that conversion happens directly via pandas + pyreadstat, bypasses the SPSS engine, saves next to the CSV by default, and supports a custom output_path. This is meaningful behavioral context beyond the schema, though it does not describe overwrite behavior or type inference.

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

  Conciseness5/5

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

  Three concise sentences with no filler. The core purpose is front-loaded, then practical benefits (no SPSS installation, speed) and default output behavior follow. Every sentence earns its place.

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

  Completeness4/5

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

  Given the output schema and fully described parameters, the description is sufficient for an agent to invoke the tool correctly. It covers the essential conversion behavior, performance characteristics, and output destination. Minor omissions such as overwrite behavior or variable type handling are acceptable because the structured schema already handles parameter details.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema already documents all five parameters. The description adds a little extra meaning by emphasizing the default output location next to the CSV and the custom output_path option, but it does not go beyond what the schema already provides. This matches the baseline for high schema coverage.

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

  Purpose5/5

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

  The description clearly states a specific action ('Convert a CSV file to SPSS .sav format'), identifies the resource (CSV) and output target (.sav), and distinguishes from sibling tools by naming the underlying method. It also explicitly contrasts itself with SPSS syntax, helping an agent recognize this as the dedicated import/export conversion tool.

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

  Usage Guidelines4/5

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

  The description provides strong usage context: it says to use this tool for CSV-to-SAV conversion without requiring IBM SPSS Statistics, and explains that it is faster than going through SPSS syntax. It doesn't explicitly list when not to use it or compare it to related tools like spss_run_syntax, but the guidance is clear enough for selection.

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

• spss_list_supported_methodsA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It does reveal that the operation lists registry-backed methods and that results have schemas, templates, and coverage assertions, but it never explicitly states that it is read-only or side-effect-free, nor does it describe the result format (though an output schema exists).

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

  Conciseness5/5

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

  Two sentences with no filler: the first states the core function, the second gives directed usage. The most important information is front-loaded, and every word earns its place.

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

  Completeness4/5

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

  The tool is simple (no parameters) and has an output schema, so the description need not detail return values. It provides enough context to invoke correctly. The only slight gap is the undefined term 'cold methods', which could confuse an agent but does not block a correct call.

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

  Parameters4/5

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

  The tool has zero parameters, so the description need not add parameter-level semantics. The 100% schema coverage of an empty object confirms no parameters are expected, earning the baseline score of 4 for parameterless tools.

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

  Purpose5/5

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

  The description uses the specific verb 'List' with a clear resource: 'registry-backed SPSS methods available for structured execution.' It further distinguishes the tool from statistical/analysis siblings by stating it discovers methods that have schemas, templates, and coverage assertions.

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

  Usage Guidelines4/5

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

  'Use this to discover cold methods that have schemas, templates, and coverage assertions' explicitly states when to use the tool. However, it does not mention when not to use it or point to any alternative, and 'cold methods' is unexplained jargon.

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

• spss_file_summaryA
  4.3/5.0
  Behavior4/5

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

  With no annotations to indicate side effects or safety, the description carries the behavioral disclosure burden. It clearly states that computation happens locally and does not require SPSS, which is meaningful behavior beyond the schema. It does not explicitly state that the file is read-only, but 'summary' plus local computation strongly implies no mutation.

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

  Conciseness4/5

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

  The description is compact and front-loaded with the core purpose and output contents. It loses a point because 'Does not require SPSS to be installed' repeats the parenthetical 'no SPSS needed,' adding minor redundancy rather than new information.

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

  Completeness4/5

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

  Given the output schema covers return structure, the description adequately covers the core purpose, input type, and the key behavioral differentiator (no SPSS required). It doesn't discuss file access requirements or edge cases, but for a summary tool with one parameter this is a workable completeness level.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must compensate for the bare string parameter. It adds meaning by indicating that file_path should reference an SPSS .sav file and that processing is local. It doesn't specify path formatting or file-size caveats, but for a single obvious parameter this is reasonably sufficient.

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

  Purpose5/5

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

  The description opens with a specific verb and resource ('Get a summary of an SPSS .sav file') and enumerates the exact contents: case count, variable count, variable list, and basic descriptive statistics. It distinguishes itself from SPSS-dependent siblings by emphasizing that the summary is computed locally without SPSS.

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

  Usage Guidelines4/5

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

  The repeated 'no SPSS needed' note gives clear context for when this tool is appropriate: when a quick local summary is desired without requiring an SPSS installation. It does not explicitly name alternatives or state when NOT to use it, but the local-computation framing provides usable selection guidance among the many SPSS tools.

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

• spss_check_statusA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It transparently conveys a read-only introspection behavior by stating it checks status and reports capabilities, path, versions, and configuration. It does not detail error behavior or connection prerequisites, but the non-mutating nature and informational return are clear.

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

  Conciseness5/5

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

  Two sentences with no filler: the first states what is checked and what is reported, the second gives the recommended invocation timing. It is front-loaded with the primary action and all details are relevant.

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

  Completeness5/5

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

  For a zero-parameter status tool with an output schema present, the description is complete: it names the exact information returned and when to call it. Return-value details are already covered by the output schema, so no additional explanation is needed.

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

  Parameters4/5

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

  The tool has zero parameters, so per the baseline rule this scores 4. The description does not need to add parameter meaning since there is nothing to configure, and the input schema is vacuously fully covered.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'Check the SPSS MCP server status' and enumerates exactly what is reported (capabilities, SPSS vs file-only mode, SPSS path, library versions, configuration). This clearly distinguishes it from sibling tools like spss_list_supported_methods or spss_get_method_support, which inspect methods rather than overall server status.

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

  Usage Guidelines4/5

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

  The description gives explicit when-to-use guidance: 'Call this first to understand what tools are available.' It does not mention explicit exclusions or alternatives, but for a status-check tool the sequencing guidance is clear and sufficient context.

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

• spss_filterA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  There are no annotations, so the description carries the behavioral disclosure burden. It clearly communicates that the operation is temporary/reversible and explains the off-switch behavior, which mitigates the main destructive risk. It could go further by stating exactly what gets filtered or whether the file on disk is modified, but the reversibility note is strong.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences with no filler. The most important behavioral distinction, reversibility versus SELECT IF, is front-loaded, and the disabling behavior is stated immediately after.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With an output schema present, the description does not need to explain return values. It covers the core behavior, the off switch, the environment requirement, and the sibling distinction. It leaves minor details implicit, such as what file_path must point to and the exact scope of the filter, but the tool is simple enough that this is not a major gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has no property descriptions (0% coverage), so the description adds real value by explaining that filter_variable is a 0/1 variable and that None turns filtering off. file_path is left to inference from its name, but in this SPSS tool family that is reasonably self-explanatory.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear action ('filter cases'), the exact mechanism ('by a 0/1 variable'), and the temporal nature ('temporarily'). It also distinguishes itself from the sibling tool spss_select_if by noting reversibility, so an agent can tell them apart.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly frames this tool as the reversible, temporary alternative to SELECT IF, which gives clear when-to-use guidance relative to a relevant sibling. It also documents how to disable the filter with filter_variable=None, preventing misuse.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.