Skip to main content
Glama

HuggingFace

huggingface
Read-only

Inspect model repositories on the Hub: metadata, file structure, and quantization quality. Query models, files, repos, searches, and organizations without downloading weight files.

Instructions

Inspect HuggingFace Hub models: metadata, files, and quantization quality.

Use this for model-repo lookups: architecture and parameter count, checkpoint size and shard layout, gated/private status, base-model lineage, per-file sizes and LFS checksums, and a quantization analysis that reports effective bits per weight rather than what the uploader claimed. huggingface.co URLs are also handled automatically by web_fetch_incisive — this tool is for structured queries.

Actions: model, file, tree, search, org.

Query formats vary by action:

  • model: "org/name" (e.g. "openai/gpt-oss-120b"), optionally "org/name@revision"

  • file: "org/name/path/to/file" (e.g. "openai/gpt-oss-120b/config.json") — use ref= for a branch/tag

  • tree: "org/name" or "org/name/subdirectory"

  • search: free text (Hub search is substring-based over repo ids); pair with author= to scope

  • org: an organization or user name (e.g. "mlx-community")

Weight files are never downloaded. Asking for a .safetensors or .gguf file returns its size, LFS checksum, and the byte-range recipe for reading the header — a multi-GB shard exposes its per-tensor dtypes and shapes in a header of a few hundred KiB.

On the model action, effective bits-per-weight is suppressed rather than guessed whenever the Hub's own numbers cannot support it: packed storage counts reported as parameter counts, repos shipping more than one checkpoint set, diffusers pipelines, and GGUF-only repos each get an explicit explanation instead of a misleading number. Set quant_audit=true to spend one extra request reading the base model's native weight format, which resolves several of those cases and yields a grid-preservation verdict.

Authentication: optional. Set HF_TOKEN env var or create ~/.config/parkour/hf_token to reach gated and private repos and raise the rate limit. Without a token the Hub returns an identical 401 for gated, private, and nonexistent repos, and this tool reports that ambiguity rather than guessing which one it hit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refNoGit revision (branch, tag, or commit SHA) for file/tree. Defaults to main.
sortNoSort field for search/org: downloads, likes, lastModified, or trendingScore.downloads
limitNoMaximum results for search/org (default 10, max 100).
queryYesFor model/tree: 'org/name' (optionally 'org/name@revision'). For file: 'org/name/path/to/file'. For search: free text (Hub search is substring-based over repo ids). For org: the organization or user name. Any huggingface.co URL is also accepted and routed automatically.
actionYesThe operation to perform. model: model metadata, quantization analysis, and model card. file: read a repo file (weight files are described, never downloaded). tree: list repo files with sizes and LFS checksums. search: find models by name, optionally scoped to an author. org: list an organization's or user's models.
authorNoScope a search to one organization or user.
quant_auditNoOn the model action, spend one extra request to read the base model's native weight format. Buys the grid-preservation verdict and a trustworthy parameter count when the Hub reported packed storage elements instead of logical weights.
Behavior5/5

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

The readOnlyHint annotation is minimal, but the description provides extensive behavioral disclosure: weight files are never downloaded, effective bits-per-weight suppression cases, the extra request for quant_audit, and the 401 ambiguity without a token. This goes well beyond what annotations convey.

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 long but well-organized and information-dense. It front-loads the core purpose, then systematically covers actions, caveats, and auth. Every sentence adds value, though a few could be tightened. For the tool's complexity, the length is justified.

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 multi-action tool with 7 parameters and no output schema, the description covers all major aspects: return behavior, edge cases, authentication, and per-action semantics. It also explains when quant_audit is valuable and what happens without a token. Highly complete.

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?

Schema descriptions cover all 7 parameters, but the description adds meaningful context: query format examples for each action, the substring behavior of Hub search, what ref= means, and the byte-range recipe detail. It adds nuance beyond a simple restatement of the schema.

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?

Opening sentence clearly states the verb (Inspect) and resource (HuggingFace Hub models), then enumerates what is inspected: metadata, files, quantization quality. The description also distinguishes itself from web_fetch_incisive by explicitly noting it is for structured queries, not URL fetching.

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?

Explicitly states 'Use this for model-repo lookups' and enumerates the exact types of lookups. It names the alternative (web_fetch_incisive) for URL handling, and provides action-specific query formats. This gives the agent clear when-to-use and when-not-to-use guidance.

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

Install Server

Other Tools

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/blightbow/parkour-mcp'

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