Skip to main content
Glama
Sign In
swdraw

swdraw

by leahmartinez
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

swdraw_build_drawing

Build a SolidWorks drawing from a YAML spec, including views, dimensions, GD&T, title block, and PDF/PNG export, with self-checks for failed steps.

Instructions

Build the ACTIVE SolidWorks drawing from a spec: scale, clear, layout, sections, details, self-checked dimensions, GD&T, leader notes, notes block, title block, fonts, PDF/PNG export. Does not save. spec_path must be absolute. steps runs a subset (e.g. ["clear", "dimensions", "gdt", "export"]). Look at result.check and the PNG afterwards.

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": {
      "spec_path": "<spec_path>"
    },
    "name": "swdraw_build_drawing"
  }
}

Input Schema

NameRequiredDescriptionDefault
stepsNo
strictNo
spec_pathYes
title_blockNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.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 does add real behavioral context: it operates on the ACTIVE drawing, it does NOT save, dimensions are self-checked, and the agent should inspect result.check and the PNG. It stops short of stating permissions, side effects on existing drawing content, or whether the non-save result is discardable.

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?

Dense and front-loaded: purpose first, then the capability list, then the key constraints (does not save, absolute path, steps subset) and the verification hint. No wasted sentences, though the long comma-run capability list is packed tightly.

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?

A mutation tool with no annotations and an output schema. The description supplies the crucial non-obvious details (active-document scope, no save, absolute spec_path, post-run check) that the structured fields lack. Only the undocumented `strict`/`title_block` parameters and permission requirements are unaddressed.

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 coverage is 0%, so the description must compensate. It meaningfully documents `spec_path` (must be absolute) and `steps` (subset selection with an example), but leaves `strict` and `title_block` entirely unexplained in both schema and prose.

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 (Build) and resource (the ACTIVE SolidWorks drawing from a spec), and enumerates the operations performed (scale, layout, dimensions, GD&T, export). It distinguishes itself by scoping to the active drawing and being spec-driven, though it never names a sibling like swdraw_revise or swdraw_validate_spec to sharpen the boundary.

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 example for `steps` (["clear", "dimensions", "gdt", "export"]) implies partial-run usage and the closing note implies a verification workflow, so usage is inferable. It never states when to prefer this over siblings such as swdraw_revise or swdraw_validate_spec, nor any prerequisites.

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