Skip to main content
Glama

set_smooth_shading

Set a mesh object's surface shading to averaged or flat, causing its faces to appear rounded or faceted.

Instructions

Set smooth or flat shading on an object.

TIP: For production use, prefer shade_auto_smooth which provides angle-based auto-smooth shading: it gives better results on hard-surface models by only smoothing faces within the angle threshold.

Args: object_name: Name of the mesh object. smooth: True for smooth shading, False for flat shading.

Returns: Confirmation dict.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
smoothNo
object_nameYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the boolean semantics and that a confirmation dict is returned, but says nothing about side effects, whether existing custom normals/auto-smooth data is overwritten, undo behavior, or any permission requirements. Adequate but thin for a state-mutating operation.

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?

Front-loads the purpose, then the routing TIP, then args. Well structured and short. The trailing "Returns: Confirmation dict" is redundant given an output schema exists, which costs a little.

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 simple two-parameter tool with an output schema present, the description covers purpose, both parameters, and the key alternative. It lacks only side-effect/interaction detail (e.g., effect on custom normals or auto-smooth settings) to be fully complete.

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 description coverage is 0%, so the description must compensate, and it does: it defines object_name and explains that smooth=True means smooth shading while False means flat. That adds meaning the schema's bare boolean/default do not convey. Minor gap in not noting that smooth defaults to true.

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?

States a specific verb and resource ("Set smooth or flat shading on an object") and immediately names the sibling it competes with, shade_auto_smooth, so an agent can tell the two apart without opening either schema. The scope (per-object shading mode toggle) 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 Guidelines4/5

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

The TIP gives explicit routing guidance: prefer shade_auto_smooth for production/hard-surface work because it smooths only within an angle threshold. That is a real alternative-with-condition statement. It stops short of a full 5 because it never states the positive case for using this tool (e.g., quick flat/smooth toggling on simple meshes).

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