Skip to main content
Glama

inspect_model

Inspect a semantic model to get a complete compact view of its columns, measures, joins, samples, and metadata without writing SQL.

Instructions

DEPRECATED: use the inspect tool. Return a complete-yet-compact view of a semantic model.

Always emitted (regardless of sections): model header + description, metadata bullets (data_source, sql_table, default_time_dimension, hidden, row_count), backing-query structure for query-backed models, and — when show_sql=True — the custom SQL block, model-level filters, and the cached backing-query SQL.

Section-gated parts (subset selectable via sections):

  • columns — unified row-level columns table with a sampled column (distinct values for string/boolean, min .. max for number/date/time, or top20 ... (N distinct) for high- cardinality categoricals).

  • measures — named-formula library.

  • aggregations — custom aggregation definitions. The formula column and the sql field of each params[] entry are gated by show_sql.

  • joins — join definitions.

  • samples — live sample-data query (COUNT(*) plus one aggregation per column).

  • learnings — learning-only memories whose canonical entities reference this model.

When a section is omitted from sections: columns, measures, aggregations and joins collapse to a one-line backticked CSV of names; samples and learnings are dropped entirely. A footer at the end of the response lists what was trimmed and how to fetch more.

Args: model_name: Name of the model to inspect. num_rows: Max sample-data rows (default: 3). show_sql: When true, include the generated SQL for the sample-data query, the custom SQL block, model-level filters, the cached backing-query SQL, and aggregation formulas/param SQL. format: Output format — "markdown" (default) or "json". Case-insensitive. sections: Subset of ["columns", "measures", "aggregations", "joins", "samples", "learnings"]. Default (None or empty list) renders all six. Unknown names are ignored with a warning line at the end of the response. A non-empty list of only unknown names resolves to no sections (not all six) — "all sections" is reserved for None/[] so a typo can't silently trigger the full expensive payload. descriptions_max_chars: When set, every description field (model, column, measure, aggregation) longer than this is truncated with a ... [truncated] suffix. Must be >= 0. None (default) means no truncation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNomarkdown
compactNo
num_rowsNo
sectionsNo
show_sqlNo
model_nameYes
data_sourceNo
descriptions_max_charsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

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

  1. First observedv0.10.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full disclosure burden and does so thoroughly. It details always-emitted content, section-gated behavior, collapse behavior for omitted sections, the footer, unknown-section handling, SQL gating via `show_sql`, and truncation semantics. This gives the agent strong awareness of response shape and edge-case behavior.

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 long but tightly structured and front-loaded with the deprecation warning and core purpose. Every major behavior is organized under clear headers, defaults and edge cases are explicit, and there is no filler or vague wording.

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

Completeness4/5

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

For an 8-parameter introspection tool with no annotations and an output schema, the description is unusually complete: it explains output composition, section subsetting, collapse behavior, SQL inclusion, format, and truncation. The only real gap is the undocumented `compact` and `data_source` parameters, which prevents a perfect score.

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 raw schema has no parameter descriptions, so the description compensates substantially for `model_name`, `num_rows`, `show_sql`, `format`, `sections`, and `descriptions_max_chars`, including a nuanced explanation of unknown `sections` values. However, `compact` and `data_source` are absent from the Args section, leaving their semantics to inference from titles and context.

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 states a specific verb ('Return') and resource ('semantic model') and defines the output as a 'complete-yet-compact view.' It also explicitly distinguishes itself from the sibling `inspect` tool by flagging DEPRECATED and directing the agent to use `inspect` instead, leaving no ambiguity about what this tool does.

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?

The description is explicit about usage: it begins with 'DEPRECATED: use the inspect tool,' naming the alternative and telling the agent when not to choose this tool. It also gives clear guidance on section selection, defaults, and edge cases, so an agent knows exactly how to request the desired subset of output.

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/MotleyAI/slayer'

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