Loading ToolBench

Reading the current corpus…

mcp-huggingface MCP server · D · ToolBench

← Browse

mcp-huggingface

github.com/pipeworx-io/mcp-huggingface

Hugging Face Hub MCP — models, datasets, spaces

2026-07-28+10 tools

54/100

Definition Quality68

Protocol Readiness35

Supportability43

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

Server defines 10 tools with complete input schemas and basic descriptions. All tools are read-only and follow verb_noun naming (search_*, get_*, list_*, trending_*). Schemas include type definitions and parameter descriptions. However, descriptions are terse (10-50 chars), lack context on WHEN to use each tool, and omit output schema documentation. Parameter descriptions are minimal, many lack guidance on valid ranges, formats, or dependencies. No error handling guidance visible. Missing idempotency hints and chaining IDs in responses.

Tools (10)

get_datasetread onlysource verified67/100

Detailed dataset info.

get_modelread onlysource verified73/100

Detailed model info — config, tags, downloads, files at root.

get_spaceread onlysource verified67/100

Detailed Space info.

list_dataset_filesread onlysource verified67/100

List files in a dataset repo.

list_model_filesread onlysource verified70/100

List files at the root of a model repo.

search_datasetsread onlysource verified67/100

Browse / search datasets on the Hub.

search_modelsread onlysource verified70/100

Browse / search models on the Hub.

search_spacesread onlysource verified

Issues (5)

HIGHtool ↗

Output schemas not documented. LLMs cannot plan downstream calls or extract required fields (repo_id, downloads, tags, etc.). Responses are opaque.

search_modelssearch_datasetssearch_spacesget_modelget_datasetget_spacelist_model_fileslist_dataset_filestrending_modelstrending_datasets

HIGHtool-description ↗

Tool descriptions are terse (10-50 chars) and lack context. Missing WHEN to use each tool, prerequisites, and how results differ from similar tools. E.g., search_models vs trending_models distinction unclear.

search_datasetssearch_spacesget_datasetget_spacelist_dataset_filestrending_modelstrending_datasets

HIGHconstrained-input ↗

Parameter descriptions lack constraints and guidance. 'limit' has no min/max bounds (code enforces 1-1000 but description says '1-1000 (default 20)' inconsistently). 'sort' and 'direction' lack enum constraints or valid value lists.

Recommendations

Document output schemas for all tools. E.g., search_models returns {items: [{id, modelId, author, downloads, likes, tags, ...}], total: number}. Include which fields are safe to chain into downstream tools.
Expand tool descriptions to 50-150 chars with WHEN/WHY context. E.g., 'search_models: Find models by name, author, or task. Use this to discover available models before calling get_model for details.' vs current 'Browse / search models on the Hub.'
Add enum constraints to 'sort' and 'direction' parameters. Replace description 'downloads | likes | trending_score | ...' with explicit enum: ['downloads', 'likes', 'trending_score', 'lastModified', 'createdAt'].
Move API key from tool parameter to server-side environment variable (HF_API_KEY). Remove '_apiKey' from all tool inputs. Document in server README how to configure authentication.
Add error recovery guidance. E.g., 'If repo_id not found, try search_models() with partial name. If rate-limited, wait 60s and retry.' Include these hints in tool descriptions or as structured error responses.

Score history

Overall score trend

First recorded score · v2 rubric

54/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	54	2026-07-28+	v2