Skip to main content
Glama

dashai_get_prediction

Read-onlyIdempotent

Retrieve class counts for a completed prediction by providing its prediction ID. Returns aggregated counts and status without exposing raw row data.

Instructions

Returns class counts for a finished prediction — never the rows.

dashAI stores predictions as an Arrow dataset on disk and GET /predict/ only returns the SQL row (id, status, paths). This tool reads that row and, when the job is finished, aggregates the output column. The label list never leaves the function.

Args: params (GetPrediction): contains prediction_id from dashai_predict.

Returns: str: JSON {prediction_id, run_id, dataset_id, status, finished, n, n_classes, class_counts}. Paths and row lists are stripped.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Addedv0.2.2

TDQS

A4.4/5.0
Behavior5/5

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

The description reveals meaningful internal behavior beyond the annotations: it reads a SQL row, aggregates an Arrow dataset stored on disk, strips paths/row lists, and ensures the label list never leaves the function. This is strong behavioral disclosure that aligns with readOnlyHint and idempotentHint.

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 with the main purpose, then uses compact context about the underlying GET /predict/ row and the returned JSON shape. Every sentence contributes useful information, though the Arrow/GET explanation could be slightly tighter.

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 single-parameter read-only tool with clear annotations, the description covers what the tool does, what it receives, what it returns, and what it deliberately strips away. It even includes the exact JSON shape, and it leaves no major ambiguity for selecting or invoking it.

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

Parameters3/5

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

The only parameter, prediction_id, is already described in the schema as 'Id returned by dashai_predict'; the description essentially repeats that without adding new constraints, examples, or edge-case guidance. The schema does the heavy lifting, so this is acceptable but not enriched.

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 sharp statement: 'Returns class counts for a finished prediction — never the rows.' This clearly identifies the resource, the action, and the exact scope, distinguishing it from row-level or run-level 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 explicitly states that it applies to a finished prediction and that the prediction_id comes from dashai_predict. It also implies that this tool is not for retrieving raw rows, since 'paths and row lists are stripped.' It does not name sibling alternatives directly, but the usage context is clear.

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

Latest Blog Posts

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/Maarmapa/dashai-mcp'

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