Skip to main content
Glama

rupa_topologi_sumber

Read-only

Measures quad, n-gon, vertex valence, poles, and edge loops directly in Blender source mesh, bypassing glTF triangulation that loses topology structure.

Instructions

Topologi SUMBER: quad, n-gon, valensi verteks, KUTUB, dan EDGE LOOP — diukur dari mesh di dalam Blender, satu-satunya tempat keempatnya masih ada.

glTF SELALU tersegitiga, jadi rupa_topologi (yang membaca GLB) menyebut keempat ukuran ini "tidak bisa diukur" di tiap keluarannya. Itu benar, dan tool ini bukan penghampirannya — ia membaca sumbernya.

KENAPA INI YANG MENENTUKAN: yang membuat aset generatif menuntut dua sampai empat jam retopology manual bukan jumlah segitiganya, melainkan tidak adanya STRUKTUR — tidak ada edge loop yang mengikuti lipatan, valensi kacau, quad tidak ada. Mesh begitu tidak bisa dideformasi, di-subdivide, atau di-UV tanpa dibangun ulang.

BATAS YANG DISEBUT: memuat GLB ke Blender TIDAK memulihkan quad-nya. Kalau mesh yang diukur seluruhnya segitiga, keluarannya memuat peringatan yang menyatakan bahwa itu bisa berarti mesh memang bertopologi segitiga ATAU informasinya sudah musnah saat impor — dan alat ini tidak bisa membedakannya. Terukur: sebuah GLB 2.976 segitiga diimpor ulang keluar sebagai 2.976 segitiga dan NOL quad.

VERTEKS BATAS dikeluarkan dari analisis kutub: valensi != 4 di tepi terbuka itu wajar, bukan cacat — bidang datar 4x4 punya seluruh tepinya bervalensi 2 atau 3.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
objekNoSatu objek mesh; kosong = seluruh mesh di adegan.
ruangNoNama ruang kerja; tiap ruang punya adegan.blend sendiri.utama
per_objekNoSertakan rincian tiap objek.
ambang_sebidangNoDerajat. Quad yang keempat verteksnya menyimpang lebih dari ini dihitung TAK SEBIDANG — Blender, mesin game, dan eksportir glTF masing-masing memilih diagonal segitiganya sendiri, jadi bayangannya berubah bentuk antar-alat tanpa satu pun yang salah.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.6.2

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare readOnlyHint true and destructiveHint false, and the description adds substantial behavioral context: all-triangle meshes produce a warning because the tool cannot distinguish genuine triangle topology from import triangulation, boundary vertices are excluded from pole analysis, and a concrete measurement example confirms zero quad recovery from GLB. These edge cases materially affect how an agent should interpret results.

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?

The text is long, but each bolded section serves a distinct purpose: scope, differentiation from the sibling, rationale, limitation, and analysis caveat. The core definition is front-loaded, though the motivational paragraph and measured example could be trimmed without losing essential invocation guidance.

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?

For a read-only measurement tool with no output schema, the description covers the source-vs-GLB distinction, the warning condition for fully triangulated meshes, boundary handling, and the four measured topology metrics. It stops short of describing the exact return shape, but an agent has enough context to invoke and interpret the result 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 every parameter (objek, ruang, per_objek, ambang_sebidang) already has a meaningful schema description. The tool description does not add parameter-level explanation, so it stays at the baseline expected when the schema carries the semantic load.

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 first sentence names a specific action and resource: measuring SUMBER topology metrics (quads, n-gons, vertex valence, poles, edge loops) from the mesh inside Blender. It also explicitly contrasts with the sibling rupa_topologi, which reads GLB and reports these as immesurable, so an agent can immediately distinguish the two tools.

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?

The description states that the tool reads the source mesh rather than approximating from a GLB, names rupa_topologi as the GLB-reading sibling, and warns that loading a GLB into Blender does not recover quads. This conveys the main usage context, though it does not spell out an explicit when-not-to-use rule for every alternative.

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