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

create_drawing_page

Create a drawing sheet with selected size, orientation, and scale, then automatically add a plan view. Populate a French title block with project, client, and drawing details.

Instructions

Create a sheet: size A4/A3/A2/A1, landscape or portrait, print scale ("1:50"), with a French title block (cartouche) filled from projet, adresse, client (maitre d'ouvrage), titre (plan title), dessine, date (default today), numero, indice. Then call add_plan_view. Create the plan's dimensions and texts with scale= so they are readable on paper.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNo
nameNoFeuille
sizeNoA3
scaleNo1:50
titreNo
clientNo
indiceNo
numeroNo
projetNo
adresseNo
dessineNo
orientationNolandscape
title_blockNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It does reveal non-obvious behavior: a French title block is filled from specific fields, and date defaults to today. However, it does not mention side effects like whether a new page is appended or replaces an existing one, or whether an active document is required.

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 compact and front-loaded: the first sentence states the core operation and key parameters, the second gives the immediate follow-up, and the third explains the scale requirement. Every sentence adds practical value with no filler.

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 complex 13-parameter tool, the description is quite complete: it covers the sheet creation, the title block content, the follow-up add_plan_view call, and the scale rule for readable dimensions. It does not clarify how the created page connects to add_plan_view or what happens to an existing sheet, but an output schema exists and the workflow is mostly unambiguous.

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 0%, so the description must compensate, and it largely does: size, orientation, scale, and the French title-block fields (projet, adresse, client, titre, dessine, date, numero, indice) are all mapped. The 'name' parameter is not explained and the title_block boolean is only indirectly referenced, preventing a perfect score.

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 opens with a specific verb and resource: 'Create a sheet' and then enumerates the key attributes (size, orientation, scale, title block). It clearly differentiates itself from sibling tools like add_plan_view by presenting that as a follow-up action rather than part of this tool.

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?

The description gives explicit workflow guidance: after creating the sheet, 'call add_plan_view', and when creating dimensions/texts, use scale=<print scale denominator>. It does not enumerate when-not-to-use cases or alternatives, but the context is clear enough for an agent to sequence calls correctly.

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