Summary: It finds, checks, and recommends real ML models/datasets for a described job, then tells you what to use, fine-tune, train, or write as code.
Asks for compute, license, stack, and data before recommending anything; “unknown” is allowed.
Splits the ML need into parts and searches Hugging Face, Kaggle, Zenodo, ModelScope, and Roboflow Universe for models and datasets.
Consolidates duplicate findings across hubs, listing every hub where a model/dataset appears.
Assigns each part a verdict: USE, TUNE, TRAIN, or WRITE.
Verifies every picked model/dataset ID live, drops missing ones, and flags gating, licenses, staleness, low use, and hardware fit.
Sizes models against available compute, including fits, stretch/quantized use, and cloud options.
Produces a final report with candidates, unpicked search results, and a “Start here” recommendation.
Supports optional HF_TOKEN for private/gated Hugging Face repos and ROBOFLOW_API_KEY for Roboflow Universe.
Searches Hugging Face Hub for models and datasets relevant to each part of a task, using task tags, popularity, trending, model names, and card text; verifies picks live and sizes them against available hardware to recommend whether to use, fine-tune, or train a model.
Tell your AI agent what you want a model to do. It searches Hugging Face, Kaggle, Zenodo, ModelScope and Roboflow Universe for models and datasets for each part of the job, and tells you which parts already exist: which are an exact fit, which to fine-tune, which to train, and which are just code. One model or dataset on several hubs is one finding, with every hub listed, so you take it from the one you use. Every model and dataset it names is real, checked live, and every model is sized for your hardware. It ends with where to start.
Works with Claude Code, Codex, Copilot, Cursor, Gemini CLI, Cline, Devin, Open WebUI and any other MCP client, or as an Agent Skill.
Its companion, Git for Me!, does the same for open-source repos on GitHub, GitLab and Codeberg.
How it works: four questions · parts · the search · verdicts · the live check · flags · sizes
Related MCP server: AI Model Advisor MCP Server
Add it to your agent (Claude Code here; every other option below):
claude mcp add --scope user where-my-hug -- npx -y where-my-hugThen ask:
Where my hug at for transcribing handwritten recipe cards?
Your agent asks the few things it can't guess, splits the job into parts, and comes back with a report like the one below, every model and dataset in it looked up live moments before. It works for any job a model might do:
Where my hug at for spotting which birds visit my feeder camera? Where my hug at for sorting support emails by how urgent they are? Where my hug at for pulling the totals off scanned receipts?
Ask for "a model that reads handwriting" and you get whatever is popular: often too big for your GPU, under a license you can't ship, or in a format your code can't load. So before anything is named, four details come first. Your agent fills in what the conversation or your codebase already says, and asks you the rest:
What it asks | What that decides | |
Compute | Where will it run, and train if it needs to?one 24 GB GPU, CPU only, a phone, rented GPUs | How big a model can be, and whether fine-tuning is possible at all |
License | What may the result be used for?commercial, open source, personal | Which licenses are allowed |
Stack | What will call the model?a Python service, Node, the browser, a mobile app | Which weight formats work |
Data | What training data is there, or could be?none, about 300 labeled photos, can collect more | Whether fine-tuning or training is realistic |
"Not sure yet" is a fine answer: the picks then cover the range, and every model shows the memory it needs, so the report helps you decide.
The agent breaks the need into parts, each with an input and an output (photo → text, text → fields). A part that isn't a model's job (rules, geometry, parsing, lookups) is marked WRITE: code does it exactly. Most needs have one. A model doing work that code does exactly is a cost, not a feature.
What an agent remembers of Hugging Face is as old as its training, and misses the long tail. So nothing is picked from memory. For every other part, the agent writes a search (the Hub's task tag, a few keywords, the job in a few words), and it runs four ways on Hugging Face:
Way | What it finds |
Most downloaded for the task | What's proven |
Trending for the task | What's new, including models released after the agent's training |
Names holding each keyword | Fine-tunes and niche models |
The text of model and dataset cards | The long tail, by what the card says, like a web search |
The ways take turns in the results, so a niche fine-tune isn't buried under whatever is popular for the task.
Models and data live elsewhere too, so the same search covers four other hubs, for models and datasets alike, taking turns the same way:
Hub | What it adds | Key |
Competition and community datasets, and Kaggle Models | none | |
Research datasets and models, with DOIs | none | |
Alibaba's hub: many Hugging Face models under the same names, and strong on Chinese-language data | none | |
Labeled image sets for detection and segmentation, and models trained on them |
|
ModelScope's search matches names, so it gets each keyword; the others get the
job in a few words. An id from one of them keeps its hub's name
(kaggle:landlord/handwriting-recognition, zenodo:1297399), so it's never
mistaken for a Hugging Face one.
The same model or dataset is often on several hubs: ModelScope carries many of Hugging Face's models under the same owner and name. It's listed once, with the others after "also on", and the report links each, so you take it from whichever hub you use. Hugging Face's id leads where it has one, since it says the most (monthly downloads, gating, who hosts it).
Verdict | Meaning |
USE | A model the search found does this job as it is. |
TUNE | One comes close: fine-tune it, ideally on a dataset the search found. |
TRAIN | Nothing it found comes close: train a model, seeded by datasets it found. |
WRITE | Not a model's job: write the code. |
The agent judges the results by what they say: task, card, downloads, age. It may add a model it knows that the search missed, but that pick ranks after the search's, and the report marks it from memory.
Every pick is looked up live on its own hub. Any that don't exist are dropped, and the agent goes back to the search for others. A pick that's on other hubs too names them, linked; picking it on two hubs gives one finding, not two. The rest are flagged for what would bite later and sized against your compute, and that report is what you see. Every id says whether it's a model or a dataset, and every dataset shows its size where the hub gives one (rows, images or bytes). It also lists what the search found that wasn't picked, so nothing it turned up is hidden. A TRAIN part whose search found models says to check them before training one. Every fact in the report (license, size, downloads, freshness) comes from the hubs themselves.
The report ends with Start here: the agent's pick of what to try first and why, and what to skip.
Under the hood it's an MCP server with three tools: where_my_hug for the
method (steps 1, 2 and 4), where_my_hug_search for step 3, and
where_my_hug_verify for step 5.
Flag | When |
UNCHECKED | Its hub didn't answer (down, rate-limited), or it's on Roboflow and no key is set. The id is kept, and asked again next time. |
GATED | You must accept its terms on its hub before downloading. |
NO_LICENSE | No license on its card. |
NON_COMMERCIAL | Non-commercial or research-only terms ( |
OWN_TERMS | Custom, use-restricted or no-derivatives terms ( |
STALE | Not updated in two years. |
LITTLE_USED | Under 100 downloads in the last month (Hugging Face only: the other hubs count downloads for all time, shown as such). |
Every model shows the memory it needs to run: 2.4 bytes per parameter, half precision plus room for activations. A model to fine-tune also shows what that takes: about 1 byte per parameter with QLoRA, 16 in full. Against the compute you gave (its first "N GB"):
The first model that fits heads its part.
Bigger ones follow under "If you can make it work": the search's picks first, then any from memory. A stretch fits only quantized to 4 bits (0.6 bytes per parameter), or on a bigger GPU. Cloud needs more than that: the report names the providers serving it on Hugging Face, or says rented GPUs.
A part where nothing fits still shows its bigger options. It isn't sent back for replacements, since the hardware might be found.
A model named as a dataset (or the other way round) is found under the right
kind. Licenses come from the card's metadata: license, license_name for
custom terms (reported as other (qwen-research)), or a license: tag.
The prompt above, from a live run on 2026-10-26 for one 24 GB GPU (abridged):
_Searched and checked on Hugging Face and the other hubs just now: 7 named, 0 not there and dropped._
## USE · Read the card
**Model: zai-org/GLM-OCR**
image-to-text · license mit · 1.3B parameters (~3.2 GB to run) · 1.7M downloads a month · found: most downloaded for image-to-text, trending for image-to-text, name has ocr
Also: deepseek-ai/DeepSeek-OCR (model) · baidu/Unlimited-OCR (model)
Models the search also found, not picked:
- datalab-to/indra-ocr (5.0k downloads a month): found as trending for image-to-text
- kaggle:lohith2007/handwritten-text-recognition: found as Kaggle search
## TUNE · Read the hard hands
**Model: microsoft/trocr-base-handwritten**
image-to-text · license mit · 333.3M parameters (~0.8 GB to run; to fine-tune, ~0.3 GB with QLoRA, ~5.3 GB in full) · 113.7k downloads a month · also on ModelScope · found: name has handwritten, ModelScope name has handwritten
**Data: kaggle:landlord/handwriting-recognition**
"Handwriting Recognition" · 1.4 GB · license CC0: Public Domain · 49.7k downloads in all · 483 likes · updated 6 years ago · found: Kaggle search
Watch out: not updated in two years.
Also: Voxel51/iam_handwriting_finevision (dataset) · zenodo:1297399 (dataset, stale)
## WRITE · Parse the amounts
No model: write this one.
## At a glance
1. Read the card USE model zai-org/GLM-OCR
2. Read the hard hands TUNE model microsoft/trocr-base-handwritten + dataset kaggle:landlord/handwriting-recognition
3. Parse the amounts WRITE your code
## Start here
Run zai-org/GLM-OCR on a dozen cards first: it fits the GPU, is MIT, and may read most hands as it is.
Tune TrOCR only on the lines it misses, starting from the Kaggle handwriting set (CC0, the most used).Every pick there was turned up by a search: the models and one dataset on Hugging Face, the others on Kaggle and Zenodo. TrOCR is on ModelScope too, under the same name, so the report links both.
Needs Node 22.18 or later. USAGE.md has step-by-step setup and links for 20+ agents: Claude Code and Desktop, Codex, Copilot (CLI and VS Code), Cursor, Windsurf, Devin, Cline, Gemini CLI, Goose, OpenCode, Zed, Junie, Kiro, Amp, Warp, Continue, LM Studio, Hermes, Mistral Vibe and Open WebUI. The quick routes:
Claude Code, Codex, Copilot CLI, as a plugin: the tools, plus a skill that knows when to reach for them. One marketplace serves all three.
/plugin marketplace add bikemeardsley/where-my-hug # Claude Code
/plugin install where-my-hug@where-my-hug
codex plugin marketplace add bikemeardsley/where-my-hug # Codex
codex plugin add where-my-hug@where-my-hug
copilot plugin marketplace add bikemeardsley/where-my-hug # Copilot CLI
copilot plugin install where-my-hug@where-my-hugAny other MCP client: a stdio server in the client's config. Most call the
key mcpServers (USAGE.md has the exceptions).
{ "mcpServers": { "where-my-hug": { "command": "npx", "args": ["-y", "where-my-hug"] } } }Antigravity CLI, as a plugin: agy plugin install https://github.com/bikemeardsley/where-my-hug/tree/main/plugin
Gemini CLI, as an extension: gemini extensions install https://github.com/bikemeardsley/where-my-hug
As an Agent Skill, for agents that read SKILL.md:
npx skills add bikemeardsley/where-my-hug.
HF_TOKEN (optional). Everything public works without one. To include
private or gated repos your account can see, pass a Hugging Face token as
HF_TOKEN (how, per agent); the Claude Code
plugin asks for it and keeps it in secure storage. Without a token, a private
repo looks missing, because Hugging Face answers 401 for both.
ROBOFLOW_API_KEY (optional). Kaggle, Zenodo and ModelScope are searched
without a key. To add Roboflow Universe, sign up free at
roboflow.com, copy your private API key (Settings →
API Keys), and pass it as ROBOFLOW_API_KEY, the same way as HF_TOKEN; the
Claude Code plugin asks for it too. Without it, the search says Roboflow
wasn't searched.
The search the agent writes for each part (a task tag, keywords, a few words
about the job) and the ids it picks, as GETs to huggingface.co/api, plus
your token if you set one. The same search, and the ids picked from it, also
go to the APIs of Kaggle, Zenodo, ModelScope (run by Alibaba Cloud in China)
and, with your key, Roboflow. Each key is sent
only to its own hub and never appears in a report. The need as you wrote it,
the method and the report stay between you and your agent.
Starting it with npx (as the MCP server, or the skill's shell fallback)
downloads the where-my-hug package from the npm registry, registry.npmjs.org.
Nothing is sent there but the request for the package.
Sizes come from safetensors metadata. Repos with only GGUF or .bin
weights show no parameter count, so they can't be sized against the
compute.
License flags read the card's metadata, not the license text.
The search finds what the Hub's own search can: names and tags, and the text of cards. A model with an unrelated name and a bare card can still be missed.
Card text is searched through the API behind the Hub's search page, which isn't documented. If it changes, that way fails and the results say so; the other three carry on.
The other hubs are searched by the job's few words (ModelScope by each keyword), not by task tag, and Kaggle wants every word to match, so a short, plain phrase finds most there. Their downloads are all-time, so they're never flagged little used.
One finding across hubs means the same owner and name. A copy under another
name (Kaggle's qwen-lm/qwen2.5-vl for Hugging Face's Qwen) is listed on its
own, for the agent to judge.
A Roboflow project is a dataset, and a model only once a version of it was trained there. Its search can't be asked for one or the other, so a model search keeps the trained projects.
Report a vulnerability privately through GitHub Security Advisories, not a public issue. SECURITY.md lists what it touches: GETs to Hugging Face and the four other hubs, and nothing on your machine.
node src/server.ts # the server, straight from source
npm test # offline: every hub is mocked, and the server is driven over stdio and HTTP
npm run check # typesnpm install also builds JavaScript into build/, which is what npx runs:
Node won't strip types from a package inside node_modules.
MIT
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.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Training data there is or could be, such as "none" or "about 300 labeled photos" | |
| need | Yes | The ML need in plain words: what goes in, what should come out, and what it is for | |
| stack | No | What will call the model: language, runtime, framework | |
| compute | No | The hardware it has to run or train on, such as "one 24 GB GPU" or "CPU only". Size flags take the first "N GB" in it as the memory a model must fit in | |
| license | No | What the result may be used for, such as "commercial, closed source" or "research only" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses conditional behavior: missing inputs produce clarifying questions, 'unknown' is acceptable, and the tool then returns a method rather than a final recommendation. It does not describe safety or statefulness, but it explains the interaction pattern and return content well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the step and purpose, and every sentence contributes to the workflow. The long method sentence is dense but not padded, though it could be split for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter planning tool with no output schema, the description explains the conditional return, the next search step, and how to use the result. It mentions step 1 of 3 but omits where_my_hug_verify, leaving a minor gap in the full workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds workflow meaning by naming the optional inputs (compute, license, stack, data), explaining that missing values trigger questions, and noting that 'unknown' is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that this is step 1 of 3 before recommending an ML model or dataset, and that it returns either clarifying questions or a method to follow. It distinguishes itself from the search sibling by directing the agent to use where_my_hug_search for hub searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly says to use this before recommending any ML model or dataset, to call again with answers when compute, license, stack, or data is missing, and to use where_my_hug_search for the search step. It lacks an explicit 'when not to use' statement but gives strong sequencing and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| parts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the search dimensions (most downloaded/trending, keyword-in-name, card text) and the deduplication rule ('One found on several hubs is listed once, naming the others'), plus what the response contains. It omits result caps, pagination, rate limits, and any auth or network-failure behavior, which matters for a tool fanning out across five hubs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with 'Step 2 of 3' and kept to a compact block; the dedup sentence and the return-field enumeration both earn their place. The parenthetical listing of search channels is a dense run-on that takes a second pass to parse, but nothing is truly wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does the right thing by enumerating the returned fields (downloads, likes, license, size, age, how each turned up) so the agent knows what it will get. Combined with the sequencing hint, this is nearly sufficient for a multi-hub search tool; only the absence of result-set size/pagination guidance is a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Top-level schema coverage is 0% – the `parts` array itself is undocumented – so the description has to compensate, and it partially does by explaining that each part drives a task/trending lookup, keyword-name match, and card-text match. Nested fields like task, phrase and keywords carry their own schema descriptions, but `id`/`name` and the maxItems=6 limit are unexplained in both places.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
A specific verb (searches) plus a concrete resource list (Hugging Face, Kaggle, Zenodo, ModelScope, Roboflow Universe, models and datasets). It also signals its position as 'Step 2 of 3' and names where_my_hug_verify as the follow-up, so an agent can place it in the workflow. It doesn't explicitly separate itself from where_my_hug (step 1), leaving that boundary implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Step 2 of 3' plus 'Then call where_my_hug_verify' gives explicit sequencing and a clear hand-off to the next tool. There are no when-not conditions and no explanation of what step 1 (where_my_hug) contributes, so the agent must infer the split, but the context is still clear enough to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | The ML need in plain words: what goes in, what should come out, and what it is for | |
| compute | No | The hardware it has to run or train on, such as "one 24 GB GPU" or "CPU only". Size flags take the first "N GB" in it as the memory a model must fit in | |
| components | Yes | ||
| recommendation | No | What to act on first: the one or two picks worth trying now and why (fit, license, use), then the ones to skip and why. Shown last, as "Start here" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that missing ids are dropped, licenses/gating/staleness/use are flagged, sizing tiers (fits / quantized / cloud) are produced, memory-sourced picks are marked, and a report is returned. It omits auth, hub-access or rate-limit behavior, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with the useful 'Step 3 of 3' anchor, but the body is a single run-on sentence piling clause upon clause. Most clauses add information, yet the density hurts readability and the retry guidance would read better as a separate sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-annotation, no-output-schema tool it covers the essential ground: what it verifies, what it flags, what it sizes, and what it returns plus the follow-up call loop. A short note on what the returned report contains would complete it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so baseline is 3, and the description adds real meaning beyond the schema: it explains that compute is used to size each model ('sizes each model against the compute') and that recommendation surfaces as 'Start here' shown last. It leaves 'need' and 'components' semantics largely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('checks every picked model and dataset id live on its hub') and situates itself as 'Step 3 of 3', distinguishing it from where_my_hug_search and where_my_hug. An agent can tell exactly what this does without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Step 3 of 3' framing plus the nextAction retry instructions give clear sequencing guidance, and the SEARCH_FIRST/RECALL_REPLACEMENTS loop tells the agent what to do on each outcome. It never names the sibling tools as alternatives, so exclusions are implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.1where_my_hug_verify1 field changedInput schema / properties / recommendationAdded value: +{
+ "description": "What to act on first: the one or two picks worth trying now and why (fit, license, use), then the ones to skip and why. Shown last, as \"Start here\"",
+ "type": "string"
+}where_my_hugwhere_my_hug_searchwhere_my_hug_verifyScored 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.
Find AI models that fit a job from your requirements, sourced benchmarks and real cost.
Find open-weight AI models that fit your hardware, with weight sizes, memory and sources.
Discover available AI models and delegate analysis or code review from your existing agent.
Rent GPUs at live prices and serve any Hugging Face model, with spend caps for AI agents.