Where to set environment variable for mcp-client tutorial?

[dennisnlt]

I am following the tutorial: Gradio as an MCP Client

Where can I set the environment variable after creating the access token such that it can run in the space?
model = InferenceClientModel(token=os.getenv(“HUGGINGFACE_API_TOKEN”))

[John6666]

Since HF_TOKEN is used more often these days, I recommend setting it as a Spaces secret (an environment variable that isn’t visible to others; regular environment variables are visible to others) :

---

Set it in your Hugging Face Space, not in your local shell and not only in your account token page.

For this tutorial, the right place is:

Your Space → Settings → Variables and secrets → New secret

Then your Gradio app can read it with os.getenv(...) at runtime. In a Gradio Space, secrets and variables are exposed to the app process as environment variables. Hugging Face also says tokens belong in Secrets, while non-sensitive config belongs in Variables. (Hugging Face)

At a high level, your Space is the hosted runtime for the MCP client app, so it reads runtime config from its own environment rather than from your laptop.

The exact answer

If your code is:

model = InferenceClientModel(token=os.getenv("HUGGINGFACE_API_TOKEN"))

then create a secret in the Space with this exact key:

HUGGINGFACE_API_TOKEN

and set its value to your Hugging Face access token.

If the key in the Space is different, os.getenv("HUGGINGFACE_API_TOKEN") will return None, and your model client will not authenticate. The name must match exactly. This follows from how Spaces expose secrets as environment variables and how os.getenv(...) reads by key name. (Hugging Face)

Why this is the right place

There are two separate things here:

1. Your Hugging Face account token

You create the token in your account settings. Hugging Face recommends User Access Tokens for authentication. (Hugging Face)

2. Your Space runtime configuration

Your deployed Gradio app does not automatically inherit your laptop’s environment or your account page state. It runs inside the Space runtime. For Gradio and other non-Static, non-Docker Spaces, Hugging Face exposes secrets and variables to the app as environment variables. (Hugging Face)

So the flow is:

1. Create the token in your account.
2. Open the Space where the app runs.
3. Put that token into the Space as a secret.
4. Read it in Python with os.getenv(...). (Hugging Face)

Step by step in the UI

Open your Space and do this:

1. Go to the Space page.

2. Click Settings.

3. Find Variables and secrets.

4. Click New secret.

5. Enter:

   • Key: HUGGINGFACE_API_TOKEN
   • Value: your Hugging Face access token

6. Save.

After that, the Space restarts. Hugging Face documents that changing Space configuration such as secrets triggers an app restart. (Hugging Face)

Secret or variable?

Use a secret.

Hugging Face’s Spaces docs are explicit:

• Variables are for non-sensitive values and are publicly accessible/viewable.
• Secrets are for access tokens, API keys, and other sensitive credentials. Their values are private and are not readable back from the Space settings page once set. (Hugging Face)

Since your Hugging Face token is a credential, it should be a secret, not a variable. (Hugging Face)

Why this tutorial is confusing

The tutorial page itself mixes two different environment variable names.

In one part, the course source says to set the access token with the environment variable HF_TOKEN and shows:

model = InferenceClientModel(token=os.getenv("HF_TOKEN"))

But in the complete example later on the same page, it uses:

model = InferenceClientModel(token=os.getenv("HUGGINGFACE_API_TOKEN"))

Both can work. The key rule is simple:

The secret name in the Space must exactly match the name inside os.getenv(...).

That inconsistency is in the tutorial source itself. (GitHub)

Which name should you use?

Use HF_TOKEN if you want the most standard Hugging Face setup.

Why:

• Hugging Face’s huggingface_hub quick start explicitly says the environment variable HF_TOKEN can be used for authentication.
• It also says this is especially useful in a Space, where you can set HF_TOKEN as a Space secret. (Hugging Face)

So the most conventional version is:

import os
from smolagents import InferenceClientModel

model = InferenceClientModel(token=os.getenv("HF_TOKEN"))

and then in the Space settings, create a secret named:

HF_TOKEN

That is the cleanest option because it matches Hugging Face’s own auth documentation. (Hugging Face)

What to do in your specific case

You have two valid options.

Option A. Keep your current code unchanged

Your current code:

model = InferenceClientModel(token=os.getenv("HUGGINGFACE_API_TOKEN"))

Then create this Space secret:

HUGGINGFACE_API_TOKEN

This works because the names match. The tutorial’s complete example uses that exact pattern. (GitHub)

Option B. Switch to the standard name

Change your code to:

model = InferenceClientModel(token=os.getenv("HF_TOKEN"))

Then create this Space secret:

HF_TOKEN

This is the option I recommend because it aligns with Hugging Face’s official quick start. (Hugging Face)

The background that matters

A lot of confusion comes from treating these as the same thing:

• a token stored on your machine
• a token created in your account
• a token available to a deployed Space

They are not the same.

Locally, you might authenticate with hf auth login or a local environment variable. But when the app is running inside a Space, the Space needs its own runtime secret. Hugging Face says authentication via environment variable or secret has priority, and specifically calls out HF_TOKEN as useful in Spaces. (Hugging Face)

So the deployed Space does not care whether your laptop shell has:

export HF_TOKEN=...

unless you are running the app locally on that same machine. Once deployed, the Space uses its own configured secrets. (Hugging Face)

A safe version of the code

This is the version I would actually use:

import os
from smolagents import InferenceClientModel

hf_token = os.getenv("HF_TOKEN")
if not hf_token:
    raise ValueError("HF_TOKEN is missing. Add it in your Space: Settings → Variables and secrets → New secret")

model = InferenceClientModel(token=hf_token)

This helps because the failure becomes immediate and obvious instead of appearing later as a vague authentication or inference error.

If you want to keep the tutorial’s alternate name, use the same pattern with HUGGINGFACE_API_TOKEN instead. The logic is the same. (GitHub)

One more detail about Space types

Hugging Face distinguishes Space SDKs:

• Gradio / most non-Static Spaces: secrets and variables are exposed as environment variables to the app.
• Static Spaces: values are exposed differently, through client-side JavaScript.
• Docker Spaces: environment handling is documented separately. (Hugging Face)

Since you are following a Gradio MCP client tutorial, the normal os.getenv(...) server-side pattern is the correct one. (Hugging Face)

The clean final recommendation

For the least confusing setup:

1. Create a Hugging Face User Access Token. (Hugging Face)
2. Open your Space.
3. Go to Settings → Variables and secrets.
4. Add a New secret named HF_TOKEN.
5. In code, use:

model = InferenceClientModel(token=os.getenv("HF_TOKEN"))

That is the best match to the official Hugging Face docs and the clearest way to avoid the tutorial’s naming inconsistency. (Hugging Face)

[dennisnlt]

Great Info Thanks!