Skip to main content
Glama
getsimba-ai

Simba MCP Server

Official
by getsimba-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Model

get_model
Read-onlyIdempotent

Retrieve a marketing model's metadata and configuration for any status, including failed models. Inspect setup, error details, and location to diagnose issues.

Instructions

Get a model's metadata and configuration echo — works for EVERY status, including failed models (unlike get_model_results, which needs 'complete').

Use this to inspect what a model was configured with, why it failed, or where it lives. Returns: id, model_hash, name, status, model_type ("mmm"/"var"), hierarchy_value, periodicity, is_saved, project_id/name, linked_var_model_hash, created_at/completed_at, error (the failure message — non-null only when status is "failed"), and model_config (the create-time configuration echo: data_source, columns, channels, priors as resolved, and the config flags).

NOTE: the echo omits a few accepted create_model inputs (operating_margin, annual_discount_rate, reporting_kernel) — absence there does not mean they weren't applied; check the financials results section for the stored margin.

Args: model_hash: The model hash (any status).

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_modelDictOutput",
+  "type": "object"
+}
  2. First observedv0.3.2

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark this as read-only and idempotent. The description adds substantive behavioral detail beyond that: it works for any status, the error field is non-null only for failed models, and it lists the configuration echo and its known omissions. This materially helps an agent predict behavior without over-claiming.

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 organized: opening purpose, use cases, returns, and a note about omissions. Every sentence carries useful information, including the critical caveat about omitted create_model inputs. The most important differentiator (works for any status) is front-loaded.

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

Completeness5/5

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

Given the simple one-parameter input, the existing output schema, and the annotations, the description covers all decision-relevant details: why to use this over siblings, what the return shape means, and an important limitation of the echo. No critical gap remains for safe invocation.

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

Parameters4/5

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

The schema only provides the parameter name and type with 0% description coverage. The description's Args section adds 'The model hash (any status),' clarifying that this identifier is valid even for failed models. For a single parameter this is adequate, though more detail on how to obtain the hash could be helpful.

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 begins with a specific verb and resource: 'Get a model's metadata and configuration echo.' It clearly states what the tool returns and explicitly contrasts itself with get_model_results, making its scope unambiguous and differentiating it from a close sibling.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance: 'works for EVERY status, including failed models' and contrasts with get_model_results which 'needs complete.' It also explains common use cases: inspect configuration, understand failure, or locate a model. This is direct and actionable.

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