spss-studio-mcp

by flupke91

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools correspond to distinct SPSS procedures (e.g., frequencies, crosstabs, t_test), but some overlap in purpose exists within the GLM family (spss_anova, spss_glm_univariate, spss_manova, spss_repeated_measures_anova) and between spss_kaplan_meier and spss_cox_regression. Chart tools are clearly differentiated by chart type, but the high number of similar analytic procedures could cause occasional misselection.
Naming Consistency5/5
All tools share the spss_ prefix. Most use a predictable spss_<procedure> pattern for statistical analyses and spss_chart_<type> for charts, with file/utility tools using verb_noun (spss_list_files, spss_read_metadata). The set is internally consistent and easy to navigate.
Tool Count3/5
At 51 tools, the server is heavily oversized for most use cases, but the scope of an SPSS integration genuinely requires many procedures, charts, and file operations. The count is justified yet borderline, as it may overwhelm agents and slow tool selection.
Completeness4/5
The server covers broad SPSS workflows: data loading/reading, descriptive statistics, common tests, advanced models (logistic, mixed, survival), charts, and syntax execution. Minor gaps exist, such as no dedicated data transformation/recoding tool beyond scale scoring, though spss_run_syntax covers arbitrary operations.
Average 3.6/5 across 51 of 51 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on August 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 prerequisite that IBM SPSS Statistics must be installed and notes the returned outputs, but does not disclose whether the tool modifies files, requires specific data formats, or any side effects. This is insufficient for a tool with no annotation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences and front-loaded with the core purpose. It contains no redundant information, but the lack of structured detail on parameters and usage keeps it from being exceptional.
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?
An output schema exists, so return-value details are covered. However, the description fails to provide usage guidelines, explain parameters like method and include_diagnostics, or mention when to use this tool compared to other regression tools. Given the tool's complexity and zero annotation support, the description 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. The description explains 'dependent' and 'predictors' but leaves file_path, method, and include_diagnostics undocumented. This is a significant gap, especially since file_path is required and method affects the regression procedure.
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 'Run SPSS linear regression' with a specific verb and resource, clearly distinguishing it from sibling tools like logistic or ordinal regression. It also lists key outputs (coefficients, R-squared, ANOVA table, significance tests) that further clarify its function.
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 guidance on when to use linear regression versus alternatives (e.g., logistic regression for binary outcomes). It implies usage by stating what it does, but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behavior. It does mention the output structure, files, warnings, and summary extraction, which is useful. However, it fails to disclose important execution side effects (e.g., arbitrary SPSS syntax may modify data or run long), and it does not explain how the save_* flags affect behavior. This is a significant gap for a tool that executes arbitrary code.
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 dense sentences that are front-loaded with the core purpose and output shape. Every phrase earns its place—it specifies the JSON fields and the types of statistics extracted—without unnecessary verbosity 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?
This is a complex execution tool with 6 parameters and no annotations, so the description needs to cover more than the return value. It does not explain the optional parameters, execution constraints, or how it relates to sibling tools. The presence of an output schema covers return values, but the missing parameter and execution context makes the overall package incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter semantics. It only names 'syntax' implicitly, but does not explain data_file, select_if, filter_variable, or save_* flags. Since the schema offers no descriptions, the tool description needed to compensate, and it completely fails to do so.
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 ('Run SPSS syntax') and the output ('unified structured result as JSON'), which distinguishes it from siblings like spss_run_syntax by emphasizing the structured JSON summary. However, it does not explicitly contrast itself with the similar spss_run_syntax tool, so it lacks the explicit sibling differentiation needed for 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 the tool is for obtaining structured results and summary statistics, but it never explicitly states when to use this versus other SPSS methods, nor does it mention exclusions or alternatives. There is no direct comparison to spss_run_syntax or guidance on choosing between them, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It states that the tool exports a file and returns the path, which is essential. However, it does not mention prerequisites such as an active dataset or the data_file parameter's role, nor any resource implications, though the core export behavior is disclosed.
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 concise (two sentences) and front-loaded with the main action. Each clause adds value, and although the technical detail 'GGRAPH + OMS IMAGE' is somewhat niche, it is not 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 the tool has 9 parameters and no annotations, the description is too sparse. It does not explain the meaning of optional parameters or how data_file relates to the active dataset. The output schema covers return value structure, but the agent still lacks sufficient context to correctly use all parameters or choose this over the density variant.
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 the continuous variable requirement and the image format enum (PNG/TIFF/EMF), but the remaining 7 parameters (dpi, title, labels, dimensions, data_file) are left to an underscriptive schema. This partial coverage is insufficient for fully understanding how to invoke the 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 states that the tool exports a publication-ready histogram and returns a file path, which is a specific verb-resource pairing. However, it does not explicitly differentiate from the sibling spss_chart_histogram_density tool, so it is clear but lacks explicit distinction.
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 a basic usage requirement ('Provide the continuous variable') but gives no guidance on when to use this tool versus alternatives. No exclusions or alternative tool mentions are provided, leaving the agent without enough context to choose among many chart siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must disclose behavioral traits. It only mentions the requirement that IBM SPSS Statistics be installed, which is an environmental prerequisite. It does not state whether the tool modifies files, produces output objects, computes new variables, or has side effects, leaving the agent without enough information about what to expect.
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 unnecessary words. The first sentence states the core action and the second adds key capabilities and a system requirement. It is as concise as possible while providing essential information.
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 having an output schema, this is a complex statistical modeling tool with 8 parameters and 3 required inputs. The description lacks guidance on how to construct the model, what the required parameters mean, or what the output will contain. It is too sparse to be considered complete for an agent needing to invoke it correctly.
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 hints at 'distribution' and 'link' parameters, naming some distribution types but providing no meaning for file_path, dependent, predictors, categorical, scale, or save_predicted. The description does not explain the roles of most parameters or how they should be formatted.
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 it runs a generalized linear model (GENLIN) with flexible distribution and link functions, which is a specific verb+resource. It indicates support for Poisson, binomial, gamma, and negative binomial distributions, distinguishing it from general linear models or mixed models by name and type, but it does not explicitly contrast with siblings like spss_glm_univariate or spss_mixed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for dependent variables following non-normal distributions by listing supported distributions, but it gives no explicit when-to-use vs alternatives or exclusions. The mention of 'flexible distribution and link functions' suggests general applicability to GLMs without specifying when not to use it or when to choose another sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only mentions the installation prerequisite and optional post-hoc tests. It does not state whether the operation is read-only, what output to expect, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the core action and efficiently add the optional post-hoc detail and the SPSS installation requirement; no wasted words.
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 statistical analysis tool with four parameters and no annotations, the description is too thin. It omits data requirements (e.g., dependent must be continuous, factor categorical), supported post-hoc tests beyond examples, and any constraints, even though the output schema may cover results.
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 zero descriptions, so the description must explain parameters. It implicitly covers dependent, factor, and post_hoc through ANOVA context, but fails to mention file_path at all, and provides no explicit parameter mapping.
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 running SPSS's ONEWAY procedure for one-way ANOVA, with optional post-hoc tests. This distinguishes it from sibling tools like spss_glm_univariate and spss_repeated_measures_anova.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool rather than alternatives such as spss_glm_univariate or spss_t_test. The description neither states conditions nor exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the prerequisite of SPSS being installed but does not disclose whether the tool modifies data, returns outputs, creates files, or has side effects. The 'dendrogram' hint is the only behavioral clue, which is insufficient for a complex statistical 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 three short sentences, each contributing distinct value: the primary action, the configurable options, and the external dependency. There is no redundant filler or unnecessary 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?
Given six parameters and a complex statistical procedure, this description is under-specified. It does not explain how to choose a linkage method, what the output (including the dendrogram) looks like, or the role of the id_variable. Although an output schema exists, the description itself provides minimal context for using the tool correctly.
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 vaguely references 'linkage methods and distance measures,' which partially aligns with the 'method' and 'measure' enums, but it does not explain the required 'file_path' and 'variables' parameters or the optional 'dendrogram' and 'id_variable' 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 opens with 'Run hierarchical cluster analysis with dendrogram,' which is a specific verb+resource statement. It clearly distinguishes this tool from siblings like 'spss_twostep_cluster' by specifying the hierarchical method, and the mention of linkage methods and distance measures further clarifies 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 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 vs alternatives. It only states what the tool does and the SPSS installation requirement, but does not mention when hierarchical clustering is appropriate, when not to use it, or whether another cluster tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It mentions output and installation requirement, but does not state whether the operation is read-only, how missing variables are handled, or any side effects or errors. This is insufficient for a 3-parameter 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 three short sentences with a clear action first, followed by output and a prerequisite. Every sentence provides useful information and there is no filler or redundant wording.
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 to explain return values, the description lacks parameter-level clarity and usage context. The bare schema has no property descriptions, and the tool's requirement and prerequisite are not enough to guide invocation for a statistical analysis tool.
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 that variables can be 'one or more' and statistics are 'optional,' but it does not define file_path semantics or which statistics are supported, leaving most parameter meaning unclear.
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 'Run SPSS FREQUENCIES on one or more variables,' giving a specific verb and resource. It clarifies the output as 'frequency tables with counts, percentages, and optional statistics,' which distinguishes it from sibling analysis tools like descriptives or crosstabs.
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 guidance on when to prefer FREQUENCIES over alternatives such as descriptives or crosstabs. It only includes a prerequisite ('Requires IBM SPSS Statistics to be installed'), not use cases, exclusions, or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions the requirement of IBM SPSS Statistics and states it returns reliability statistics, but it does not disclose potential side effects, data prerequisites, or limitations. For an analysis tool, the absence of explicit side-effect information and error conditions is a notable 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 concise, consisting of two sentence fragments that are front-loaded with purpose and key return information. Every word earns its place, with no unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, many similar sibling tools) and absence of annotations, the description is incomplete. It lacks parameter explanations, usage guidelines, and sufficient behavioral context. While an output schema exists, the description does not leverage it to compensate for missing details, leaving the agent unable to invoke the tool confidently for nuanced cases.
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%, so the description must compensate. It does not explain any of the four parameters (file_path, variables, model, scale_name). The mention of Cronbach's alpha hints at the model parameter but does not clarify the ALPHA/OMEGA choice or any other 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 states the tool 'Run SPSS RELIABILITY analysis (Cronbach's alpha)', which is a specific verb+resource that distinguishes it from sibling tools like spss_factor or spss_correlations. Mentioning 'psychometric workflows' further clarifies its intended use.
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 psychometric workflows' provides some context for when to use the tool, but there is no explicit guidance on when not to use it or how it compares to alternatives like spss_factor or spss_compute_scale_score. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, but it only mentions the requirement that IBM SPSS Statistics be installed. It does not disclose side effects, permissions, limitations, or other behavioral characteristics beyond this installation prerequisite, leaving significant gaps.
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, consisting of three sentences that each serve a purpose: defining the operation, noting supported outcome types, and stating a prerequisite. It is front-loaded with the core purpose and contains no irrelevant filler, though it could be slightly tighter by avoiding redundancy with the tool name.
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 having an output schema (which covers return values), the description lacks essential practical details for complex modeling tools: it omits how to specify distribution/link, how random effects are structured, and any discussion of assumptions or data preparation. The installation requirement is the only contextual detail, leaving the tool under-specified for a 7-parameter statistical function.
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 missing parameter explanations. However, it provides almost no parameter-specific guidance, only weakly hinting at the 'distribution' parameter via 'non-normal outcomes' and 'random effects' parameter via the tool's name. It does not clarify required inputs like file_path, dependent, or fixed_effects.
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' and clearly identifies the resource as 'generalized linear mixed model', explicitly mentioning the combination of GLM with random effects. This distinguishes it from sibling tools like spss_genlin (GLM without random effects) and spss_mixed (linear mixed model), giving clear purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'Supports non-normal outcomes with hierarchical structure', which hints at scenarios where this tool is appropriate. However, it does not explicitly state when to use this tool vs alternatives like spss_genlin or spss_mixed, nor does it provide exclusion criteria or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the prerequisite that IBM SPSS Statistics must be installed and lists supported features, which is useful context. However, it does not disclose side effects, output format, error behavior, or whether it saves files. This is a moderate disclosure that could be richer, especially for a complex statistical procedure.
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 core action, and both sentences carry meaningful information. It avoids redundancy and fluff, making it concise and easy to scan. This is an example of efficient writing without irrelevant 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?
This is a complex tool with 8 parameters, no annotations, and an output schema that is not described in the text. The description covers only high-level capabilities and a prerequisite, leaving users without guidance on key parameters and usage context. For a statistical modeling tool, this is incomplete and likely to cause misconfiguration.
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 provides some meaning by tying 'stepwise selection' to the method parameter and 'categorical predictors' to the categorical parameter, but it completely ignores other parameters like contrast, print_options, and save_predicted. Given 8 parameters, this is insufficient guidance for an agent to correctly populate the schema.
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 function: 'Run binary or multinomial logistic regression.' This identifies the specific verb and resource, and the binary/multinomial qualifier helps distinguish it from ordinal or Cox regression. However, it does not explicitly contrast with sibling tools like spss_ordinal_regression or spss_cox_regression, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning support for stepwise selection, categorical predictors, and model diagnostics, suggesting scenarios like model building with categorical variables. But it provides no explicit when-to-use or when-not-to-use guidance, nor does it reference alternative tools such as ordinal or Cox regression. The intended usage is largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It notes that the tool exports a file (implying non-mutating behavior) and mentions GGRAPH + OMS as the underlying mechanism, but it does not disclose potential side effects like file overwriting, output location, error conditions, or limitations. Key behavioral aspects remain unclear.
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 concise, consisting of two short sentences that immediately convey the core purpose and required inputs. There is no fluff or redundant detail—every word earns its place. This is a model of efficient writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters and no annotations, the description is far from complete. It does not explain critical parameters like data_file, dpi, width/height, or image_format, and does not differentiate usage from sibling chart tools sufficiently. Although an output schema exists, the description still leaves too much unspecified for an agent to invoke the tool correctly without further schema inspection.
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 references a 'continuous variable' and 'categorical grouping variable,' which loosely map to the 'variable' and 'category' parameters, but it provides no guidance on the other eight parameters such as dpi, dimensions, image_format, or data_file. The description adds only minimal meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: exporting a publication-ready box-and-whisker plot in PNG/TIFF/EMF formats. It specifically identifies the chart type, distinguishing it from sibling chart tools like scatter, bar, and line. The verb 'Export' plus the specific resource makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating boxplots by specifying required input (continuous variable and optional categorical group), but it does not explicitly state when to use this tool versus alternatives. No exclusions or comparisons to other chart tools are mentioned, leaving the usage context implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implementation via GGRAPH + OMS and the supported output formats (PNG/TIFF/EMF), but does not explain side effects, file handling (e.g., overwriting), prerequisites (like active dataset or required variables), or how the output is returned. This is a significant gap for a tool with 11 parameters.
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, well-structured sentence that front-loads the essential purpose (export chart) and includes key specifics (formats, statistical content, implementation). There is no wasted wording, and it is appropriately sized for the tool's core function.
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 having an output schema, the description lacks crucial context for an 11-parameter tool: it does not explain the role of data_file, dimensions, format details, or how the chart is generated and returned. The absence of parameter descriptions and behavior notes makes it incomplete for reliable invocation, particularly in edge cases or customizations.
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 hints at a few parameters: 'mean' relates to value, 'category' relates to category, and 'confidence-interval' relates to ci. It does not explain the meaning of dpi, image_format, width_px, height_px, title, labels, or data_file. Thus, the description fails to compensate for the lack of schema descriptions, leaving many parameters opaque to the agent.
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 function: exporting a publication-ready error bar chart with mean and confidence-interval whiskers per category. The verb 'Export' is specific, the resource is well-defined, and the scope (mean with CI whiskers) distinguishes it from general bar charts or histograms. Though it doesn't explicitly name sibling alternatives, the unique chart type and formats 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 usage when an error bar chart is needed, but it does not explicitly state when to use this tool versus alternatives like spss_chart_bar_error or spss_chart_bar. There are no exclusion criteria or mentions of other chart tools, so the guidance is merely implied rather than clearly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool runs the KM procedure and exports specified image formats, but it does not mention side effects, prerequisites like an active dataset, or output behavior such as file paths or return values. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the tool's purpose and the essential inputs. There is no redundant or extraneous text, and the structure front-loads the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, 0% schema coverage, and no annotations, the description is too sparse to be fully actionable. It covers only three parameters and does not address formatting dimensions, event coding semantics, or data_file defaults, even though the 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. It only explains time, status, and group, leaving seven other parameters (dpi, event, title, width_px, data_file, height_px, image_format) without added meaning. This fails to provide sufficient guidance for an agent invoking the tool.
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 ('Export') and clearly identifies the resource as a 'publication-ready Kaplan-Meier survival curve' with output formats (PNG/TIFF/EMF). This distinguishes it from sibling chart tools and from spss_kaplan_meier, which likely performs the analysis rather than the chart export.
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 provides clear context that time and status variables are required and group is optional, giving preconditions for use. However, it does not explicitly mention alternatives or when not to use this tool, such as using spss_kaplan_meier for statistical results or other chart types for different visualizations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 PPLOT and OMS pipeline, but it does not clarify whether the chart is returned directly, saved to a file, or how the data_file parameter affects execution. It also lacks any mention of side effects, prerequisites, or output format details beyond the image types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and chart type. It avoids unnecessary words, though the acronyms PPLOT and OMS could be slightly more transparent to a general agent.
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 purpose is well-covered, but the description lacks guidance on when to use the tool, parameter semantics for several fields, and behavioral details like return values or file handling. Given the 7-parameter schema and output schema existence, more contextual completeness would be expected.
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?
With 0% schema coverage, the description must compensate for parameter documentation. It does clarify that 'variable' is a continuous variable and lists image formats (matching image_format), but it leaves dpi, title, dimensions, and data_file unexplained. This is 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a specific chart type (normal Q-Q plot) with supported formats (PNG/TIFF/EMF) for a continuous variable, using a specified method (PPLOT via OMS). This distinguishes it from sibling chart tools and statistical procedures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for continuous variables to create normal Q-Q plots, but it does not explicitly state when to use this tool versus alternatives such as spss_normality_outliers or other chart types. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only mentions the installation requirement and does not disclose whether the operation is read-only, what output is returned, potential side effects, or handling of missing data. This is insufficient for an agent to anticipate the tool's runtime 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?
The description is a single sentence that is direct and free of redundancy. It front-loads the key action and output, and the additional installation note is concise. No words are wasted.
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 that the tool has four parameters and no annotations, the description is too sparse to be contextually complete. It lacks information about data assumptions, output structure (despite an output schema existing), or typical use cases beyond the bare statement of computing a correlation matrix. The agent would need to infer too much.
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 for parameters, and the tool description does not compensate. It mentions 'Pearson' and 'Spearman', which relates to the method parameter, but says nothing about file_path, variables, or two_tailed. The agent receives minimal guidance on how to set them correctly.
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 function: 'Run SPSS CORRELATIONS to compute Pearson or Spearman correlation matrix.' It names the specific SPSS procedure, the verb 'compute', and the output type. This unambiguously distinguishes it from sibling statistical tools like spss_regression or spss_t_test.
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 context is implied: you would use this when you need a correlation matrix. However, it does not explicitly mention alternatives or when-not-to-use. The prerequisite 'Requires IBM SPSS Statistics to be installed' provides some operational guidance but not comparative selection advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behavior. It discloses the environmental requirement and high-level outputs, but does not mention side effects, permissions, speed, or whether it writes output files. The output schema likely covers return values, but the description alone offers limited behavioral context.
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 sentences, front-loaded with the core purpose, followed by outputs and a necessary prerequisite. Every sentence earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (7 parameters, statistical analysis) but the description omits parameter semantics and usage disambiguation from sibling survival/plot tools. Although an output schema exists, the missing guidance on when to use and how to configure parameters makes the description incomplete.
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 provides no parameter-level details. While parameter names like 'time_variable' and 'status_variable' are suggestive, the description adds no meaning for fields such as 'status_event_value' or 'compare_method' enum values, leaving the agent without guidance on how to populate the 7 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 clearly states a specific action ('Run Kaplan-Meier survival analysis with log-rank test') and resource, which distinguishes it from sibling tools like spss_cox_regression and spss_chart_km_curve. It also mentions expected outputs ('survival curves' and 'compares groups'), fully conveying the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for survival analysis comparing groups but does not explicitly state when to use this tool over alternatives such as spss_cox_regression. It mentions a prerequisite (IBM SPSS Statistics installed) but lacks guidance on exclusions or alternative selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the burden of behavioral disclosure. It adds one meaningful prerequisite (IBM SPSS Statistics installation) and notes supported structures, but does not disclose side effects, error behavior, or output specifics. The description largely repeats capabilities rather than providing 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the purpose; every sentence adds relevant context about the tool's scope and prerequisite. No filler or redundancy.
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 9-parameter tool with no schema descriptions and no annotations, this sparse description leaves significant gaps in how to invoke correctly. It covers supported model types but lacks parameter semantics and usage guidance, making it insufficient for an agent despite an output schema existing.
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 vaguely references random effects and repeated-measures structures. It does not explain required parameters like file_path, dependent, and fixed_effects, nor optional ones such as method, subject, covtype_random, and repeated_type.
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 clearly identifies the tool as a linear mixed-effects model with random effects, including nested/crossed random effects and repeated measures. This distinguishes it from sibling analysis tools like spss_glm_univariate or spss_genlinmixed, even though it does not explicitly name them.
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 multilevel modeling with random effects and repeated measures, giving clear context. However, it provides no explicit when-to-use vs alternatives or exclusions, such as when to choose spss_genlinmixed for generalized models or spss_repeated_measures_anova for simpler repeated-measures designs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It mentions the prerequisite that SPSS must be installed, but does not disclose side effects, return behavior, data handling, or what happens if SPSS is missing. Other than the prerequisite, no behavioral traits are revealed.
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 concise, using two short sentences (21 words) and front-loading the core purpose. The prerequisite sentence is valuable and earns its place. No filler or redundancy.
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 is moderately complex with 5 parameters, 3 required, and an output schema. The description is too sparse for an agent to invoke correctly without additional information about parameter structure (e.g., how 'variables' relates to 'grouping_variable' or 'group_values'). It also lacks behavioral context and does not leverage the output schema to explain returned results.
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 the 5 parameters. It provides the enum values for test_type by naming the three tests, which adds some meaning. However, it does not explain file_path, variables, group_values, or grouping_variable, leaving significant ambiguity for a user preparing input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Run', the resource 'common nonparametric tests in SPSS', and specifically lists the three test types (Mann-Whitney U, Wilcoxon signed-rank, Kruskal-Wallis). This distinguishes it from sibling tools like t_test, anova, and regression which are parametric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for nonparametric testing through the term 'nonparametric', but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or assumptions. The prerequisite 'Requires IBM SPSS Statistics to be installed' is a useful context but does not guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only mentions feature support (link functions, parallel lines) and the SPSS requirement. It does not explain side effects (e.g., save_predicted behavior), whether it modifies data, or what the output looks like. This is a significant transparency gap for a statistical procedure with multiple options.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the tool's purpose, key features, and prerequisite. Every phrase earns its place with no filler or redundancy, exhibiting strong front-loading and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no annotations, output schema present), the description is too brief to be fully contextual. It does not explain the workflow, result interpretation, or how parameters interact. While an output schema exists, the description still lacks necessary context for correct invocation, especially considering the absence of parameter descriptions in the schema.
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%, so the description needs to compensate by explaining parameter meanings. However, it only references 'link functions' and 'parallel lines test' without detailing the parameters themselves (file_path, dependent, predictors, categorical, save_predicted). The description adds almost no value beyond the raw schema, leaving the agent uninformed about 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 states the tool runs ordinal regression (PLUM) for ordered categorical outcomes, using a specific verb and resource. It distinguishes itself from sibling regression tools by specifying the outcome type (ordered categorical), making its 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it is for ordered categorical outcomes, which tells when to use it. It also mentions the prerequisite that IBM SPSS Statistics must be installed, which is useful guidance. However, it does not explicitly name alternatives or define exclusions, so it falls 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.
Behavior3/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 discloses a key prerequisite ('Requires IBM SPSS Statistics to be installed') and lists supported features, but does not describe behavioral traits such as whether the tool modifies files, long-running behavior, error modes, or side effects. The prerequisite and feature list add some context, but richer behavioral disclosure is absent.
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. It is front-loaded with the core purpose ('Run Cox proportional hazards regression'), followed by capabilities and a requirement. No wasted words; every sentence contributes meaningful 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 complex 9-parameter statistical tool with no parameter descriptions, the description provides a high-level summary but lacks details needed for correct invocation. The existence of an output schema reduces the need to explain return values, but input semantics and usage context are still thin. It is minimally adequate but leaves clear gaps for an agent.
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 explaining the 9 parameters. It only indirectly hints at 'stratification' correlating with the strata parameter, but does not explain method, categorical, save_survival, status_event_value, or the relationship between predictors and time-dependent covariates. This is insufficient for correctly constructing a call.
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 action and resource: 'Run Cox proportional hazards regression for survival analysis.' It also lists specific capabilities (time-dependent covariates, stratification, model diagnostics) that distinguish it from sibling survival tools like spss_kaplan_meier. This is a specific and informative purpose statement.
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 guidance on when to use this tool versus alternatives. It does not mention competing analyses (e.g., Kaplan-Meier for survival curves, logistic regression for binary outcomes) or exclusion criteria. The only practical note is the SPSS installation requirement, which is a prerequisite, not a usage guideline. This lacks the 'versus' context needed for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral transparency, but it only reveals that it exports via GGRAPH + OMS. It does not disclose side effects like file creation or overwriting, prerequisites, required data context, or what happens on failure. This is a significant gap for an export 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 a single, front-loaded sentence that immediately states the key action, resource, and output formats. No redundant filler or excessive detail; it earns its place 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?
Despite the tool's moderate complexity (11 parameters, 2 required), the description gives no guidance on data source, parameter semantics, or output handling. The presence of an output schema is not leveraged in the description, leaving the agent with insufficient information for reliable invocation.
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 description hints that 'category' and 'value' are used for means and that image_format may be one of the listed formats, but it does not explain critical parameters like ci, dpi, width_px, height_px, labels, title, or data_file. With 0% schema description coverage, the description fails to compensate for the missing parameter context across 11 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 uses specific verb 'Export' and clearly identifies the resource: a bar chart of category means with confidence-interval error bars. This distinguishes it from sibling tools like spss_chart_bar and spss_chart_errorbar, and the format list (PNG/TIFF/EMF) adds further specificity.
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 'category means with confidence-interval error bars' conveys a clear use case that differs from simpler bar charts or standalone error bar charts. However, it does not explicitly mention when to choose this over alternatives or provide any exclusions, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behavioral traits. It mentions a key prerequisite (IBM SPSS Statistics installed) and the core outputs (eigenvalues, variance explained, rotated factor matrix). However, it does not disclose side effects, read-only behavior, error handling, or output format details, leaving significant 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 three sentences, front-loaded with the core action, and each sentence adds distinct information: what it runs, what it produces, and a critical prerequisite. No unnecessary words 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 complex statistical tool with five parameters and an output schema, the description is quite sparse. It fails to explain parameter meanings, extraction methods, rotation choices, or how to interpret results. While the output schema may cover return structure, the description alone is insufficient for an agent to use this tool 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. It implicitly references the method parameter by naming PC and PA, and rotation via 'rotated factor matrix,' but it does not explain the required parameters file_path and variables, nor n_factors. This leaves most parameters under-specified, providing only minimal semantic 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 clearly states the tool runs SPSS FACTOR analysis, specifically naming principal components and principal axis factoring, and lists key outputs. This unambiguously identifies the tool's function and distinguishes it from siblings like regression or cluster analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for factor analysis but provides no explicit guidance on when to choose this tool over alternatives such as PCA or other dimension reduction methods. It neither mentions exclusions nor suggests alternative tools, so usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only mentions the requirement that IBM SPSS Statistics be installed, but does not disclose what the tool returns, whether it modifies files, or any side effects. This is a significant gap for a statistical computation 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 long, front-loaded with the core purpose, and every sentence adds value. It efficiently states what the tool does and a key requirement without any 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?
Given the complexity of 8 parameters and no schema descriptions, the description is too minimal. It does not provide enough context for an agent to decide when to choose this over spss_anova, how to specify the model, or what the output shape will be. The tool's integration in a broader SPSS suite requires more guidance.
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 compensate. It mentions 'estimated marginal means' and 'post-hoc tests' which map to emmeans and posthoc parameters, and 'contrasts' which is not a parameter in the schema. It does not explain core parameters like file_path, dependent, factors, covariates, or save_predicted, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Run univariate general linear model (GLM) with factorial designs,' using a specific verb and resource. It distinguishes itself from sibling tools like MANOVA or ANOVA by specifying 'univariate' and 'factorial designs,' making its 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for factorial designs and lists supported features (estimated marginal means, contrasts, post-hoc tests), giving clear context for when to use it. However, it does not explicitly name alternatives or exclusion criteria, such as preferring spss_anova for simpler models, so it misses a point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses that the tool tests multivariate effects, provides univariate follow-ups, and requires IBM SPSS Statistics. However, it does not state whether it modifies data, how missing values are handled, or other behavioral constraints 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?
The description is three short sentences, front-loaded with the core action followed by output behavior and prerequisite. There is no fluff or redundancy; each sentence adds necessary 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 complex tool with 8 parameters and no annotations, the description is too sparse. While an output schema exists (covering return values), it omits usage guidance, parameter semantics, and assumptions (e.g., data requirements, missing data handling), leaving the agent under-informed for correct invocation.
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% parameter description coverage, so the description must compensate. It only hints at the role of dependents ('multiple dependent variables') and indirectly factors, but does not explain method, factor_ranges, covariates, print_multivariate, print_univariate, or other parameters. This is insufficient for an 8-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run') and the resource ('multivariate analysis of variance (MANOVA) for multiple dependent variables'), which precisely identifies what the tool does. It also mentions univariate follow-ups, making it distinct from univariate ANOVA tools like spss_anova.
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 by specifying it is for 'multiple dependent variables', but it does not explicitly mention alternatives or exclusionary conditions. It only notes a prerequisite (SPSS installed), which is useful but not full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions the requirement for IBM SPSS to be installed and the input structure. It does not describe what happens when run (e.g., output format, side effects, errors, or processing time).
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 adds value. It is concise and well-structured without unnecessary detail.
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 has moderate complexity, and an output schema exists, so return values are presumably covered. The description gives enough to run the analysis but omits the optional pairwise parameter and any assumptions or limitations. It is minimally viable but lacks richer context.
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 meaning for the core parameters by explaining to provide a within-factor name, number of levels, and one variable per level. However, it does not explain the optional 'include_pairwise' parameter.
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 runs SPSS repeated-measures ANOVA (within-subject GLM), which is a specific verb+resource. It distinguishes from sibling tools like spss_anova and spss_glm_univariate by specifying the repeated-measures/within-subject design.
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 (repeated measures) but provides no explicit comparison to alternatives or exclusions. It says to provide within-factor name, levels, and variables, but does not mention when to choose this over spss_mixed or regular ANOVA.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It notes that IBM SPSS Statistics must be installed, which is a key prerequisite, and lists supported test types, but it doesn't disclose error behavior or parameter relationships.
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?
A single sentence with no filler; it front-loads the verb and resource and includes only core information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, 3 required, and types with different parameter needs), this description is too thin to guide correct usage. It doesn't explain which params apply to which test type or how to structure the variables array.
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 zero descriptions for its 5 parameters, and the description only partially illuminates test_type by naming its three enum values. File path, variables, test_value, and grouping_variable remain obscure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run SPSS t-test') and lists the three supported test types, which distinguishes it from sibling statistical 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?
It implies usage for t-tests by naming the tool and enumerating supported types, but it doesn't explicitly state when to prefer this over alternatives like ANOVA or nonparametric tests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only discloses the prerequisite 'Requires IBM SPSS Statistics to be installed.' It does not mention side effects, whether it is read-only, how missing values are handled, or what the output looks like—leaving major 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 three concise sentences, front-loaded with the core purpose, followed by relevant capabilities and a prerequisite. There is no fluff or redundancy.
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 having an output schema, the tool is complex with 7 parameters and no annotations. The description offers only a high-level overview and one prerequisite, but lacks guidance on parameter selection, data preparation, or invocation context, making it incomplete for reliable use.
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 7 parameters with 0% description coverage, so the description must compensate. It hints at 'automatic cluster number determination' (implying num_clusters can be null) and 'mixed variable types' (implying continuous/categorical parameters), but does not explain any parameter names, ranges, or behaviors. This is insufficient for 7 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 clearly states 'Run two-step cluster analysis with automatic cluster number determination,' which is a specific verb+resource combination. It also distinguishes from sibling tools like spss_cluster_hierarchical by explicitly mentioning automatic clustering and mixed variable types.
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 implies when to use the tool: when handling large datasets, mixed variable types, and needing automatic cluster count. However, it does not explicitly exclude alternatives or name the hierarchical cluster tool as an alternative, so it lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It mentions the implementation (GGRAPH + OMS) but does not reveal side effects such as file overwriting, output management changes, or error handling. No details on missing data or validation behavior are provided.
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, well-structured sentence that is front-loaded with the action ('Export') and includes all essential information without fluff. Every word contributes 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?
Given the tool has 10 parameters and many sibling chart types, the description provides a minimal viable definition but lacks guidance on file output, data_file usage, or interaction with other settings. The existence of an output schema covers return values, but the description remains somewhat thin for the complexity involved.
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 clarifies x and y ('y against a time/ordinal x variable'), leaving dpi, title, width, height, data_file, and other parameters unexplained. The mention of formats partially covers image_format but not the rest.
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 exports a publication-ready area chart, specifies output formats (PNG/TIFF/EMF), and defines the relationship between y and a time/ordinal x variable. This distinguishes it from sibling chart tools like line or scatter plots.
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 clear usage context by specifying that the chart plots y against a time/ordinal x variable, implying when an area chart is appropriate. However, it does not explicitly name alternatives or state when not to use this tool, so it falls 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds some behavioral context by noting the IBM SPSS requirement and supported options (stepwise selection, cross-validation). However, it does not disclose potential side effects such as creating new variables or modifying the input file, or any permissions or error 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?
Two sentences that are lean and front-loaded: the first states the core purpose, the second adds key capabilities and a prerequisite. No wasted words or 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 complex statistical tool with 8 parameters and an external dependency, the description covers the essential identity and requirement but omits details like data format expectations, grouping variable constraints, or output behavior. The presence of an output schema lessens the need to describe return values, but assumptions and preconditions are missing.
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 by explaining parameter semantics, but it does not. It only hints at stepwise selection, which maps vaguely to the method enum, but leaves parameters like priors, group_values, and save_class unexplained. The description adds minimal value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: 'Run discriminant analysis to classify cases into groups.' This is a specific verb+resource statement that distinguishes it from sibling tools like regression or factor analysis. Mentioning stepwise selection and cross-validation further clarifies 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 when discriminant analysis is needed for classification, but it does not explicitly contrast with alternatives like logistic regression or MANOVA, nor does it provide when-not-to-use guidance. The context is clear enough for a basic selection but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states that SPSS is not required, which is useful. However, it does not explicitly state that the operation is read-only, nor does it mention error handling or behavior for missing labels. The 'list' action implies read-only, but more explicit disclosure would strengthen this.
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: two sentences that state the main action, optional filter, and key technical note. No wasted words, and all information is relevant.
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?
This is a simple tool with two parameters and an existing output schema. The description covers the main purpose and optional filtering. It lacks some detail on search behavior and file path requirements, but given the simplicity and output schema, it is reasonably 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 explains that the 'search' parameter filters by a search term, but does not specify whether it searches variable names, labels, or both. The 'file_path' parameter is not explained beyond its name, though it is self-explanatory. Partial but not complete compensation.
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 lists variable names and their labels from an SPSS .sav file, using the specific verb 'List' and indicating the resource. It also mentions optional filtering, which distinguishes it from other SPSS sibling tools like spss_list_files or spss_read_data.
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 alternatives. It only notes that SPSS is not required, which is a technical detail rather than usage context. No alternative tools are mentioned, and no scenarios for use are described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 key side effects (persisting .spv and .sps files by default), prerequisites (IBM SPSS Statistics installed), and output format (Markdown). This goes beyond the schema and adds important context.
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 sentences, front-loaded with the core action and output, followed by optional data_file behavior and then side effects/prerequisites. Every sentence adds value with no 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?
The tool is complex (7 params, no annotations) but has an output schema, so return values need not be explained. The description covers purpose, side effects, and prerequisites, but it misses key parameter behaviors like filtering and dry_run, leaving the description incomplete for fully reliable invocation.
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 data_file (prepends GET FILE) and indirectly the save flags (persisting files), but fails to describe dry_run, select_if, and filter_variable. These parameters remain under-defined for a 7-parameter tool.
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: 'Execute arbitrary SPSS syntax commands and return the output as Markdown.' This distinguishes it from sibling tools that provide specific analyses, making the general-purpose nature explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. Given the many sibling tools for specific procedures, the description should mention that this is for arbitrary syntax not covered by dedicated methods, but it does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses the technical mechanism ('via GGRAPH + OMS') and the output nature ('Export'), but it omits important behavior such as what OMS does (e.g., suppressing table output), file handling details (naming, overwriting), or behavior when the variable is not continuous. The description is not misleading but is under-specified for a tool with no annotation safety net.
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 that states the action, output, and key input requirement. Every word adds value, and there is no irrelevant filler. It is appropriately concise for a focused chart-export tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, 0% schema coverage, and no annotations, the description must carry a heavy load but only covers the core purpose and one input. It does not explain the data_file parameter, default behaviors, or how the output is returned (although an output schema exists, that doesn't cover input semantics). The description is too sparse to enable correct use in varied contexts.
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 for the variable parameter ('Provide a continuous variable'). Parameters like data_file, dpi, width_px, height_px, image_format, and labels are left entirely to their names, which may be self-explanatory for some but not all (e.g., data_file). The description fails to compensate for the lack of 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 clearly states a specific action ('Export a publication-ready histogram overlaid with a normal density curve') and distinct output formats (PNG/TIFF/EMF), which differentiates it from sibling tools like spss_chart_histogram that likely produce a simpler histogram without the density overlay. The verb 'Export' and resource specification are precise.
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 instruction 'Provide a continuous variable' gives a clear prerequisite for use. The description implies when to use it (when a histogram with normal density is needed) but does not explicitly name alternatives or exclusions, such as 'use spss_chart_histogram if you don't need the density curve.' Overall, the context is clear but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions the export mechanism (GGRAPH + OMS IMAGE) and that a file path is returned, but does not clarify side effects like file overwriting, required active SPSS dataset, or variable type constraints. This is moderate transparency but leaves significant 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?
Two succinct sentences with no filler. The core purpose, required inputs, and return value are front-loaded. Perfectly concise for the information provided.
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?
Provided complexity is moderate (10 params, no annotations, output schema exists). The description covers the main action and return value, but omits behaviors like file saving details, prerequisites, and parameter formats. It is minimally viable but not fully complete for a charting tool with many options.
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%. The description adds meaning for x and y (time/ordinal and the variable), but the other 8 parameters (dpi, title, labels, width, height, data_file, image_format) are not explained. Given 10 parameters, the description compensates poorly 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 clearly states the tool exports a publication-ready line chart, names the specific technology (GGRAPH + OMS IMAGE), and lists output formats (PNG/TIFF/EMF). This distinguishes it from sibling chart tools (e.g., spss_chart_bar, spss_chart_scatter) and the verb 'Export' is specific.
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 implies usage by specifying to provide x (time/ordinal) and y variables, and the tool name makes the line chart context obvious. However, it does not explicitly exclude other chart types or reference sibling tools as alternatives, so it falls short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 export mechanism (GGRAPH + OMS IMAGE), the output formats (PNG/TIFF/EMF), and the return of a file path—useful behavioral details beyond the schema. It doesn't mention whether the tool overwrites files or how data is sourced (e.g., active dataset vs. data_file parameter), which is a slight gap, but the core outcome is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and then gives a quick usage note. It avoids fluff and every clause earns its place. However, it is almost too terse for a tool with 10 parameters, but for conciseness alone it's efficient and clear.
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 10 parameters, no annotations, and schema descriptions cover none of the parameters. The one-sentence description leaves critical gaps, particularly the data_file parameter (how to supply data if no active dataset exists) and the meaning of visualization options like dpi, labels, and dimensions. Even though an output schema exists, the lack of guidance on data source and optional formatting makes the description incomplete for effective use.
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 meanings. It only clarifies x and y variables and optionally implies the image format list (PNG/TIFF/EMF). Many parameters remain unexplained: dpi, title, x_label, y_label, width_px, height_px, data_file, and image_format defaults. The description provides minimal semantic value beyond the schema's type/default information, leaving users guessing about data_file and formatting options.
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 exports a scatter plot in PNG/TIFF/EMF formats using GGRAPH + OMS IMAGE. The verb 'Export' and specific resource 'scatter plot' distinguish it from sibling chart tools like histogram or bar. It also mentions the key inputs (x and y variables), 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives direct instruction to provide x and y variables, which is the core usage. It also notes that the chart file path is returned for direct submission, providing context for when this tool is appropriate (e.g., preparing publication figures). However, it doesn't explicitly contrast with alternative chart tools or state when not to use it, though the name and sibling list make this somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses that the tool returns specific statistics and requires IBM SPSS Statistics to be installed, which is useful. However, it does not mention what happens with invalid variables, missing values, or how optional statistics behave.
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 front-load the action and output. Every word contributes value, and no redundant information is present.
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 likely covers return values, so the description's mention of returned statistics is enough on that front. However, the parameter semantics gap for file_path and the vague 'optional statistics' leave the tool under-specified for correct use.
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 hints at 'variables' being numeric and 'optional statistics' existing. It does not explain file_path, the format of variables, or what statistics values are accepted, leaving significant ambiguity for correct invocation.
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 runs SPSS DESCRIPTIVES for numeric variables and lists the computed statistics (N, mean, std deviation, min, max, optional statistics). This specific verb-resource pairing distinguishes it from siblings like spss_frequencies and spss_correlations.
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 clear context: use for numeric variables and requires SPSS installed. It does not explicitly mention alternatives or when not to use, but the numeric-variable scope effectively implies its primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 adds valuable context by stating the computation is done locally and does not require SPSS, which is a key behavioral trait. However, it does not mention potential side effects like file size limitations, error conditions, or whether the operation is read-only (though that is 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?
The description is two sentences, front-loaded with the purpose, and includes the key differentiator ('no SPSS needed') without any wasted words. Every sentence contributes meaningful 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 tool's simplicity (one parameter, output schema present), the description is fairly complete: it lists the exact contents of the summary and highlights the local computation aspect. It could mention potential failure modes or file requirements, but the output schema covers return values and the tool is straightforward.
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 one parameter (file_path) with zero description coverage. The description indirectly clarifies that the file_path should point to an SPSS .sav file, but does not explicitly document the parameter or provide additional syntax, format, or prerequisite details. It 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 clearly states a specific verb+resource: 'Get a summary of an SPSS .sav file' and enumerates exactly what the summary contains (case count, variable count, variable list, basic descriptive statistics). This distinguishes it from siblings like spss_read_metadata or spss_descriptives, which target more detailed or specific outputs.
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 'computed locally (no SPSS needed)' implies this tool is useful when SPSS is unavailable or for a quick overview, but no explicit alternatives or when-not-to-use scenarios are mentioned. The context is clear but lacks explicit exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the output contents (command family, support tier, coverage assertions, documentation tags), which is helpful. However, it doesn't explicitly state that this is a read-only operation, whether it errors for unsupported methods, or any other behavioral nuances. It's adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action ('Get support metadata') and lists the specific output categories without any fluff. Every phrase earns its place, and the structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and an output schema (not shown), so return value details are handled by the schema. The description covers the key output categories and the tool's scope. It lacks a mention of failure cases or prerequisites (e.g., method must exist), but given the simplicity, it's largely 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 coverage is 0% and the schema only shows 'tool_name' as a string with no description. The description indirectly implies that tool_name refers to the registry-backed SPSS method name, but it doesn't explicitly state what values are valid or how to obtain them (e.g., via spss_list_supported_methods). The meaning is inferable but not fully clarified.
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 ('Get') and clearly identifies the resource ('support metadata for a registry-backed SPSS method'), further detailing the contents ('command family, support tier, coverage assertions, documentation tags'). This distinguishes it from sibling tools like spss_list_supported_methods (list) and spss_get_method_schema (schema).
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 purpose implies usage (look up support metadata for a method), but there is no explicit 'when to use this vs. alternatives' guidance. It doesn't mention that spss_list_supported_methods provides the valid method names or that spss_get_method_schema handles schema queries, so the agent is left to infer context from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 transparency. It discloses that the tool creates a .sav file, where it saves by default, and that it bypasses the SPSS engine. However, it omits important behavioral traits such as whether existing files are overwritten, data type handling, or encoding limitations. This is adequate but not deeply transparent.
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 sentences, front-loaded with the core purpose, and every sentence adds value: what it does, why it's faster, and where output goes. No redundant or filler text. It is succinct and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 params, no annotations), the description provides the essential context for the primary use case but leaves out guidance on several parameters (encoding, delimiter, column_labels) and potential edge cases like overwriting or unsupported features. It is sufficient for a straightforward conversion task but lacks depth for full autonomous use without schema alone.
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 understanding. It only mentions 'output_path' as a custom destination; it does not explain 'encoding', 'delimiter', or 'column_labels', even though these are important for correctly importing a CSV. The parameter names are somewhat self-explanatory, but the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Convert a CSV file to SPSS .sav format'. It clearly differentiates from sibling analysis tools by naming the conversion goal and the technical approach (pandas + pyreadstat), and contrasts with SPSS syntax execution via spss_run_syntax. This 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 description implies the primary use case: converting CSV to SPSS .sav without requiring SPSS installation. It explicitly compares to 'going through SPSS syntax' and notes it is 'much faster', providing an alternative. However, it does not state when not to use this tool or mention any prerequisites beyond the CSV file, so it is slightly short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states it runs EXAMINE and checks normality/outliers, but does not disclose whether the operation is read-only, how missing data is handled, or potential failure modes. Some behavior is conveyed but not comprehensive.
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 core purpose, and includes a necessary prerequisite. There is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple analysis tool, the description provides sufficient context to select and invoke it. An output schema exists, so return values need not be described. Minor gaps include lack of annotation-level safety info and minimal param details, but overall acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies that variables are numeric and plots are optional, covering two of three parameters. However, file_path is not described, leaving some ambiguity about expected path format or supported file types.
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 specifically states 'Run SPSS EXAMINE to check normality and outliers for numeric variables', using a clear verb and resource. It also mentions optional diagnostic plots, making it distinct from sibling tools like descriptives or frequencies.
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 normality/outlier checks and provides a prerequisite (IBM SPSS Statistics installed), but it does not explicitly say when to use this tool versus alternatives like spss_descriptives or spss_chart_qqplot.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior fully. It mentions output formats (PNG/TIFF/EMF), publication-ready, and the underlying method (GGRAPH + OMS IMAGE), but doesn't disclose side effects, file saving behavior, or requirements. This adds some behavioral context but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that front-loads the tool's purpose and key options. No redundant or unnecessary phrasing.
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?
With 11 parameters and no annotations, the description only covers a subset of parameters and lacks usage caveats. The output schema covers return values, but the description's thinness forces the agent to infer several parameter meanings (e.g., width_px, height_px, data_file) and chart behavior (e.g., how missing values are handled). This is a moderate gap for an agent to select and invoke the tool accurately.
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 category, value, and stat via the main purpose sentence, and image_format explicitly mentions PNG/TIFF/EMF. However, other 8 params (dpi, title, x_label, y_label, width_px, height_px, data_file) are left to inference from their names, providing only partial compensation.
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 'Export' and clearly identifies the resource: a publication-ready bar chart of a categorical variable against the mean/sum of a continuous variable. This clearly differentiates it from sibling chart tools like spss_chart_histogram or spss_chart_line by specifying the bar chart type and aggregation.
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?
Description provides clear context about the tool's purpose (bar chart for categorical vs continuous) but does not explicitly state when to use it over alternatives like spss_chart_bar_error or spss_chart_histogram. No exclusions or alternative tool mentions are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses core behaviors: computing sum/mean, optional reverse coding, and minimum valid item count, plus the installation requirement. However, it does not describe side effects like whether it overwrites variables, or what happens when min_valid is not met, leaving notable transparency 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 two sentences long, front-loaded with the main action and key features. Every phrase adds value without redundancy, making it highly concise and well-structured.
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 provides a high-level overview but lacks details on parameter semantics, edge cases, and dataset mutation behavior. The presence of an output schema helps but does not cover the full context needed to use the tool correctly.
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 conceptual meaning for some parameters by mentioning method (SUM/MEAN), reverse coding, and minimum valid item count. But it does not explain individual parameters like reverse_min/reverse_max or the items array, leaving ambiguity for a tool with 8 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 clearly states the action ('Compute a scale score'), the resource ('from multiple item variables'), and the methods ('SUM or MEAN'). It also mentions optional reverse coding and minimum valid count, which distinguishes it from sibling tools like spss_reliability_alpha that compute reliability instead.
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 for when to use the tool: to compute scale scores from item variables. It also provides a prerequisite ('Requires IBM SPSS Statistics to be installed'). However, it does not explicitly mention when not to use it or recommend alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the burden of behavioral disclosure. It states this is a retrieval operation but doesn't elaborate on side effects, prerequisites, or registry behavior. 'Registry-backed' adds some context, but the description remains minimal.
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, front-loaded with the primary action and followed by a purpose clause. Every word earns its place with no redundancy.
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 introspection tool with an output schema, the description adequately covers purpose and usage. It could be slightly more complete by detailing the tool_name parameter, but the overall simplicity and schema presence make this sufficient.
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 the meaning of 'tool_name'. Although the parameter name is self-evident, the description fails to explicitly connect it to the SPSS method being inspected, leaving the agent to infer from the tool name alone.
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 function: 'Get the JSON schema for a registry-backed SPSS method.' This is a specific verb+resource that distinguishes it from siblings like spss_list_supported_methods and spss_get_method_support by focusing on schema retrieval.
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 clear context for when to use the tool: 'Useful for structured orchestration and parameter inspection before execution.' It doesn't explicitly name alternatives or exclusions, but the use case is specific enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It accurately describes a read-only listing operation but doesn't disclose behaviors like error handling, sorting, or how paths are returned. For a simple list operation, basic transparency is met but with minimal depth.
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 core action, and includes a practical use case without unnecessary filler. 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?
An output schema is present, so return values are likely covered. The description gives sufficient context for a simple file-listing tool, but the lack of parameter guidance and behavioral details prevents a perfect score. Still, it is functionally complete for its simplicity.
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 mentions 'directory' generically without explaining the 'recursive' parameter at all. It fails to add meaning beyond the schema, leaving the boolean flag 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?
The description clearly states 'List SPSS .sav files in a directory' with a specific verb and resource. It distinguishes itself from sibling tools like spss_list_variables or spss_read_metadata by focusing on file system discovery rather than data content.
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 provides a clear use case: 'Useful for discovering available datasets when the user hasn't specified a file path.' This implies when to use it, though it doesn't explicitly exclude alternatives or mention other tools. The context is specific enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It reveals that the tool returns a Markdown report and does not require SPSS, but it does not mention side effects, permissions, or error conditions. The read-only nature is implied by 'Read', but more explicit detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core action, and contains no filler. Every clause adds value, making it a model of concise structure.
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 single-parameter, read-only metadata tool with an output schema, the description covers the essential context: purpose, input file type, and output format. It lacks explicit comparison to sibling tools, but given the tool's simplicity, it is sufficiently 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?
The schema has one parameter with zero description coverage, so the description must compensate. It does by stating the tool reads from an 'SPSS .sav file', clarifying that file_path refers to that file. However, it does not specify format or access constraints, so it is not a full 5.
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 ('Read') and resource ('variable names, types, labels, and value labels from an SPSS .sav file'), and notes the output is a 'detailed Markdown report'. This distinguishes it from data-reading and file-summary sibling tools, making its purpose obvious.
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 (need metadata structure from .sav) and provides context like 'Does not require SPSS to be installed', but it does not explicitly name alternative tools or state when not to use it. With many sibling metadata-related tools, this lack of explicit guidance leaves some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions 'registry-backed' and 'available for structured execution,' giving some context about data source and output nature. However, it does not disclose potential side effects, authentication requirements, or filtering criteria, leaving some gaps for a discovery 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 long, front-loaded with the primary action ('List registry-backed SPSS methods'), and every phrase adds value. It avoids unnecessary detail and is easily scannable.
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 tool's simplicity (no params), an output schema is present, and the description covers the main behavioral context (registry-backed, structured execution, schemas/templates/coverage). It is sufficiently complete for a list/discovery tool, though it could mention whether the list is exhaustive or paginated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. Per baseline rules, a 4 is appropriate since there is no parameter information to add beyond what the schema already communicates.
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 function: 'List registry-backed SPSS methods available for structured execution.' It also specifies the purpose of discovering 'cold methods that have schemas, templates, and coverage assertions,' which distinguishes it from sibling tools like spss_get_method_schema and spss_get_method_support.
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 explicit usage guidance: 'Use this to discover cold methods...' This tells the agent when to call this tool. It does not explicitly exclude alternatives, but the context of sibling tools (e.g., get_method_schema for details) implies differentiation clearly enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It explains the three-step process, the regression-based paths, and the Sobel test, and explicitly states a limitation (no PROCESS macro). This adds useful context beyond the name, though it does not mention assumptions (e.g., normality, variable types) or whether the tool modifies files.
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 core purpose, and contains no redundant information. Every phrase adds value, from the specific method to the output details and the PROCESS macro exclusion.
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 tool's statistical complexity and the absence of annotations, the description covers the main workflow, outputs, and a key limitation. The output schema presumably handles return-value documentation. It omits assumptions and data prerequisites, but the description is still reasonably complete for an agent to understand the tool's role and select it appropriately.
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 input schema has no descriptions (0% coverage), so the description must compensate. It maps x, mediator, y to the X, M, Y roles in the mediation model, which adds meaning. However, file_path is not explained, and there is no mention of variable types, ordering, or data preparation requirements. The param names are self-explanatory, but the description only partially bridges 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 specific verb ('Run') and clearly identifies the resource ('Baron & Kenny three-step mediation analysis (X -> M -> Y)'). It lists exact outputs (paths a/b/c/c', indirect effect a*b, Sobel test) and distinguishes itself from PROCESS macro, differentiating it from sibling tools like spss_regression and spss_moderation.
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 implies when to use this tool by specifying the mediation method and output. It also notes a key exclusion ('Does not bundle the PROCESS macro'), guiding users away from expecting that functionality. However, it does not explicitly state 'use this instead of regression when examining mediation' or mention any alternative tool for other mediation approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 for behavioral disclosure. It adds value by explaining that variables are mean-centred and that the interaction term is reported. However, it does not mention potential side effects like data modification or requirements like variable types/numeric ranges, so it is not fully transparent.
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 that delivers the essential information without any wasted words. It is concise yet precise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered by that. The description sufficiently describes the statistical method and purpose for an agent to select the tool correctly, but it could include assumptions like continuous moderator not being explicitly stated.
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 clarifies the roles of x, moderator, and y through the model formula, but does not explain file_path or specify the expected input types (e.g., variable names vs. column indices). This is partial compensation.
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'), names the resource ('mean-centred moderation regression'), and specifies the exact model formula (Y ~ X + W + X*W). It clearly states the output (interaction term) and differentiates from sibling tools like spss_regression and spss_mediation.
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 clearly indicates the tool is for testing moderation effects, which implies when to use it. However, it does not explicitly mention when not to use it or name alternative tools (e.g., if only main effects are needed, use spss_regression).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states the output format (Markdown table), the optional filters, and the notable operational fact that SPSS is not required. It does not mention behavior around value labels or error handling, but the read-only nature is clear from 'Read rows.' Overall, it provides more context than many tools.
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 and every phrase earns its place. It leads with the core action and result, then adds optional capabilities and a key operational condition. There is no filler or repetition.
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 relatively simple, an output schema exists, and the description covers the primary input (file path), optional filters, row limit, and output format. The main gap is the lack of explanation for the 'apply_value_labels' parameter, which could significantly affect the output. Given the overall simplicity and existing schema, the description is sufficiently complete, but not exhaustive.
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 offers no parameter descriptions (0% coverage), so the description must compensate. It does explain the meaning of two parameters: 'filter to specific variables' for the 'variables' parameter, and 'limit row count' for 'max_rows'. However, it completely omits 'apply_value_labels' and offers nothing beyond the name for 'file_path'. Thus, it adds partial value but doesn't fully compensate for the missing 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 uses a specific verb phrase 'Read rows of data' and clearly identifies the resource (an SPSS .sav file) and the output format (Markdown table). It also mentions optional variable filtering and row limiting, which distinguishes it from sibling tools like spss_read_metadata or spss_list_variables that focus on metadata rather than data rows.
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 clearly implies when to use this tool—when you need actual data values from a .sav file in a readable table format, and not just metadata. It also provides a practical condition: 'Does not require SPSS to be installed.' However, it does not explicitly name alternative tools or state when NOT to use it, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses that the tool does not execute syntax (safety behavior) and requires IBM SPSS Statistics to be installed (prerequisite). It also honestly limits itself to 'basic syntax errors.' It does not describe output behavior, but 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?
The description is three concise sentences, front-loaded with the primary action. Each sentence contributes: what it does, what it doesn't do, and a prerequisite. There is no 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 simple validation tool with one string parameter and an existing output schema, the description covers the essential behaviors: non-execution, basic error checking, and dependency. Minor gap: the nature of the SPSS installation (local vs. remote) is ambiguous, but not critical.
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 input schema has one parameter 'syntax' with no description and 0% coverage, so the description must compensate. It indirectly indicates the parameter holds SPSS syntax via 'Validate SPSS syntax,' but does not add details on format, limits, or encoding. This is minimal added value over the parameter name.
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 validates SPSS syntax without executing it, using a specific verb+resource combination. It distinguishes itself from spss_run_syntax by explicitly noting 'without executing it' and scoping to 'basic syntax errors.'
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 clear context: use this tool when you want to validate syntax without executing it. The phrase 'without executing it' implies it is an alternative to execution, but it does not explicitly name alternatives like spss_run_syntax or state when not to use it. This is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the external dependency (SPSS must be installed), the action (run CROSSTABS), and optional behavioral components (chi-square, row/column percentages). This is adequate for a non-destructive statistical tool, though it does not discuss side effects or detailed failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action and output. Every sentence adds meaningful information, and there is no redundancy or 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 6-parameter tool with no schema descriptions, the description covers the core purpose, variable roles, optional analyses, and a critical prerequisite. The output schema likely covers return structure. It omits explicit guidance on file_path format or variable-level restrictions, but overall it is complete enough for effective tool selection and invocation.
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 0% description coverage, so the description must compensate. It clarifies that row_variable and column_variable are categorical and that the three boolean flags correspond to chi-square and row/column percentages. It does not explain file_path, but the parameter name is 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 uses a specific verb and resource ('Run SPSS CROSSTABS') and clearly defines the output as a 'contingency table between two categorical variables.' This distinguishes it from sibling statistical tools like correlations or t-tests, which target different variable types and analyses.
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 clearly states the intended use case: analyzing the relationship between two categorical variables. It does not explicitly name alternative tools or exclusion criteria, but the categorical-variable framing provides sufficient usage context among the statistical sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses the scope of the check (capabilities, path, versions, configuration), implying a read-only operation. It could explicitly state it has no side effects, but for a status tool this is minimally risky.
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 sentence that front-loads the main action ('Check the SPSS MCP server status') before elaborating on details. Every word adds value.
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?
Given the simplicity (no params, output schema exists), the description fully covers what the agent needs: what the tool does, what it reveals, and when to call it. The output schema handles return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this (empty properties). Baseline 4 applies since no parameters need explanation.
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 checks SPSS MCP server status, specifying exactly what is checked (capabilities, SPSS path, library versions, configuration). This is distinct from all sibling tools, which are operational actions.
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 explicitly says 'Call this first to understand what tools are available,' providing clear when-to-use guidance. It doesn't mention when-not-to-use or alternatives, but as a status check it is naturally the first step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![spss-studio-mcp MCP server](https://glama.ai/mcp/servers/flupke91/spss-studio-mcp/badges/card.svg)](https://glama.ai/mcp/servers/flupke91/spss-studio-mcp)

Score Badge

Copy to your README.md:

[![spss-studio-mcp MCP server](https://glama.ai/mcp/servers/flupke91/spss-studio-mcp/badges/score.svg)](https://glama.ai/mcp/servers/flupke91/spss-studio-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/flupke91/spss-studio-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server