Skip to main content
Glama

Check a floor plan

check_floorplan
Read-onlyIdempotent

Requires a free Messe Atlas account (sign in when prompted). Checks an exhibition floor plan against published default safety and layout limits — no AI, deterministic: stand overlaps, keep-clear gangways, fire-point halos, 4 m entrance strips, rows ≤ 30 m, gangways ≥ 3 m, travel distance ≤ 61 m, dead ends ≤ 18 m, stand area ≤ 2 × gangway area, exit width at 5 mm per person, gate lines, power pits. Coordinates in metres, origin at the hall's north-west corner, x east, y south. plan is either the short form {hall: {w, l} (or space_id), exits: [{id, kind: public|fire|folding|service|open, a: [x,y], b: [x,y]}], stands: [{id, x, y, w, d, door_side?: n|e|s|w}] (x, y = the stand's north-west corner), features?: [{id, x, y, w, d}], peak_people} or the full L2 plan dict (hall|site, exits, units, solids, keep, fire, peak). space_id (from get_venue_spaces) supplies the hall only when Atlas holds its outline; otherwise send the hall inline. Returns ok, every check with rule, value, limit and source, a summary (stands, m² sold, gangway m², ratio), limits_status, a preview_url (SVG, 24 hours) and a disclaimer. Convex polygons only; at most 2,000 objects and 160,000 m². Free accounts get 3 successful checks a month, Pro 30, Team and Enterprise unlimited; invalid plans are not counted.

Input Schema

NameRequiredDescriptionDefault
planYesThe short form (stands, exits, hall or space_id, features, peak_people) or the full L2 plan dict (hall|site, exits, units, solids, keep, fire, peak). Metres; origin north-west; at most 512 KB of JSON.
space_idNoVenue space id or slug from get_venue_spaces / search_venue_spaces (short form only). Used for the hall only when its geometry_status is outline or better.
confirmed_onlyNoLeave out exits listed in the plan's pending_exits (awaiting the venue's confirmation).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover safety (readOnly/idempotent/non-destructive), but the description adds substantial context beyond them: determinism ('no AI'), the account/rate-limit regime per tier, the 24-hour SVG preview URL, the returned fields, and hard input bounds (convex polygons, ≤2,000 objects, ≤160,000 m²). This is rich behavioral disclosure well past the annotation bar.

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?

Front-loads the account requirement then the rule list, the coordinate contract, the plan shape, the return payload and the limits in a logical order. Dense and mostly every sentence earns its place, though the plan-shape prose partially duplicates the schema and could be trimmed.

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?

With no output schema, the description still names what is returned (ok, per-rule results with rule/value/limit/source, summary, limits_status, preview_url, disclaimer), states the input limits, the coordinate system, and the quota behavior. An agent has everything needed to call and interpret this 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?

Schema coverage is 100% for the top-level params, so baseline is 3, but the description meaningfully supplements the nested shapes it doesn't detail: coordinate origin (hall's north-west corner), axis directions (x east, y south), exit kind values, exit endpoint pairs, and door_side placement. The full L2 plan alternative is also disambiguated. Slightly short of 5 only because some of this detail could be pushed into the schema.

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?

States a specific verb and resource — checking an exhibition floor plan against published safety/layout limits — and enumerates exactly which rules are evaluated (stand overlaps, gangways, travel distance, exit width, etc.). No sibling tool does anything similar, so the agent can distinguish it immediately.

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?

Explains that a free Messe Atlas account is required and sign-in is prompted, and points to get_venue_spaces as the source of space_id. Monthly quota tiers (3/30/unlimited) and the note that invalid plans are not counted further inform the decision to call. No explicit when-not-to-use or alternative routing is given, but no sibling alternative exists.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources