Skip to main content
Glama
enesjakozh
gregkop

Sketchfab MCP Server

by gregkop
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

Sketchfab MCP Server

A Model Context Protocol (MCP) server for interacting with Sketchfab's 3D model platform. This MCP allows you to search, view details, and download 3D models from Sketchfab directly through Claude or Cursor.

Features

  • Search for 3D Models: Find models on Sketchfab using keywords, tags, and categories

  • View Model Details: Get comprehensive information about specific models

  • Download Models: Download models in various formats (gltf, glb, usdz, source)

Related MCP server: meshy-mcp

Prerequisites

  • Node.js 18 or higher

  • A Sketchfab API key (for authentication)

Installation

  1. Clone this repository

  2. Install dependencies:

    npm install

  3. Build the project:

    npm run build

Usage

Running the MCP Server

npm start

To provide your Sketchfab API key, use the --api-key parameter:

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

Alternatively, you can set the SKETCHFAB_API_KEY environment variable:

export SKETCHFAB_API_KEY=YOUR_API_KEY
npm start

Available Tools

1. sketchfab-search

Search for 3D models on Sketchfab based on keywords and filters.

Parameters:

  • query (optional): Text search query (e.g., "car", "house", "character")

  • tags (optional): Filter by specific tags (e.g., ["animated", "rigged", "pbr"])

  • categories (optional): Filter by categories (e.g., ["characters", "architecture", "vehicles"])

  • downloadable (optional): Set to true to show only downloadable models

  • limit (optional): Maximum number of results to return (1-24, default: 10)

2. sketchfab-model-details

Get detailed information about a specific Sketchfab model.

Parameters:

  • modelId: The unique ID of the Sketchfab model

3. sketchfab-download

Download a 3D model from Sketchfab.

Parameters:

  • modelId: The unique ID of the Sketchfab model to download

  • format (optional): Preferred format to download the model in (gltf, glb, usdz, source)

  • outputPath (optional): Local directory or file path to save the downloaded file

Using with Cursor

  1. Go to Cursor Settings -> MCP -> Add new MCP server

  2. Configure your MCP:

    • Name: Sketchfab MCP

    • Type: command

    • Command: node /path/to/build/index.js --api-key YOUR_API_KEY

Using with Claude Desktop

Add the following MCP config to your Claude Desktop configuration:

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

Environment Variables

You can set the following environment variables:

  • SKETCHFAB_API_KEY: Your Sketchfab API key (alternative to passing it with the --api-key parameter)

License

ISC

Available Tools

4 tools
sample-toolD

A sample tool for demonstration purposes

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesInput parameter for the sample tool

TDQS

D1.7/5.0
Behavior1/5

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. The description offers no information about what the tool does, whether it's read-only or destructive, what permissions it requires, rate limits, or expected behavior. It fails to provide any behavioral context beyond the generic 'demonstration purposes' statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (one sentence), but this brevity comes at the cost of being under-specified rather than efficiently informative. While it's technically concise, it doesn't provide enough substance to be truly helpful. The single sentence doesn't earn its place by adding meaningful value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/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 but no annotations and no output schema, the description is completely inadequate. It doesn't explain what the tool does, when to use it, what behavior to expect, or what it returns. For a tool that presumably performs some function (given its siblings are all Sketchfab-related), this description fails to provide the necessary context.

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 description coverage is 100%, so the schema already documents the single 'input' parameter with its type and description. The tool description adds no additional meaning about parameters beyond what the schema provides. With complete schema coverage, the baseline score of 3 is appropriate.

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 restates the tool name 'sample-tool' without specifying what it actually does. It doesn't mention any specific verb or resource, nor does it distinguish this tool from its siblings (sketchfab-download, sketchfab-model-details, sketchfab-search). The description is vague about the tool's actual function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/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 versus its siblings or any alternatives. There's no mention of context, prerequisites, or exclusions. This leaves the agent with no information about appropriate usage scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sketchfab-downloadC

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

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure but provides minimal information. It mentions downloading but doesn't cover important aspects like authentication requirements, rate limits, file size considerations, network behavior, or what happens if the model isn't downloadable. The description is functionally correct but lacks operational 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?

The description is a single, efficient sentence that states the core function without unnecessary words. It's appropriately sized for a straightforward download operation and gets directly to the point with zero wasted verbiage.

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?

For a download tool with no annotations and no output schema, the description is insufficient. It doesn't explain what gets returned (file path? success status?), error conditions, authentication needs, or important constraints like the 'must be downloadable' requirement mentioned in the schema. The combination of missing behavioral context and output information creates significant gaps.

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, the baseline is 3. The description doesn't add any parameter semantics beyond what's already in the schema - it doesn't explain what makes a model 'downloadable' (hinted in schema), provide format selection guidance, or clarify output path behavior. The schema already documents all three parameters thoroughly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('download') and resource ('3D model from Sketchfab'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'sketchfab-model-details' or 'sketchfab-search' - all could involve downloading or accessing models, so the distinction isn't explicit.

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 is provided about when to use this tool versus alternatives like 'sketchfab-model-details' (which might provide metadata before downloading) or 'sketchfab-search' (which might help find models first). The description only states what the tool does, not when it's appropriate to invoke it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sketchfab-model-detailsC

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

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves 'detailed information' but doesn't specify what that includes (e.g., metadata, statistics, licensing), whether it requires authentication, rate limits, or error handling. This leaves significant gaps for a tool that likely interacts with an external API.

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 a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.

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?

For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'detailed information' includes, how results are structured, or potential errors. Given the external API context implied by the tool name, more behavioral and output details are needed for effective 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?

The input schema has 100% description coverage, clearly documenting the single required 'modelId' parameter with its purpose and source. The description doesn't add any additional semantic context beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('detailed information about a specific Sketchfab model'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'sketchfab-search' (which likely returns multiple models) or 'sketchfab-download' (which likely retrieves files rather than metadata).

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 versus alternatives. It doesn't mention sibling tools like 'sketchfab-search' for finding models or 'sketchfab-download' for obtaining files, nor does it specify prerequisites such as needing a model ID from search results or URLs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.7/5.0
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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gregkop/sketchfab-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server