Extrabold Tools Gridfinity

Generate Gridfinity Drawer Baseplate

generate_gridfinity_drawer_baseplate

Read-onlyIdempotent

Generate a Gridfinity baseplate sized to a known drawer preset. Supply measured drawer dimensions when available and the printer build volume; the tool automatically enables build-plate splitting when the baseplate does not fit.

Input Schema

Name	Required	Description	Default
`version`	No		5.3
`tolerance`	No	Experimental fit setting saved per printer. For dovetails, 0 mm gives the largest male tab; higher values make it smaller, up to 0.5 mm. Also affects CLICKbase clips and magnet holes. Print the tolerance test package to choose a dovetail fit. Normal bin pockets keep fixed geometry; the included bin-fit sample is a reference check. Values: none = 0 mm, tight = 0.1 mm, standard = 0.2 mm, loose = 0.3 mm, very-loose = 0.4 mm, extra-loose = 0.5 mm.	standard
`linkOrigin`	No		mcp
`marginType`	No		solid
`borderRadius`	No
`magnetHeight`	No
`baseplateType`	No		normal
`gridUnitDepth`	No
`gridUnitWidth`	No
`plateMarginMm`	No
`screwHeadSize`	No
`screwHoleSize`	No
`splitStrategy`	No		fewerParts
`toggleMagnets`	No
`drawerPresetId`	Yes	Exact preset id returned by find_gridfinity_drawer_presets.
`magnetDiameter`	No
`partsConnector`	No	Experimental dovetails interlock split pieces without separate parts and use your printer tolerance for male tabs. They require Split to Build Plates and work with all baseplate types. Clips connect split seams and optional outer edges; the printable clip model is included (not compatible with Skeleton).	none
`magnetDirection`	No		top
`magnetHoleStyle`	No		cylinder
`splitOffMargins`	No	Create outer margins as separate strips while keeping corners attached to top or bottom strips.
`toggleScrewHoles`	No
`measuredDimensions`	No	Measured drawer interior dimensions in millimeters. These override the approximate preset dimensions.
`printerBuildVolume`	Yes	The printer build volume used to decide whether this drawer-sized baseplate must be split.
`splitToBuildplates`	No	Override the automatic printer-fit split decision.
`connectMarginCrossings`	No	Also place a dovetail wherever a split edge crosses from grid cells into a margin region. Off: dovetails only at cell-to-cell crossings.
`removeHolesOnSplitLines`	No
`toggleMagnetReleaseHole`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 8, 2026

addedInput schema / properties / connectMarginCrossings

Added value: +{
+  "default": true,
+  "description": "Also place a dovetail wherever a split edge crosses from grid cells into a margin region. Off: dovetails only at cell-to-cell crossings.",
+  "type": "boolean"
+}

addedInput schema / properties / partsConnector / description

Added value: +"Experimental dovetails interlock split pieces without separate parts and use your printer tolerance for male tabs. They require Split to Build Plates and work with all baseplate types. Clips connect split seams and optional outer edges; the printable clip model is included (not compatible with Skeleton)."

addedInput schema / properties / tolerance / description

Added value: +"Experimental fit setting saved per printer. For dovetails, 0 mm gives the largest male tab; higher values make it smaller, up to 0.5 mm. Also affects CLICKbase clips and magnet holes. Print the tolerance test package to choose a dovetail fit. Normal bin pockets keep fixed geometry; the included bin-fit sample is a reference check. Values: none = 0 mm, tight = 0.1 mm, standard = 0.2 mm, loose = 0.3 mm, very-loose = 0.4 mm, extra-loose = 0.5 mm."

changedInput schema / properties / version / default
```
Previous value: -"0.5.21"New value: +"5.3"
```

Changed2 schema fields changedAug 12, 2026

addedInput schema / properties / splitOffMargins

Added value: +{
+  "default": false,
+  "description": "Create outer margins as separate strips while keeping corners attached to top or bottom strips.",
+  "type": "boolean"
+}

changedInput schema / properties / version / default
```
Previous value: -"0.5.20"New value: +"0.5.21"
```

First observedAug 5, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds that splitting is auto-enabled when the plate doesn't fit, but that behavior is also conveyed by the splitToBuildplates schema text ('Override the automatic printer-fit split decision'), and nothing is said about what the tool returns or how split results are delivered.

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?

Two front-loaded sentences with no filler: the core action comes first, followed by the input guidance and the auto-splitting behavior. Every sentence earns its place.

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 27-parameter tool with nested objects, four enums, no output schema and only 30% schema description coverage, the description is far too thin. It omits the return value, how a split result is surfaced, and any orientation around the large option surface an agent must navigate to call this correctly.

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 30% across 27 parameters, so the description bears heavy compensation burden but supplies almost none. It only gestures at measured drawer dimensions and printer build volume — parameters whose schema entries already explain themselves — leaving the other ~19 options (tolerance, baseplateType, splitStrategy, connectors, magnets, etc.) undocumented in the description.

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?

States a specific verb and resource ('Generate a Gridfinity baseplate') scoped to a 'known drawer preset', which separates it from the generic sibling generate_gridfinity_baseplate. An agent can tell it produces a drawer-sized plate keyed off a preset, but the description never explicitly names the sibling it contrasts with.

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?

It gives conditional guidance ('Supply measured drawer dimensions when available'), which tells the agent when measuredDimensions is worth filling in. However, it never names alternatives (e.g. generate_gridfinity_baseplate or find_gridfinity_drawer_presets for obtaining the preset id) or states when NOT to use this tool, so usage is implied rather than specified.

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

All Extrabold Tools Gridfinity tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?