Skip to main content
Glama
Maarmapa

dashai-mcp

by Maarmapa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

dashai_predict

Enqueue a prediction job using a model from a finished run. Specify an optional dataset and receive a job ID to track progress.

Instructions

Enqueues a prediction using the model of an already finished run.

Like training, it is asynchronous: it returns a job_id and the result is followed with dashai_job_status.

Collapses the two calls the GUI makes (read from DatasetPredictionPanel + createPrediction + enqueuePredictionJob, not from the docs):

  1. POST /predict/ creates the Prediction row ({run_id, dataset_id})

  2. POST /job/ PredictJob enqueues with {prediction_id} — NOT run_id

Passing only run_id to the job raises KeyError 'prediction_id' inside PredictJob.run. The Prediction row must exist first.

Args: params (Predict): contains: - run_id (int): id of a finished run - dataset_id (Optional[int]): dataset to score; defaults to the run's training dataset (from its model session)

Returns: str: JSON {"job_id", "run_id", "prediction_id", "dataset_id", "status": "enqueued", "next_step"}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.2
    • addedInput schema / $defs / Predict / properties / dataset_id
      Added value: +{
+  "anyOf": [
+    {
+      "minimum": 1,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Dataset to predict on. If omitted, the run's training dataset is used. Must have the same input columns as the model; pick it from dashai_list_datasets.",
+  "title": "Dataset Id"
+}
  2. First observedv0.2.0

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond annotations by explaining that the tool creates a Prediction row and then enqueues a PredictJob, that the job expects prediction_id rather than run_id, that passing only run_id causes a KeyError, and that the operation is asynchronous. This is valuable behavioral disclosure beyond the readOnlyHint/idempotentHint flags.

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-structured: a one-sentence purpose, a clear async follow-up note, a concise two-step internal flow, a warning about a specific failure mode, and an Args/Returns recap. Every section adds important operational knowledge without padding.

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

Completeness5/5

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

Given the complexity of the two-step internal flow, the description covers the operation end-to-end: input semantics, async behavior, response shape, and follow-up tool. The KeyError warning is especially valuable for correct use of the returned prediction_id.

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 description includes an Args section explaining run_id as a finished run and dataset_id as optional with a default to the run's training dataset. It adds important context about the internal run_id/prediction_id distinction, though the input schema already provides detailed descriptions for the nested fields.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Enqueues a prediction using the model of an already finished run.' It clearly distinguishes this from training, dataset listing, and job-status tools, and it states that the operation is asynchronous and returns a job_id.

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 usage context: use it for a finished run, the operation is asynchronous like training, and the result should be followed via dashai_job_status. It does not explicitly enumerate when not to use it, but it provides enough contextual guidance for selection.

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

Deploy Server

Other Tools