Skip to main content
Glama
Sign In
mcp-spatial-critic

mcp-spatial-critic

by vanovri
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

audit_stl

Validate STL models by checking manifoldness, shell connectivity, inverted normals, and plate grounding. Evaluate mesh structural integrity and readiness for printing before slicing or 3D production.

Instructions

Audit a STL mesh for watertightness/manifoldness, build-plate grounding, disconnected shells, inverted normals and thin features.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "audit_stl"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesPath to a .stl file
min_wall_mmNo
min_z_tolerance_mmNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries full behavioral burden. It usefully discloses the specific checks performed, but omits whether the operation is read-only, what errors or side effects may occur, and what the result looks like. This is adequate but incomplete.

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?

A single front-loaded sentence lists the audit dimensions efficiently with no wasted language. Every phrase contributes to defining the check.

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?

There is no output schema and no annotations, so the description should explain return values and parameter meanings. It describes the checks but not what the agent receives back or how the numeric threshold parameters affect the audit, leaving significant gaps.

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 33%: only path is documented. The description does not explain min_wall_mm or min_z_tolerance_mm, despite their names hinting at thresholds. It fails to compensate for the low schema coverage.

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 uses a specific verb (Audit) and resource (STL mesh) and enumerates the exact defect classes checked, making the tool's purpose unambiguous and distinct from the unrelated sibling tools.

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?

The auditing purpose implies when to use it, but there is no explicit guidance on prerequisites, when not to use it, or how it compares to any alternative. The siblings are unrelated, so the lack of differentiation is less harmful, but usage remains only implied.

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