Assets for three.js

Get one 3D model's details

get_model

Read-onlyIdempotent

Everything the store lists for one model or assembly: name, pack, store page and preview image, size in metres, triangles and file size at each level of detail (high, medium, low), embedded texture count, material slots, sockets, era and setting, the parts an assembly places, the licence summary, and its price with a buy link (or the free pack page). Pass the id from search_models or the model's store page URL. It does not return the GLB file or a download link, and it cannot buy anything. Read-only.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "get_model"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	The model id (e.g. "london-pubs-corner") or its page URL (https://assetsforthreejs.com/assets/<id>/).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the description's added value is in the scope boundaries: no GLB payload, no download link, no purchase capability. That prevents a plausible misuse (calling it expecting a file). It doesn't discuss pagination or error behaviour, but those are minor here.

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?

Purpose and return contents are front-loaded in the first clause, with constraints and read-only status trailing. The field enumeration is long but each item tells the agent what to expect, so it earns its place; only slight tightening would improve it.

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

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the burden of describing return values and does so thoroughly, including the notable absence of file/download data. Combined with annotations covering safety, an agent has what it needs to call this correctly.

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% and the single id parameter already documents both the slug form and the page URL format. The description restates the same two accepted forms, adding convenience but no new semantics beyond the schema — baseline 3 applies.

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?

States a specific verb and resource ('Everything the store lists for one model or assembly') and then enumerates exactly what that entails — LOD triangle counts, texture count, sockets, licence, price. An agent can distinguish this from search_models or list_packs without opening any schema.

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

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear entry conditions ('Pass the id from search_models or the model's store page URL') and useful exclusions ('does not return the GLB file or a download link, and it cannot buy anything'). It stops short of naming which sibling to use when the agent actually needs a file or a purchase, so it is strong but not a full when/when-not/alternative map.

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

All Assets for three.js tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?