This server lets Claude control Altair AI Studio 2026.x (a RapidMiner-based ML/data mining desktop app on Windows) via headless batch execution and an optional HTTP bridge extension.
Diagnostics
altair_check_connection — Verify the batch script and optional HTTP bridge are reachable (run first when troubleshooting)
Data Ingestion
altair_import_data — Import/preview tabular data from a local CSV or Studio repository entry
altair_list_repository — Browse repository folders and entries (requires HTTP bridge)
altair_read_repository_entry — Read a repository dataset as CSV (requires HTTP bridge)
altair_store_csv_to_repository — Write a local CSV into the Studio repository (requires HTTP bridge)
Data Preparation
altair_clean_data — Handle missing values (average/min/max/zero/custom), remove duplicates, drop columns
altair_normalize_data — Normalize numeric columns via Z-score, min-max, proportion, or IQR scaling
altair_generate_attribute — Create derived columns using RapidMiner expressions (e.g., revenue - cost)
altair_split_data — Partition a dataset into train/test splits with a configurable ratio
Exploration
altair_descriptive_stats — Compute mean, min, max, std, median, and count for numeric columns
Machine Learning
altair_train_classifier — Train and evaluate classifiers (Decision Tree, Random Forest, Naive Bayes, k-NN, SVM, Logistic Regression, Neural Net, GBT) with k-fold cross-validation
altair_cluster_kmeans — Segment data using k-Means; returns dataset with a cluster-id column added
altair_association_rules — Mine frequent itemsets and association rules via FP-Growth (requires pre-binarized input)
altair_reduce_dimensions_pca — Reduce dimensionality with PCA up to a target explained-variance threshold
Automation
altair_run_process_file — Execute any existing .rmp process file headlessly (with optional macro overrides)
altair_run_operator_chain — Advanced escape hatch: run any arbitrary RapidMiner operator graph (DBSCAN, hierarchical clustering, database connections, Python/R scripting, LLM operators, etc.) by specifying exact class keys, parameters, and port connections
GUI Hand-off (requires HTTP bridge)
altair_get_current_process — Read the XML of the process currently open in the Studio GUI
altair_open_process_in_studio — Push a generated process XML into the Studio GUI for the user to inspect, edit, or run visually
Enables running Hugging Face models and LLMs through Altair AI Studio's operator chain.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-altair-studio load the iris dataset and train a decision tree"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP (Model Context Protocol) que permite a Claude controlar Altair AI Studio (el producto de minería de datos/ML de Altair, basado en RapidMiner) instalado en tu PC con Windows: importar/limpiar/transformar datos, entrenar y evaluar modelos de ML, clusterizar, minar reglas de asociación y ejecutar procesos guardados — todo desde una conversación con Claude.
Repositorio: https://github.com/alan4041207/mcp-altair-studio
El target de este proyecto es Altair AI Studio 2026.1.1, instalado en:
C:\Program Files\Altair\RapidMiner\AI Studio 2026.1.1Todo este proyecto se construyó y validó contra esa instalación real (ver "Qué se verificó realmente" más abajo) en lugar de basarse solo en documentación.
Altair AI Studio es una aplicación de escritorio sin una API REST propia para su GUI. Este proyecto usa los dos puntos de integración reales que el producto sí ofrece:
Ejecución headless por batch (principal, siempre disponible): el
servidor MCP genera al vuelo un archivo de proceso .rmp (XML de
RapidMiner) y lo ejecuta con el lanzador de línea de comandos incluido,
scripts\ai-studio-batch.bat -f <archivo>. Está verificado de punta a
punta (ver abajo) y no requiere instalar nada adicional.
Limitación real confirmada de este modo (no es un bug del MCP, es del
lanzador batch de Altair AI Studio 2026.1.1): cualquier resultado que
NO sea una tabla de datos (Performance Vector, Association Rules, etc.) se
pierde silenciosamente — se enruta al puerto "result N" del proceso pero
nunca se imprime. Se confirmó desensamblando
com.rapidminer.launcher.CommandLineLauncher.runProcessAndQuit: llama a
Process.run() y descarta el IOContainer devuelto sin pasarlo jamás a
ResultService.logResult(...), pese a que el propio log dice
"using stdout for logging results!". Esto afecta a altair_train_classifier
(el Performance Vector de la validación cruzada no se ve) y a cualquier uso
de Create Association Rules que no termine en una tabla. Mitigación usada
en este proyecto: para altair_association_rules/reglas de asociación,
exportar los itemsets frecuentes (que sí son tabulares, vía
item_sets_to_data) y calcular confidence/lift/conviction con las fórmulas
estándar fuera de Studio — ver examples/market-basket-optimization/ para
un caso real completo. Este modo sí funciona sin problema para todo lo que
ya es una tabla (ExampleSet/Data Table): limpieza, normalización, PCA,
clustering con add_cluster_attribute, itemsets, etc.
Bridge HTTP opcional (altair-http-bridge/): una pequeña extensión
Java que se compila e instala en la carpeta de extensiones de Studio.
Levanta un servidor HTTP en localhost dentro de la sesión de Studio
que ya está corriendo, para que Claude pueda explorar el repositorio y
leer/reemplazar el proceso que esté abierto en la GUI en ese momento. Es
opcional — todo lo demás funciona sin él. Ver altair-http-bridge/README.md.
Estado: construido, instalado y verificado funcionando — altair_check_connection
reporta el bridge como alcanzable en http://127.0.0.1:8266. Dos detalles
no documentados oficialmente que costó descubrir (y que ya están corregidos
en el código/README de la extensión, para que un rebuild futuro no los
repita):
La carpeta que Altair AI Studio 2026.x realmente escanea en el arranque
es %USERPROFILE%\.AltairRapidMiner\AI Studio\shared\extensions, no
%USERPROFILE%\.RapidMiner\extensions (confirmado desmontando
Plugin.class del jar núcleo de Studio).
El método de entrada initPlugin() debe ser estático — Studio lo
invoca por reflexión con Method.invoke(null, ...), y si es un método de
instancia falla con un NullPointerException silencioso que la GUI
muestra como "Incompatible extensions".
Related MCP server: Linear Regression MCP
En lugar de adivinar nombres de operadores de RapidMiner de memoria (es fácil
equivocarse: por ejemplo "PCA" en realidad se llama
principal_component_analysis, y los operadores más nuevos viven detrás de
prefijos de namespace como concurrency:), la construcción de este proyecto:
Inspeccionó los jars reales instalados (lib\*.jar, lib\plugins\*.jar)
para confirmar las claves de operador y sus prefijos de namespace
(concurrency:, blending:) vía el registro OperatorsXxx.xml de cada
extensión y su MANIFEST.MF.
Ejecutó el CLI real ai-studio-batch.bat contra procesos de prueba
construidos a mano, iterando sobre los mensajes de error reales hasta que
pasaron, confirmando:
La sintaxis del CLI es ai-studio-batch.bat -f <ruta-al-rmp> (no la
sintaxis clásica posicional rapidminer-batch.sh '//repo/ruta' que
describen algunos manuales antiguos).
Un pipeline completo Retrieve -> Write CSV corre y produce el resultado
correcto.
Un pipeline completo Set Role -> Cross Validation(Naive Bayes / Apply Model / Performance) corre de punta a punta, lo cual corrigió dos
suposiciones erróneas de nombres de puerto en el camino (el puerto de
entrada exterior de Cross Validation es example set, no training; el
puerto reenviado de su subproceso Training es training set).
Un Performance Vector no puede alimentar directamente a Write CSV
(incompatibilidad de tipos) — debe enrutarse al puerto de resultado
exterior del proceso, donde el runner de batch lo imprime en stdout.
Las recetas de limpiar/normalizar/dividir/PCA reutilizan las mismas convenciones clásicas de puertos de ExampleSet confirmadas arriba, pero no se volvieron a ejecutar individualmente en esta sesión — si alguna reporta un operador/puerto desconocido, ver "Si algo falla" más abajo.
Reglas de asociación y k-Means: verificados de punta a punta y dos bugs
reales corregidos (sesión de análisis Market Basket Optimization, ver
examples/market-basket-optimization/):
sourceOperator() fijaba el parámetro first_row_as_names en read_csv,
pero ese parámetro no existe en el operador real que Altair AI Studio
2026.x usa para read_csv (com.rapidminer.operator.nio.CSVTableSource) —
se verificó ejecutándolo con ese valor en false contra un CSV sin
encabezado y comprobando que igual trataba la fila 1 como nombres de
columna (perdiendo una fila de datos real). El parámetro correcto es
use_header_row. Corregido en recipes.ts; documentado inline por qué.
associationRulesRecipe() y kMeansRecipe() usaban las claves de operador
sin namespace (fp_growth, k_means). Se verificó que ambas resuelven a
la implementación central obsoleta (com.rapidminer.operator.learner .associations.fpgrowth.FPGrowth / ...clustering.clusterer.KMeans), no a
la versión moderna de la extensión Concurrency (BeltFPGrowth/BeltKMeans)
pese a que esta última declara priority=100 — la prioridad más alta NO
gana la resolución de la clave sin prefijo en esta instalación. Se confirmó
ejecutando fp_growth (sin prefijo) con input_format="items in separate columns": el operador ni reconoce ese parámetro ("unknown for operator")
y además elimina en silencio cualquier columna no binominal ("Removed N
non-binominal attributes"). Corregido a concurrency:fp_growth y
concurrency:k_means explícitamente en recipes.ts.
El operador De-Pivot (de_pivot) requiere que el parámetro
attribute_name se pase como lista ({key: nombre_columna_resultado, value: regex_de_atributos_fuente}), no como string simple — el nombre del
parámetro coincidía pero el tipo no, y usarlo como string simple produce 0
filas de salida sin ningún error. Confirmado desensamblando
Attribute2ExamplePivoting.getParameterTypes(). No se usa en las recetas
actuales de este proyecto (FP-Growth consume el formato ancho directamente,
ver el ejemplo), pero queda documentado aquí porque es la ruta clásica que
cualquier tutorial de RapidMiner asume.
No verificado: Gradient Boosted Trees (la extensión H2O está instalada
en esta máquina, pero su clave de operador no se confirmó).
También se descubrió: esta instalación no tiene alcance a un servidor de licencias de Altair activo, así que Studio recae en licenciamiento community/RapidMiner. La ejecución batch de los operadores principales funcionó bien en ese estado; algunos operadores de nivel Professional pueden requerir licencia según tu cuenta de Altair.
git clone https://github.com/alan4041207/mcp-altair-studio.git
cd mcp-altair-studio
npm install
npm run buildRequiere JDK 17+ y Gradle — ver altair-http-bridge/README.md para el paso a
paso completo (incluye cómo obtener ambos sin permisos de administrador).
cd altair-http-bridge
gradle build -PaltairHome="C:\Program Files\Altair\RapidMiner\AI Studio 2026.1.1"
gradle installExtension -PaltairHome="C:\Program Files\Altair\RapidMiner\AI Studio 2026.1.1"Reinicia Altair AI Studio después de instalar la extensión.
Agrega (o fusiona, si ya tienes otros servidores MCP configurados) esta
entrada en %APPDATA%\Claude\claude_desktop_config.json:
{
"mcpServers": {
"altair-studio": {
"command": "node",
"args": ["C:\\ruta\\a\\mcp-altair-studio\\dist\\index.js"],
"env": {
"ALTAIR_HOME": "C:\\Program Files\\Altair\\RapidMiner\\AI Studio 2026.1.1",
"ALTAIR_DEFAULT_REPOSITORY": "Local Repository",
"ALTAIR_HTTP_BRIDGE_ENABLED": "true",
"ALTAIR_HTTP_BRIDGE_PORT": "8266"
}
}
}
}Reinicia Claude Desktop después de modificar este archivo.
En una conversación de Claude Desktop, pide que ejecute
altair_check_connection. Debe reportar el script de batch encontrado en
ALTAIR_HOME, y si el bridge HTTP opcional está alcanzable (no lo estará
hasta que completes el paso 2 y reinicies Studio).
Tool | Categoría | Notas |
| diagnóstico | ejecutar primero |
| ingesta | archivo CSV o entrada de repositorio |
| ingesta | requiere el bridge HTTP |
| ingesta | requiere el bridge HTTP |
| ingesta | requiere el bridge HTTP |
| preparación | valores faltantes, duplicados, eliminar columnas |
| preparación | Z-score/rango/proporción/IQR |
| preparación | columna derivada vía expresión |
| preparación | partición train/test |
| exploración | media/mín/máx/desv. estándar/mediana/conteo |
| ML | árbol de decisión/random forest/naive bayes/k-NN/SVM/regresión logística/red neuronal/GBT + validación cruzada k-fold. El Performance Vector no se imprime en modo batch (ver limitación en "Cómo se conecta") — la tool devuelve el log crudo, que no contendrá las métricas. |
| ML | k-Means (usa |
| ML | FP-Growth + reglas. Requiere datos ya binarizados (item presente/ausente); las reglas mismas tampoco se imprimen en modo batch — ver |
| ML | PCA |
| automatización | ejecuta cualquier |
| automatización | vía de escape: cualquier grafo de operadores que armes (DBSCAN, clustering jerárquico, conexiones a bases de datos, scripting Python/R, operadores de Hugging Face/LLM, Optimize Parameters, Loop Files, ...) |
| GUI hand-off | requiere el bridge HTTP |
| GUI hand-off | requiere el bridge HTTP |
Este proyecto deliberadamente no expone decenas de tools hechas a mano una por
una. RapidMiner/Altair tiene cientos de operadores; codificar cada uno de
memoria implicaría o bien una superficie enorme de baja confianza, o entregar
tools que silenciosamente invoquen la clave de operador equivocada. En su
lugar: ~17 tools bien probadas cubren los casos comunes de cada categoría, más
altair_run_operator_chain como bloque de construcción totalmente genérico —
se le pasa cualquier clave de clase de operador + parámetros + cableado de
puertos, y lo ejecuta. Arma el proceso una vez en la GUI de Studio, usa
Process ▸ Export Process para ver las claves de clase/puerto exactas, y
pásaselas directamente a la tool.
examples/market-basket-optimization/ — análisis completo de reglas de
asociación (Market Basket Optimization) sobre un dataset real de 7 501
transacciones: flujo construido y ejecutado contra Altair AI Studio, 959
itemsets frecuentes, 249 reglas con support/confidence/lift/conviction/
leverage/coverage, y un reporte HTML autocontenido con hallazgos de negocio.
Es el caso real que motivó los tres bugs corregidos arriba (use_header_row,
concurrency:fp_growth, la limitación de resultados no tabulares en modo
batch) — ver su propio README.md para el detalle completo.
Ejecuta altair_check_connection.
Lee el log de error en la respuesta de la tool — los mensajes de error propios de Altair AI Studio suelen nombrar exactamente el operador/puerto incorrecto (así se corrigieron los nombres de puerto en las recetas de este proyecto).
Para un operador/puerto del que no estés seguro: arrástralo a un proceso en
la GUI de Studio, conéctalo, y luego Process ▸ Export Process (o la
vista de XML del proceso) para ver la clave de clase y nombres de puerto
reales, y usa altair_run_operator_chain directamente o corrige la
función correspondiente en src/altair/recipes.ts.
Para inspeccionar tú mismo el registro real de operadores del producto instalado (misma técnica usada para construir este proyecto):
Add-Type -AssemblyName System.IO.Compression.FileSystem
$zip = [System.IO.Compression.ZipFile]::OpenRead("C:\Program Files\Altair\RapidMiner\AI Studio 2026.1.1\lib\plugins\concurrency-12.1.1-all.jar")
$zip.Entries | Where-Object { $_.FullName -match "Operators.*\.xml" }Si el bridge HTTP deja de responder tras un rebuild: revisa
%USERPROFILE%\.AltairRapidMiner\AI Studio\<versión>\ai-studio.log en
busca de la línea Register plugin: MCP HTTP Bridge y cualquier
WARNING/excepción justo después — casi siempre apunta al problema
exacto (ruta de instalación incorrecta, firma de método incorrecta, etc.).
src/
config.ts ALTAIR_HOME, puertos, carpeta scratch (todo sobreescribible por env)
altair/
rmpXml.ts constructor genérico de XML .rmp
recipes.ts grafos de operadores escritos y probados a mano
batchRunner.ts lanza ai-studio-batch.bat
httpBridgeClient.ts habla con la extensión Java opcional
connector.ts elige bridge vs. batch, lee los CSV de resultado
tools/ registro de tools MCP (esquemas zod + handlers)
index.ts punto de entrada del servidor MCP (transporte stdio)
altair-http-bridge/ extensión Java opcional (ver su propio README)
examples/
market-basket-optimization/ caso real: reglas de asociación end-to-end (ver su README)
claude-desktop-config.example.jsonMine association rules with FP-Growth + Create Association Rules (market-basket analysis). Input data must be in transactional/binominal (item present/absent) form. Covers actions 61-64 (association rules, support/confidence/lift, market basket analysis).
| Name | Required | Description | Default |
|---|---|---|---|
| csvFile | No | Absolute path to a local CSV file to read directly (bypasses the repository). Use this OR repositoryEntry. | |
| minSupport | No | ||
| minConfidence | No | ||
| repositoryEntry | No | Altair AI Studio repository path, e.g. "//Local Repository/data/customers" or "//Samples/data/Iris". Use this OR csvFile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the algorithm and data format but does not mention side effects, authentication needs, or whether the tool creates or modifies data. The behavioral impact is largely unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and algorithm, then data requirement. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not mention return values. For a mining tool, the output format (e.g., rules with metrics) is important but omitted. The action codes reference is vague.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with descriptions for only two parameters (csvFile, repositoryEntry). The description adds no parameter details, leaving minSupport and minConfidence unexplained. It does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool mines association rules using FP-Growth and is used for market-basket analysis. It specifies the algorithm and the required data format, distinguishing it from other Altair tools like clustering or classification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite (data must be in transactional/binominal form) and mentions coverage of association rule actions. It implies usage context (market-basket analysis) but does not explicitly state when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check how this MCP server can currently reach Altair AI Studio 2026.0.5: whether the optional live HTTP bridge extension is running, and whether the headless batch script (rapidminer-batch.bat) is reachable at ALTAIR_HOME. Run this first when troubleshooting.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes what it checks but does not detail return format or potential errors. However, it is sufficient for a diagnostic read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences with no waste. It front-loads the purpose and provides a usage recommendation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple diagnostic tool with no parameters. It lacks output format details, but the context of 'check connection' implies a status result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description does not need to add parameter information. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking connectivity to Altair AI Studio 2026.0.5 by verifying two specific components. It is distinct from sibling tools which focus on data operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to run this first when troubleshooting, providing clear usage context. Does not mention exclusions or alternatives, but the sibling tools are clearly different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clean a dataset: replace missing values, remove duplicate rows, and optionally drop named columns. Covers missing-value handling, duplicate removal, and column selection (actions 11-15, 20 of data preparation).
| Name | Required | Description | Default |
|---|---|---|---|
| csvFile | No | Absolute path to a local CSV file to read directly (bypasses the repository). Use this OR repositoryEntry. | |
| dropColumns | No | Column names to remove before cleaning. | |
| repositoryEntry | No | Altair AI Studio repository path, e.g. "//Local Repository/data/customers" or "//Samples/data/Iris". Use this OR csvFile. | |
| missingValueStrategy | No | How to replace missing values. Default: average. | |
| missingValueReplacement | No | Replacement value when missingValueStrategy is "value". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes what operations are performed (replace missing values, remove duplicates, drop columns) but fails to mention important behaviors such as whether the tool modifies the file in-place or returns a new dataset, required authentication, or limitations on data size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long: the first sentence states the core purpose, and the second provides context via action numbers. It is front-loaded, concise, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the tool returns or whether it has side effects. It only states 'clean a dataset' without explaining the output format or any changes to the input file. Given the 5 parameters and lack of annotations, the description leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are fully described in the schema (100% coverage). The description reiterates the operations but does not add significant meaning beyond the schema, such as default behavior or typical usage patterns. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: cleaning a dataset with specific operations (missing value handling, duplicate removal, column dropping). It also references actions 11-15 and 20 of data preparation, providing context. While it doesn't explicitly differentiate from sibling tools, the operations are distinct enough for an agent to understand the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cleaning tasks but does not explicitly state when to use this tool versus alternatives like altair_normalize_data or altair_split_data. The reference to specific data preparation actions gives some guidance, but no exclusions or comparison are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Segment data with k-Means clustering; returns the dataset with an added cluster-id column. Covers actions 56, 60, 64-65 (segmentation / clustering).
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| csvFile | No | Absolute path to a local CSV file to read directly (bypasses the repository). Use this OR repositoryEntry. | |
| repositoryEntry | No | Altair AI Studio repository path, e.g. "//Local Repository/data/customers" or "//Samples/data/Iris". Use this OR csvFile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states the output is the dataset with an added cluster-id column. It does not mention any side effects, destructive behavior, permissions needed, or what happens if parameters are invalid. The reference to action numbers is not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that state the core function and returns. However, it could be better structured to separate the purpose from the action numbers, but overall it is efficiently written with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool performs k-Means clustering with 3 parameters, no output schema, and no annotations, the description is incomplete. It does not explain how the cluster-id is labeled, the algorithm's behavior, handling of edge cases, or prerequisites like data format. The action number reference provides versioning context but not operational completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the purpose or constraints of the parameters ('k', 'csvFile', 'repositoryEntry'). Schema coverage is 67% with csvFile and repositoryEntry having descriptions, but the parameter 'k' lacks explanation beyond its default and range. The description adds no additional semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool segments data using k-Means clustering and returns the dataset with an added cluster-id column. The verb 'Segment' and resource 'data with k-Means clustering' are specific. However, it does not differentiate from sibling tools like altair_association_rules or altair_reduce_dimensions_pca, which also perform segmentation or dimension reduction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Covers actions 56, 60, 64-65 (segmentation / clustering)', which is internal reference to Altair AI Studio actions but provides no guidance on when to use this tool versus alternatives. It lacks explicit when-to-use, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute descriptive statistics (average, min, max, standard deviation, median, count) for every numeric column. Covers actions 26-28 (descriptive statistics, distribution summary).
| Name | Required | Description | Default |
|---|---|---|---|
| csvFile | No | Absolute path to a local CSV file to read directly (bypasses the repository). Use this OR repositoryEntry. | |
| repositoryEntry | No | Altair AI Studio repository path, e.g. "//Local Repository/data/customers" or "//Samples/data/Iris". Use this OR csvFile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it computes stats for every numeric column. It does not disclose behavioral traits like handling of non-numeric columns, side effects, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and concise. It conveys the purpose without waste, but could include more useful information without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain the return format or value. It mentions statistics but lacks details on how results are presented. For a simple computation tool, this is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes descriptive statistics (average, min, max, standard deviation, median, count) for every numeric column, which is a specific verb+resource. It distinguishes from sibling tools that handle association rules, clustering, cleaning, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. It does not mention alternatives among sibling tools or provide context for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new derived/calculated column using a RapidMiner expression, e.g. attributeName="profit", expression="revenue - cost". Covers action 21 (create new variables via formulas).
| Name | Required | Description | Default |
|---|---|---|---|
| csvFile | No | Absolute path to a local CSV file to read directly (bypasses the repository). Use this OR repositoryEntry. | |
| expression | Yes | RapidMiner expression syntax, e.g. "revenue - cost" or "log(price)". | |
| attributeName | Yes | ||
| repositoryEntry | No | Altair AI Studio repository path, e.g. "//Local Repository/data/customers" or "//Samples/data/Iris". Use this OR csvFile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool creates a new column but does not disclose behavioral traits such as whether it modifies the dataset in place, if it is reversible, or what happens if an attribute with the same name exists. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, including an example and a reference to action 21. Every sentence adds value; there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and missing annotations, the description is incomplete. It lacks details on parameter relationships (csvFile vs repositoryEntry), return value, and usage context (e.g., whether it can be undone). Key gaps reduce the agent's ability to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, slightly below the 80% threshold, so the description should supplement. The description provides an example for attributeName and expression, adding context where the schema lacks description for attributeName. However, it does not explain the mutual exclusivity of csvFile and repositoryEntry, which the schema already hints at.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new derived/calculated column using a RapidMiner expression, with an explicit example. It distinguishes from sibling tools like altair_clean_data or altair_normalize_data by specifying 'generate attribute' and referencing action 21, which is unique among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a derived column is needed, but provides no explicit guidance on when to use this tool versus alternatives (e.g., altair_clean_data) or when not to use it. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the XML of the process currently open in the Altair AI Studio GUI (requires the HTTP bridge extension). Useful to see what the human user is working on before suggesting changes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates the tool reads XML (non-destructive) and requires an extension, but does not explicitly declare it as read-only or safe. The behavior is clear, but lacks explicit confirmation of no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the main action and adds a practical usage note. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description provides adequate context: purpose, prerequisite, and use case. It does not describe the return format or size, but for a read operation, this is acceptable. Slight improvement could be a note on the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is effectively 100%. The description does not need to add parameter information, earning a baseline of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read the XML') and the resource ('process currently open in the Altair AI Studio GUI'). It differentiates from siblings by focusing on the GUI state rather than repository or file operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the requirement ('requires the HTTP bridge extension') and provides use case ('useful to see what the human user is working on before suggesting changes'). It implies when to use but does not explicitly state when not to use or list alternatives, though the sibling set suggests alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import/preview tabular data through Altair AI Studio, from a repository entry or a local CSV file. Covers CSV/repository ingestion (actions 1-2, 5-7, 9 of the data-ingestion category).
| Name | Required | Description | Default |
|---|---|---|---|
| csvFile | No | Absolute path to a local CSV file to read directly (bypasses the repository). Use this OR repositoryEntry. | |
| repositoryEntry | No | Altair AI Studio repository path, e.g. "//Local Repository/data/customers" or "//Samples/data/Iris". Use this OR csvFile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It says 'Import/preview tabular data', but it is unclear whether this tool modifies state (imports) or only previews (read-only). The vague reference to 'ingestion actions' does not clarify safety, authentication, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the core function, and the second provides categorical context. It is efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and parameters for a simple tool without output schema or annotations. It lacks some context like whether the tool returns data or saves it, and what prerequisites exist (e.g., repository access). However, given the low complexity, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions for both csvFile and repositoryEntry. The tool description adds that these are two sources, but the schema already explains their meaning. The description does not add significant semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports/previews tabular data from a repository entry or local CSV file. The mention of covering specific actions (1-2, 5-7, 9) provides some context, but it does not explicitly differentiate among siblings like altair_read_repository_entry, which may also handle repository data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is used for importing/previewing data from CSV or repository, but it does not specify when to choose this over alternatives, nor does it provide any exclusions or prerequisites. The agent is left to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List folders/entries in the Altair AI Studio repository (requires the HTTP bridge extension, since the repository lives inside the running Studio session). Example path: "//Local Repository" or "//Samples/data".
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | //Local Repository |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the requirement for the HTTP bridge extension and the repository living inside a running Studio session, which is important behavioral context. It does not mention side effects or return format, but adds value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, requirement, and examples. It is concise, front-loaded, and every sentence adds value without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single optional parameter and no output schema, the description adequately covers purpose, prerequisite, and parameter usage. It could be more complete by mentioning return format or error behavior, but for a simple list tool it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds significant meaning by providing example paths (e.g., '//Local Repository' or '//Samples/data') and indicating the format, which clarifies the parameter's purpose beyond the schema's default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists folders/entries in the Altair AI Studio repository, with a specific verb and resource. It distinguishes from sibling tools like altair_read_repository_entry or altair_store_csv_to_repository which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (requires HTTP bridge extension, lives inside running Studio session) and example paths, guiding when to use the tool. However, it does not explicitly state when not to use or mention alternatives, leaving some room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Normalize/scale numeric attributes (Z-transformation, range/min-max, proportion, or interquartile range). Covers actions 17-18 (normalize and scale variables).
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | Z-transformation | |
| csvFile | No | Absolute path to a local CSV file to read directly (bypasses the repository). Use this OR repositoryEntry. | |
| repositoryEntry | No | Altair AI Studio repository path, e.g. "//Local Repository/data/customers" or "//Samples/data/Iris". Use this OR csvFile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only states the action (normalize/scale) without mentioning side effects, data mutation, missing value handling, or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words. Efficient and front-loaded, though it could benefit from slightly more structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description is too brief. It does not explain what the tool returns, whether it modifies the input, or how to handle errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (two params have descriptions). The description adds the list of methods but does not elaborate on parameter usage, defaults, or trade-offs. With moderate coverage, the description provides marginal additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Normalize/scale numeric attributes' and lists four specific methods (Z-transformation, range, proportion, interquartile), distinguishing it from sibling tools like altair_descriptive_stats or altair_clean_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no scenarios where it is appropriate or inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace the process currently open in the Altair AI Studio GUI with the given XML, handing control back to the human user so they can inspect/run/edit it visually (requires the HTTP bridge extension).
| Name | Required | Description | Default |
|---|---|---|---|
| xml | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool replaces the current process (destructive) and hands control to the user, but does not detail side effects like loss of unsaved changes or behavior if the HTTP bridge is missing. Partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that front-loads the main action and key requirement. It is not verbose, though could be slightly restructured for even faster parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action, prerequisite, and outcome, but lacks details on error handling, return value, or validation. Given the tool's simplicity and lack of output schema, it is minimally adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only one parameter (xml) and 0% schema coverage, the description adds meaning by stating 'with the given XML', clarifying the parameter's role as the process XML content. No additional details on format or constraints, but adequate for a single string param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'replace' and the resource 'process currently open in the Altair AI Studio GUI', and distinguishes the tool from siblings like altair_get_current_process (read) or altair_run_process_file (run without human interaction) by emphasizing handing control back to the user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a requirement ('requires the HTTP bridge extension'), but does not explicitly state when to use this tool versus alternatives, such as altair_get_current_process for reading or altair_run_process_file for batch execution. Usage context is implied but not formally guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a data entry from the Altair AI Studio repository as CSV (requires the HTTP bridge extension).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| maxRows | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only reveals the output format and a prerequisite. It does not disclose error handling, effects of maxRows, or whether the operation is read-only. Minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is under-specified. It is not verbose, but the lack of detail reduces its usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal description, the tool lacks completeness. It does not explain return values, pagination, or error scenarios, which are important for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no information about parameters. It fails to explain the meaning of 'path' (e.g., absolute vs relative) or 'maxRows' (e.g., row limit behavior).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a data entry as CSV from the Altair AI Studio repository, specifying the verb, resource, format, and a prerequisite. It distinguishes from siblings like altair_list_repository (listing) and altair_store_csv_to_repository (writing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a required extension but provides no explicit guidance on when to use this tool versus alternatives like altair_import_data or altair_list_repository. The usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reduce dimensionality with PCA, keeping enough components to reach a target variance threshold. Covers action 43 (PCA).
| Name | Required | Description | Default |
|---|---|---|---|
| csvFile | No | Absolute path to a local CSV file to read directly (bypasses the repository). Use this OR repositoryEntry. | |
| repositoryEntry | No | Altair AI Studio repository path, e.g. "//Local Repository/data/customers" or "//Samples/data/Iris". Use this OR csvFile. | |
| varianceThreshold | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. While it mentions the variance threshold, it omits important details such as whether the tool is destructive (modifies original data), prerequisites (e.g., numeric data), performance implications, or edge cases (e.g., insufficient variance). This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) with no redundant information. It front-loads the core functionality. However, the second sentence about action number adds minimal value and could be integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (PCA with a parameter), no output schema, and no annotations, the description is incomplete. It fails to specify what the output is (e.g., reduced dataset), prerequisites (numeric data, no missing values), or limitations. This leaves the agent with insufficient information to correctly invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 of 3 parameters described). The description adds context by linking varianceThreshold to the target variance objective, but does not provide syntax or constraints beyond the schema. For a low-coverage schema, the description partially compensates but remains insufficient for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'reduce', the resource 'dimensionality', and the method 'PCA'. It specifies the behavior of keeping enough components to reach a target variance threshold, making the tool's purpose unambiguous and distinct from siblings like clustering or normalization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use PCA vs other dimensionality reduction methods or when not to use it. It mentions 'Covers action 43 (PCA)' but provides no guidance on alternatives or context. Usage is implied but not clearly delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ADVANCED / escape hatch: run ANY Altair AI Studio / RapidMiner operator graph you assemble yourself, by giving the exact operator class keys, parameters, and port-level connections. Use this for operators not covered by the dedicated tools (DBSCAN, hierarchical clustering, database connections, web/text/scraping extensions, Hugging Face / LLM operators, Optimize Parameters, Loop Files, Python/R scripting, etc). Tip: build the graph once in the Altair AI Studio GUI and use Process > Export Process to see the exact class keys and port names to copy here. The graph must end by writing its result(s) with a 'write_csv' operator to an absolute file path you choose — read that file back afterwards to see the result.
| Name | Required | Description | Default |
|---|---|---|---|
| macros | No | ||
| operators | Yes | ||
| connections | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the need to write results via write_csv and implies the tool executes arbitrary graphs, which could have side effects. Missing details on error handling or performance, but sufficient for typical usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two-sentence description that front-loads 'ADVANCED / escape hatch' to set expectations. Every sentence adds value: purpose, when to use, tip, requirement. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, no output schema, no annotations), the description provides enough context: purpose, usage guidance, a key requirement, and a practical tip. It does not explain the return value, but the write_csv instruction implies the result is in the file. Overall, well-rounded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds context by mentioning 'operator class keys, parameters, and port-level connections' and the tip about Export Process. However, it does not detail each parameter structure beyond what schema provides, leaving some interpretation for agents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an advanced escape hatch to run arbitrary operator graphs, distinguishing it from dedicated sibling tools by listing examples like DBSCAN, Hugging Face, etc. The verb 'run' and resource 'operator graph' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this for operators not covered by the dedicated tools' and provides a practical tip on exporting from Altair AI Studio. Also states a critical requirement: the graph must end with write_csv to an absolute path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute an existing .rmp process file (already saved on disk or exported from the Studio repository) headlessly via rapidminer-batch. Covers actions 76-80 (run saved/repeatable workflows, automate experiments) and scoring-on-new-data flows (action 84).
| Name | Required | Description | Default |
|---|---|---|---|
| macros | No | Macro overrides, passed as -M key=value. | |
| processFilePath | Yes | Absolute path to the .rmp file to run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral traits. It mentions 'headlessly via rapidminer-batch' but does not disclose return values, error handling, or side effects. The absence of output schema makes this gap more significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two succinct sentences with no extraneous information. The core action is front-loaded, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should explain what the tool returns or produces (e.g., logs, process results). It only describes the action but omits the outcome, making it incomplete for an agent to understand the tool's full effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no new meaning beyond the schema's parameter descriptions; it only restates the context of headless execution. No extra format or constraint details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Execute') and resources ('.rmp process file'), and differentiates from siblings like altair_run_operator_chain by specifying it runs saved files headlessly. It also cites relevant action numbers (76-80, 84) for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use: for saved .rmp files, headless execution, and repeatable workflows. It implicitly distinguishes from siblings (e.g., altair_open_process_in_studio for interactive use), but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split a dataset into train/test partitions. Covers action 66 (train/validation/test split).
| Name | Required | Description | Default |
|---|---|---|---|
| csvFile | No | Absolute path to a local CSV file to read directly (bypasses the repository). Use this OR repositoryEntry. | |
| trainRatio | No | ||
| repositoryEntry | No | Altair AI Studio repository path, e.g. "//Local Repository/data/customers" or "//Samples/data/Iris". Use this OR csvFile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without explaining behavior: whether the split is random, if it modifies the original data, or any side effects like creating new repository entries. The internal action number '66' adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences with no wasted words. It front-loads the primary purpose and includes a secondary reference to an internal action identifier, which is brief but does not clutter the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (splitting data for machine learning), the description is insufficient. It lacks details about the split strategy (e.g., random, stratified), reproducibility (no seed parameter), handling of imbalanced classes, or output format. Absence of output schema and annotations exacerbates the lack of completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents two of three parameters (csvFile and repositoryEntry) with descriptions of their usage and mutual exclusivity. trainRatio has default and range constraints. The description adds no parameter-specific information beyond what the schema provides. With 67% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool splits a dataset into train/test partitions, which is a specific verb+resource. However, it mentions 'train/validation/test split' in parentheses, which is slightly different from the main description but still conveys the core purpose. It distinguishes from sibling tools like altair_clean_data or altair_normalize_data because splitting is a distinct operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as the need for a dataset already in the repository or local file, or any conditions under which splitting is appropriate. There is no comparison with other data manipulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a local CSV file's contents into an Altair AI Studio repository entry (requires the HTTP bridge extension). Covers action 82-83 style export-to-repository / reuse-as-input flows.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| csvFilePath | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It notes the HTTP bridge requirement but does not indicate whether the tool overwrites or appends, what happens on failure, or any side effects. This is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main action and key requirement. It is efficient without unnecessary elaboration, though it could be slightly more structured with parameter hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters and no output schema, so the description should be relatively complete. However, it omits parameter details, error conditions, and behavior for existing entries, making it inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies csvFilePath is the local CSV file and path is the repository location, but adds no details on format, validation, or constraints. The parameter names are somewhat self-explanatory, but the lack of explicit semantics hurts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a local CSV file's contents to a repository entry, with specific reference to action 82-83 flows. This distinguishes it from sibling tools like altair_import_data or altair_read_repository_entry, though it could be more explicit about the nature of a repository entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the HTTP bridge extension requirement and references specific actions, providing context for use. However, it does not specify when not to use this tool or suggest alternatives among siblings, leaving the agent without clear exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Train and evaluate a classification model with k-fold cross validation (Decision Tree, Random Forest, Naive Bayes, k-NN, SVM, Logistic Regression, Neural Net, or Gradient Boosted Trees). Returns the performance vector (accuracy/precision/recall/etc). Covers actions 46-55, 66-74 (supervised learning + validation).
| Name | Required | Description | Default |
|---|---|---|---|
| folds | No | ||
| csvFile | No | Absolute path to a local CSV file to read directly (bypasses the repository). Use this OR repositoryEntry. | |
| learner | No | decision_tree | |
| labelAttribute | Yes | Name of the target/label column. | |
| repositoryEntry | No | Altair AI Studio repository path, e.g. "//Local Repository/data/customers" or "//Samples/data/Iris". Use this OR csvFile. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the return value (performance vector) but does not disclose side effects (e.g., whether the model is saved or if the training set is modified). This leaves some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, each serving a distinct purpose: the first defines functionality, the second specifies return and scope. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately explains the return type (performance vector). It covers the main purpose and key parameters, though it could mention prerequisites (e.g., labelAttribute must exist in data) or outcome of training.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, and the description adds value by mapping the learner enum to human-readable model names and explaining the folds parameter in the context of k-fold cross-validation. It also clarifies the relationship between csvFile and repositoryEntry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as training and evaluating classification models with k-fold cross-validation, listing eight specific model types. This verb+resource combination is distinct from sibling tools like clustering or association rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by mentioning the covered actions (46-55, 66-74) and supervised learning + validation, implying when to use. However, it lacks explicit exclusions or alternatives, such as mentioning when to use other classification-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0altair_association_rulesaltair_check_connectionaltair_clean_dataaltair_cluster_kmeansaltair_descriptive_statsaltair_generate_attributealtair_get_current_processaltair_import_dataaltair_list_repositoryaltair_normalize_dataaltair_open_process_in_studioaltair_read_repository_entryaltair_reduce_dimensions_pcaaltair_run_operator_chainaltair_run_process_filealtair_split_dataaltair_store_csv_to_repositoryaltair_train_classifierScored across 18 tools
Each tool targets a distinct data science operation or utility (e.g., classification vs. clustering vs. PCA vs. data cleaning), with no overlapping responsibilities. The advanced escape hatch is clearly separated as a catch-all for unsupported operators.
All tools follow a consistent 'altair_verb_noun' pattern in snake_case, with clear action words (e.g., import_data, train_classifier, run_operator_chain). The minor deviation in 'descriptive_stats' still fits the pattern well.
18 tools is well-calibrated for a data science MCP server, covering data ingestion, preparation, modeling, evaluation, and process management without being overwhelming. Each tool feels necessary and justified.
The set covers the core data science workflow (import, clean, transform, model, evaluate, export) thoroughly. A dedicated regression tool is missing, but the advanced operator-chain escape hatch fills that gap, making it nearly complete for common tasks.
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
MCP server for building and testing AI agents with multi-model experimentation and insights.
