Skip to main content
Glama
bikemeardsley

Where My Hug At?

by bikemeardsley
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Where my hug at?

where_my_hug

Collect missing compute, license, stack, and data details before recommending Hugging Face models, then return a plan to split your ML need into parts and search each one.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoTraining data there is or could be, such as "none" or "about 300 labeled photos"
needYesThe ML need in plain words: what goes in, what should come out, and what it is for
stackNoWhat will call the model: language, runtime, framework
computeNoThe 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
licenseNoWhat the result may be used for, such as "commercial, closed source" or "research only"

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools