Summary: Turns a plain-language ML need into a verified, hardware-sized shortlist of real Hugging Face models and datasets, marking each part of the job as use, tune, train, or write code.
Ask the right questions first — where_my_hug takes your need (plus optional compute, license, stack, and data) and, if any are missing, returns the questions to ask you before recommending anything.
Split a job into parts — returns a method for breaking the need into input→output parts, flagging the ones that aren't a model's job (parse, rules, lookups) as WRITE.
Search Hugging Face four ways per part — where_my_hug_search runs up to 6 parts, each with a task tag, a phrase, and up to 3 name keywords, covering most-downloaded, trending, name matches, and model/dataset card text.
Give a verdict per part — USE an existing model, TUNE a close one, TRAIN from scratch, or WRITE plain code, with a rationale.
Verify every pick live — where_my_hug_verify checks each model/dataset id on Hugging Face, drops the ones that don't exist, and asks for replacements when needed.
Flag what would bite later — gated repos, missing/non-commercial/custom licenses, stale (2+ years), and little-used (under 100 downloads/month) picks.
Size picks against your hardware — memory to run, QLoRA vs. full fine-tune cost, whether a model fits, is a 4-bit stretch, or needs cloud (with hosting providers named).
Show its work — marks picks that came from memory rather than search, and lists what the search found but wasn't picked.
Return a report to show the user — a live-checked, dated recommendation, including alternatives bigger than your compute.
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 for each part of the job and tells you which parts already exist there: which are an exact fit, which to fine-tune, which to train, and which are just code. Every model it names is real, current, and sized for your hardware.
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 on Hugging Face 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:
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.
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 on Hugging Face, live. Any that don't exist are dropped, and the agent goes back to the search for others. The rest are flagged for what would bite later and sized against your compute, and that report is what you see. 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 Hugging Face.
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 | Hugging Face didn't answer (down, rate-limited). The id is kept, and asked again next time. |
GATED | You must accept its terms on Hugging Face 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. |
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-14 for one 24 GB GPU (abridged):
_Searched and checked on Hugging Face just now: 7 named, 1 from memory rather than the search, 0 not there and dropped._
## USE · Read the card
**Model: zai-org/GLM-OCR**
license mit · 1.3B parameters (~3.2 GB to run) · 1.7M downloads a month · found: name has ocr, most downloaded for image-to-text
If you can make it work, bigger than one 24 GB GPU:
- Qwen/Qwen3.8-27B: a stretch: ~66.7 GB to run, ~16.7 GB quantized to 4 bits, hosted by novita, cerebras, …
- google/gemma-4-31B-it: a stretch: ~75.1 GB to run, ~18.8 GB quantized to 4 bits, hosted by novita, …
Also: deepseek-ai/DeepSeek-OCR
The search also found, not picked:
- google/gemma-4-26B-A4B-it (11.3M downloads a month): found as most downloaded for image-text-to-text
- openbmb/MiniCPM-V-4.7-35B-A3B (4.2k downloads a month): found as trending for image-text-to-text
## TUNE · Read the hard hands
**Model: microsoft/trocr-base-handwritten**
license mit · 333.3M parameters (~0.8 GB to run; to fine-tune, ~0.3 GB with QLoRA, ~5.3 GB in full) · found: name has handwritten
**Data: Voxel51/iam_handwriting_finevision**
license cc · 1.9k downloads a month · found: name has handwriting
Also: Teklia/IAM-line (stale, from memory)
## WRITE · Parse the amounts
No model: write this one.Every model there was turned up by the search, including ones released this year. The one dataset the agent added from what it remembered is marked.
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.
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 token is sent only there 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.
Report a vulnerability privately through GitHub Security Advisories, not a public issue. SECURITY.md lists what it touches: GETs to Hugging Face, and nothing on your machine.
node src/server.ts # the server, straight from source
npm test # offline: Hugging Face 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 Hugging Face 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 for each with where_my_hug_search, and decide from what it finds which parts Hugging Face covers (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 full burden. It does disclose behavior worth knowing — that it may return questions instead of a result, and that it returns a method — but says nothing about side effects, idempotency, auth, or rate limits for what is essentially an advisory/stateless tool.
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-loads the critical 'Step 1 of 3' framing and stays to one dense paragraph with no filler. It is slightly run-on and the inline quote-upset ('"unknown" is fine') interrupts flow, but every clause is functional.
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 no annotations, so the description must explain returns — which it does, describing both the clarifying-questions branch and the method branch. It positions the tool correctly within a 3-step sibling workflow, leaving only edge-case behavior unspecified.
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 description coverage is 100% and every parameter (need, data, stack, compute, license) is documented in-schema with examples. The description only gestures at which fields matter ('compute, license, stack or data') without adding format or semantics beyond the schema, so the baseline 3 applies.
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?
Despite a cryptic name, the description states the tool's role: 'Step 1 of 3, before recommending any Hugging Face model or dataset,' and explains it returns clarifying questions and then a method. It distinguishes itself from the sibling search tool by naming where_my_hug_search as the next step.
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 gives an explicit trigger ('before recommending any Hugging Face model or dataset') and instructions for the follow-up call ('call again with the answers, "unknown" is fine'). The alternative is named and incorporated into the workflow, though where_my_hug_verify is not addressed.
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 models, names holding each keyword, and the text of model and dataset cards. Returns what it found, with downloads, likes, license, 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 provided, the description carries the full behavioral burden. It does disclose search scope (downloaded/trending models, name matches, card text) and the returned fields (downloads, likes, license, age, how each turned up), which is genuinely useful. It says nothing about read-only guarantees, rate limits, latency, or failure modes, leaving notable behavioral gaps.
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 the pipeline position ('Step 2 of 3') and follows with the search scope, return payload, and next call in a compact run. It is dense but every clause carries information; the third sentence's sequencing instruction is the only piece that borders on filler.
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?
With no output schema, the description correctly spells out what comes back (downloads, likes, license, age, provenance of each hit) and how the result is to be used (pick verdicts and candidates). Combined with the pipeline sequencing, an agent has enough to call it and consume the response, though it lacks any note on limits or error behavior.
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 description coverage is reported at 0%, and the required id/name sub-fields are undocumented, so the description must compensate. It partially does by explaining that search happens 'for each part of the need' and naming what is looked up per part, but the nested task/phrase/keyword semantics are left to the schema's own descriptions rather than being expanded here.
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 (searches) and resource (Hugging Face), and enumerates the three search modes: most-downloaded/trending models for the task, names holding each keyword, and card text. It positions itself as 'Step 2 of 3' with a named successor, but it never distinguishes itself from the sibling where_my_hug (presumably step 1), so the agent can't fully tell the two apart.
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?
Explicitly places itself as step 2 of a 3-step pipeline and names the follow-up call ('Then call where_my_hug_verify'), which is clear routing guidance. It offers no when-not-to-use condition or alternative path, so it stops short of full usage coverage.
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 Hugging Face, 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, 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses that missing ids are dropped, that licenses/gating/staleness/low-use are flagged, how sizing outcomes (fits, quantized stretch, cloud, host) are derived, and that unpicked finds are surfaced. It is silent on auth needs (e.g. HF token for gated repos), rate limits, and error behavior, so it is not exhaustive.
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 3 of 3' and dense with concrete behavior – nearly every clause carries information. The single run-on sentence listing eight separate actions is harder to scan than it needs to be, which keeps it out of the top band.
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 complex pipeline tool with no annotations and no output schema, the description explains process behavior but never describes the report it returns beyond 'the report to show the user', and it references nextAction without enumerating its possible values or the full decision tree. The agent is left guessing at the response shape.
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 description coverage is 67%, so the schema already documents most fields. The description only touches 'compute' sizing implicitly; it says nothing meaningful about how 'need' or the nested 'components' payload should be constructed, so it adds little beyond 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?
Names a specific verb and resource – it verifies picked model/dataset ids live on Hugging Face – and enumerates the concrete checks it performs (existence, license, gating, staleness, low use, compute fit, memory-sourced picks). The 'Step 3 of 3' framing plus the sibling tools where_my_hug and where_my_hug_search make its place in the pipeline unmistakable.
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' label and the instruction to follow nextAction when it is SEARCH_FIRST or RECALL_REPLACEMENTS tell the agent when this tool runs and that it may need to be called repeatedly. There is no explicit statement of when not to use it or which alternative to prefer, so it stops short of a 5.
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.
where_my_hugwhere_my_hug_searchwhere_my_hug_verifyScored across 3 tools
Each tool is explicitly labeled as a distinct step (1 of 3, 2 of 3, 3 of 3), so the workflow boundaries are clear. The very similar names (where_my_hug vs where_my_hug_search vs where_my_hug_verify) create mild risk of misselection, but the step annotations largely resolve it.
All tools use snake_case with a consistent shared prefix and stage-descriptive suffixes (search, verify), forming a predictable family pattern. The base tool 'where_my_hug' lacks an action suffix, a minor deviation from the otherwise uniform verb-style naming.
Three tools map cleanly onto a three-stage pipeline (gather context, search, verify), and each stage earns its place. The set is slightly thin but appropriate for a focused, linear recommendation workflow rather than a broad CRUD domain.
The surface covers the full decision lifecycle for its purpose: eliciting requirements, searching Hugging Face, verifying live existence/licenses/compute fit, and producing a report. No obvious dead ends, though there is no explicit tool for comparing or ranking multiple candidates in depth.
Find AI models that fit a job from your requirements, sourced benchmarks and real cost.
Discover available AI models and delegate analysis or code review from your existing agent.
Free enterprise-grade due diligence for your app, run by your coding agent. Then the full SDLC.
Your AI dev team: agents that build, test, review and ship, each on its own cloud machine.