Skip to main content
Glama

Analyze Model

analyze_model

Derive model architecture facts—parameter count, quantization, layers, and KV heads—from a Hugging Face repo's config.json to assess MLX models.

Instructions

Derive architecture facts (params, quantization, layers, KV heads) from config.json.

Input Schema

NameRequiredDescriptionDefault
repo_idYesHF repo id, e.g. 'mlx-community/...-4bit'

Output Schema

NameRequiredDescriptionDefault
notesNo
is_moeNo
repo_idYes
head_dimNo
confidenceNomedium
model_typeNo
num_layersNo
hidden_sizeNo
max_contextNo
architectureNo
num_kv_headsNo
quantizationYesMLX quantization parameters (from config.json `quantization` block).
sliding_windowNoWindow (tokens) of sliding-window layers.
total_params_bNoTotal params in billions.
active_params_bNoParams READ per decoded token in billions: active experts + attention + lm_head; excludes the input-embedding table (row lookup only). Drives the speed estimate.
weights_file_gbNoActual size of the safetensors files in GiB (from the Hub); preferred for memory.
num_linear_layersNoLinear-attention layers (constant-size state, no growing KV cache).
kv_cache_supportedNoFalse for architectures where the standard GQA KV formula does not apply.
num_sliding_layersNoLayers whose KV cache is capped at the window.
num_attention_headsNo
full_attention_head_dimNoHead dim of full-attention layers if it differs (Gemma 4 global layers).
full_attention_kv_headsNoKV heads of full-attention layers if they differ (Gemma 4 global layers).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries full behavioral burden. It does add real context by naming the source of truth (config.json), implying a metadata-only read rather than a weight download. But it says nothing about network access, auth/HF token needs, failure when config.json is missing, or whether results are cached.

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?

One sentence, zero filler, with the extracted facts front-loaded. Nothing in it is redundant or misplaced.

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?

An output schema exists so return values need no explanation, and the lone parameter is fully specified. What's lacking is behavioral context around the fetch itself (network access, missing-file handling), which matters for a tool that reads a remote config.

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 schema fully documents the single repo_id parameter with a concrete example format, so the description carries no additional burden. It adds only the indirect hint that the id points at a repo containing config.json.

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

Purpose4/5

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

A specific verb ('derive') plus the exact resource and the fields extracted (params, quantization, layers, KV heads), plus the source ('config.json'). This is enough for an agent to distinguish it from analyze_model_card, though the distinction from that sibling is only implicit rather than stated.

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

Usage Guidelines2/5

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

The use case is only implied — feed it a repo id to get architecture facts. There is no statement of when to prefer this over analyze_model_card, estimate_fit, or scan_mlx_models, and no prerequisites or exclusions given.

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