Financial data international cyber guaranteed security

.

ücreti yatırmama rağmen pro üyeeliğim aktif değil

This MCP server can't be used by ChatGPT to search information because it doesn't implement our specification: search action not found
https://platform.openai.com/docs/mcp#create-an-mcp-server

Please add to your MCP Server "search" and "fetch" tools according to OpenAI MCP specification.

This MCP server can't be used by ChatGPT to search information because it doesn't implement our specification: search action not found
https://platform.openai.com/docs/mcp#create-an-mcp-server

Please add to your MCP Server "search" and "fetch" tools according to OpenAI MCP specification.

Hi @markba , this update is in our plans and should come soon 👍 cc @evalstate

not good

how can i get gemini-cli to connect to this mcp server?

Hi @bivalve -- have you followed the instructions for connecting Gemini here: https://github.com/google-gemini/gemini-cli/blob/main/docs/tools/mcp-server.md ? Can you say more about the error you are seeing?

1. https://huggingface.co/learn/mcp-course/unit1/hf-mcp-server#get-started bullet 2 promises Zed but there is no Zed option provided

Fails in VScode , Kiro

I have claude connected to Hugging face connector and when trying to use HF to generate an image coming back with this:
"The problem is clear: The Hugging Face MCP connector in your Claude setup has gradio=none configured, which completely blocks all image generation invocations regardless of which space I try to use."
I don't see a way to change this, can anyone help?

I'm having the same problem as @jj210tx after following this guide https://huggingface.co/blog/claude-and-mcp

I have claude connected to Hugging face connector and when trying to use HF to generate an image coming back with this:
"The problem is clear: The Hugging Face MCP connector in your Claude setup has gradio=none configured, which completely blocks all image generation invocations regardless of which space I try to use."
I don't see a way to change this, can anyone help?

Hi @jj210tx @gqbit -- Anthropic updated their content policy so the connector by default has images disabled. If you "add a custom connector" instead, you can use the URL https://huggingface.co/mcp?login and all should work normally.

I have claude connected to Hugging face connector and when trying to use HF to generate an image coming back with this:
"The problem is clear: The Hugging Face MCP connector in your Claude setup has gradio=none configured, which completely blocks all image generation invocations regardless of which space I try to use."
I don't see a way to change this, can anyone help?

Hi @jj210tx @gqbit -- Anthropic updated their content policy so the connector by default has images disabled. If you "add a custom connector" instead, you can use the URL https://huggingface.co/mcp?login and all should work normally.

This works but it should be noted that Custom Connectors require a paid Claude plan.

Remove gradio_none

Can’t configure through Claude code

nothing happened when claude mcp add hf-mcp-server -t http "https://huggingface.co/mcp?login"

can you just remove claude code to prevert someone poor tried many times?

Love it

Why is IBM Bob not listed as an MCP Client option?

One bit of feedback from operating MCP/tool-using agents: the next layer that feels important is a consistent run record around tool calls.

For example, when an assistant calls an HF MCP tool, it would be useful for the host/client to preserve:

• run/session id
• user turn id
• tool call id
• host/client name + version
• selected MCP server/tool
• input/output metadata
• approval state if any
• final artifact or action

The big thing I would avoid is treating the model's explanation as authorization evidence. It is useful context for review, but policy should come from deterministic metadata: user/session, tool metadata, scopes, environment, and approval state.

This is the same direction we are exploring with Armorer for local/self-hosted agents: make runs, tools, approvals, and artifacts inspectable instead of leaving agent execution as an opaque chat transcript.
https://github.com/ArmorerLabs/Armorer

Curious if HF MCP already has a preferred place for this kind of audit/run metadata, or if it is expected to live entirely in the host application for now.

Hugging Face MCP

This discussion is dedicated to providing feedback on the HF MCP.

About HF MCP

The Hugging Face Model Control Protocol (MCP) is a new server that enables seamless integration between the Hugging Face Hub and any AI assistant that supports MCP, such as VSCode, Cursor, or Claude Desktop. It provides a standardized way for assistants to access and interact with Hugging Face tools and resources, including Spaces, semantic search in Papers, and model or dataset exploration. Additionally, MCP allows assistants to connect to any compatible Gradio app, extending their capabilities with machine learning-powered applications developed by the community.

This feature is experimental ⚗️ and will continue to evolve

Let us know what you think 💬👇

Small terminology correction: the About section currently expands MCP as “Model Control Protocol”. Hugging Face’s current MCP documentation and the protocol’s own documentation use “Model Context Protocol”. Updating that sentence would avoid confusion for readers comparing this discussion with the current server documentation.

Building on @armorerlabs ' point about a consistent run record — that field list matches what we ended up with almost exactly, but I'd add one constraint we only found by getting it wrong: a run record is worth exactly as much as the thing that signs it.

If the host writes run_id / tool_call_id / client / server / tool / approval_state, and the operator can also write them, an audit trail is a formatted claim. On the GitHub side this is solved without any shared secret: the Actions runtime mints a short-lived OIDC token the workflow author cannot forge, so a third party can verify that a run really happened, in that repo, at that time.

The gap worth flagging to the HF team: there is no equivalent pointing outward from the Hub. Trusted Publishers runs the other direction (CI provider token -> Hub token), which is the right primitive aimed the wrong way for this. Today a Space has no way to prove to any third party that it executed a given run. The only available evidence is the Space owner's own word — which is exactly the situation the fabricated-benchmark threads keep circling back to.

