Skip to main content
Glama

rupa_adegan_cahaya

Destructive

Set or add scene lighting, overwriting existing light IDs to replace the default sun. Ensure at least one light has strength above zero to prevent black renders when publishing.

Instructions

Atur atau tambah cahaya. id yang sudah ada akan DITIMPA, jadi tool ini juga cara mengubah matahari bawaan. Adegan tanpa satu pun cahaya berkekuatan > 0 ditolak saat terbit — ia akan terbit HITAM, dan layar hitam tanpa pesan adalah kegagalan yang paling mahal.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
kuatNo
hapusNo
jenisNo
ruangNoNama ruang kerja; tiap ruang punya adegan.blend sendiri.utama
warnaNo
posisiNo
bayanganNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.6.2

TDQS

A4.2/5.0
Behavior5/5

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

The description goes beyond the destructiveHint annotation by explaining that existing ids are overwritten and that publishing a scene with no light of strength > 0 produces a black screen with no message. This is exactly the kind of high-cost behavioral warning an agent needs.

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?

Three short sentences, front-loaded with the core action and immediately followed by the most critical destructive and failure behaviors. No filler or redundant restatement of the schema.

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

Completeness3/5

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

The description covers the most severe risk and overwrite semantics, but with 8 parameters and no output schema it is not fully complete. An agent still has to guess the meaning of deletion, light type, color, position, and shadow parameters from names alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 13%, so the description must compensate, but it only adds meaningful semantics for 'id' (overwrite) and indirectly for 'kuat' (strength must be > 0 to avoid black publish). It does not explain 'hapus', 'jenis', 'warna', 'posisi', 'bayangan', or how fields interact.

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?

The description opens with a specific verb-resource pair, 'Atur atau tambah cahaya' (set or add light), and clarifies scope by stating existing ids are overwritten and that the default sun can be changed. This clearly distinguishes it from other scene tools like kamera or lingkungan.

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?

It gives clear context for when the tool is appropriate: adding a light or modifying an existing one by its id, including the default sun. It does not explicitly list alternatives or exclusions, but the usage context is concrete enough for an agent to act on.

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