Skip to main content
Glama
Sign In
orcaslicer-mcp

orcaslicer-mcp

by MaxEllis
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Delete a project file from disk

delete_project_file
Destructive

Permanently delete a .3mf OrcaSlicer project file from disk, not just File > Recent; confirm with the user and ensure Remote API project deletion is allowed.

Instructions

Delete a .3mf project file from disk for good; forget_recent_project only takes it off File > Recent.

There is no trash, and the file leaves File > Recent too. Only .3mf files can be deleted this way, and never the open project's own file: new_project or open_project first. Confirm with the user before calling this on a file they did not just ask to remove. OrcaSlicer refuses it (blocked_by_remote_api_policy) unless the user ticked Preferences > Remote API > 'Allow deleting and replacing project files'. Needs fork v2.4.2-mcp.15 or later.

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": {
      "path": "<path>"
    },
    "name": "delete_project_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesThe .3mf file to delete, on the OrcaSlicer host.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.21

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known; the description still adds non-obvious behavior — no trash, the file disappears from File > Recent too, hard refusal with blocked_by_remote_api_policy unless a specific Preference is enabled, and a minimum fork version. It does not describe the return/response payload, but the behavioral coverage is otherwise strong.

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-loads the distinction from forget_recent_project, then layers constraints, confirmation guidance, and gating requirements. Dense but every sentence carries information; the only minor repetition is between 'for good' and 'there is no trash'.

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 one-parameter destructive tool this covers the failure modes an agent needs before calling: file-type restriction, open-project exclusion, user confirmation, capability toggle, and version requirement. No output schema exists, but the gating error name is disclosed so the agent can interpret refusal.

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?

Only one parameter with 100% schema coverage, so the schema already explains path. The description nonetheless adds a real constraint beyond the schema: the path must be a .3mf file and must not be the currently open project's file.

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?

States a specific verb and resource (delete a .3mf project file from disk) and immediately contrasts it with the sibling forget_recent_project, which only removes it from File > Recent. The scope restriction to .3mf files further sharpens what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the alternative (forget_recent_project) and the condition selecting it, gives a hard precondition (new_project or open_project first; never the open project's own file), and adds a confirmation norm plus the Preference toggle and fork version required for the call to succeed.

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