UK Premises Licence Preflight

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

With no annotations and no output schema, the description carries the disclosure burden. It does convey that the tool compares licensing requirements and surfaces policy differences/trade-offs, which is useful behavioral context. However, it does not describe what a result contains, whether any side effects or authorization are involved, or what happens when fewer than two authorities are provided.

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

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

Two sentences, front-loaded with the core selection rule and followed by an explicit exclusion. The Birmingham/Liverpool example is concrete without being verbose; no filler or wasted words.

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

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

For a tool with 56 parameters, no annotations, and no output schema, this description is too thin to be fully actionable. It gives the high-level use case and an exclusion but omits required-input guidance, expected output shape, and relationship to the single-authority sibling tools.

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

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

Schema description coverage is 0%, so the description must compensate, but it adds almost no parameter semantics. It hints at 'authorities' via 'two or more councils' and at business concept via 'same bar/business concept', yet fails to explain the other required parameter (applicant_age) or any of the other 54 parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific selection use-case: cross-authority comparison of premises-licensing requirements, policy differences, or trade-offs between two or more councils. It includes a concrete Birmingham/Liverpool example and explicitly contrasts itself with single-authority compliance decisions, making its scope unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit when-to-use condition ('ANY CROSS-AUTHORITY comparison... two or more councils') and a clear when-not-to-use ('Do not use for a single-premises single-authority compliance decision'). It does not name the sibling tool(s) that should be used instead, so it falls short of full alternative routing.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses that this tool reports user-facing health categories rather than technical fingerprint values, and it explicitly scopes out fingerprint/hash requests. For a read-only status tool, this is reasonably transparent, though it could add detail about default authority behavior.

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

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

Two sentences, front-loaded with the core purpose and status categories, followed by a critical boundary condition. No filler or repetition; every sentence earns its place.

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

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

The description covers tool selection and the key alternative, and an output schema exists to document return values. However, the single parameter 'authority' is left under-explained, including its default/null behavior, so the overall context is not fully complete for correct invocation.

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

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

Schema description coverage is 0% and the description adds no direct guidance about the 'authority' parameter: what values to pass, whether null means 'all authorities', or how to discover valid authorities. The word 'authority' and the tool context give some clue, but the description does not compensate for the missing schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (authority source health), a clear action (select for status), and enumerates the statuses it returns (fresh, stale, changed, blocked, unavailable, under review). It also explicitly distinguishes itself from the source_fingerprint_status sibling, so an agent can tell them apart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit when-to-use signal ('USER-FACING AUTHORITY SOURCE HEALTH') and an explicit when-not-to-use rule with a named alternative: never for fingerprints/hashes, always use source_fingerprint_status instead. This is direct routing guidance.

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

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

No annotations are present, so the description carries the behavioral burden. It conveys a read-oriented list/check operation and includes a strong guardrail against misuse, but it does not describe the output payload or what determines whether an authority is supported. For a simple zero-parameter tool with an output schema, this is acceptable but not rich.

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

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

The description is two sentences with the core purpose front-loaded and the negative usage guardrail in the second sentence. Every clause adds value and there is no redundant or vague filler.

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

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

For a no-argument list/check tool with an output schema, the description is largely complete: it defines the intended use and excludes adjacent decision types. The exact meaning of 'supported' could be clarified, but the low complexity and available output schema keep that gap minor.

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

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

The tool has zero parameters and 100% schema coverage, so there are no parameter details the description must explain. The mention of checking a named authority is achievable by inspecting the returned supported-authority list rather than requiring a parameter, so there is no schema conflict.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: list supported councils/local licensing authorities or check whether a named authority is supported. It also explicitly carves out what the tool is not for, which helps an agent distinguish it from the sibling tools like licensing_source_status or local_policy_capabilities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance and clear when-not-to-use criteria covering compliance, source health, pricing, and policy-capability decisions. However, it does not name the specific sibling tools an agent should use instead, so alternative routing is left to inference.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Capability coverage only', which indicates informational scope, but it does not state whether the tool is read-only, what the response contains, whether side effects occur, or any error/limit behavior. This is insufficient for a tool with no annotation support.

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

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

The description is two sentences with no filler. The trigger condition is front-loaded, and the exclusion is placed in the second sentence. The all-caps 'WHAT' is slightly noisy but does not undermine clarity or conciseness.

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

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

There is no output schema, so the description should explain what a capability-coverage answer looks like, but it does not. The 'provided_facts' parameter is also left undefined, so an agent cannot confidently construct a correct call. The purpose is clear, but the operational details are incomplete.

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

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

Schema description coverage is 0%, yet the description does not explain either parameter. 'authority' is weakly implied by 'for an authority', but its format and optional behavior are not stated, and 'provided_facts' is completely unexplained. The description fails to compensate for the total lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: reporting which local licensing-policy dimensions the service can evaluate for an authority, including cumulative-impact constraints. The 'Capability coverage only' clause further distinguishes it from actual compliance/blocker decision tools, making the resource and scope unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The first sentence gives an explicit trigger: use this when the user asks WHAT local licensing-policy dimensions can be evaluated. The second sentence gives an explicit when-not: do not use it for the actual premises compliance/blocker decision. It lacks named sibling alternatives, but the exclusion is clear enough to prevent misuse.

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

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

There are no annotations, so the description carries the burden of behavioral disclosure. It does say the tool checks completeness and lists missing inputs, and frames itself as a pre-call guard. It does not state side effects, whether it performs any decision logic, or what happens with the provided_facts object.

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

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

The description is short, front-loaded with the primary purpose, and avoids unnecessary detail. There is minor redundancy in repeating 'price/cost', and the exclusion list could be tightened, but overall it is efficient.

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

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

With no output schema and no annotations, the description should clarify parameter meaning and return value more fully. It only says 'list missing inputs' and leaves the relationship to premises_licence_preflight implicit, which is a notable gap for a tool with minimal structured metadata.

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

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

Schema description coverage is 0%, and the description never explains 'authority' or 'provided_facts'. An agent can guess from names that authority is a jurisdiction and provided_facts is a fact bundle, but there is no guidance about expected values, structure, or how they are used.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: check whether applicant/venue inputs are complete enough to run the paid premises decision, and list missing inputs. It clearly distinguishes itself from price/cost and general-information queries, though it does not directly clarify how it differs from the similarly named sibling premises_licence_preflight.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use the tool ('Select ONLY to check...') and gives an explicit when-not list. It also names premises_licence_info as the destination for price/cost questions. However, it does not explicitly route to the intended decision tool or fully map exclusions like 'service capabilities' to alternatives.

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

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

With no annotations, the description carries the transparency burden. It conveys a read-only metadata/pricing role and sets expectations about what it will not answer, though it does not explicitly state read-only behavior, data source, or output shape. The presence of an output schema reduces the need to describe return values.

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

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

The description is front-loaded with the core purpose and uses examples and exclusions efficiently. The sentence 'This is the pricing tool' is slightly redundant after the opening, but the overall length is reasonable for the scope it covers.

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

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

For a no-parameter metadata lookup with an output schema, this description is complete: it states what information is available, gives example queries, and rules out the main misuse cases. An agent has enough context to select and invoke it correctly.

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

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

The tool has zero parameters, so there is no parameter schema to clarify. The description compensates by defining the categories of questions the tool answers, which is all that is needed here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as the service/pricing/discovery metadata source for premises licensing and gives concrete query categories (jurisdiction, workflow, free/paid, x402/payment mode). It distinguishes itself from compliance/blocker checks, though it lacks a direct action verb like 'get' or 'list' and does not name sibling tools explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit when-to-use guidance: select for jurisdiction, supported workflow, pricing, payment mode, or any cost question. It also gives a clear when-not-to-use exclusion for compliance/blockers and applicant input completeness, but it does not point to a named sibling alternative.

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

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.

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.

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.

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.

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.

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.

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

With no annotations provided, the description carries the behavioral burden. It communicates that this is a read-oriented diagnostic operation and that it can report stored fingerprint values and drift. However, it does not explicitly state that it has no side effects, require any permissions, or explain how the result is presented beyond the existing output schema.

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

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

The description is front-loaded with the core purpose and is short overall, but the heavy use of all-caps and repetitive phrasing ('fingerprint' appears multiple times) makes it less crisp than it could be. All three sentences do contribute useful routing information.

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

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

The tool is simple, has an output schema, and the description gives strong selection guidance. The main gap is the undocumented 'authority' parameter, which an agent would need to understand to invoke the tool correctly when the user specifies a particular authority or source.

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

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

The description does not mention the only parameter, 'authority', at all. Schema description coverage is 0%, so the description must compensate, but it adds no meaning about what authority values are valid, whether it filters results, or how the agent should populate it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it provides low-level fingerprint/hash/checksum diagnostics. It also explicitly distinguishes itself from ordinary source-health status questions, making its purpose clear even among the licensing-focused sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit trigger phrases for when to select this tool ('fingerprint', 'hash', 'checksum', 'fingerprint drift') and an explicit exclusion for ordinary source-health questions. It does not name a specific alternative tool for those ordinary cases, but the when-to-use and when-not-to-use guidance is strong.

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