Hugging Face
Server Details
Connect to Hugging Face Hub and thousands of Gradio AI Applications
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 7 of 7 tools scored. Lowest: 2.9/5.
Most tools have distinct purposes: documentation search/retrieval, repo search/details, file operations, authentication, space search. However, hf_fs is broadly defined and overlaps with hub_repo_search and hub_repo_details, potentially causing confusion.
Tools use mixed prefixes (hf_, hub_) and space_search lacks a prefix. Verb styles vary (fetch, search, etc.). Naming is not fully consistent.
With 7 tools covering documentation, repos, files, spaces, and authentication, the count feels well-scoped for the server's apparent purpose.
The tool set covers reading and searching documentation, repos, and files, but lacks any write operations (e.g., creating repos, uploading files) which are common Hugging Face actions, leaving notable gaps.
Available Tools
7 toolshf_doc_fetchFetch a document from the Hugging Face documentation libraryARead-onlyInspect
Fetch a document from the Hugging Face or Gradio documentation library. For large documents, use offset to get subsequent chunks.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Token offset for large documents (use the offset from truncation message) | |
| doc_url | Yes | Documentation URL (Hugging Face or Gradio) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by explaining chunking behavior with offset, but does not disclose other traits like authentication needs or error responses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence states the purpose, and the second provides actionable guidance. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and chunking behavior. It does not explain return format or error handling, but given the tool's simplicity and lack of output schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds meaning to 'offset' by stating 'use the offset from truncation message,' providing context beyond the schema's description. No other parameters need elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Fetch a document from the Hugging Face or Gradio documentation library,' using a specific verb and resource. It clearly distinguishes from the sibling tool 'hf_doc_search' which is for searching documents, as indicated by the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides contextual guidance for offset usage on large documents, but does not explicitly state when not to use this tool or contrast it with alternatives beyond the implicit distinction from search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hf_doc_searchHugging Face Documentation SearchARead-onlyInspect
Search and Discover Hugging Face Product and Library documentation. Send an empty query to discover structure and navigation instructions. Knowledge up-to-date as at 10 July 2026. Combine with the Product filter to focus results.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Start with an empty query for structure, endpoint discovery and navigation tips. Use semantic queries for targetted searches. | |
| product | No | Filter by Product. Supply when known for focused results |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnly and openWorld hints. Description adds temporal knowledge boundary ('up-to-date as at 10 July 2026') and the ability to use empty query for navigation. No contradictions. Could mention result format, but not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value: purpose, usage tip, date and filter advice. No fluff. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool without output schema, it covers main points: what it searches, how to discover structure, and how to filter. Could mention that results are summaries/links, but not required given typical search patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters fully. Description adds strategic guidance: empty query for structure and product filter for focus. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches and discovers Hugging Face documentation. The empty query tip distinguishes it from other tools like hf_doc_fetch (likely for specific doc retrieval). Purpose is specific verb+resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage guidance: 'Send an empty query to discover structure' and 'Combine with the Product filter to focus results.' Lacks explicit exclusions or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hf_fsHugging Face FilesCRead-onlyInspect
List, read, find, or search Hugging Face repos, buckets, files, collections, and papers.
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | ||
| uri | Yes | Hugging Face URI in the form hf://models|datasets|spaces|buckets/OWNER[/NAME[/PATH]] or hf://collections[/OWNER[/SLUG]] or hf://papers[/ARXIV_ID[/PATH]]. | |
| glob | No | ||
| name | No | find glob matched against entry name/basename. | |
| path | No | find glob matched against entry path relative to the requested URI. | |
| sort | No | Sort for discovery listings/search. Use hf://papers/trending for the paper trending view; other sort values are provider-specific. | |
| limit | No | ls/search max result size. ls default 1000; ls hf://papers uses limit for its recent-paper sample (default 10, capped at 100) in addition to structural entries; paper batch and trending listings default to and are capped at 100; search default 100. | |
| query | No | Search query for hf://models, hf://datasets, hf://spaces, hf://collections, or hf://papers. | |
| offset | No | cat read start offset. | |
| max_bytes | No | cat max read length. 0 means the maximum allowed 80000 bytes. | |
| recursive | No | ||
| entry_type | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| op | Yes | |
| lfs | No | |
| uri | Yes | |
| url | No | |
| path | No | |
| size | No | |
| type | No | |
| bytes | No | |
| exists | No | |
| content | No | |
| entries | No | |
| arxiv_url | No | |
| namespace | No | |
| truncated | No | |
| target_uri | No | |
| next_offset | No | |
| content_type | No | |
| published_at | No | |
| daily_papers_uri | No | |
| daily_papers_date | No | |
| truncation_reason | No | |
| truncation_message | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe, read-only tool. The description adds no additional behavioral context (e.g., error handling, rate limits, or specific constraints beyond schema). With annotations present, the description meets a baseline but does not enhance transparency beyond what is already provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise but overly brief for a complex tool with 12 parameters and multiple operations. It lacks structure (e.g., separating operation types) that would help an agent parse it. It is not verbose, but the brevity reduces clarity given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema and schema descriptions covering 67% of parameters, the description omits crucial operational details (e.g., explanations of ls, cat, stat, find, search modes; default behaviors; or examples). For a tool with such breadth, the description feels incomplete, leaving the agent to infer usage from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 67% of parameters with descriptions, which already provides substantial meaning. The high-level description ('List, read, find, or search') does not add specific parameter-level insights. For a tool with 12 parameters and multiple enums, additional param semantics in the description would be beneficial, but the current level is minimally adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists specific verbs ('List, read, find, or search') and resources ('Hugging Face repos, buckets, files, collections, and papers'), which clearly defines the tool's scope. However, it does not differentiate this tool from siblings like hub_repo_search or space_search, which may overlap in functionality, reducing clarity for an AI agent deciding between tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings or when to choose among its own operations (ls, cat, stat, find, search). There are no explicit context signals or exclusions, leaving the AI agent without sufficient information to make a correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hf_whoamiHugging Face User InfoARead-onlyInspect
Hugging Face tools are being used anonymously and may be rate limited. Call this tool for instructions on joining and authenticating.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description adds context about anonymous usage and rate limits. No contradictions. It discloses the tool's role in providing authentication instructions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with important note about anonymous usage, no wasted words. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with no output schema, the description sufficiently explains the purpose and conditions. It could mention what the output contains, but it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (0 params), so the baseline score is 4 per guidelines. The description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Call this tool for instructions on joining and authenticating,' which is a specific verb+resource. It distinguishes from sibling tools that focus on docs, repos, and spaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the context (anonymous usage, rate limits) and directs when to use the tool (for authentication instructions). It does not explicitly state when not to use, but the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hub_repo_detailsARead-onlyInspect
Get details for one or more Hugging Face repos (model, dataset, or space). Auto-detects type unless specified. For datasets, use operations: overview, dataset_structure, dataset_preview. Use dataset_structure first to discover configs, splits, sizes, and schema. Use dataset_preview only when config and split are known, unless the dataset has a single config/split.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Row count for dataset_preview. Defaults to 5 and is clamped to 1-100. | |
| split | No | Dataset Viewer split. Required for dataset_preview when the dataset has multiple config/split options. Discover via dataset_structure. | |
| config | No | Dataset Viewer config. Required for dataset_preview when the dataset has multiple config/split options. Discover via dataset_structure. | |
| offset | No | Row offset for dataset_preview. Defaults to 0. | |
| repo_ids | Yes | Repo IDs for (models|dataset/space) - usually in author/name format (e.g. openai/gpt-oss-120b) | |
| repo_type | No | Specify lookup type; otherwise auto-detects | |
| operations | No | Details to return. Defaults to ["overview"]. For datasets, prefer ["overview", "dataset_structure"] first; then call ["dataset_preview"] with config and split. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is clear. The description adds context about auto-detection and operation ordering, which is valuable beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet informative, with no wasted words. It front-loads the main purpose and then provides targeted detail for dataset usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description covers key usage scenarios and workflows. It doesn't repeat schema details but adds essential behavioral context. Some minor gaps (e.g., what overview returns for models/spaces) are acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% parameter description coverage, but the description adds workflow context for parameters like operations, config, and split, explaining their interplay and defaults (e.g., limit defaults to 5, offset defaults to 0).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details for one or more Hugging Face repos, auto-detects type, and differentiates from sibling tools like hub_repo_search by focusing on specific repo details rather than search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use dataset_structure vs dataset_preview, and implies the default operation is overview. It sets a clear workflow for dataset operations, helping the agent choose the right approach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hub_repo_searchRepo SearchARead-onlyInspect
Search Hugging Face repositories with a shared query interface. You can target models, datasets, spaces, or aggregate across multiple repo types in one call. Use space_search for semantic-first discovery of Spaces. Include links to repositories in your response.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order (descending): trendingScore, downloads, likes, createdAt, lastModified | |
| limit | No | Maximum number of results to return per selected repo type | |
| query | No | Search term. Leave blank and specify sort + limit to browse trending or recent repositories. | |
| author | No | Organization or user namespace to filter by (e.g. 'google', 'meta-llama', 'huggingface'). | |
| filters | No | Optional hub filter tags. Applied to each selected repo type (e.g. ["text-generation"], ["language:en"], ["mcp-server"]). | |
| repo_types | No | Repository types to search. Defaults to ["model", "dataset"]. space uses keyword search via /api/spaces. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already indicating readOnlyHint, openWorldHint, and destructiveHint, the description adds behavioral context: it can aggregate across multiple repo types, uses keyword search for Spaces, and instructs to include links. It could further disclose pagination or result format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, alternative tool instruction, and a response guideline. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description and schema together provide adequate context for a search tool. It covers when to use, parameters, and cross-type behavior. Missing details on output structure (pagination, fields) but acceptable given the schema's thoroughness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 6 parameters (100% coverage). The description reinforces that query, author, filters work across repo types and that limit is per type, but adds little beyond the schema's own parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches Hugging Face repositories with a shared query interface, targeting models, datasets, or spaces. It effectively distinguishes from the sibling tool space_search, which is for semantic-first discovery of Spaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on using space_search for Spaces instead of this tool, and instructs to include links. However, it does not mention when to use hub_repo_details for single-repo details or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
space_searchHugging Face Space SearchARead-onlyInspect
Find Hugging Face Spaces using semantic search. IMPORTANT Only MCP Servers can be used with the dynamic_space toolInclude links to the Space when presenting the results.
| Name | Required | Description | Default |
|---|---|---|---|
| mcp | No | Only return MCP Server enabled Spaces | |
| limit | No | Number of results to return | |
| query | Yes | Semantic Search Query |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's 'semantic search' adds minimal behavioral context. No additional traits like auth, rate limits, or return format are disclosed. The bar is lower due to annotations, but the description doesn't significantly enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences plus a note) but contains a typo (missing space between 'tool' and 'Include'). It is front-loaded with the primary purpose and includes an important usage note, though the sentence structure could be improved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, but the description implies results include links. Given the tool's simplicity and good parameter annotations, the description is adequate but could be more explicit about return structure (e.g., list of space objects).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds value by linking the 'mcp' parameter usage to the dynamic_space tool, clarifying that only MCP-enabled spaces should be used with dynamic_space. This goes beyond the schema description of 'Only return MCP Server enabled Spaces'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds Hugging Face Spaces using semantic search, with a specific verb 'find' and resource 'Hugging Face Spaces'. It distinguishes from siblings like hub_repo_search (repos) and paper_search (papers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (e.g., 'semantic search' and linking to Spaces) but lacks explicit guidance on when to use this tool versus alternatives. It mentions that only MCP Servers can be used with dynamic_space, which is indirect guidance for result filtering, but no clear when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!