Skip to main content
Glama
UHQ-Actual
by UHQ-Actual

Estimate Annual Dollar Volume (ADV) and FLSA $500K Coverage Flag

adv_estimate

Calculates an estimated annual dollar volume (ADV) screening signal for FLSA enterprise-coverage triage using employee count, capacity data, or chain per-unit figures. Returns method, range, and confidence level.

Instructions

Deterministic ADV screening calculator for FLSA enterprise-coverage triage. Encodes Methods 1-4 (per-employee, capacity-derived, chain per-unit, format default), the geographic multiplier, ±40% range math, and the $500,000 FLSA flag (Above / Below / Borderline / Insufficient Data). NOT a coverage determination — screening signal only. Method selection priority: chain per-unit ADV > employee count > capacity input > format default. Method 2 capacity input priority (highest first): seatCount > occupantLoad (×0.85 → seats) > squareFootage (BOH subtract + IBC 15-sqft-per-occupant + ×0.85) > parkingSpaces (× format-typical seats-per-space). Always pass capacitySource so the audit trail records where the number came from. Best practice: read employeeCount from osha_inspection_search results and pass it in here when an OSHA inspection record exists for the establishment (employee_count is a required OSHA field). Returns separate columns for estimate, range, method, capacity_input, capacity_source, flsa_flag, confidence, and a derivation-chain notes string.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNoRestaurant format, optionally with cuisine qualifier (e.g. 'Casual dining — Italian', 'Pizzeria', 'Fast food'). Lead term is normalized; cuisine after em-dash is ignored for benchmarks. Required for Methods 2 and 4.
areaTypeNoArea tier for the cost-of-living multiplier. major_metro = 1.20×; mid_metro = 1.00× (default); small_or_rural = 0.85×. Get this from census_area_profile.
bohRatioNoOverride the default back-of-house fraction (0.30 FSR / 0.40 LSR / 0.35 Unclear) for square-footage derivation. Use when you have a verified BOH split.
chainFlagNoWhether the establishment is part of a multi-location brand. Drives Method 3 selection and adds the enterprise-coverage caveat to notes when Yes.
seatCountNoDirect dining seat count. Highest-confidence Method 2 capacity input. Sources: published menu, OpenTable / Resy / Tock inventory, owner interviews, news articles. Confidence: Medium.
serviceTypeNoService type. Required for Method 1 per-employee benchmarks; also drives default BOH ratio for square-footage derivation (FSR=30%, LSR=40%, Unclear=35%). Defaults to Unclear if omitted.
occupantLoadNoPosted maximum occupant load from Certificate of Occupancy, fire marshal permit, or ABC license. Tool applies 0.85 conversion to seated capacity (accounts for staff, BOH, standing). Used only when seatCount is absent. Confidence: Medium.
parkingRatioNoOverride the default seats-per-parking-space ratio (FSR 2.75, LSR 2.25, bar 1.75). Use only when local zoning specifies a different ratio.
staleSourcesNoSet true when the underlying source data is older than 12 months. Forces confidence to Very Low.
employeeCountNoTotal employees at the single establishment. Triggers Method 1 (per-employee). Look in osha_inspection_search results first — OSHA records always include employee count.
parkingSpacesNoStriped parking spaces from satellite imagery or zoning permit. Tool multiplies by format-typical seats-per-space (FSR/casual/fine 2.75; LSR/fast 2.25; bar 1.75). Last-resort capacity input — only when no other capacity data is available. Confidence: Very Low.
squareFootageNoTotal establishment square footage from county assessor, real estate listing (LoopNet/Crexi), CO, or building permit. Tool subtracts BOH (default 30% FSR / 40% LSR / 35% Unclear), divides remaining dining area by 15 sqft per occupant (IBC A-2 standard), then multiplies by 0.85 for seated capacity. Used only when seatCount and occupantLoad are absent. Confidence: Low.
capacitySourceNoFree-text label for where the capacity number came from. Recommended values: 'assessor', 'CO', 'fire_marshal', 'ABC', 'health_permit', 'OSHA', 'OpenTable', 'Resy', 'LoopNet', 'Crexi', 'real_estate_listing', 'satellite', 'photos', 'news_article', 'owner_interview', 'zoning_permit', 'format_default'. Echoed in the notes field for audit.
chainPerUnitAdvNoBrand-reported per-unit annual sales (from Franchise Disclosure Document or industry report). Triggers Method 3 when chainFlag is Yes; takes precedence over Methods 1 and 2.
listPageEmployeeDataNoSet true when employeeCount came from a list/aggregator page rather than a direct profile or OSHA record. Caps Method 1 confidence at Low.
highCostOfLivingStateNoAdd +0.10 to the area multiplier for CA, NY, MA, WA, or HI. Get this from census_area_profile.
Behavior4/5

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

With no annotations, the description fully details behavioral traits: deterministic nature, method priority, capacity derivation, confidence levels, and audit trail. It does not mention edge cases but is highly transparent.

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 quite lengthy and dense. While all information is valuable, it could be more concise. Front-loading of purpose is good, but some details could be streamlined.

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?

Given 16 parameters, no output schema, and no annotations, the description is exceptionally complete, covering methods, confidence, audit trail, and parameter relationships. It leaves few gaps.

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%, baseline 3. The description adds significant meaning beyond schema, e.g., explaining method selection priority, capacity input hierarchy, and how capacitySource should be used. This extra context raises the 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 clearly states the tool is a 'Deterministic ADV screening calculator for FLSA enterprise-coverage triage' with specific verbs (estimate, screening) and resources (ADV, FLSA flag). It distinguishes from sibling tools by focusing on a niche function not covered by others.

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 provides explicit usage guidance: 'NOT a coverage determination — screening signal only', method selection priority, and best practice to use employeeCount from OSHA. It lacks explicit alternatives but is clear on when to use this tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/UHQ-Actual/DOL_MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server