r-stats-mcp

Overview Schema Source Related Servers Score Discussions Admin

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct targets, and the survey_* prefix cleanly separates complex-survey variants from their base counterparts. However, check_assumptions in model mode substantially overlaps with model_diagnostics, and data_inspect versus describe could be confused at first glance.
Naming Consistency4/5
The suite uses recognizable prefixes such as data_*, test_*, model_*, and survey_*, which gives it a strong internal structure. The pattern is not universal: standalone names like describe, correlation, regression, sem, and survival_analysis break the convention, and session_clear/data_list do not follow the r_* session prefix.
Tool Count2/5
33 tools exceeds the 25+ threshold and will burden an agent with a very large action space to search. Each analysis family is individually justified, but the overall count is high relative to what most statistical workflows require.
Completeness5/5
The tool surface covers the full statistical workflow: data loading, inspection, transformation, export, descriptive statistics, assumption checks, common and advanced tests, regression, model diagnostics/comparison/prediction, survey analysis, latent variable modeling, mediation, moderation, survival, time series, and plotting. There are no obvious dead ends for standard R-based statistical analyses.
Average 4.2/5 across 29 of 33 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It states the core side effect of writing to disk but does not mention whether an existing file is overwritten, whether parent directories need to exist, what happens on failure, or what the return value is. For a write operation, overwrite behavior is 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 a single, front-loaded sentence with no wasted words. It states the action, the source, the destination, and the supported formats efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool with a fully documented schema, the description is mostly adequate. Still, the missing overwrite/error/return behavior leaves some operational ambiguity that an agent would need to handle when invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents 'data', 'path', and 'format' adequately. The description adds a little context by enumerating CSV, TSV, Excel, and RDS, but this does not materially go beyond the schema's own format list and override semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Write'), the resource ('dataset from the session'), and the output destination ('to disk') with concrete formats. It is clearly distinct from read-oriented siblings like data_load or data_list, but it does not explicitly name or contrast a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys that this tool is for persisting an in-session dataset to disk, so the usage context is implied. However, it does not state when not to use it, mention prerequisites (e.g., the dataset must already exist in the session), or point to alternatives like data_load for reading data in.
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 behavioral disclosure. It transparently lists the computed diagnostics and plots, but omits whether the tool mutates the model, what model types it supports, or whether results are printed or returned. These gaps matter for an analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that leads with the core purpose and then enumerates the report components. Every listed item is specific and informative, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately conveys the tool's scope, but without an output schema or annotations, it should clarify supported model types and the form of the returned report. The gap is significant given the complexity of the diagnostics and the absence of other structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving a baseline of 3. The description adds meaning by clarifying that 'influence_n' refers to cases identified by Cook's distance and leverage, and that 'plots' relates to the four standard diagnostic plots. This goes beyond the terse schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool produces a 'full diagnostic report for a fitted model' and enumerates the specific diagnostics included. It distinguishes itself by naming concrete tests and plots, though it does not explicitly contrast with sibling tools like check_assumptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as check_assumptions or model_compare. The context is implied to be post-fit diagnostics, but the description never states a preferred scenario or exclusion criteria.
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 does not explain side effects, whether the data is returned or assigned to the session, error behavior, or what happens if the package is not installed. The examples hint at usage but do not disclose the actual operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The core action is front-loaded, and the example list is compact and informative. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and typical use cases, and the schema documents all parameters. However, with no annotations and no output schema, it leaves out what happens when data loads (return value vs. session assignment) and how package resolution works, so it is only minimally complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds real examples for dataset/package combinations, which supports parameter understanding, but it does not explain the optional 'name' parameter beyond what the schema already states.
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-resource pairing ('Load a dataset that ships with R or with an installed package') and provides concrete examples like mtcars, iris, and sleepstudy from lme4. This makes the tool's purpose immediately identifiable and distinct from generic data-loading tools.
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 states clear usage context: 'Useful for demonstrating a method or checking that an analysis works before running it on real data.' It does not explicitly mention alternatives or when not to use it, but the intended scenario is clear.
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 does disclose the key output behavior: frequency tables normally, and counts plus row percentages when `by` is given. However, it does not mention how missing values, sorting, or weighted counts affect the output, leaving some behavioral gaps beyond what the schema already states.
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 wasted words. It front-loads the core functionality first and adds the follow-up guidance second, making it easy for an agent to parse and act on quickly.
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 7-parameter schema, no output schema, and no annotations, the description provides the essential behavioral context for the tool's main purpose and output structure. It names the output format (frequency tables and row-percentage cross-tabulations) and connects to the relevant follow-up test, though it leaves minor details about edge cases to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even without additional detail in the tool description. The description does add small semantic value by explaining that `by` changes the output to a cross-tabulation with row percentages, but it does not elaborate on the other parameters beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function as generating frequency tables for categorical variables and cross-tabulations with counts and row percentages when `by` is supplied. It names the resource and scope, and implicitly positions itself relative to `test_categorical`, though it does not explicitly contrast with other 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description communicates the primary use case and gives a clear next-step recommendation ('Use `test_categorical` afterwards to test the association'), which is actionable context. It does not explicitly state when not to use this tool or name alternative tabulation tools, but the context is clear enough for a typical agent.
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 burden of behavioral disclosure, and it does so well: it reveals the return structure (full matrix plus per-pair tests), the statistics computed, and the partial-correlation behavior of the `control` parameter. It does not mention missing-data handling or plot outputs, but the essential computational behavior is clearly 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 two dense sentences: the first front-loads the primary output, and the second covers methods, adjustment, and the non-obvious `control` behavior. Every clause contributes unique information with 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?
For a 9-parameter statistical tool with no output schema, the description covers the main result structure, supported methods, and the partial-correlation mechanism, while the schema documents every parameter. It does not address edge cases like missing values or how `plots` and `correlate_with` alter the output, but the core calling context 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?
Schema description coverage is 100%, so the baseline is 3. The description adds genuine value beyond the schema by explaining that `control` residualises variables out of every pair to produce partial correlations, and by clarifying the output shape. This is more than the schema's bare 'Variables to partial out' text provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Correlations between numeric variables' and immediately lists the outputs (full matrix plus per-pair tests with n, r, p, confidence intervals, magnitude label), so the tool's core function is clear. It does not explicitly distinguish itself from siblings like survey_correlation or regression, but the scope and statistical detail are specific enough to be unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever pairwise correlations among numeric variables are wanted, with support for Pearson, Spearman, Kendall, and partial correlations. It does not provide explicit when-to-use versus when-not-to-use guidance, nor does it point to alternatives such as survey_correlation for survey-weighted analyses.
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. It transparently lists what statistics are returned and how categorical columns are summarized, but it does not state side effects, missing-value handling, output shape, or behavior across groups. It is informative but leaves some behavioral uncertainties.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose, then enumerates the statistics in one dense sentence. The categorical sentence adds necessary behavior without fluff. It is slightly list-heavy but earns its space.
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?
There is no output schema, so the description reasonably carries the burden of explaining return values: it lists the statistics and categorical summary behavior. It is adequate for a 7-parameter analysis tool, though the exact output structure and grouped result layout are left unspecified.
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 already documents all parameters well, so the baseline is 3. The description adds value by clarifying that group_by accepts one or more grouping variables and that categorical columns yield a level count and modal category, which goes beyond the schema's generic parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear resource and outcome: descriptive statistics for the session dataset, with a detailed list of computed measures and categorical fallback behavior. It differentiates from sibling tools like frequency_table and data_inspect by showing it returns aggregate summaries, not raw inspection or frequency tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it—when summary statistics are needed—and adds context via grouping by variables. However, it does not explicitly say when not to use it or mention alternatives such as frequency_table for categorical distributions or data_inspect for data overview.
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 carry behavioral burden. It discloses the tests performed (normal approximation and exact binomial for one sample, group comparison for multiple) and input modes. However, it does not disclose the output shape, the specific multi-group test used, or handling of continuity/confidence intervals beyond what the schema already provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and every clause adds a distinct piece of information: one-sample mode, raw-data mode, and multi-sample mode. No filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description handles the main usage modes and input styles, and the schema covers all parameter details. However, with no output schema or annotations, the return value and the exact multi-group statistical method remain underspecified, leaving some residual uncertainty for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds useful framing for x/data/successes/n and group by tying them to one-sample vs group-comparison modes, but it does not add significant semantics beyond the existing per-parameter 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?
States a specific verb, 'test', and resource, 'proportions', with concrete scenarios: one-sample against a hypothesized proportion (normal approximation plus exact binomial) and multi-sample group comparison. This clearly distinguishes it from sibling test tools like t-tests or ANOVA.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use one-sample vs two-or-more-sample mode ('pass group to compare') and when to give raw successes/n vs a dataset. It does not explicitly mention when not to use it relative to sibling test_categorical, but the intra-tool usage conditions are strong.
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 must carry the behavioral burden, and it does reveal key mechanics: for `at`, 'holding everything else at its average' and using original data when neither argument is passed. It stops short of describing the output format or how conf_level/type alter results, leaving some behavior implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with code-formatted arguments, front-loaded main purpose, and no filler. Each clause earns its place by explaining a distinct mode or example.
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 six parameters, no output schema, and no annotations, so the description must cover a lot. It explains the central at/newdata distinction thoroughly, but it never states what the result looks like (e.g., a table with predictions and confidence intervals) or how type/conf_level affect the output. This leaves an agent guessing about return shape.
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 input schema already documents every parameter, so the baseline is 3. The description adds valuable meaning by explaining what `at` computes (estimated marginal means with other predictors at their average) and contrasting it with `newdata` and the default fitted-value behavior. This goes beyond the schema's terse field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Predictions from a fitted model', which clearly states the tool's verb and resource. It goes on to explain three distinct prediction modes (at, newdata, neither), making its scope evident. However, it never references sibling tools like model_diagnostics or model_compare, so it doesn't explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit rules for choosing among the three modes: use `at` for marginal means, `newdata` for specific new cases, and neither for fitted values. It even flags `at` as 'the usual way to describe what a model implies.' However, it does not discuss when to prefer this tool over a sibling tool such as model_compare or 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 provided, the description carries the full burden of behavioral disclosure. It plainly frames the action as 'Report' and enumerates exactly what information is covered, making the read-only nature reasonably clear. It does not mention behavior if R is unavailable, but that is a minor gap for such a simple inspection 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 starts with the action and lists the reported items without any filler. Every word contributes to the tool's meaning.
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 zero-parameter, read-only info tool, the description is largely complete: an agent knows what information will be reported. The lack of an output schema means return-format details are absent, and 'key statistics packages' is slightly vague, but neither blocks correct selection or 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 input schema is empty with zero parameters, so there are no parameter semantics for the description to add. The 0-parameter baseline of 4 applies here because the description cannot add value beyond an already-complete 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 ('Report') and names the exact resource ('R version, platform, working directory and which key statistics packages are available'). This clearly distinguishes it from siblings like r_install_packages or data_list, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as r_run or session_clear, nor any mention of when not to use it. The only implied use case is checking session info, but that is left to the agent to infer.
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 present, so the description carries the full burden of behavioral disclosure. It transparently states that the model is automatically selected between ARIMA and ETS, enumerates the diagnostics performed (ADF, KPSS, STL, Ljung-Box), and notes that plots are generated. It does not mention that save_as can create a session object, but that is documented in the input schema, so the description adds meaningful behavioral context beyond the structured data.
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 two sentences and front-loads the main behavior before the frequency instruction. The first sentence is a long list, but every listed item is meaningful, and the second sentence provides an actionable parameter-setting rule that is worth its place. There is no fluff or repetition of schema content.
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 complex 11-parameter tool with no output schema, so the description must communicate what the agent will receive. It does so by itemizing the stationarity tests, decomposition, selected model, in-sample accuracy, residual test, forecast intervals, and plots. It could additionally note that plots can be suppressed or that save_as persists a ts object, but those are already covered by parameter descriptions and the main call is otherwise fully specified.
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?
Since every parameter already has a schema description, the baseline is 3. The tool description adds value by translating the frequency parameter into concrete real-world examples: 12 for monthly, 4 for quarterly, and 7 for daily data with a weekly cycle. It does not add prose guidance for method or h, but those are already well described in 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 opens with a clear domain and operation, 'Time series analysis and forecasting,' then enumerates a specific set of statistical outputs and plot types. This makes the tool's purpose unambiguous and separates it from general-purpose siblings like describe, plot, or data_inspect. It lacks an explicit action verb like 'performs' and does not name a sibling alternative, but the output inventory is specific enough to identify 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 intended context is clearly time-series data, and the closing sentence provides concrete guidance about setting the frequency parameter for monthly, quarterly, and daily-weekly data. The description does not explicitly state when to avoid this tool or which sibling to use instead, but none of the siblings offer forecasting or stationarity testing, so the absence of exclusions is a minor gap.
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 of behavioral disclosure. It enumerates the exact tests and plots produced (Shapiro-Wilk, Levene, Q-Q plots, VIF, etc.) and clearly separates raw-data vs fitted-model behavior. It does not explicitly state that the tool is read-only or what the return structure looks like, but the disclosed behavior is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 organized by semicolons to separate raw-data and model contexts. Every clause carries information; there is no filler or repetition of parameter names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 optional parameters, no annotations, and no output schema, the description does a strong job covering both operation modes, the relevant statistical checks, and the role of `plots`. It lacks a brief note on the return value/result object, but this is not critical for selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the mode-switching relationship between `model` and `variables`, and by grouping checks by data vs model. This is meaningful added value, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('assumptions behind parametric tests'), and clearly distinguishes two modes: raw data and fitted model. It does not explicitly differentiate from the sibling tool 'model_diagnostics', which could overlap with the fitted-model checks, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 each mode ('On raw data' vs 'On a fitted model') and even instructs to pass `model` instead of `variables`. It does not, however, mention when not to use this tool or name alternative sibling tools, so it lacks explicit 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, the description carries the behavioral burden. It is transparent about what is returned and about the tool's role in guiding analysis. It doesn't explicitly state the operation is read-only, but 'Inspect' and the output list strongly imply no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences front-load the output inventory and then provide actionable guidance. No filler or redundancy; every clause earns its place.
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?
The tool is simple, the schema fully documents the parameters, and the description covers the return surface (dimensions, types, missing/distinct counts, examples, first rows) in the absence of an output schema. Nothing an agent needs to decide whether to call it is missing.
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?
All three parameters already have clear descriptions in the schema (data name, row count with bounds, optional variable restriction), so the description doesn't need to add parameter detail. It doesn't provide any extra semantics beyond what the schema already states, matching the 100% coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource ('Inspect a dataset') and enumerates specific outputs (dimensions, per-column type, missing counts, distinct counts, example values, first rows). It doesn't explicitly contrast itself with a sibling like describe, but the emphasis on column types and factors gives it a distinct identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit 'when' directive: 'Run this before choosing an analysis,' and explains why (numeric vs factor columns determine whether a test will work). It doesn't name alternatives or say 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the modeling approach (mean-centred predictors), the reported statistics (R-squared change, simple slopes), and the plot output. But it omits side effects such as saving a model to the session (save_as) and does not mention assumptions, missing-data handling, or whether the original data is modified. This leaves some behavioral aspects implicit.
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 two sentences with no filler. The first sentence crisply states the purpose as a question, and the second packs the details into a compact list. The second sentence is dense but not overly long; it could be slightly better structured as a list, but it remains concise and front-loaded.
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 an output schema, the description adequately explains the core outputs: R-squared change, simple slopes, and an interaction plot. It does not fully describe the output format or potential error conditions, but for invoking the tool with the required parameters, the provided context is sufficient.
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 provides 100% parameter coverage, so the baseline is 3. The description adds meaningful semantics beyond the schema: it explains that predictors are mean-centred (relating to 'center'), simple slopes are reported at -1 SD/mean/+1 SD or by group (relating to 'simple_slopes'), and an interaction plot is produced (relating to 'plots'). This clarifies how parameters shape the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the precise research question 'does the effect of X on Y depend on W?' and then enumerates the concrete operations: fitting an interaction model, reporting R-squared change, computing simple slopes, and producing an interaction plot. This clearly identifies the tool as moderation analysis and distinguishes it from sibling tools like regression and 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 frames when to use the tool: when you want to know whether an effect depends on a moderator. It provides clear context for selecting this tool over a plain regression or mediation. However, it does not explicitly state when not to use it or name alternative tools for comparison.
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 transparency burden. It clearly signals a read-only listing operation, scopes it to the current R session, and states that dimensions are included. It does not describe the exact output format, but this is adequate for a simple listing 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?
A single, focused sentence that front-loads the action and resource. Every word adds value, and there is no redundant or vague content.
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 zero-parameter tool with no output schema, the description covers the core scope and output content. It could be slightly more explicit about the return format, but nothing essential is missing for correct 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 tool has zero parameters, so the description cannot add parameter-level meaning. With no parameters, the baseline of 4 applies and nothing further is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), names the resource ('datasets and other objects currently in the R session'), and adds detail ('with their dimensions'). This clearly distinguishes it from sibling tools like data_load, data_inspect, and r_session_info.
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?
There is no explicit when-to-use guidance or mention of alternatives. However, the phrase 'currently in the R session' implies it is for inspecting loaded objects in the workspace, so usage is inferable but not fully spelled out.
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 behavioral burden and does substantial work: it lists the statistical outputs and discloses that omitting n_factors uses the parallel-analysis suggestion. It does not cover data requirements, missing-data handling, or what saving a solution implies, but the disclosed behavior is already 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?
Three sentences each serve a distinct purpose: naming the analysis type, listing the output bundle, and clarifying the key n_factors default behavior. No filler or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 10-parameter tool with no output schema, the description is quite complete: it covers the analysis family, major results, and the critical default-selection behavior. Minor gaps remain around data preparation, side effects of save_as, and the exact result object structure, but the essentials for correct invocation are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds value beyond parameter names by explaining that leaving n_factors empty invokes the parallel-analysis suggestion and by framing the type parameter as EFA vs PCA.
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 exploratory factor analysis or principal component analysis, and enumerates a specific set of outputs (KMO, Bartlett's test, loading matrix, communalities, variance, scree plot, cross-loading items). This distinguishes it from sibling statistics tools, none of which offer EFA/PCA.
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 (dimension reduction/construct exploration) but provides no explicit when-to-use or when-not-to-use guidance and names no alternatives. The only usage directive is parameter-level advice about leaving n_factors empty, not tool selection 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 disclosure burden and does substantial work: it says the tool builds the path model, fits it, and reports all relevant paths with bootstrap confidence intervals. It does not mention optional session side effects such as save_as or the exact output structure, but core behavior is clearly 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?
Two well-structured sentences lead with the mediation question, then specify model fitting, reported paths, bootstrap intervals, and supported extensions. 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?
For a moderately complex statistical tool with no output schema, the description covers the essential inputs and expected results, including multiple mediators and covariates. It leaves out minor details like interval method or default bootstraps, but those defaults are already in the schema.
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 100%, so the schema already documents all 9 parameters; the description adds useful context by naming X, M, Y, multiple mediators, and covariates, but it does not explain conf_level, digits, or save_as in prose. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific analytical verb (fits a path model and reports mediation paths) and a concrete resource: the indirect effect of X on Y through M. The description distinguishes this from generic regression or SEM by naming the precise a, b, c', and indirect paths with bootstrap confidence intervals.
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 opening question 'does X affect Y through M?' makes the intended use clear, and the mention of multiple mediators and covariates signals when broader mediation models are appropriate. It does not explicitly warn against alternatives like sem or regression, but the context is strong enough to guide tool selection.
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 for behavioral disclosure. It does disclose that the tool returns an image and explains special behavior for scatter (smooth) and bar (summary means vs counts) plots. However, it does not describe what happens on error, how the image is delivered or rendered, whether any session state is changed, or limitations around data requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the main purpose and supported types. The second paragraph efficiently groups related parameters and their roles, and the final sentence routes complex needs to r_run. Every sentence earns its place, and there is no redundant repetition of schema content.
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 has 23 parameters and no output schema, the description is reasonably complete: it covers the key semantic roles and tells the agent when to defer to r_run. All parameters are already documented in the schema with 100% coverage, so the description does not need to repeat them. The main gap is the absence of detail on the returned image format or in-session behavior, which would be helpful but is not critical for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds meaningful semantic context beyond the schema. It clarifies that x is the grouping variable for box/violin plots, y is the outcome, group adds colour, and facet splits panels. It also explains that giving y to a bar plot produces group means rather than counts, which is not obvious from the parameter descriptions 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 opens with a specific verb and resource: 'Draw a publication-style ggplot2 chart and return it as an image.' It lists the supported chart types, making the tool's scope immediately clear. It also distinguishes itself from the sibling r_run by designating plot for standard charts and r_run for more specific custom ggplot2 code.
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: for standard chart types like histogram, scatter, and bar, and for common variations like smooth lines or error bars. It explicitly names the alternative r_run for 'anything more specific', which is a strong usage boundary. However, it does not enumerate all the situations where a different sibling (e.g., correlation, regression) might be more appropriate for the underlying analysis.
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 disclosure burden. It states the source (CRAN), the target (user's R library), and a timing consequence ('can take several minutes for packages that compile'). It does not detail dependency installation or the default skip-if-present behavior, but the core mutation and its cost are clearly 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 three short sentences with no wasted words: action and target first, usage trigger second, and an important duration caveat last. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter installer, the description covers when to use it, what it installs, where it installs, and that it may be slow. The schema fully defines the arguments. Minor gaps such as dependency handling and failure behavior do not make the tool difficult to invoke 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 100%, with both 'packages' and 'force' already documented in the schema, including the default for force and an example list format. The description adds no parameter-specific meaning beyond what the schema provides, so it remains at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Install R packages from CRAN into the user's R library.' It clearly specifies what the tool does and where packages go, and it is readily distinguishable from the sibling data and analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger: 'Use when a tool reports that a package is missing.' It does not mention exclusions or alternatives, but no sibling tool provides package installation, so the guidance is sufficient for the context.
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 behavioral disclosure burden. It clearly reveals the persistent-session side effect ('Objects created here persist and are visible to the other tools'), the output format, and offers a concrete persistence example. It does not explicitly mention destructive side effects like overwriting objects, but the word 'arbitrary' and the persistence warning convey the powerful, stateful nature of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no wasted words. The first sentence front-loads the core action and return value, the second provides use cases and positions the tool relative to siblings, and the third covers the critical persistence behavior. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essentials for a general-purpose code runner: what it executes, what it returns, and the stateful persistence behavior. There is no output schema and no annotations, so explaining return values and side effects is essential and the description does both. It does not describe error behavior or what happens when code fails, but this is a minor gap given the tool's open-ended nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description adds a useful usage example for the `code` parameter via `summary(anova_fit1)` and clarifies object persistence, but it does not add meaning beyond the schema for `timeout`, `plot_width`, or `plot_height`. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Run arbitrary R code in the persistent session' and explicitly names the return values ('console output plus any plots'). It further differentiates itself from the structured sibling tools by calling itself the 'escape hatch' for custom models, package-specific functions, and data wrangling, making it immediately identifiable.
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 when-to-use guidance: 'This is the escape hatch for anything the structured tools do not cover' followed by concrete example categories. It implies that structured tools should be preferred when they do cover the task, though it does not name specific sibling alternatives or describe specific exclusion scenarios.
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 behavioral burden. It discloses the side effect (dataset available session-wide), the return value (dimensions and per-column summary), and format detection from extension. It does not mention overwrite behavior if a name is reused, but the disclosed behavior is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action, followed by formats, return behavior, and reuse. Every sentence earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a load tool with no output schema, the description explains what the call returns, how formats are inferred, and how to reference the loaded dataset later. The optional parameters are well covered by the schema, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds useful high-level context about format detection and naming, but does not go beyond what the parameter descriptions already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Load a data file into the session under a name.' It enumerates supported formats and the session-level effect, making it easy to distinguish from sibling tools like data_list, data_inspect, or data_export.
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: it loads external file formats into the session and makes them available to all other tools as data="<name>". It does not explicitly name alternatives or exclusions, 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?
With no annotations provided, the description carries the full behavioral burden, and it does disclose a key side effect: 'The fit is saved in the session for model_diagnostics, model_compare and model_predict.' It does not detail behavior around error handling or unsupported combinations, but for a statistical fitter the essential stateful behavior is revealed.
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 long but every sentence earns its place for a 15-parameter tool. The core purpose is front-loaded, then the type catalog, then specification methods, then the session-save side effect. The only mild redundancy is explaining type meanings that partly overlap with the schema's 'type' description, but the added detail justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema and no annotations, the description covers the type system, both specification alternatives, the save behavior, and parameter syntax examples. It doesn't describe the return format in detail beyond 'coefficients with confidence intervals, model fit and diagnostics,' but combined with the 100%-covered schema this is adequate for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description genuinely adds meaning beyond the schema: it explains each type value where the schema only lists names, gives the formula syntax for GAM terms (s(x)), demonstrates the random-effects syntax, and clarifies formula vs dv+predictors as mutually alternative paths. This goes beyond the schema's per-field 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 opens with a specific verb-resource statement: 'Fit a regression model and report coefficients with confidence intervals, model fit and diagnostics.' This clearly differentiates it from siblings like correlation, check_assumptions, and test_ttest, and the enumerated type list further scopes what counts as a 'regression model'.
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 strong within-tool guidance: each supported type is explained (e.g., 'ordinal: ordered outcome... order the levels with data_transform first', 'mixed: give the random part in random'), and it clarifies the two specification paths (formula vs dv+predictors). However, it never routes the agent away from alternative modeling siblings such as survey_regression, mediation, or survival_analysis, so situational exclusion guidance is missing.
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 behavioral burden. It discloses concrete outputs for each model type: median survival, survival curve, log-rank test, hazard ratios, concordance, and the Schoenfeld test. It also states the required event coding, which is a critical operational detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded, with the core purpose stated first and model-specific details following. It is appropriately sized for a complex statistical tool, though it slightly repeats the event-coding requirement already present in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters and no output schema or annotations, the description covers the key decision points and expected results well. It could be more explicit about the `auto` type and `time2` usage, but the schema already documents those, and the description provides enough operational context for correct 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?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining what `type='km'` and `type='cox'` actually produce, and how `group` and `times_of_interest` change the analysis. This goes beyond simple field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific phrase, 'Survival / time-to-event analysis,' and immediately distinguishes the tool's two primary modes: Kaplan-Meier and Cox proportional hazards. It clearly states the resource and the analytical outputs, making it distinct from regression and other statistical siblings.
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 internal guidance on when to use `type='km'` vs `type='cox'`, when a log-rank test is included, and when `times_of_interest` is relevant. It does not explicitly discuss alternatives or exclusions among sibling tools, but the time-to-event context is clear 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description is the sole source of behavioral disclosure. It reveals that the likelihood-ratio or F test is only applied when models are nested, a conditional behavior, and implicitly indicates a read-only comparison rather than model modification. It does not describe output format or edge cases, but covers the key behavioral caveat.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first states the core functionality and the second states the prerequisite. Purpose is front-loaded with no filler or schema-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?
For a tool with no output schema and no annotations, the description covers the core action, the metrics, the nested-model condition, and how to prepare inputs. It does not spell out the return value, but the purpose sentence implies the output, and the schema covers parameter details. This is complete enough for correct 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 input schema already documents all three parameters at 100% coverage, setting a baseline of 3. The description adds meaningful context by explaining that the models parameter refers to save_as names from prior regression/test_anova calls, which clarifies what value should be supplied beyond the schema's 'Names of fitted models in the session'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'Compare' and a precise resource 'two or more fitted models', enumerating the metrics (AIC, BIC, log-likelihood, delta AIC) and the conditional test. This distinguishes it clearly from sibling model_diagnostics, which is for single-model inspection, and from regression/test_anova which fit models.
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 an explicit prerequisite: fit models first with regression or test_anova and assign save_as names. This tells an agent when it is ready to call the tool. It does not name alternatives or when-not-to-use cases, so it falls short of a full 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?
With no annotations provided, the description carries the behavioral burden, and it does well by stating what it computes and that it 'flags items that weaken the scale.' This gives an agent a realistic picture of the output behavior. It does not discuss side effects or missing-data handling, but the described behavior is read-only statistical computation and is not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence is front-loaded with the core purpose and full output list, and the second adds essential reverse-scoring guidance. Every clause contributes useful 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?
For a statistical tool with six parameters and no output schema, the description covers the important operational details: what it computes, what statistics are returned, and how to handle reverse-worded items. It is missing explicit preconditions such as requiring at least two numeric items or how missing values are handled, but the core calling context is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds meaningful semantics by explaining that `reverse` is for reverse-worded items and must be paired with `scale_max`, which is not obvious from the schema alone. This goes beyond the baseline for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific analysis ('internal-consistency reliability for a set of scale items') and gives a concrete list of outputs: Cronbach's alpha with CI, McDonald's omega, average inter-item correlation, and per-item statistics. This clearly distinguishes it from sibling tools like correlation, factor_analysis, or test_ttest, even without naming them explicitly.
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 establishes a clear context: use when you have a set of scale items and need internal-consistency reliability. It also provides direct guidance on how to handle reverse-worded items ('Use reverse (with scale_max)'), which is an actionable usage rule. It does not explicitly mention when not to use the tool or point to alternatives, 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?
With no annotations, the description carries the full burden and does well: it discloses automatic Fisher's exact test selection when expected counts are too small, lists the computed statistics, and notes default uniform probabilities. It stops short of explaining plot behavior or data requirements, but it is substantially 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 compact, front-loaded, and every sentence earns its place by explaining a distinct usage mode or automatic behavior. There is no repetition of schema content and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no annotations, and no output schema, the description covers the main decision paths and expected outputs. Minor gaps remain around plot output and data preparation, but the schema handles parameter formats and the description handles behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning by linking x and y to specific test variants and expected_probs to goodness-of-fit. This cross-parameter context goes beyond the individual property 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 opens with a specific verb and resource ('Tests for categorical data') and then enumerates distinct analyses: chi-square independence, goodness-of-fit, and McNemar. This clearly differentiates it from sibling statistical tools like test_ttest or correlation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear conditions: use x and y together for independence tests, x alone for goodness-of-fit, and test='mcnemar' for paired binary data. It does not explicitly name sibling tools or state when not to use it, but the categorical-data framing and conditional branches provide solid usage context.
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, and it discloses two key behaviors: operations run in a fixed order, and results write back to the same name unless save_as is given. It stops short of describing all side effects (e.g., return visibility), but the most operationally important traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact paragraphs with no filler: the first states purpose, pipeline order, and overwrite behavior; the second gives targeted usage tips for the most common downstream need. Every sentence earns its place.
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 16 parameters and no output schema, the description plus fully documented input schema covers everything needed to invoke the tool correctly. The fixed operation order and write-back behavior resolve the most likely ambiguities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds practical meaning beyond the schema by giving a realistic to_factor example and explaining that factor_levels sets reference and ordinal order for outcomes. This extra guidance helps the agent construct correct calls.
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 'Clean and reshape a dataset', a specific verb and resource, and then enumerates the exact pipeline operations. This clearly distinguishes it from sibling analysis/test tools, so an agent knows what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context by noting that converting grouping variables to factors is the most common prerequisite for the test tools, with concrete examples. It does not explicitly state when not to use it or name alternatives, but the implied workflow is strong enough for an agent to select it appropriately.
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 behavioral transparency burden. It does so well by listing the fit statistics reported, the standardized estimates, composite reliability, and what the `modification_indices=true` flag does. It does not mention convergence failure or side effects like saving a model, but the key behavioral expectations are 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 front-loaded with the purpose, then uses a compact syntax legend, lists the output, and ends with a conditional flag explanation. Every sentence contributes useful information and none of it is redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no output schema, the description covers the most complex and essential parts: model syntax, output statistics, and modification indices. The remaining parameters are fully described in the input schema, so an agent has enough information to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description earns extra credit by decoding the lavaan syntax operators (`=~`, `~`, `~~`, `:=`) with concrete examples for the `model` parameter, which is the most semantically rich parameter. It also clarifies the behavior of `modification_indices=true` beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise statement of what the tool does: confirmatory factor analysis or structural equation modelling with lavaan. It also explains the lavaan syntax operators, making the resource and method unambiguous. This clearly separates `sem` from sibling tools like `regression` or `factor_analysis`.
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 intended use is explicitly stated: CFA/SEM models written in lavaan syntax. It gives clear context for when to use the tool, though it does not name alternative tools or list exclusion criteria. The mention of 'confirmatory' versus the sibling `factor_analysis` implies the boundary, but not explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 side effects (freeing memory), scope (session only), preservation behavior (`keep`), and a safety property (never touches the server's internal bindings). This is rich, useful behavior disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short, purposeful sentences: action, use case, parameter hint, and safety caveat. There is no wasted text and the most important behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-parameter tool with no output schema, the description covers operation, usage context, parameter semantics, and behavioral safety. Nothing essential is missing for an agent to invoke it 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 coverage is 100%, and the schema already describes `keep` as 'Names of objects to keep.' The description adds a small semantic gloss with 'hold on to named objects,' but largely restates the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Remove datasets and models from the session.' It clearly identifies session-scoped cleanup and differentiates itself from sibling data/analysis tools by scope and safety guarantee.
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?
Explicitly states when to use the tool: 'Use it when switching to an unrelated topic.' It also explains how to preserve objects with `keep`. It does not name alternatives or give when-not-to-use conditions, so it is not a full 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?
With no annotations provided, the description carries the behavioral disclosure burden. It explains how replicate weights can be supplied as explicit columns or a prefix, how JK2 replicates are constructed from jkzone/jkrep, and how `method` auto-selects. This goes well beyond a minimal definition, though it does not describe output format or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient: it front-loads the tool's purpose, then presents usage alternatives and method defaults without redundant phrasing. Every sentence contributes either to what the tool does or how to invoke it correctly.
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 complexity, 13 parameters, and absence of an output schema, the description covers the main invocation paths and critical defaults well. It could be more complete by stating the shape of the return value or what happens when both design paths are supplied, but the schema fills most remaining gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema: the list-or-prefix behavior for replicate_weights, the jkzone+jkrep pairing, the automatic method defaults tied to replicate weight counts, and the distinction between `variables` and plausible-value sets.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific operation ('Correlates each column in x against either variables or a plausible-value set') and the resource ('complex survey data'), and distinguishes it from the simpler sibling `correlation` by emphasizing replicate-weight standard errors and plausible-value pooling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: complex survey data, two mutually exclusive design specification paths, and method selection defaults (JK2 vs Fay for 60+ supplied columns). It does not explicitly name alternatives like `correlation`, but the survey-specific framing makes the intended use clear.
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 and does a solid job: it discloses the full set of reported outputs, the Student vs Welch default behavior, and the nonparametric alternative with effect size. It stops short of mentioning missing-data handling or plot side effects, but covers the core behavioral traits well.
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 well organized: first the output promise, then the three designs in compact bullets, then the nonparametric flag. Every sentence earns its place and there is no filler or repetition of schema-only details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter statistical tool with no output schema and no annotations, the description is unusually complete. It explains all three test modes, the key parameters that activate each, and the full set of returned statistics, leaving little an agent needs to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description adds real value by mapping parameter combinations to the three test designs and explaining the practical meaning of var_equal and nonparametric. This goes beyond the individual parameter descriptions in 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 opens with a precise verb and resource ('Compare means with a t-test') and immediately lists the exact statistics it will report. The three named designs (one-sample, independent groups, paired) clearly delimit the tool's scope and distinguish it from sibling tests like test_anova or test_proportion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit design-level usage guidance, showing which parameters correspond to one-sample, independent-group, and paired designs, plus when to set nonparametric=true. It does not explicitly say 'use this for two groups only and use test_anova for more', but the intended scenarios are strongly implied by the three designs.
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 full burden. It richly discloses statistical behavior: Rubin's rules, Barnard-Rubin degrees of freedom, sampling versus measurement standard-error decomposition, and default method selection (JK2 vs Fay). It does not explicitly state whether the function mutates session state or the exact return object, which is a minor gap without annotation support.
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 about 170 words in three focused paragraphs: what it does, when to use it, and how to specify the design. Every sentence carries signal, and the most important purpose and sibling contrast are front-loaded.
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 14-parameter tool with no output schema and no annotations, the description covers the hard parts: plausible-value expansion, replicate-weight alternatives, default methods, and the sampling-vs-measurement SE reporting. The main remaining gap is the lack of an explicit return contract, such as what result columns an agent should expect, since no output schema exists to supply that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 100% coverage, the description adds meaning beyond it: `pv_prefix='BSMMAT'` expands to BSMMAT01..05, `pv_pattern='PV{i}MATH'` expands to PV1MATH.., `replicate_weights` can be a prefix matching W_FSTURWT1..80, and `method` defaults differ by design. These details materially improve correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Weighted regression for complex survey data' with replicate-weight standard errors and plausible-value pooling. It explicitly contrasts with sibling `regression` ('Use this instead of regression for TIMSS/PISA-style data'), so an agent can distinguish it without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: use instead of `regression` for TIMSS/PISA-style data with plausible values, and warns never to pass a single score. It also details two mutually exclusive design-specification routes (`replicate_weights` vs `jkzone`+`jkrep`) and names the specific data formats, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and meets it: it discloses design-correct error computation, the risk of understated SEs, multi-stage plausible-value expansion, two accepted design specifications, and the fact that output separates sampling versus measurement error. It also states method defaults for JK2 and Fay, which is exactly the behavioral nuance an agent needs beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and every sentence adds relevant guidance with no filler. It is dense rather than concise, packing three distinct topics (when-to-use, plausible values, replicate-weight designs) into one paragraph, but the complexity of the tool justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter tool with no output schema and no annotations, the description covers the crucial decision points: sampling design, plausible values, replicate-weight specification, and method defaults. It still relies on the schema for obvious details like `by`, `digits`, and `fay`, but the high-risk ambiguity areas are all resolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds substantial meaning: `pv_prefix='BSMMAT'` expands to BSMMAT01..05, `pv_pattern='PV{i}MATH'` expands to PV1MATH..., `replicate_weights` accepts either lists or prefixes, and `jkzone` + `jkrep` builds JK2 replicates automatically. This is essential operational detail that the bare schema fields do not convey.
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 opening sentence names a specific verb, resource, and key differentiator: 'Means for complex survey data, with design-correct standard errors.' It also explicitly contrasts with `describe`, which lets an agent immediately know this is the survey-aware mean tool rather than a generic descriptive tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool 'instead of `describe`' for clustered or stratified samples and explains why the ordinary standard error is inadequate. It also gives concrete conditions for plausible values versus single scores and how to supply replicate weights, providing clear when-to-use and how-to-proceed guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discharges it well: it discloses effect sizes, Levene's test, post-hoc via estimated marginal means, the nonparametric/Welch alternatives, and the side effect that the fitted model is saved for model_diagnostics. It also specifies data-shape requirements, going well beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the main output features, and structured as a scannable bullet list of design recipes. No sentence is filler; the final sentence about saving the model adds necessary cross-tool context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 13-parameter tool with no output schema or annotations, the description covers all major design families, parameter combinations, the long-format requirement, and the model_diagnostics handoff. An agent has enough to configure a correct ANOVA call and route the results appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds design-level semantics by showing how dv, between, within, covariates, and id combine for each ANOVA family. It also maps nonparametric and welch booleans to concrete tests, giving the agent decision rules the schema alone does not provide.
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 the tool performs ANOVA across multiple designs ('one-way / factorial', 'ANCOVA', 'repeated measures', 'mixed'), with outputs and variants. This clearly separates it from sibling tests such as test_ttest and test_categorical, and the planned contrasts among designs make 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance for each design: 'dv plus between', 'add covariates', 'within plus id', 'both between and within', plus 'nonparametric=true' for Kruskal-Wallis/Friedman and 'welch=true' when variances differ. It also warns that repeated-measures data must be in long format, which is a direct prerequisite.
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

r-stats-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![r-stats-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Ian3738/r-stats-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Ian3738/r-stats-mcp)

Score Badge

Copy to your README.md:

[![r-stats-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Ian3738/r-stats-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Ian3738/r-stats-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/Ian3738/r-stats-mcp'

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