Use this guide to write, render, bake, upload, apply, and preview WGSL VFX nodes as Roblox flipbook textures, starting with the overview and node sections.
How to write, render, bake, upload, apply and preview VFX lab nodes (WGSL baked into Roblox textures). Without section: the index and the overview. Sections: overview, node, helpers, examples, quality, roblox. Read overview and node first.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose useful behavior, namely that omitting the section parameter returns the index and overview. However, it does not state that the tool is read-only/side-effect free, nor characterize the response size or format of each section.
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?
Three short sentences, front-loaded with the purpose and followed by the default-behavior rule and the recommended reading order. The fragment style ('Without section: ...') is slightly awkward but wastes no space.
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 single-parameter documentation tool with no output schema, the description supplies purpose, valid values, default behavior, and reading order. It does not say what each section actually contains, which would help an agent jump straight to the right section instead of reading overview and node first.
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 0% (a bare untyped 'string'), so the description must compensate, and it does: it enumerates every valid section value (overview, node, helpers, examples, quality, roblox) and defines the default behavior when the parameter is omitted. This is exactly what an agent needs and is not available anywhere else.
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 specific content: it covers writing, rendering, baking, uploading, applying and previewing VFX lab nodes as WGSL baked into Roblox textures, and that it returns a guide by section. This is clearly separable from siblings like vfx_render or vfx_bake, which perform those actions. It never uses an explicit verb like 'returns documentation', so the exact nature of the response is inferred rather than stated.
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?
'Read overview and node first' gives explicit sequencing guidance for a guide tool. The default behavior with no section is also given. It stops short of stating when to consult this versus calling the sibling operation tools directly, which would be the final piece of routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.