Skip to main content
Glama
Hachimeder

maxplus2-mcp

by Hachimeder
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Clone a project for isolated work

project_clone

Copy a MAX+plus II project directory to a new folder, preserving filenames and verifying each copied file with SHA-256; optionally limit to source/design files.

Instructions

Copy the project directory into a new directory; preserve names and verify SHA-256 for every copied file. Default all; sources selects design extensions and explicit includePaths, avoiding old SCF/TBL/reports in large projects. Preserves originals, excludes backup stores. Does not infer external hierarchy dependencies; inspect and compile the copy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNoApply the described file change when true; otherwise return a preview. This is a tool argument, not a request for another user approval.
profileNoDefault all. sources copies ACF/GDF/SYM/HDL/INC/MIF/HEX/EDIF/ASM, while excluding other files unless named in includePaths.
projectYesExisting .acf project path or unambiguous project name. File paths are scoped to its directory.
directoryYesNew destination directory under workspace. Must not already exist or be inside the source directory.
workspaceNoWorkspace directory for resolving project names, or the scope when no project is supplied.
includePathsNoExplicit files to retain, e.g. a stimulus SCF/VEC or memory asset with an unusual extension. Each must exist within the source directory.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.3

TDQS

A4.1/5.0
Behavior4/5

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

Adds real behavioral context beyond annotations: SHA-256 verification of each copied file, 'Preserves originals', 'excludes backup stores', and the caveat that it does not infer external hierarchy dependencies. This is consistent with destructiveHint=false and adds meaningful edge-case disclosure, though it omits failure/rollback behavior.

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 core purpose and reasonably tight at three sentences. Minor awkwardness from the telegraphic 'Default all;' fragment, but no wasted content.

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 clone tool with no output schema and fully documented params, the description covers the copy semantics, integrity checking, exclusions, and required follow-up steps. It does not describe the return/preview payload, but otherwise an agent has enough to invoke it correctly.

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 already 100%, so the schema fully documents all six parameters. The description restates the profile enum behavior (already in schema) and adds only the 'avoiding old SCF/TBL/reports' rationale, which is marginal added value. Baseline 3 is appropriate.

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: 'Copy the project directory into a new directory'. An agent can immediately distinguish this from sibling project_create or project_restore_file because the copy-into-new-directory behavior is stated up front.

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?

Explains profile selection ('Default all; sources selects design extensions ... avoiding old SCF/TBL/reports in large projects') and suggests a follow-up workflow ('inspect and compile the copy'). Clear context, but it never explicitly states when NOT to use this tool or names an alternative.

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