Skip to main content
Glama
Stv-devl
by Stv-devl

create_line

Draw a straight line between two [x, y] points in millimeters, optionally on a named layer.

Instructions

Draw a straight line between two [x, y] points (mm), optionally on a named layer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endYes
layerNo
startYes
fit_viewNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. 'Draw' clearly conveys a mutating creation operation, and the named-layer option adds useful context. However, it does not explain what happens when layer is null, nor does it mention the fit_view side effect, which are meaningful behavioral details.

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 description is one front-loaded sentence where every clause adds information: the operation, the geometric primitive, coordinate format, units, and layer option. There is no filler or redundancy.

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?

For a simple drawing tool with an output schema, the core behavior is understandable and identifiable among many siblings. However, the unexplained fit_view parameter and unspecified layer-null behavior leave gaps that an agent would need to infer or probe.

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 0%, so the description must compensate. It explains start and end as [x, y] points in mm and layer as optional, but it leaves fit_view entirely unexplained and does not state that the point arrays must contain exactly two numbers. This is partial, not complete, compensation.

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?

The description states a specific verb ('Draw') and resource ('straight line between two [x, y] points'), includes units (mm), and notes the optional layer. This clearly distinguishes it from siblings like create_polyline, create_circle, and create_rectangle without requiring schema inspection.

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

Usage Guidelines3/5

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

The description implies when to use it by naming the exact primitive, but it never explicitly contrasts it with alternatives such as create_polyline for multi-segment lines or create_wall_2d for walls. Usage is inferable rather than stated, so it meets the minimum but leaves selection partly to the agent.

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