Skip to main content
Glama
Sign In
WinProLadder MCP

WinProLadder MCP

by Syrup2718
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_capabilities

Read-only

Retrieve server-wide support, policy, limits, build/version, scope, workspace, and artifact-delivery metadata only; set detail=true to expand instruction-specific limits.

Instructions

Return server-wide support, policies and limits as metadata only.

    Includes build/version, generation and simulation scope, architecture policy, workspace,
    output directory and artifact delivery. detail=true expands instruction-specific limits.
    This never reads or modifies program content; use modify_network to edit one network.
    PLC access and artifact rename/delete are intentionally outside this offline server.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_capabilities"
  }
}

Input Schema

NameRequiredDescriptionDefault
detailNoFalse returns the compact server summary; true includes full instruction, generation and simulation capability details.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.1
    • addedInput schema / properties / detail / description
      Added value: +"False returns the compact server summary; true includes full instruction, generation and simulation capability details."
  2. Changed1 schema field changedv1.0.0
    • addedInput schema / properties / detail
      Added value: +{
+  "default": false,
+  "title": "Detail",
+  "type": "boolean"
+}
  3. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral facts beyond that: it never reads or modifies program content, and it is an offline server with deliberately excluded operations (PLC access, artifact rename/delete). The only missing piece is any note on output shape, which the output schema covers.

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?

The scope statement is front-loaded, followed by content enumeration, the mode toggle, and boundaries. Every sentence carries information, though the included-content list is somewhat dense and the boundaries could be tightened.

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?

With an output schema present, return values need not be described. The description covers purpose, scope, the detail toggle's effect, and explicit exclusions, which is sufficient for a low-complexity single-parameter metadata tool. Minor gap: no hint at how it relates to the instruction-specific capability sibling.

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 coverage is 100% and the single 'detail' parameter is already documented as returning compact vs. full details. The description restates this ('detail=true expands instruction-specific limits') with a slight scoping nuance toward limits rather than generation/simulation details, but adds little beyond what the schema already says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Return server-wide support, policies and limits as metadata only') and enumerates the content domains it covers (build/version, generation and simulation scope, architecture policy, workspace, output directory, artifact delivery). It is clearly distinguishable from sibling tools like modify_network, though it does not explicitly position itself against get_instruction_capabilities, which the detail flag arguably overlaps with.

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 gives explicit when-to-use context ('as metadata only'), names the alternative for editing ('use modify_network to edit one network'), and declares out-of-scope behaviors (PLC access, artifact rename/delete). It stops short of full when-not guidance, e.g. when to prefer get_instruction_capabilities over detail=true.

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