aras-plm-mcp

aras_plan_delete

Assess deletion consequences before removing an item: check affected generations, release/lock state, and referenced relations to prevent accidental data loss.

Instructions

ANALIZZA cosa comporterebbe cancellare un elemento, SENZA cancellarlo: quante generazioni sparirebbero, se e' rilasciato, se e' bloccato, e in quali relazioni e' ancora referenziato. Da chiamare SEMPRE prima di cancellare. Distingue purge (una generazione) da delete (tutte).

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": {
      "itemType": "<itemType>",
      "id": "<id>"
    },
    "name": "aras_plan_delete"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes
`modo`	No	purge = solo questa generazione; delete = tutte le generazioni	purge
`itemType`	Yes
`relazioni`	No	Relazioni da controllare; default: le relazioni note dell'ItemType

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 23, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It explicitly states the tool does NOT delete (SENZA cancellarlo), clarifying its non-destructive nature. It also discloses the two modes (purge/delete) and what it analyzes (generations, release, block, references). It does not detail return format or error behavior, but the core behavioral transparency is present.

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 fluff. The primary purpose (non-destructive analysis) is front-loaded, followed by the key behaviors and the purge/delete distinction. Every word adds value.

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 4 parameters, no output schema, and no annotations, the description covers the tool's purpose, its non-destructive nature, the parameters' semantic differences, and the types of information returned (generations, release, block, references). It could specify the response format or prerequisites, but for a planning tool it is reasonably complete.

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 50%, and the description adds meaning to the 'modo' parameter by explaining purge vs delete. It also clarifies the purpose of the 'relazioni' parameter (which relations are checked) and implies the context of id/itemType. The description compensates for the partially covered schema by explaining the tool's operation, though id/itemType remain self-evident but undocumented.

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 description clearly states the tool analyzes the impact of deleting an element without performing the deletion. It lists specific outputs (generations lost, released/blocked status, references) and distinguishes between purge and delete. This is a specific verb (ANALIZZA) on a resource (deletion impact) and distinguishes itself from aras_delete_item among siblings.

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?

The description explicitly instructs the agent to always call this before deleting, which is a clear when-to-use condition. It also explains the difference between purge and delete, aiding parameter selection. However, it does not name the alternative tool (aras_delete_item) for the actual deletion step, though the intent is implied.

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

Deploy Server