Skip to main content
Glama
gchen19

AnkusDrive

by gchen19
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Pocket

pocket

Cut a recess into a solid by removing a pad-shaped volume of specified length. Handles through-wall cuts, shelled bodies, and warns if the cut removes nothing or the entire body.

Instructions

Subtract a pad of length mm from the body. through_all ignores length.

through ('wall'|'body'): preferred over through_all. 'wall' ray-casts the body to find the first exit boundary and cuts exactly one wall thick — correct for solids (one wall = full thickness) AND shelled bodies. 'body' is the legacy ThroughAll; on a shelled body it punches through every wall and ruins the cavity. Implies direction='into_body'. Result carries wall_depth_mm so the caller can verify. direction (preferred over reversed): 'into_body' makes the cut actually remove material; 'away_from_body' extrudes outside the body. The tool probes both Reversed values and picks the one matching intent. reversed: legacy raw flag, used only if neither through nor direction is set. strict: raise instead of warning on a degenerate pocket (see below).

Returns {handle, name, volume, removed_volume, volume_ratio}, plus warnings ONLY when the pocket removed the whole body or removed nothing (the same two degenerate outcomes as boolean_op's cut). Warn-don't-fail is the default; pass strict=True in a scripted recipe to turn both into an error instead. direction='away_from_body' is an explicit request to remove nothing, so it never warns and never raises.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoPocket
lengthNo
sketchYes
strictNo
throughNo
reversedNo
directionNo
through_allNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.5
    • addedInput schema / properties / strict
      Added value: +{
+  "default": false,
+  "title": "Strict",
+  "type": "boolean"
+}
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

The description thoroughly discloses behavior beyond the sparse annotations: how `through` ray-casts and cuts shelled bodies, how `direction` probes Reversed values, the warn-don't-fail default, and the degenerate whole-body/removed-nothing outcomes. The only transparency flaw is an internal inconsistency: it claims "Result carries wall_depth_mm," but the subsequent return list `{handle, name, volume, removed_volume, volume_ratio}` does not include `wall_depth_mm`.

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 description is long but densely organized, with each parameter getting its own line and the core behavior front-loaded first. Most sentences earn their place, though the wall_depth_mm/return-list inconsistency adds confusion. For an 8-parameter tool, the length is justified.

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 no output schema and sparse annotations, the description covers the main invocation-critical details: purpose, parameter semantics, return fields, warning behavior, and exception handling. It is not fully complete because the required `sketch` parameter is unexplained and the return shape is internally inconsistent regarding `wall_depth_mm`.

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 carries the full burden. It does this well for most parameters: `length`, `through_all`, `through`, `direction`, `reversed`, and `strict` all receive meaningful semantics beyond the bare schema. The required parameter `sketch` is never explicitly explained, and `name` is also omitted, so the coverage is not complete.

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 first sentence, "Subtract a pad of `length` mm from the body," states a specific verb, resource, and dimension in one clear statement. It also signals that this is the subtractive counterpart to the sibling `pad` tool. The additional line about `through_all` ignoring length adds a precise behavioral distinction.

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?

There is strong internal guidance: `through` is "preferred over through_all," `direction` is "preferred over reversed," and the shelled-body warning tells the user which mode to avoid. However, the description never explicitly says when to choose this tool over alternatives such as `boolean_op`, `hole`, or `pad`; the usage context is mostly implied by the name and first sentence.

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