Sketchfab MCP Server
Servidor MCP de Sketchfab
Un servidor de Protocolo de Contexto de Modelo (MCP) para interactuar con la plataforma de modelos 3D de Sketchfab. Este MCP permite buscar, ver detalles y descargar modelos 3D de Sketchfab directamente a través de Claude o Cursor.
Características
Búsqueda de modelos 3D : encuentre modelos en Sketchfab usando palabras clave, etiquetas y categorías
Ver detalles del modelo : Obtenga información completa sobre modelos específicos
Descargar modelos : Descarga modelos en varios formatos (gltf, glb, usdz, source)
Related MCP server: meshy-mcp
Prerrequisitos
Node.js 18 o superior
Una clave API de Sketchfab (para autenticación)
Instalación
Clonar este repositorio
Instalar dependencias:
npm installConstruir el proyecto:
npm run build
Uso
Ejecución del servidor MCP
npm startPara proporcionar su clave API de Sketchfab, utilice el parámetro --api-key :
node build/index.js --api-key YOUR_API_KEYAlternativamente, puede configurar la variable de entorno SKETCHFAB_API_KEY :
export SKETCHFAB_API_KEY=YOUR_API_KEY
npm startHerramientas disponibles
1. búsqueda en sketchfab
Busque modelos 3D en Sketchfab según palabras clave y filtros.
Parámetros:
query(opcional): consulta de búsqueda de texto (por ejemplo, "coche", "casa", "personaje")tags(opcional): Filtrar por etiquetas específicas (por ejemplo, ["animado", "manipulado", "pbr"])categories(opcional): Filtrar por categorías (por ejemplo, ["personajes", "arquitectura", "vehículos"])downloadable(opcional): Establézcalo como verdadero para mostrar solo los modelos descargableslimit(opcional): número máximo de resultados a devolver (1-24, predeterminado: 10)
2. detalles del modelo de sketchfab
Obtenga información detallada sobre un modelo específico de Sketchfab.
Parámetros:
modelId: El ID único del modelo de Sketchfab
3. descarga de sketchfab
Descargue un modelo 3D de Sketchfab.
Parámetros:
modelId: El ID único del modelo de Sketchfab para descargarformat(opcional): Formato preferido para descargar el modelo (gltf, glb, usdz, source)outputPath(opcional): directorio local o ruta de archivo para guardar el archivo descargado
Uso con cursor
Vaya a Configuración del cursor -> MCP -> Agregar nuevo servidor MCP
Configura tu MCP:
Nombre: Sketchfab MCP
Tipo: comando
Comando:
node /path/to/build/index.js --api-key YOUR_API_KEY
Uso con Claude Desktop
Agregue la siguiente configuración de MCP a su configuración de Claude Desktop:
{
"mcpServers": {
"sketchfab": {
"command": "node",
"args": ["/path/to/build/index.js", "--api-key", "YOUR_API_KEY"]
}
}
}Variables de entorno
Puede configurar las siguientes variables de entorno:
SKETCHFAB_API_KEY: Su clave API de Sketchfab (alternativa a pasarla con el parámetro --api-key)
Licencia
ISC
Available Tools
4 toolssample-toolC
A sample tool for demonstration purposes
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Input parameter for the sample tool |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides zero behavioral information beyond the name. With no annotations provided, the description carries the full burden of disclosing behavioral traits like whether this is a read or write operation, what side effects it might have, authentication requirements, or rate limits. The description fails to address any of these aspects, leaving the agent completely in the dark about how this tool behaves.
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 extremely concise at just one sentence with no wasted words. It's appropriately sized for what little information it conveys, and while it's under-specified, it's not verbose or poorly structured. Every word in 'A sample tool for demonstration purposes' serves its purpose within the minimal context provided.
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 that this is a tool with one parameter, no annotations, no output schema, and no sibling tools, the description is incomplete. It fails to explain what the tool actually does, what behavior to expect, or what context it operates in. While the simplicity of the tool might lower expectations, the description doesn't provide enough information for an agent to understand when and how to use it effectively.
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?
With 100% schema description coverage and only one parameter documented in the schema, the description adds no additional parameter information. The schema already describes the 'input' parameter as 'Input parameter for the sample tool,' so the description doesn't compensate or add meaning beyond what's in the structured data. This meets the baseline of 3 when schema coverage is high.
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 'A sample tool for demonstration purposes' is a tautology that essentially restates the tool name 'sample-tool' without specifying what it actually does. It doesn't mention any specific verb or resource, nor does it explain what kind of demonstration it performs. While it's not misleading, it provides minimal functional information beyond the name itself.
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, what context it's appropriate for, or what alternatives might exist. With no sibling tools mentioned, there's no need for differentiation, but the description fails to establish any usage context whatsoever. It doesn't indicate whether this is for testing, learning, or any specific scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sketchfab-downloadB
Download a 3D model from Sketchfab
| Name | Required | Description | Default |
|---|---|---|---|
| modelId | Yes | The unique ID of the Sketchfab model to download (must be downloadable) | |
| format | No | Preferred format to download the model in (defaults to gltf if available) | |
| outputPath | No | Local directory or file path to save the downloaded file (will use temp directory if not specified) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'download' but does not specify that the tool may overwrite files, requires network access, or what happens if the model is not downloadable or the format is unavailable.
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 concise sentence with no wasted words. However, it could include a few more details without becoming verbose, such as indicating the output is a file.
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?
Missing important context: no description of return value (e.g., saved file path), no error handling info, and no note about whether the tool checks for model availability before downloading. Despite having only 3 parameters, the description is too minimal for safe agent use.
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%, so each parameter has a description. The tool description adds no additional meaning beyond what is in the schema. The default behavior for format and outputPath is already stated in 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?
The description clearly states 'Download a 3D model from Sketchfab', which is a specific verb+resource combination and distinguishes it from sibling tools that list categories, licenses, search, or get model details.
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?
No guidance on when to use this tool versus alternatives, no prerequisites (e.g., model must be downloadable), and no context about the required modelId coming from a search or list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sketchfab-model-detailsB
Get detailed information about a specific Sketchfab model
| Name | Required | Description | Default |
|---|---|---|---|
| modelId | Yes | The unique ID of the Sketchfab model (found in URLs or search results) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'detailed information' without explaining what behavior to expect (e.g., does it require authentication? Are there rate limits?). It lacks behavioral context.
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?
Single sentence, 9 words, no fluff. Front-loaded with the action, efficient for a simple tool.
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 exists, and the description does not hint at what 'detailed information' includes (e.g., metadata, stats, file URLs). For a tool returning model details, the description should outline the scope of the response.
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% and the parameter description is informative. The tool description does not add additional semantic meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
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 action ('Get detailed information') and resource ('specific Sketchfab model'). It is distinct from sibling tools like sketchfab-search (list) and sketchfab-download (file retrieval).
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?
No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or cases where another sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sketchfab-searchC
Search for 3D models on Sketchfab based on keywords and filters
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Text search query (e.g., "car", "house", "character") to find relevant models | |
| tags | No | Filter by specific tags (e.g., ["animated", "rigged", "pbr"]) | |
| categories | No | Filter by categories (e.g., ["characters", "architecture", "vehicles"]) | |
| downloadable | No | Set to true to show only downloadable models, false to show all models | |
| limit | No | Maximum number of results to return (1-24, default: 10) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches but doesn't describe key behaviors: whether it requires authentication, rate limits, pagination, error handling, or the format of returned results. For a search tool with zero annotation coverage, this leaves significant gaps in understanding how the tool operates beyond basic functionality.
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, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does and the key inputs, making it easy to understand at a glance. Every part of the sentence contributes to clarifying the tool's function.
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 the tool's complexity (5 parameters, no annotations, no output schema), the description is insufficient. It lacks details on authentication requirements, result format, error conditions, and how it differs from sibling tools. For a search operation that likely returns structured data, the absence of output schema means the description should compensate by at least hinting at return types, which it does not.
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 description mentions 'keywords and filters,' which loosely maps to parameters like 'query,' 'tags,' and 'categories.' However, with 100% schema description coverage, the schema already fully documents all 5 parameters. The description adds minimal value beyond what's in the schema, such as clarifying the tool's focus on 3D models, but doesn't provide additional semantic context or usage examples for parameters.
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's purpose: 'Search for 3D models on Sketchfab based on keywords and filters.' It specifies the verb ('Search'), resource ('3D models on Sketchfab'), and scope ('based on keywords and filters'). However, it doesn't explicitly differentiate from sibling tools like 'sketchfab-model-details' or 'sketchfab-download,' which would require more specific boundary definitions.
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 alternatives. It doesn't mention sibling tools like 'sketchfab-download' or 'sketchfab-model-details,' nor does it specify prerequisites, such as whether authentication is required or if this is the primary search entry point. Usage is implied but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
- First observed
sample-tool - First observed
sketchfab-download - First observed
sketchfab-model-details - First observed
sketchfab-search
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: sample-tool is for demonstration, sketchfab-download handles downloading models, sketchfab-model-details retrieves model information, and sketchfab-search performs searches. There is no overlap in functionality, making tool selection straightforward for an agent.
Three of the four tools follow a consistent 'sketchfab-' prefix and hyphenated naming pattern (e.g., sketchfab-download, sketchfab-model-details, sketchfab-search), which is predictable and readable. The outlier is sample-tool, which deviates from this pattern, but the overall set remains mostly consistent.
With 4 tools, the count is reasonable for a Sketchfab server, covering core operations like search, details, and download. It is slightly lean but functional; adding tools like model upload or user management could enhance it, but it's not incomplete for basic use.
The tools cover key operations for interacting with Sketchfab models: search, get details, and download. However, there are notable gaps such as uploading models, managing user accounts, or handling collections, which limits full lifecycle coverage. The sample-tool adds no functional value to the domain.
Maintenance
Related MCP Connectors
Search and download free CC0 GLB models and game packs, and submit new ones on a user behalf.
Product Hunt for AI tools. Search, submit, upvote from Claude Code or Cursor.
Search verified Claude Code plugins and skills; fetch portable SKILL.md sources. Read-only.
Turn text or an image into an animation-ready 3D model (GLB): generate, rig, animate, retexture.
Related MCP Servers
- AlicenseDqualityDmaintenanceAn interface that enables Claude to interact with Spline 3D design tool, allowing operations like exporting scenes, importing models, and creating animations through natural language commands.7385MIT
- AlicenseAqualityFmaintenanceEnables Claude to generate 3D models from text or images, apply textures, and export to GLB/FBX/USDZ using the Meshy AI API.63MIT

Meshy MCP Serverofficial
AlicenseNot gradedqualityCmaintenanceEnables AI agents to create, manage, and download 3D models, textures, images, rigged characters, and animations through natural conversation.1,783 npm45MIT- FlicenseNot gradedqualityDmaintenanceSearch and download 3D models from Sketchfab using the Sketchfab API.-