3dassets
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| THREEDASSETS_API_KEY | No | Optional API key for submitting models on behalf of a user. Leave unset for read-only access. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_packsA | Find cohesive free GLB game kits by text, theme or style. Returns file counts, total bytes and starter scene URLs. Use get_pack for every individual model and loader snippet. |
| get_packA | Get a free pack manifest with direct CDN URLs, licences, geometry budgets, loader snippets and its assembled starter scene. Download models individually or use the starter scene. |
| list_demosA | List the walkable demo scenes staff have built from single packs. Each is a small environment a person can walk through on the site and an agent can load as a layout. Use get_demo for the placements. |
| get_demoB | Get one demo: the pack, the spawn point, the walkable bounds, the points of interest, and every placement (public asset slug, position in metres, yaw in degrees) with the CDN URL and bounds of each model placed. Load the models with a plain GLTFLoader and apply the transforms to reproduce the scene. |
| search_assetsA | Search the free GLB catalogue on 3dassets.dev (three.js, Blender, Godot, Unity) by text, category (what it is), theme (what world) and style (what look). Returns direct CDN URLs (CORS *, immutable) that load with a plain GLTFLoader. Published models use CC0 1.0 Universal: free personal and commercial use without attribution. Licence metadata is retained in each result. |
| get_assetA | Full details for one asset by slug: CDN URL, licence + attribution text, stats, bounding box, animations, and ready-to-paste loader snippets. |
| get_asset_usageC | Code or steps to load an asset in three.js, React Three Fiber, , Blender, Godot or Unity. |
| list_categoriesA | List categories available on 3dassets.dev (slugs are what other tools accept). |
| list_tagsA | List tags available on 3dassets.dev (slugs are what other tools accept). |
| list_licensesA | Returns the sole accepted submission dedication: CC0 1.0 Universal. No licence selection is needed. |
| list_ai_modelsB | Search model suggestions from OpenRouter, refreshed hourly. Custom model/tool names are accepted; the list is not exhaustive. Unavailable suggestions never block uploads. |
| create_accountA | Create a contributor account for the user. Needs only a username and email. There is no password anywhere in this product, so never ask the user for one. A 6-digit code is emailed to them; ask the user to read it to you, then call verify_account to receive their API key. Only do this with the user’s explicit consent. |
| verify_accountA | Exchange the emailed 6-digit code for the account’s API key. Show the key to the user and tell them to configure it as the Bearer token for this MCP server. |
| submit_asset_from_urlA | Submit a .glb hosted at a public https URL on the user’s behalf (requires their API key). We download it, validate and re-encode it, then a human reviews it before publishing. CC0 is automatic, but the user must accept its irrevocable dedication before submission. Max 25 MB, 1M triangles, embedded textures only. |
| get_upload_urlA | For clients that can upload bytes: returns a presigned PUT URL for a .glb (and optionally a PNG preview). Then call finalize_upload with the returned keys. |
| finalize_uploadA | After PUTting the file to the URL from get_upload_url, describe the asset and submit it for processing and review. |
| my_assetsA | List the user’s submissions with status (processing, pending review, published, rejected + reason, failed + reason). |
| submit_packA | Group 2–50 of the user’s own uploads (any that are processing, pending or published) into a pack proposal. Upload the models first with finalize_upload or submit_asset_from_url, then pass their slugs here. Each model is still reviewed on its own; a person approves the pack as a whole, which publishes any members still pending and creates the pack page. Nothing goes live until then. The user is emailed the outcome. |
| my_packsA | List the user’s pack proposals with status (submitted, approved + pack URL, rejected + reason) and the status of each member model. |
| update_assetA | Edit the metadata of one of the user’s own assets. The uploaded GLB can never be changed. Editing an asset that is already published does not change it: the proposal goes to the review queue and the live version keeps serving until a person approves it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Each tool has a clearly distinct purpose: account management, asset upload steps, asset and pack queries, metadata lists, and usage examples. The stepwise upload flow (get_upload_url, submit_asset_from_url, finalize_upload) is well-separated, and user-specific vs. general queries are unambiguous.
Most tools follow a verb-first pattern (get_, list_, search_, submit_, create_, verify_, finalize_), but 'my_assets' and 'my_packs' break this convention by using a noun phrase. This inconsistency is noticeable but not chaotic, as the verbs are otherwise regular.
With 20 tools, the server is slightly above the typical 3-15 range, but the breadth is justified by covering accounts, assets, packs, demos, metadata, and usage. It feels comprehensive rather than bloated, and each tool serves a distinct function.
The surface covers the full asset lifecycle: account creation/verification, both upload methods, asset retrieval/search/update, pack creation/search, demo listing, and supporting metadata (categories, tags, licenses, AI models). No obvious missing operations like delete are required given the immutable design (assets cannot be changed after upload).