Where My Hug At?
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HF_TOKEN | No | Optional Hugging Face token. Everything public works without one. To include private or gated repos your account can see, pass a Hugging Face token as HF_TOKEN. Without a token, a private repo looks missing, because Hugging Face answers 401 for both. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| where_my_hugA | Step 1 of 3, before recommending any machine learning model or dataset. If compute, license, stack or data is missing, returns the questions to ask the user first: call again with the answers ("unknown" is fine). Then returns the method: split the ML need into parts, search Hugging Face and the other hubs for each with where_my_hug_search, and decide from what it finds which parts they cover (use a model as is, fine-tune one, train one) and which are plain code. Follow it. |
| where_my_hug_searchA | Step 2 of 3: searches Hugging Face for each part of the need (the task's most downloaded and trending, names holding each keyword, and the text of model and dataset cards), and Kaggle, Zenodo, ModelScope and Roboflow Universe, for models and datasets alike. One found on several hubs is listed once, naming the others. Returns what it found, with downloads, likes, license, size, age and how each turned up, to pick each part's verdict and candidates from. Then call where_my_hug_verify. |
| where_my_hug_verifyA | Step 3 of 3: checks every picked model and dataset id live on its hub, drops the ones that are not there, flags licenses, gating, staleness and low use, sizes each model against the compute (fits, a stretch that fits only quantized, or cloud, with who hosts it), marks picks the search didn't turn up as from memory, names every hub a pick is on, shows what it found that wasn't picked, and returns the report to show the user. If nextAction is SEARCH_FIRST or RECALL_REPLACEMENTS, do what its instructions say and call again. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
The three tools are explicitly numbered as steps 1, 2, and 3 of a single pipeline, each with a clearly bounded role (intake, search, verify). There is no realistic way for an agent to confuse gathering answers with searching hubs or verifying picks.
All three names share the where_my_hug prefix and use predictable suffixes (base, _search, _verify) in snake_case. The entry tool lacks a verb-like suffix, a minor deviation, but the pattern remains obvious and readable.
Three tools map exactly onto the three phases of a linear recommendation workflow, with each step earning its place. This is well-scoped and avoids fragmenting the pipeline into unnecessary tools.
The surface covers the full lifecycle of the stated purpose: clarifying questions, multi-hub search, and live verification with actionable nextAction branching. Since it is an advisory read-only workflow, no create/update/delete operations are needed, leaving only minor gaps like no explicit restart/cleanup tool.