How to connect Hugging Face to Hermes Agent

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.

Reconnect Hugging Face from the dashboard, then start a fresh chat if the runtime still has the old tool catalog loaded.

Hugging Face tool schemas load on demand the first time a tool runs and are cached after that, so this error usually clears on its own: wait a few seconds and retry the same request. If every Hugging Face call keeps failing with it in a fresh chat, reconnect from the dashboard, and contact support if it still persists — that pattern points to a configuration problem on our side, not something you can fix by reconnecting again.

Two usual causes. The connected account may not have access to the specific workspace, inbox, store, or project in the request — check that first. If access looks right, the agent may have sent a placeholder value (like "YOUR_ID" or an example id from documentation) instead of a real one: ask it to run a list or search tool first, then retry the action with a real id from those results. Most failures at this stage are one of these two, not ClawLink bugs.

The engine-taught causes for this error are manual-token causes: a missing token, a misformatted one, an expired one, or one with too little permission. In the hosted flow two of those still apply and two change shape. If the token was deleted, rotated, or expired on Hugging Face after you pasted it, every tool fails from that moment and re-pasting the current token in the dashboard is the fix. If the token is fine but the account shows connected and the tool still 401s, the usual hosted-flow culprit is a token of the wrong type or scope for what you asked: a read token cannot call a write tool, and a fine-grained token hits 401 on repos outside its allowed list. Ask the agent to quote the exact error and which tool produced it before touching the connection.

Ask the agent to diagnose it:

Call hugging_face_get_model_info on a public model I name and quote the exact error string. Then tell me which token type you believe this connection uses. Do not retry the failing tool yet.

Hugging Face's permission model is two things: token scope and repo access. A token with read scope 403s on write actions, and a fine-grained token 403s outside the repos it names. Separately, gated repos return 403 to any token that has not been granted access: the fix there is hugging_face_create_ask_access, which files the request with the repo owner, not a re-paste of the token. The hosted-toolkit causes still apply on top: a placeholder id from documentation fails like a real permission error, and a model or dataset in a private org the token was not issued for is a genuine access boundary. Have the agent distinguish "this token lacks scope" from "this repo is gated" by quoting the error, because the two fixes are opposite.

Ask the agent to diagnose it:

Call hugging_face_get_model_info on the exact model that failed, then hugging_face_get_model_tags_by_type on the same name. Quote both errors and say whether the repo looks gated or the scope looks wrong. Do not create any access requests yet.

Hugging Face rate limits by tier, and an agent enumerating a large dataset or fanning out inference calls is the traffic shape that meets the limit: many calls, one allowance. The response is not to retry in a tight loop, which digs the hole deeper, but to change the work's shape: read dataset statistics instead of rows, page through results instead of pulling everything, and spread a long inference job across turns. The 429 response usually carries the retry timing, so have the agent report it and wait rather than guess.

Ask the agent to diagnose it:

Tell me how many Hugging Face calls you made in the last minute and what you were iterating over. Quote the 429 body. Do not call Hugging Face again until I reply.

The engine-taught causes for this symptom are all self-hosted MCP mechanics: a stale client, a missing token in a config file, a transport failure. None of those can happen here, because there is no local MCP server to go stale. The real causes are the two hosted ones: the connection or pairing is incomplete (confirm the plugin installed with --enable, both pairing commands ran, and Hugging Face shows as connected), or schemas loaded on demand, so the first Hugging Face call in a fresh session can arrive before the catalog and needs one retry. If most tools work and one name fails, that name is wrong rather than missing, and the error lists the closest real ones.

Ask the agent to diagnose it:

List the Hugging Face tools you actually have access to. If there are none, say so plainly. If there are, tell me which one returns a model's info and use that exact name.

Double-check that the API key for Hugging Face has the right scopes or account access. A valid key can still be too limited for some reads or writes.

Yes. ClawLink is the fastest way to connect Hermes to Hugging Face: link your Hugging Face account once in the browser and Hermes Agent can call the Hugging Face API through 135 ready-made tools — no custom code or token handling.

Install the plugin with hermes plugins install ClawLink-HQ/hermes-plugin --enable, then pair once: run hermes clawlink begin, approve the link in your browser, and run hermes clawlink finish. Connect Hugging Face in the dashboard and Hermes can use it from the next message — no config files, and the Hugging Face key you paste is stored server-side instead of in your environment.

About two minutes. Sign in, click Connect next to Hugging Face in the dashboard, authenticate, and Hermes Agent can use it from the next chat message.

The alternative to ClawLink is usually manual API key setup plus your own token handling, permission troubleshooting, and tool plumbing for Hermes Agent. That is fine if you want to build and maintain the integration yourself. Most teams just want Hugging Face working from chat.

You paste a Hugging Face access token once on the hosted setup page, and ClawLink stores and uses it server-side. The agent calls the Hugging Face tools through the hosted connection, so the token value never lands in Hermes's environment, its config, or its logs, and never sits in a .env file on a machine you happen to have used. This is the exact "backend token broker" arrangement that ChatGPT independently describes as the ideal answer to using Hugging Face without managing your own token, applied to a page that ships it. Rotating the token on Hugging Face and re-pasting it in the dashboard is the whole maintenance story.

No, and it is worth being clear about the split. This integration gives the agent tools that act on the Hub: reading model cards and tags, dataset statistics and rows, spaces metadata, collections, discussions, and daily papers, plus asking for access to gated models. Running inference is a different connection: that is the model-provider reading of "Hermes + Hugging Face", configured in Hermes itself with an inference token. The two can coexist, but they are not the same integration, and the error that follows a wrong assumption is usually a token error on one side while the other works fine.

The Hub's research surface, mostly read-first: model info and tags, dataset validity, statistics, first rows, and size, collections, discussions, and the daily papers feed, plus embeddings and chat completions through the inference side of the API. The write surface is where to be careful: creating collections, asking for access to gated models (hugging_face_create_ask_access), and dataset uploads are real actions on shared objects. A research workflow barely touches the writes; a publishing workflow should confirm each one before the agent does it.

Whatever your token carries. Hugging Face access tokens come in three flavors: read, write, and fine-grained, where fine-grained tokens can be limited to specific repos or scopes. The tools act as your token, so a read token cannot create a collection or upload dataset rows, and a token without access to a gated repo gets the same 403 the repo's gate produces. Pasting a fine-grained token scoped to what the agent should touch is the least-privilege setup, and it is fully supported here since the token is passed through as-is.

The safety answer is a credential-scope answer. The secret is held server-side and never written to a machine-local file, which removes the environment-file leak path that most Hugging Face agent guides teach. What is left is normal token hygiene: use a fine-grained token limited to the repos the agent genuinely needs, keep a read token for research-only work, and revoke or rotate from the ClawLink dashboard the moment you stop trusting a session. None of this stops an agent from being told to read something it has access to, so scope the token to the smallest surface that does the job.

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.