Skip to main content
Glama

proj_delete_variant

Delete a project variant and all its component variation entries, reporting how many entries were removed so you can confirm the impact before and after.

Instructions

Delete a project variant, with every component variation in it.

THIS IS NOT REVERSIBLE FROM HERE. A variant's entries record which components are not fitted and which carry an alternate part, and DM_RemoveProjectVariant is the ONLY write in Altium's whole variant API. There is no scripted way to add a variation entry back, so deleting a variant with fifty entries costs fifty decisions that have to be re-made in the Variant Management dialog. The reply reports entries_removed so the size of that is on the record; read it with proj_list_variants first if the variant is not one you created.

The variant is addressed by name rather than index, because removing one renumbers the rest: two deletions by index taken from a single listing would remove the wrong second variant.

Args: variant_name: name of the variant to remove. project_path: optional project path; defaults to the focused project.

Returns: {"success": true, "variant_name": ..., "entries_removed": N, "variant_count_before": N, "variant_count_after": N, "verified": true}, or success: false with a reason when the variant is still listed afterwards.

Input Schema

NameRequiredDescriptionDefault
project_pathNo
variant_nameYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: irreversible, only write in the variant API, no scripted way to restore variation entries, and a concrete cost model (fifty entries = fifty re-made decisions). It also discloses the failure mode ('success: false' with a 'reason' when the variant is still listed afterwards).

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-loaded with the action and the irreversible warning, and nearly every sentence adds information. The explicit 'Returns' block is somewhat redundant given an output schema exists, and the Args/Returns docstring formatting adds length without adding navigational value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, annotation-free, two-parameter mutation this covers what an agent needs: irreversibility, restoration cost, the addressing scheme, the default for the optional parameter, and the shape of both success and failure outcomes. Nothing material is missing.

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 coverage is 0%, so the description must compensate; it explains both parameters, including that project_path is optional and defaults to the focused project. It also adds genuine semantics beyond the schema by justifying name-based addressing ('removing one renumbers the rest'), though the variant_name gloss is close to restating the field name.

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?

Specific verb + resource ('Delete a project variant') with an explicit scope qualifier ('with every component variation in it'). It is clearly distinguishable from proj_create_variant and proj_list_variants, and an agent can tell what it operates on without opening the schema.

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?

It names the pre-check alternative explicitly: 'read it with proj_list_variants first if the variant is not one you created', which routes the agent to a sibling before committing. It also states the irreversibility precondition, but does not enumerate other alternatives (e.g. deactivating vs deleting) or say when deletion is inappropriate.

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