WinProLadder MCP

Overview Schema Source Related Servers Discussions Admin

export_ldr

Re-encode an existing .ldr into a new .ldr artifact for a lossless round trip, preserving unknown payloads and CRC validity; the source stays untouched and existing output names are rejected.

Instructions

Re-encode one existing .ldr into a separate new .ldr artifact.

    Use this for a lossless round trip that preserves unknown payloads and the source file's CRC
    validity state; it does not change network logic. The source remains untouched and an
    existing output_name is rejected. Returns the new artifact link, size, SHA-256 and warnings.
    Use modify_network to insert, replace or delete logic, or generate_ldr for new Ladder IR.

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>",
      "output_name": "<output_name>"
    },
    "name": "export_ldr"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes	Existing .ldr source path inside the configured workspace.
`output_name`	Yes	New plain .ldr filename in the artifact directory; never overwrites.

Output Schema

Name	Required	Description
`error`	No	Structured error code, message and written=false on handled validation failure.
`artifact`	No	Artifact metadata on success; absent when validation fails before writing.
`warnings`	No	Generation or verification warnings; empty when none were reported.
`diagnosis`	No	Structured LDR generation failure diagnosis; absent on success.
`response_mode`	Yes	Whether repeated design metadata was compacted or returned in full.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.1.1Nov 11, 2026

addedInput schema / properties / output_name / description

Added value: +"New plain .ldr filename in the artifact directory; never overwrites."

addedInput schema / properties / path / description

Added value: +"Existing .ldr source path inside the configured workspace."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$defs": {
+    "ArtifactDescriptor": {
+      "description": "Download metadata shared by generated and retrieved artifacts.",
+      "properties": {
+        "mime_type": {
+          "description": "Media type of the returned bytes.",
+          "title": "Mime Type",
+          "type": "string"
+        },
+        "name": {
+          "description": "Plain artifact filename.",
+          "title": "Name",
+          "type": "string"
+        },
+        "sha256": {
+          "description": "Lowercase SHA-256 digest of the exact artifact bytes.",
+          "title": "Sha256",
+          "type": "string"
+        },
+        "size": {
+          "description": "Artifact size in bytes.",
+          "minimum": 0,
+          "title": "Size",
+          "type": "integer"
+        },
+        "uri": {
+          "description": "MCP resource URI for the artifact bytes.",
+          "title": "Uri",
+          "type": "string"
+        }
+      },
+      "required": [
+        "uri",
+        "name",
+        "mime_type",
+        "size",
+        "sha256"
+      ],
+      "title": "ArtifactDescriptor",
+      "type": "object"
+    }
+  },
+  "additionalProperties": true,
+  "description": "Structured result for artifact-writing and artifact-retrieval tools.",
+  "properties": {
+    "artifact": {
+      "anyOf": [
+        {
+          "$ref": "#/$defs/ArtifactDescriptor"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "description": "Artifact metadata on success; absent when validation fails before writing."
+    },
+    "diagnosis": {
+      "anyOf": [
+        {
+          "additionalProperties": true,
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "description": "Structured LDR generation failure diagnosis; absent on success.",
+      "title": "Diagnosis"
+    },
+    "error": {
+      "anyOf": [
+        {
+          "additionalProperties": true,
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "description": "Structured error code, message and written=false on handled validation failure.",
+      "title": "Error"
+    },
+    "response_mode": {
+      "description": "Whether repeated design metadata was compacted or returned in full.",
+      "enum": [
+        "compact",
+        "full"
+      ],
+      "title": "Response Mode",
+      "type": "string"
+    },
+    "warnings": {
+      "description": "Generation or verification warnings; empty when none were reported.",
+      "items": {},
+      "title": "Warnings",
+      "type": "array"
+    }
+  },
+  "required": [
+    "response_mode"
+  ],
+  "title": "ArtifactToolOutput",
+  "type": "object"
+}

Changed1 schema field changedv1.0.0Oct 28, 2026

changedOutput schema / (root)

Previous value: -{
-  "additionalProperties": true,
-  "title": "export_ldrDictOutput",
-  "type": "object"
-}New value: +null

First observedv0.1.0Sep 11, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare a non-destructive, closed-world mutation, and the description adds real behavior beyond them: the source is untouched, an existing output_name is rejected rather than overwritten, unknown payloads and CRC validity state are preserved, and network logic is unchanged. That is exactly the extra context a write-shaped tool needs on top of destructiveHint=false.

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?

The core action is front-loaded in the first sentence, followed by behavioral guarantees and then alternative routing. Every sentence earns its place; no filler or restatement of the tool name.

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?

With an output schema present, return values need not be enumerated, yet the description still names artifact link, size, SHA-256 and warnings as a courtesy. Annotations cover the safety profile and the schema fully documents both parameters, so nothing an agent needs to call this correctly 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 100%, so the baseline is 3, but the description adds meaning the schema does not: an existing output_name is rejected, i.e. the value must be new and never collides. It does not elaborate on path resolution beyond the schema's 'inside the configured workspace', so it stops short of a 5.

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 ('Re-encode one existing .ldr into a separate new .ldr artifact') with the scope of the operation made explicit. The contrast with modify_network and generate_ldr makes it trivially distinguishable from the siblings that also produce or change .ldr files.

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?

Gives an explicit when-to-use ('lossless round trip that preserves unknown payloads and the source file's CRC validity state') plus explicit routing away: modify_network for insert/replace/delete, generate_ldr for new Ladder IR. Nothing about tool selection is left to inference.

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