Skip to main content
Glama
nakomis

nakomis-dragonfruit-mcp

by nakomis

mesh_info

Report an STL's triangle count, bounding box, size, and volume, and warn when dimensions or volume suggest wrong units or a non-closed mesh.

Instructions

Report an STL's triangle count, bounding box, size (mm) and volume (mm3 and ml).

Warns about sizes that suggest the wrong units and volumes that suggest the mesh is not a closed solid. Volume is the CLI's signed-volume sum, which cannot tell a closed mesh from an open one that happens to integrate sensibly; it does not report watertightness itself. The absence of the fill-ratio warning therefore proves nothing about whether the mesh is closed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stl_pathYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
sourceYesWhat the CLI read: stl, voxl or directory
size_mmYes
bbox_maxYes
bbox_minYesmm, in the file's own coordinate frame
verticesYesUnwelded: three per triangle
warningsNo
trianglesYes
volume_mlYesvolume_mm3 / 1000: the resin a solid print needs
volume_mm3YesSigned-volume integral, absolute value

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it does substantial work: it explains the warning conditions, states the volume is a signed-volume sum, and explicitly cautions that it does not report watertightness and that a missing fill-ratio warning proves nothing. What it omits is behavior on bad input (non-STL file, missing path) and permission/side-effect posture, though a reporting tool implies a safe read.

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 first sentence front-loads the four reported values, then the caveats follow. The three-sentence caveat block is a bit dense, but each sentence carries distinct, non-redundant information.

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?

An output schema exists, so return values need not have been explained, yet the description usefully clarifies their interpretation. For a single-parameter read tool with no annotations, it is nearly complete, lacking only input-failure behavior and an explicit usage routing against siblings.

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 0% for the single stl_path parameter, which is undocumented in the schema. The description implies the input is an STL file ('an STL's triangle count') but adds no path format, resolution, or error-handling semantics, so it only partially compensates.

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 names a specific verb and resource: reporting triangle count, bounding box, size, and volume for an STL. It is immediately distinguishable from siblings like engine_info or find_islands, but it never explicitly contrasts itself with them.

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

Usage Guidelines3/5

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

Usage is only implied — an agent infers it inspects a mesh before other geometry operations. There is no explicit when-to-use statement, no prerequisites, and no pointer to the sibling tools that might be the better choice for related queries.

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