Interactive 3D science models in Chinese and English, found and shown live in the chat.
Scored across 3 tools
Each tool has a distinct role: search_models discovers plates by question, show_model displays one, and list_chapters enumerates chapters/settings for a known plate. The search-then-show workflow is clearly signposted, though search_models and list_chapters both touch discovery enough to cause slight initial hesitation.
All three names follow a consistent snake_case verb_noun pattern: list_chapters, search_models, show_model. The verbs accurately reflect each operation.
Three tools is well-scoped for this server's purpose: find a plate, inspect its structure, and display it. Each tool earns its place with no redundancy or bloat.
The core workflow—search, inspect chapters/lab settings, and show—is fully covered. There is no way to browse or list all available plates without a specific question, a minor gap for exploratory users.
Lists one plate’s chapters (ids and titles) and the lab settings it accepts (ids, ranges, options), for show_model. Use it when the user wants another part of a plate than the one search_models gave, or wants to set the lab.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | zh (Chinese) or en (English). | |
| slug | Yes | The plate id from search_models (e.g. "tides"). |
| Name | Required | Description |
|---|---|---|
| lang | Yes | The language of the texts: zh or en. |
| slug | Yes | |
| params | Yes | The lab settings the plate accepts. |
| chapters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, non-destructive behavior, and a closed-world scope, so the safety profile is clear. The description adds that it surfaces available chapters and lab settings rather than mutating them, but it does not add deeper behavioral details such as pagination, permissions, or limits; output-schema coverage also reduces the need for return-value explanation.
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 two sentences and front-loads the purpose before the usage guidance. The parenthetical return details make the first sentence dense but still efficient; little is wasted.
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?
For a simple, read-only tool with two parameters and an output schema, the description covers the purpose, what is listed, and when to choose it over search_models. The main gap is that the relationship to show_model and the meaning of “set the lab” are not fully spelled out.
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 description coverage is 100%, so both parameters are already documented in the input schema. The description implies the slug denotes a single plate, but it adds no meaningful semantics beyond that and does not mention the lang parameter.
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 states a specific verb and resource: it lists a plate’s chapters and the lab settings that plate accepts, including the kinds of values returned. It also ties the tool to show_model and search_models, though it does not fully delineate how it differs from show_model.
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 second sentence gives explicit usage conditions: use it when the user wants a different part of a plate than search_models returned, or wants to set the lab. It names search_models as the relevant alternative, but does not give explicit when-not guidance or clarify the show_model relationship.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks how something works or why something happens in physics, engineering, AI, biology and medicine, earth and space science or mathematics, or asks to see or try a mechanism: e.g. “why do we have seasons”, “how does a jet engine work”, “潮汐是怎么形成的”, “Transformer 的注意力是什么”. Searches the interactive 3D models (“plates”) on world.lapla.si: first an index of the questions each plate answers (Chinese and English), then titles and topics. Returns the best plates, each with its slug, the chapter that answers the question and sometimes lab settings, to pass to show_model. Returns no results when no plate covers the question. Not for news, prices, homework calculations, or medical, legal or financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the results: zh (Chinese) or en (English). Default: the query’s language. | |
| limit | No | How many plates to return at most. | |
| query | Yes | The user’s question in their own words, in any language (e.g. “why is the sky blue”, “光刻机是怎么工作的”), or a topic (“black hole”, “黑洞”). |
| Name | Required | Description |
|---|---|---|
| lang | Yes | The language of the texts: zh or en. |
| query | Yes | The query as received. |
| results | Yes | The plates that answer the query, best first; empty when none does. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, and the description adds genuinely new behavior: the two-stage search order (question index first, then titles and topics), the bilingual index, the empty-result case, and what each hit contains (slug, answering chapter, sometimes lab settings). That is materially more than the annotations provide.
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?
Front-loaded with the use trigger and tight overall, but the opening sentence is a long run-on stacking many domains and four quoted examples, which dilutes scannability. The exclusions and show_model handoff are well placed at the end.
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?
An output schema exists, yet the description still summarizes the shape of results and the no-results case, and it covers the search strategy and handoff to show_model. Nothing an agent needs to select or call this correctly is missing.
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 the baseline is 3; the description still adds meaning by clarifying that the query index is bilingual (Chinese and English) and that query may be a full question or a bare topic in any language. It says nothing about the limit parameter, so it does not fully exceed 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?
States a specific verb and resource — searches interactive 3D models ('plates') on world.lapla.si — and scopes it to answering 'how/why' science questions. It is clearly distinguished from siblings: show_model is named as the downstream step and list_chapters is implicitly a different browsing path.
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?
Gives explicit when-to-use triggers with multilingual example questions, plus an explicit negative list ('Not for news, prices, homework calculations, or medical, legal or financial advice'). It also names the follow-up tool (show_model), so the agent knows both entry and continuation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows one interactive 3D model from world.lapla.si in the conversation, opening at the chapter that answers the user’s question; the user can turn it, step through its chapters and try its lab. Use it after search_models with the slug and chapter (and params) it returned, or when the user names a plate. Also returns a short text summary and the plate’s link, for clients that show no UI.
| Name | Required | Description | Default |
|---|---|---|---|
| lab | No | Open at the lab, the chapter where the user can change the settings, with its panel open. Only when the user asks to experiment or to change a setting. (In a chat’s inline card the panel starts folded, one tap away; full screen opens it.) | |
| lang | No | zh (Chinese) or en (English). | |
| slug | Yes | The plate id from search_models (e.g. "seasons"). | |
| params | No | Lab settings by id, from search_models or list_chapters: a number for a slider, an option id for a choice, true/false for a toggle. | |
| chapter | No | The chapter id to open at, from search_models or list_chapters (e.g. "tilt"). Default: the cover. |
| Name | Required | Description |
|---|---|---|
| url | Yes | The plate’s page on world.lapla.si. |
| card | Yes | The plate’s card picture, if it has one. |
| hall | Yes | The hall of the site the plate is in. |
| lang | Yes | The language of the texts: zh or en. |
| slug | Yes | The plate id, for show_model and list_chapters. |
| plate | Yes | The plate’s number on the site (e.g. "05", "F07"). |
| title | Yes | |
| params | Yes | Lab settings by id. |
| chapter | Yes | |
| summary | Yes | |
| chapters | Yes | |
| embedUrl | Yes | The embed page the UI shows. |
| description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds behavior they cannot express: it renders an interactive inline UI the user can rotate, page through, and run a lab in, and it falls back to 'a short text summary and the plate's link, for clients that show no UI.' That dual-mode output disclosure is exactly the kind of context an agent needs to predict the call's effect on the conversation.
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?
Two sentences, front-loaded with what the tool does and what the user can do with it, then the call-ordering guidance. Slightly dense but no sentence is filler; the UI-fallback clause is long but earns its place.
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?
With an output schema present the description needn't enumerate return fields, and annotations cover the safety profile; the description still supplies the chained-call workflow, the interactive surface, and the no-UI fallback. Nothing an agent needs to call this correctly is missing.
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 description coverage is 100% and each parameter carries a rich, example-bearing description (slug example 'seasons', chapter example 'tilt', lab's panel semantics, params' value typing). The description only restates the source of slug/chapter/params ('it returned'), adding marginal meaning beyond the schema, so the baseline 3 applies.
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?
Specific verb and resource ('Shows one interactive 3D model from world.lapla.si in the conversation') with the added behavioral scope of opening at the answering chapter. It is clearly distinct from search_models (discovery) and list_chapters (enumeration), so an agent can route without opening schemas.
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?
Explicitly names the prerequisite/alternative workflow: 'Use it after search_models with the slug and chapter (and params) it returned, or when the user names a plate.' That covers both the chained-call case and the direct-trigger case. It stops short of stating when not to call it (e.g. when no slug is known and search_models has not run).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_chapters1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "chapters": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "n": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "n",
+ "title"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "lang": {
+ "description": "The language of the texts: zh or en.",
+ "enum": [
+ "zh",
+ "en"
+ ],
+ "type": "string"
+ },
+ "params": {
+ "description": "The lab settings the plate accepts.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "default": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "slider",
+ "toggle",
+ "choice"
+ ],
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "max": {
+ "type": "number"
+ },
+ "min": {
+ "type": "number"
+ },
+ "options": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "label"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "step": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "id",
+ "kind",
+ "label"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "lang",
+ "chapters",
+ "params"
+ ],
+ "type": "object"
+}search_models1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "lang": {
+ "description": "The language of the texts: zh or en.",
+ "enum": [
+ "zh",
+ "en"
+ ],
+ "type": "string"
+ },
+ "query": {
+ "description": "The query as received.",
+ "type": "string"
+ },
+ "results": {
+ "description": "The plates that answer the query, best first; empty when none does.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "chapter": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "The chapter to open at, for show_model.",
+ "type": "string"
+ },
+ "n": {
+ "description": "Its number; 0 is the cover.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "n",
+ "title"
+ ],
+ "type": "object"
+ },
+ "hall": {
+ "description": "The hall of the site the plate is in.",
+ "type": "string"
+ },
+ "params": {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "boolean"
+ }
+ ]
+ },
+ "description": "Lab settings by id.",
+ "type": "object"
+ },
+ "plate": {
+ "description": "The plate’s number on the site (e.g. \"05\", \"F07\").",
+ "type": "string"
+ },
+ "slug": {
+ "description": "The plate id, for show_model and list_chapters.",
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "description": "The plate’s page on world.lapla.si.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "plate",
+ "title",
+ "summary",
+ "hall",
+ "url",
+ "chapter"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "query",
+ "lang",
+ "results"
+ ],
+ "type": "object"
+}show_model2 fields changedInput schema / properties / lab / descriptionPrevious value: -"Open the lab panel."New value: +"Open at the lab, the chapter where the user can change the settings, with its panel open. Only when the user asks to experiment or to change a setting. (In a chat’s inline card the panel starts folded, one tap away; full screen opens it.)"Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "card": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The plate’s card picture, if it has one."
+ },
+ "chapter": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "The chapter the model opens at.",
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title"
+ ],
+ "type": "object"
+ },
+ "chapters": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "embedUrl": {
+ "description": "The embed page the UI shows.",
+ "type": "string"
+ },
+ "hall": {
+ "description": "The hall of the site the plate is in.",
+ "type": "string"
+ },
+ "lang": {
+ "description": "The language of the texts: zh or en.",
+ "enum": [
+ "zh",
+ "en"
+ ],
+ "type": "string"
+ },
+ "params": {
+ "additionalProperties": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ },
+ {
+ "type": "boolean"
+ }
+ ]
+ },
+ "description": "Lab settings by id.",
+ "type": "object"
+ },
+ "plate": {
+ "description": "The plate’s number on the site (e.g. \"05\", \"F07\").",
+ "type": "string"
+ },
+ "slug": {
+ "description": "The plate id, for show_model and list_chapters.",
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "description": "The plate’s page on world.lapla.si.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "plate",
+ "title",
+ "summary",
+ "hall",
+ "url",
+ "lang",
+ "description",
+ "chapter",
+ "chapters",
+ "params",
+ "embedUrl",
+ "card"
+ ],
+ "type": "object"
+}list_chapterssearch_modelsshow_model3D printing: printable models, calculators, troubleshooting wiki, build guides, AI 3D + CAD design.
Low-poly 3D models and kits for three.js and game engines: search, match, remix, preview.
Search and read ~95,000 interactive concept diagrams that explain how things work — visually.
Read real Chinese word by word: each word's meaning in its sentence, its pinyin and its parts.
Add one secure layer between your agents and this server.
