Skip to main content
Glama
AstroQuestStudio

catia-v5-mcp

catia_add_new_part

Creates a new empty part in an assembly or sub-assembly using a specified part number. Model and save it before designating faces for constraints.

Instructions

Create a new empty Part inside the assembly (or a sub-assembly), with its part number. It must be modelled and then saved (catia_save_all) before faces can be designated for constraints.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
parentNoSub-assembly path (default: root).
part_numberYesPart number, e.g. 'Shaft_A'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare non-readOnly, non-destructive, non-idempotent, so the safety profile is covered. The description adds genuinely non-structured context: the created part starts empty, and it must be saved via catia_save_all before faces become constrainable — a real behavioral dependency an agent must respect.

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 sentences, no filler, and the core action ('Create a new empty Part...') is front-loaded before the workflow caveat. Every clause carries information.

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 two-parameter creation tool with no output schema and adequate annotation coverage, the description supplies the essential prerequisite chain (create → model → save → constrain). The only gap is the absence of disambiguation from the near-identical sibling catia_new_part.

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 description coverage is 100% (both 'parent' and 'part_number' are documented inline with an example), so the schema carries the parameter burden. The description only echoes 'with its part number' and implies the assembly/sub-assembly target, adding no syntax or format detail beyond the schema.

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 ('Create a new empty Part') plus scope ('inside the assembly (or a sub-assembly), with its part number'). Clear on its own, but it never distinguishes itself from the sibling tools catia_new_part and catia_add_sub_assembly, which an agent could easily confuse with this one.

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?

Gives a valuable sequencing rule ('must be modelled and then saved (catia_save_all) before faces can be designated for constraints'), which tells the agent where this step sits in the workflow. However, it never says when to pick this over catia_new_part or catia_add_component, so the selection guidance is 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