Skip to main content
Glama
tiranyx

rupa3d

by tiranyx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

rupa_topologi

Read-only

Inspect GLB mesh topology by welding vertices by position, then report non-manifold edges, boundary holes, inverted triangles, degenerate slivers, and UV issues directly from the file.

Instructions

Periksa TOPOLOGI sebuah GLB — bagaimana verteksnya TERSAMBUNG, bukan di mana letaknya. Bekerja pada berkas dari mana pun, termasuk keluaran generator AI, tanpa perlu Blender.

Yang dilaporkan: tepi tak-manifold, tepi batas (lubang), segitiga berputar terbalik, segitiga degenerasi dan sliver, nisbah pecah verteks, sebaran kerapatan texel, dan UV di luar 0–1.

SATU HAL YANG MENENTUKAN: verteks DILAS menurut posisi sebelum dihitung. glTF memecah verteks di tiap jahitan UV, jadi menghitung manifold pada indeks mentah membuat setiap jahitan terlihat sebagai lubang — terukur pada satu aset: 30.790 mentah vs 360 setelah dilas, menggelembung 85 kali.

DAN YANG TIDAK BISA DIUKUR DARI GLB, disebut apa adanya: nisbah quad/n-gon dan pola edge loop sudah HILANG sebelum berkasnya ditulis, karena glTF selalu tersegitiga. Alat mana pun yang mengklaim menilai quad-dominance dari sebuah GLB sedang mengarang.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
berkasYesJalur absolut .glb
per_primitifNoSertakan rincian tiap primitif. Angka gabungan DIJUMLAHKAN bukan dirata-rata: rata-rata menenggelamkan satu primitif rusak parah di antara tiga puluh yang sehat.
toleransi_lasNoJarak maksimum dua titik dianggap sama. Kosongkan supaya diturunkan dari diagonal berkasnya (1e-6 x diagonal) — ambang MUTLAK akan melas seluruh model milimeter jadi satu titik.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.6.2

TDQS

A4.6/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, so the agent knows it's safe. The description goes well beyond that by disclosing the critical vertex-welding preprocessing step with a concrete example (30,790 vs 360 after welding, inflating 85x), and it transparently states the limitations of glTF (no quad/n-gon info). This adds significant behavioral context that the annotations cannot convey, and there is no contradiction.

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?

The description is well-structured: it opens with a crisp one-sentence purpose, then lists the reported metrics, then highlights the critical welding caveat with a concrete example, and finally states the inherent limitations. Every sentence earns its place, and the most important information (purpose and the welding caveat) is front-loaded. It is detailed but not bloated.

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?

Given the tool's complexity, the description covers all essential aspects: purpose, supported checks, preprocessing behavior, and limitations. It also lists the output metrics in the description, which partially compensates for the lack of an output schema. A minor gap is the absence of the exact output structure or return format, but for an agent deciding whether to call it, this is sufficient. Overall it is complete for the task at hand.

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

Parameters4/5

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

Schema coverage is 100% with each parameter having a descriptive comment, so the baseline is 3. The description's main body reinforces the meaning of toleransi_las by explaining the welding concept and its implications, which helps an agent understand why the parameter exists and how it affects results. This adds context beyond the schema's individual descriptions, justifying a 4.

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 clearly states the tool's purpose: inspecting the topology of a GLB file, focusing on connectivity rather than positions. It lists specific checks (non-manifold edges, boundary edges, inverted triangles, degenerate triangles, vertex split ratio, texel density, UV out of range) and explicitly differentiates from a generic inspect tool by naming the resource and the operation. The phrase 'bagaimana verteksnya TERSAMBUNG, bukan di mana letaknya' makes the scope unambiguous, and it is distinct from siblings like rupa_periksa or rupa_ukur.

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 provides strong usage context: it works on any GLB file without Blender, and it warns about the vertex-welding behavior that affects interpretation of manifold results. It also explicitly states what cannot be measured (quad/n-gon ratio, edge loops) because glTF is triangulated, cautioning against tools that claim otherwise. However, it does not explicitly name alternative tools or give a when-not-to-use directive, so it falls short of a perfect 5.

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

Deploy Server

Other Tools