Skip to main content
Glama
Meteor-Simulation

BULC MCP

Official

Draw set wall params

draw_set_wall_params
Idempotent

Set default wall height and thickness for 2D drawings so geometry uses consistent dimensions in BULC MCP fire simulations.

Instructions

Set default wall height and thickness for 2D drawing [bulc-mcp rules] EVAC-001, GEO-002 — bulc_knowledge_search ""

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
wallHeightNoWall height (m, default 3.0)
wallThicknessNoWall thickness (m, default 0.2)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.0.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and closed-world, so the safety and idempotency profile is covered. The description adds the crucial scope detail that these are defaults for future drawings, not retroactive edits, but omits any mention of required permissions or what happens to already-drawn walls.

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 core sentence is a tight, front-loaded statement of purpose. The appended rule-reference line is cryptic and arguably noise, but it is short and does not bury the main content.

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 two-param, fully-specified schema with a clear annotation profile, the core description is adequate. What is missing is the scope clarification that these are defaults applied to future drawing operations, plus any explanation of the referenced rules.

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 100%, with both wallHeight and wallThickness documenting units (m) and defaults (3.0, 0.2). The description adds nothing beyond the schema, so baseline 3 applies.

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?

States a specific verb (set) and resource (default wall height/thickness for 2D drawing). Distinguishes itself from draw_set_door_params and draw_set_window_params by naming walls explicitly, though it does not call out those siblings.

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?

No when/when-not guidance or mention of alternatives. The trailing '[bulc-mcp rules]' line references EVAC-001 and GEO-002 with a bulc_knowledge_search call suggestion, which is opaque rule jargon rather than actionable usage context.

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