Power CAD MCP

Overview Schema Source Related Servers Discussions Admin

add_mtext

Insert multiline text (MTEXT) in a CAD drawing with its top-left corner at a given insertion point; set color, layer, height, and wrap width.

Instructions

Add multiline text (MTEXT) with its top-left corner at the insertion point.

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": {
      "text": "<text>",
      "insert": "<insert>"
    },
    "name": "add_mtext"
  }
}

Input Schema

Name	Required	Description
`text`	Yes	Paragraph text; use \P for new lines
`color`	No	ACI 0-256 or name (red, yellow, green, cyan, blue, magenta, white, bylayer)
`layer`	No	Target layer (created if missing). Default: current layer.
`width`	No	Wrap width; 0 = no wrapping
`height`	No
`insert`	Yes	[x, y] or [x, y, z]

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 28, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), which the description does not contradict. The description adds the useful anchoring convention (top-left corner at insertion point) but says nothing about what happens on overlap, whether text can be edited later, or layer creation side effects mentioned only in the schema.

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?

A single, front-loaded sentence with zero filler that puts the resource and the distinguishing positioning rule in the first clause. It is efficient, though arguably too terse to route the agent among siblings.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and 83% parameter coverage, the description need not explain returns or most parameters, and the annotation set covers the safety profile. What is missing is sibling differentiation from add_text and any indication of when each text type is appropriate, which is material for a 38-tool CAD surface.

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 high at 83%, including \P line breaks, ACI color values, width/height defaults, and the [x,y,z] insert format, so the schema does the heavy lifting. The description only echoes the insert point and adds no parameter meaning beyond that, which is the baseline when the schema is well documented.

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 ('Add multiline text (MTEXT)') and adds the distinctive geometric anchor ('top-left corner at the insertion point'), which is meaningful for a text tool. However, it never distinguishes itself from the sibling add_text, leaving the agent to infer that MTEXT (paragraph) differs from single-line text.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool versus add_text, the obvious alternative for label text. No prerequisites (e.g., an open drawing) or exclusions are given, so selection between the two text tools is left entirely to inference.

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