Skip to main content
Glama

Show or hide disciplines

edit_disciplines

Select or hide plan disciplines and layers (electrical, plumbing, lighting, appliances, joinery) to control what appears in plan and 3D views.

Instructions

Change what the plan shows. select {d: electrical|plumbing|architecture}: new symbols (catalog cat electrical/plumbing) and lines go there and the rest is dimmed; select architecture hides the electrical and plumbing projects (show brings one back); select a project shows it with the architecture dimmed. show/hide {d}, where d can also be a layer of the plan — lighting (lamps, spots, LED), appliances (fridge, stove, oven, hood, washer…) or joinery (cabinets, wardrobes, countertops): hidden from the plan, its exports and the 3D. The 3D follows the plan unless show_all_3d=true, which makes it show everything. Pieces are in a layer by what they are; update(layer=lighting|appliances|joinery|none) overrides it. What is shown now is the disciplines tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dNo`electrical`, `plumbing` or `architecture`; for show/hide also a plan layer: `lighting`, `appliances` or `joinery`
actionNo`select`, `show` or `hide`
show_all_3dNoWhether the 3D shows everything (true) or hides what the plan hides (false). Applies with any action

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
activeNoDiscipline drawn on top: electrical, plumbing, or null
hiddenNoDisciplines hidden
layersNoPlan layers: {lighting, appliances, joinery} → {pieces, hidden}
lines_cmNoaction=quantities: drawn lines by discipline, cm
plumbingNoaction=quantities: [kind, count, names?]
electricalNoaction=quantities: [kind, count, names?]
show_all_3dNoEvery discipline shown in 3D

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses what gets dimmed or hidden, how exports and 3D are affected, and how show_all_3d modifies behavior. This is substantive context that goes beyond the structured annotation data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense, run-on paragraph mixing multiple actions and referencing 'update' in a confusing way. It lacks bullet points or clear separation of concepts, making it longer and harder to parse than necessary.

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?

The description covers behavioral effects well, but it introduces confusion with 'update' and does not address prerequisites or failure conditions. Since an output schema exists, return values need not be explained, but the applicability of the tool could be clearer.

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 100%, so the baseline is 3. The description adds real value by explaining the practical effects of each d and action value, listing example items per layer, and detailing show_all_3d interactions—going beyond the schema's short parameter descriptions.

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 opening 'Change what the plan shows' states a clear verb+resource, and the description elaborates on select/show/hide behaviors. It doesn't explicitly contrast with sibling tools like show_plan, but the core purpose is clear.

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 usage through examples (select architecture hides electrical/plumbing, show/hide layers) but gives no explicit guidance on when to prefer this tool over alternatives. The mention of 'update' as a layer override is not framed as a when-to-use comparison.

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