Two shapes that would help, cheapest first:

• a signed "this Space executed" receipt endpoint, even with no per-call detail;
• or an OIDC issuer on the Hub whose tokens carry space_id, run_id and a timestamp, verifiable by anyone against a public JWKS.

Either lets external tooling distinguish "this Space reports that it ran" from "this Space ran". Without one, every reliability claim about Hub-hosted agents is self-reported by construction.

Disclosure: I'm downstream of this. aiopsenabler.com keeps public run records for agents, and the absence of this primitive is the reason Hub-hosted agents can't reach the same evidence level as CI-hosted ones on our side — so I'd rather see it exist than work around it.

The Hugging Face ChatGPT/Codex connector advertises model_search,
dataset_search, space_search, paper_search, hf_doc_search and
hf_doc_fetch, but these calls fail with:
“MCP tool ... was not returned by tools/list”.

hub_repo_details, hf_whoami and read-only hf_jobs/ps work.
Public searches through the current hub_repo_search and hf_fs
tools also work directly from our VPS.

Please update the connector's published tool catalog/bindings,
preserving existing OAuth grants, scopes and active sessions.
Please provide the supported procedure for refreshing the tools
in an existing ChatGPT/Codex conversation without disconnecting
the account.

**Sol 6.1 Max feedback

https://ca.linkedin.com/in/aissa-mohammedi-2308743b2?trk=public_post_feed-actor-name

Protocole "SQUELETTE" (Systemic Skeleton Protocol)

Ce protocole définit comment un modèle léger (Phi-3 Mini) orchestre un système complexe écrit dans des langages rares (Rust, JAX, C++), sans jamais "halluciner" la structure du code.

1. Le Principe Fondamental : "Le Squelette avant la Chair"

Le LLM (Phi-3 Mini) n'écrit pas la logique métier complexe. Il génère et valide uniquement le squelette structurel (les signatures de fonctions, les interfaces, les points d'entrée). La logique interne est ensuite remplie par des modules déterministes ou des humains. Cela garantit que le système ne "ment" pas sur son architecture.
2. Le Rôle de Phi-3 Mini (Le Squelette)

Phi-3 Mini est un modèle de 3.8B paramètres, extrêmement léger (1.8 Go quantifié en 4-bit) et capable de tourner localement sur un appareil mobile . Dans ce protocole, il est utilisé pour :

Générer les Stubs : Créer les fichiers vides avec les bonnes signatures (ex: une fonction fn process_data(input: &[f32]) -> Result<Vec<f32>, Error> en Rust).

Valider les Types : Vérifier que les échanges de données entre JAX (Python) et C++ (Rust) respectent les types définis.

Router les Requêtes : Décider quel module (Rust, JAX, ou C++) doit être appelé en fonction du prompt utilisateur.

3. L'Architecture Multi-Langages (Le Corps)

Pour connecter ces langages rares de manière légère et sans surcharge, on utilise des standards d'interopérabilité éprouvés.

Le Cœur (C++) : Utilise Apache TVM FFI. C'est une ABI (Application Binary Interface) ouverte et minimale conçue pour l'interopérabilité zéro-copie (zero-copy) entre Python, C++ et Rust. Elle supporte nativement JAX via le protocole DLPack . C'est le pont idéal pour ton architecture.

Le Calcul (JAX) : JAX est utilisé pour les calculs tensoriels et la différenciation automatique. Il est connecté au C++ via TVM FFI .

La Performance (Rust) : Rust gère la sécurité mémoire et la logique système. Il peut appeler du code C++ via des bindings FFI, ou utiliser des crates comme jax-rs pour une intégration directe avec JAX (bien que cette crate soit orientée WebGPU/WebAssembly) .

L'Interopérabilité C++/JAX : Le projet Enzyme-JAX permet d'intégrer du code C++ directement dans JAX pour la différenciation automatique, via le framework MLIR .

4. Le Protocole de Codage (Les Règles)

Voici les étapes exactes pour qu'un agent (ou toi) code dans ce système :

Définition du Contrat (Phi-3 Mini) : Tu donnes un prompt à Phi-3. Il génère un fichier contract.json qui définit les types d'entrée/sortie, les noms de fonctions, et le langage cible.

Génération du Squelette (Phi-3 Mini) : À partir du contrat, Phi-3 génère les fichiers de stub vides dans les langages cibles. Par exemple, un fichier .rs avec les signatures, un fichier .py avec les décorateurs @jax.jit vides.

Implémentation (Humain/Agent) : La logique est remplie. Le code doit impérativement respecter le squelette généré.

Validation (Déterministe) : Un script de validation (basé sur le contract.json) vérifie que les signatures sont intactes et que les types sont compatibles. Si une erreur est détectée, le code est rejeté. Le LLM ne valide jamais la logique, il valide la structure.

5. La Légèreté (La Contrainte)

   Phi-3 Mini : 3.8B paramètres, quantifié en 4-bit, il tient dans 1.8 Go de RAM et tourne sur un téléphone .

   TVM FFI : Conçu pour être "minimal" et "ultra low-overhead" .

   Enzyme-JAX : Utilise MLIR pour optimiser le code, évitant ainsi les surcharges inutiles .

En résumé, tu construis un système où Phi-3 Mini est le chef d'orchestre léger, et où C++, JAX, et Rust sont les musiciens, connectés par des interfaces standards (TVM FFI, MLIR) pour garantir que personne ne joue faux.