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.