Skip to main content
Glama
enesjakozh
gregkop

Sketchfab MCP Server

by gregkop
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Sketchfab MCP 서버

Sketchfab의 3D 모델 플랫폼과 상호 작용하기 위한 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 MCP를 사용하면 Claude 또는 Cursor를 통해 Sketchfab에서 3D 모델을 직접 검색하고, 세부 정보를 확인하고, 다운로드할 수 있습니다.

특징

  • 3D 모델 검색 : 키워드, 태그, 카테고리를 사용하여 Sketchfab에서 모델 찾기

  • 모델 세부 정보 보기 : 특정 모델에 대한 포괄적인 정보를 얻으세요

  • 모델 다운로드 : 다양한 형식(gltf, glb, usdz, source)의 모델을 다운로드하세요

Related MCP server: meshy-mcp

필수 조건

  • Node.js 18 이상

  • Sketchfab API 키(인증용)

설치

  1. 이 저장소를 복제하세요

  2. 종속성 설치:

    지엑스피1

  3. 프로젝트를 빌드하세요:

    npm run build

용법

MCP 서버 실행

npm start

Sketchfab API 키를 제공하려면 --api-key 매개변수를 사용하세요.

node build/index.js --api-key YOUR_API_KEY

또는 SKETCHFAB_API_KEY 환경 변수를 설정할 수 있습니다.

export SKETCHFAB_API_KEY=YOUR_API_KEY
npm start

사용 가능한 도구

1. 스케치팹 검색

키워드와 필터를 기반으로 Sketchfab에서 3D 모델을 검색하세요.

매개변수:

  • query (선택 사항): 텍스트 검색 쿼리(예: "자동차", "집", "문자")

  • tags (선택 사항): 특정 태그로 필터링(예: ["애니메이션", "조작", "PBR"])

  • categories (선택 사항): 카테고리별로 필터링합니다(예: ["캐릭터", "건축", "차량"])

  • downloadable (선택 사항): 다운로드 가능한 모델만 표시하려면 true로 설정합니다.

  • limit (선택 사항): 반환할 최대 결과 수(1-24, 기본값: 10)

2. 스케치팹-모델-디테일

특정 Sketchfab 모델에 대한 자세한 정보를 얻으세요.

매개변수:

  • modelId : Sketchfab 모델의 고유 ID

3. 스케치팹 다운로드

Sketchfab에서 3D 모델을 다운로드하세요.

매개변수:

  • modelId : 다운로드할 Sketchfab 모델의 고유 ID

  • format (선택 사항): 모델을 다운로드하는 데 선호하는 형식(gltf, glb, usdz, source)

  • outputPath (선택 사항): 다운로드한 파일을 저장할 로컬 디렉토리 또는 파일 경로

커서와 함께 사용

  1. 커서 설정 -> MCP -> 새 MCP 서버 추가로 이동하세요.

  2. MCP를 구성하세요:

    • 이름: Sketchfab MCP

    • 유형: 명령

    • 명령어: node /path/to/build/index.js --api-key YOUR_API_KEY

Claude Desktop과 함께 사용

다음 MCP 구성을 Claude Desktop 구성에 추가하세요.

{
  "mcpServers": {
    "sketchfab": {
      "command": "node",
      "args": ["/path/to/build/index.js", "--api-key", "YOUR_API_KEY"]
    }
  }
}

환경 변수

다음 환경 변수를 설정할 수 있습니다.

  • SKETCHFAB_API_KEY : Sketchfab API 키(--api-key 매개변수와 함께 전달하는 대안)

특허

아이에스씨

Available Tools

4 tools
sample-toolC

A sample tool for demonstration purposes

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesInput parameter for the sample tool

TDQS

C2.3/5.0
Behavior1/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose2/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
modelIdYesThe unique ID of the Sketchfab model to download (must be downloadable)
formatNoPreferred format to download the model in (defaults to gltf if available)
outputPathNoLocal directory or file path to save the downloaded file (will use temp directory if not specified)

TDQS

B3.1/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
modelIdYesThe unique ID of the Sketchfab model (found in URLs or search results)

TDQS

B3.2/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updates
    • First observedsample-tool
    • First observedsketchfab-download
    • First observedsketchfab-model-details
    • First observedsketchfab-search
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.7/5.0

Scored across 4 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count4/5

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.

Completeness3/5

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

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches