Skip to main content
Glama

UK Premises Licence Preflight

premises_licence_preflight

Select for the ACTUAL SINGLE-PREMISES, SINGLE-AUTHORITY licensing compliance decision: whether the application appears compliant, regulatory/local-policy blockers, missing decision facts, and next actions. Do NOT use for general service/pricing information, input-readiness checks, cross-authority comparison, or policy-capability coverage.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
authorityYes
venue_typeNo
members_clubNo
applicant_ageYes
premises_zoneNo
sells_alcoholNo
camden_day_typeNo
hot_food_end_hourNo
cardiff_ndrv_statusNo
hot_food_start_hourNo
entertainment_exemptNo
westminster_day_typeNo
leeds_cumulative_areaNo
newcastle_policy_areaNo
leeds_application_typeNo
manchester_policy_areaNo
regulated_entertainmentNo
bristol_application_typeNo
cardiff_application_typeNo
dps_has_personal_licenceNo
manchester_delivery_onlyNo
westminster_premises_useNo
camden_framework_categoryNo
camden_requested_end_timeNo
cardiff_rateable_value_gbpNo
liverpool_application_typeNo
manchester_operating_phaseNo
newcastle_application_typeNo
supplies_hot_food_or_drinkNo
birmingham_application_typeNo
brighton_requested_end_timeNo
camden_requested_start_timeNo
westminster_in_west_end_cizNo
birmingham_rateable_value_gbpNo
camden_cumulative_impact_riskNo
camden_outside_framework_hoursNo
leeds_relevant_representationsNo
westminster_outside_core_hoursNo
westminster_requested_end_timeNo
bristol_relevant_representationsNo
cardiff_primary_alcohol_businessNo
cardiff_relevant_representationsNo
westminster_requested_start_timeNo
brighton_is_variation_applicationNo
bristol_in_cumulative_impact_areaNo
cardiff_in_cumulative_impact_areaNo
newcastle_outside_framework_hoursNo
liverpool_relevant_representationsNo
newcastle_relevant_representationsNo
birmingham_primary_alcohol_businessNo
birmingham_relevant_representationsNo
manchester_relevant_representationsNo
brighton_delivery_only_after_midnightNo
liverpool_minor_variation_extends_alcohol_hours_23_07No
brighton_good_operator_no_formal_intervention_3_to_5_yearsNo
brighton_good_operator_holder_at_application_and_determinationNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses useful behavioral context: the tool returns a compliance judgement, blocker list, missing-facts list, and next actions, which implies it handles incomplete inputs gracefully rather than erroring. However, it does not disclose side-effect profile (read-only vs. mutating), authorization requirements, or behavior when required inputs are unsatisfiable — gaps that matter for a decision tool.

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

Conciseness5/5

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

Two sentences with zero waste. The scoping statement is front-loaded with the key discriminator (single-premises, single-authority), and the second sentence is a compact exclusion list. For a tool of this complexity, the description is remarkably tight and every clause earns its place.

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

Completeness2/5

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

This is a high-complexity tool: 56 parameters, no output schema, and no annotations. The description covers purpose and output categories well, but an agent invoking it correctly still lacks the return value shape, side-effect profile, and any guidance on which authority-specific parameter sets apply to a given authority value. The routing story is complete; the invocation story is substantially under-specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 56 parameters, so the description must compensate, and it does not. It adds no meaning about authority, applicant_age, applicant_age, venue_type, or any of the authority-specific fields. The only marginal connection is that 'single-authority' implies the authority parameter selects the jurisdiction. The schema's titles and enums are self-descriptive, but for a 56-parameter tool the agent receives no guidance on which parameters matter for which authority or how the decision engine consumes them.

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 states a specific scope ('ACTUAL SINGLE-PREMISES, SINGLE-AUTHORITY licensing compliance decision') and enumerates concrete outputs: compliance verdict, regulatory/local-policy blockers, missing decision facts, and next actions. The explicit 'Do NOT use for...' list differentiates it from sibling tools by function, so an agent can tell it apart from preflight_readiness, compare_licensing_requirements, and local_policy_capabilities without opening their schemas.

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 states when to use the tool ('Select for...') and gives explicit exclusions: general service/pricing information, input-readiness checks, cross-authority comparison, and policy-capability coverage. It does not literally name the sibling tool to switch to for each excluded case, but the exclusions map directly to the functions of preflight_readiness, compare_licensing_requirements, premises_licence_info, and local_policy_capabilities, so routing is nearly explicit.

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.

TDQS

A3.8/5.0
Disambiguation4/5

Each tool has a distinct role, and the descriptions are very explicit about routing, especially between licensing_source_status and source_fingerprint_status. However, several names are easy to confuse at a glance (premises_licence_info vs premises_licence_preflight, licensing_source_status vs source_fingerprint_status, preflight_readiness vs premises_licence_preflight), so an agent might need to read carefully.

Naming Consistency3/5

All names use clear lowercase snake_case, but the set mixes verb-led names (compare_licensing_requirements, list_supported_authorities) with noun-led descriptive names (licensing_source_status, local_policy_capabilities, premises_licence_preflight). This is readable but not a consistent verb_noun convention.

Tool Count5/5

Eight tools is well-scoped for a premises-licensing preflight service, covering the decision itself, readiness, comparison, capabilities, source health, fingerprint diagnostics, supported authorities, and pricing/info. No tool is redundant, and the set does not feel bloated.

Completeness5/5

The tool surface covers the full preflight workflow: input-readiness check, actual compliance decision, cross-authority comparison, local-policy capability awareness, source status/fingerprint diagnostics, supported-authority lookup, and pricing/service discovery. There are no obvious dead ends or missing operations for the stated domain.

Resources