Skip to main content
Glama
andyluu98
by andyluu98

dung_mai

Builds a 3D concrete roof in Blender using input points, allowing flat or single-pitch types with adjustable slope and overhang.

Instructions

Dung mai betong.

kieu: 'bang' cho mai bang co doc thoat nuoc, 'doc' cho mai mot doc. do_doc: ty le doc, 0.02 la 2 phan tram. vuon: phan mai dua ra ngoai mep tuong.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dayNo
tenNo
dinhYes
kieuNobang
vuonNo
cao_doNo
do_docNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden and does not disclose anything about the operation itself — no note on required existing geometry, side effects, reversibility, or whether it needs a level/base to attach to. It only explains three parameter meanings, which is parameter semantics rather than behavioral disclosure.

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?

Four short lines, purpose front-loaded, each subsequent line mapping to a parameter with no filler. Efficient and well-ordered, though extremely terse.

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

Completeness2/5

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

For a 7-parameter geometry-construction tool with no annotations and no output schema, the definition is under-specified: the required 'dinh' coordinate input and the 'day'/'cao_do'/'ten' parameters are never addressed, leaving an agent unable to call it correctly from the description alone.

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 coverage is 0%, so the description must compensate; it usefully defines kieu ('bang' vs 'doc'), do_doc (slope ratio, 0.02 = 2%), and vuon (overhang past the wall) — including an implicit enum the schema lacks. However, it leaves 4 of 7 parameters undocumented, including the required 'dinh' (apex points), plus day, ten and cao_do.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 ('Dung mai betong' = build concrete roof), which is self-evidently distinct from siblings like dung_san (floor), dung_cot (column) or dung_dam (beam). It does not explicitly contrast with any sibling, but the resource is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to choose this tool versus alternatives (e.g. dung_san for a flat slab), and no prerequisites or workflow context. The remaining lines explain parameter values rather than usage conditions.

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