Skip to main content
Glama

Check the plumbing project

plumbing
Read-only

Check plumbing layouts against NBR 5626/8160 codes: verify points, pipe sizes, traps, drains, and connections to water/sewer sources, identifying violations and missing elements for fixtures and areas.

Instructions

Plumbing project, NBR 5626 (cold and hot water) and NBR 8160 (sewer). Points are the plumbing pieces (catalog plumbing: cold-water, hot-water, sewer, valve, grease-trap, inspection-box, water-meter, gas-point, vent-pipe, and the drains as the models they are: floor-drain caixa sifonada 150x150x50, floor-drain-100, floor-drain-75 (150x185x75, up to 15 UHC), trap-drain-small (seal under 50 mm, no trap), dry-drain, linear-drain (w 50/70/90, no trap), linear-drain-trap, rain-drain for open areas; drains are set flush in the floor of a room, never in a wall, a door span or under a cabinet) and what a point is comes from its catalog, never its name; fixtures are the pieces that use water (toilet, basin, kitchen sink, shower, bathtub, washer, laundry sink, dishwasher). check (default): {points:{kind:count}, pipes_m, findings:[[sev, place, msg, src, key, accepted?]], pending, orphaned, sources} — a cold-water point by every fixture and a sewer point (or a floor drain for basin, shower, tub and machines) within reach, the discharge diameter it needs (toilet 100 mm, kitchen sink and machines 50, others 40); hot water where the project has any; a floor drain in every bathroom, kitchen and laundry, inside the shower area where there is one, at least one real trap (50 mm seal) per room, the UHC its outlet takes (50 mm: 6, 75 mm: 15), rain drains for open terraces; a grease trap for a kitchen sink; the premises — where the water comes from (water-meter or valve) and where the sewer goes (inspection-box or stack); points no drawn pipe of their kind reaches. orphaned lists acceptances whose finding is gone (the accept tool marks findings looked at, and its prune drops those). Pipe runs are laid with edit_plumbing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pointsYesPoints by kind
pendingYesFindings not accepted
pipes_mYesPipe metres: {cold, hot, sewer, vent}
sourcesYesStandards cited, by code: [title, tier, url]
findingsYesRows [severity erro|alerta|dica, place, message, source, key, accepted reason?]
orphanedYesAcceptances whose finding is gone: [key, reason, successor key?]

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already provide readOnlyHint=true and openWorldHint=false, and the description adds substantial behavioral detail: the exact default output structure, the validation rules, the meaning of orphaned findings, and the relationship to the accept tool and its prune behavior. There is no contradiction and the description goes well beyond the annotations.

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

Conciseness3/5

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

The description is information-dense and mostly earns its content, but it is a single long unstructured paragraph with many enumerations and sub-rules. It would be easier to parse with bullets or section breaks, and its front-loading is weak because it starts with NBR standards and piece classifications before stating the output structure.

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

Completeness5/5

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

For a complex, domain-specific checker with no parameters, the description is remarkably complete: it specifies the output shape, the checks performed, the relationship to orphaned acceptances, and the sibling editing tool. Combined with the presence of an output schema, the agent has enough context to invoke and interpret the tool correctly.

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?

The tool has zero parameters and an empty input schema, so there are no parameter semantics to document. The description references a default check ('check (default):') and defines its output, which is sufficient given the 0-parameter baseline.

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 title and description explicitly state a check action on the plumbing project, and the description details what the check returns (points, pipes_m, findings, pending, orphaned, sources). It also distinguishes itself from edit_plumbing by noting that pipe runs are laid with edit_plumbing, so an agent can tell this is a validation/audit tool rather than an editing 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 clearly implies this tool is for validating plumbing rules and explicitly says 'Pipe runs are laid with edit_plumbing', which is a useful when-not-to-use signal. However, it does not compare itself to other checking siblings like check_layout or explain when to prefer this over alternative checkers, so it falls short of fully explicit routing.

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