Skip to main content
Glama
getsimba-ai

Simba MCP Server

Official
by getsimba-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Model Status

get_model_status
Read-onlyIdempotent

Check a model's fitting progress to get current status, percent complete, ETA, and heartbeat liveness for stall detection.

Instructions

Check the fitting progress of a model.

Returns status (pending/under way/complete/failed), progress percentage, estimated time remaining, and timestamps. When supported by the backend, fit_liveness reports heartbeat age and the configured stall threshold in seconds, with last_heartbeat_at as Unix seconds. seconds_until_stall_threshold is time to the stale-heartbeat threshold, not fit ETA or an exact kill time. stall_threshold_exceeded does not change the model status. If fit_liveness is absent or available is false, liveness is unknown: do not infer a healthy or stalled fit. Reasons include heartbeat_unavailable and not_fitting. Continue polling with backoff; do not automatically restart a fit.

Args: model_hash: The model hash returned by create_model or list_models.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_hashYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "get_model_statusDictOutput",
+  "type": "object"
+}
  2. First observedv0.3.2

TDQS

A4.8/5.0
Behavior5/5

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

The description goes far beyond the annotations (which already declare readOnly, idempotent, etc.) by explaining subtle behaviors: fit_liveness heartbeat semantics, stall_threshold meaning, that stall_threshold_exceeded does not change status, and how to handle missing liveness data. This level of detail is exceptional and eliminates ambiguity.

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 structured with a clear purpose statement, then details on return values, liveness behavior, and polling guidance. Every sentence adds value; there is no filler. The critical information is front-loaded, and the parameter explanation is appended logically. It is concise for the complexity it covers.

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 tool's complexity (liveness, stall thresholds, edge cases) and that an output schema exists (so return format is covered elsewhere), the description is fully complete. It addresses all possible scenarios an agent might encounter: supported vs unsupported backend, absent liveness, stall threshold semantics, and appropriate polling behavior. Nothing critical is missing.

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 description coverage is 0%, so the description must fully explain the parameter. It does: 'model_hash: The model hash returned by create_model or list_models.' This adds clear meaning about where to obtain the value, which is essential for correct usage. The description fully compensates for the lack of schema documentation.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Check the fitting progress of a model.' It specifies the resource (model) and the action (check status). It also distinguishes itself from sibling tools like get_model_results or get_optimizer_results by focusing on fitting progress, not results. The description is explicit and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: it's for polling fitting progress, and explicitly instructs to 'Continue polling with backoff; do not automatically restart a fit.' It also warns about how to interpret liveness data and when not to infer health. While it doesn't name specific alternative tools, the guidance on when to use and what to avoid is sufficient for an agent to decide correctly.

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