Skip to main content
Glama
threejs-devtools-mcp

threejs-devtools-mcp

by DmitriyGolub

set_fog

Idempotent

Adjust Three.js scene fog color, near/far or density, and background color in a live browser preview; changes are undoable and not saved to source.

Instructions

[LIVE PREVIEW] Changes the scene in the browser only — NOT saved to source code, lost on reload. Recorded in pending_changes (→ code edits) and undoable with revert_changes. Change scene fog (color, near/far or density) and the background color.

Input Schema

NameRequiredDescriptionDefault
farNoFog only
nearNoFog only
colorNo#RRGGBB
densityNoFogExp2 only
backgroundNoScene background color, #RRGGBB

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.5.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / background / description
      Previous value: -"Scene background color (#RRGGBB)"New value: +"Scene background color, #RRGGBB"
    • changedInput schema / properties / color / description
      Previous value: -"Fog color (#RRGGBB)"New value: +"#RRGGBB"
    • changedInput schema / properties / density / description
      Previous value: -"Fog density (FogExp2 type)"New value: +"FogExp2 only"
    • changedInput schema / properties / far / description
      Previous value: -"Fog far distance (Fog type)"New value: +"Fog only"
    • changedInput schema / properties / near / description
      Previous value: -"Fog near distance (Fog type)"New value: +"Fog only"
  2. First observedv0.4.1

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare safety semantics (readOnlyHint=false, idempotent, non-destructive); the description adds the crucial behavioral facts: the change is browser-only, never persisted to source, lost on reload, tracked in pending_changes, and reversible via revert_changes. That is well beyond what the annotations disclose.

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?

Two sentences with zero filler, and the highest-risk constraint ([LIVE PREVIEW], not saved) is front-loaded before the functional description. Every clause carries non-redundant information.

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

Completeness5/5

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

For a non-destructive preview mutation with full annotation coverage and a complete parameter schema, the description supplies everything the agent needs: persistence semantics, undo mechanism, and which scene properties are affected. No output schema exists, so no return-value description is required.

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 baseline is 3. The description groups the parameters ('color, near/far or density' and background color), reinforcing the schema but adding no new syntax, constraints, or defaults beyond what is already documented per-property.

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 (Change) plus resource and scope: scene fog (color, near/far or density) and the background color. This distinguishes it from read-only siblings such as fog_details and scene_background, so an agent can route correctly without opening the 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?

Explicitly frames when this applies — live preview only, not written to source, lost on reload — and names the follow-up path (pending_changes → code edits) plus the undo path (revert_changes). It gives clear operating context but no explicit 'use X instead when you want persistence' alternative tool.

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