Skip to main content
Glama

RegEvidenceHub Waste

by io.github.ChanghuLiu
OverviewDiscussionsAdmin

Server Details

RegEvidenceHub Waste: England waste registration, DWT readiness and permit-change preflight.

Ownership verified
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
ChanghuLiu/uk-waste-rule-mcp
GitHub Stars
0

TDQS

A4.4/5.0

Scored across 7 tools

Disambiguation5/5

Each tool has a clearly bounded purpose and the descriptions include explicit exclusions plus cross-references to the correct alternative, such as carrier vs. DWT vs. permit-change vs. general preflight. An agent should be able to select the right tool reliably.

Naming Consistency4/5

All names are snake_case and consistently prefixed with waste_, which is a good foundation. However, the suffixes are not fully standardized (preflight, readiness, catalog, info, status) and the set does not follow a verb_noun pattern, so the naming is mostly consistent but not perfectly uniform.

Tool Count5/5

Seven tools is a well-scoped size for this domain: five regulatory workflow preflights plus a rule catalog, service-info, and source-health tool. Each tool earns its place and there are no redundant or filler tools.

Completeness4/5

The main England waste preflight workflows are covered: general routing, carrier/broker/dealer lifecycle, permit changes, DWT receiving-site readiness, plus metadata and evidence-health checks. The main gap is that a brand-new non-carrier operation is not explicitly covered, since the general tool says 'current' and the permit-change tool excludes new operations.

Available Tools

7 tools
waste_carrier_broker_dealer_preflightA
Read-onlyIdempotent
Inspect

FREE CARRIER/BROKER/DEALER REGISTRATION LIFECYCLE tool for England. Select when the unresolved question is a new registration, renewal, detail/activity change, legal-type change, or lower-to-upper change for a carrier, broker or dealer. Supply role and lifecycle action, plus own-waste/tier facts when relevant. Returns a bounded route, fee route, findings and official evidence. It is read-only and never submits or renews a registration. Do NOT use for site permit changes or DWT reporting readiness.

ParametersJSON Schema
NameRequiredDescriptionDefault
scenarioYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's additional statement that it 'never submits or renews a registration' reinforces and enriches those signals. It also discloses the return categories ('bounded route, fee route, findings and official evidence'), which adds useful behavioral context 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.

Conciseness5/5

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

The description is compact and front-loaded: it begins with the core purpose, then gives usage conditions, required inputs, expected outputs, and exclusions. Every sentence contributes useful selection or invocation information without repetition or fluff.

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 read-only preflight tool with a detailed output schema and rich annotations, the description covers the key decision points: when to use, what to supply, what it returns, and exclusions. Nothing critical is missing for an agent to select and invoke 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?

Although the top-level schema has no description for the scenario object, the nested schema fields are well-documented. The description compensates by telling the agent to 'Supply role and lifecycle action, plus own-waste/tier facts when relevant,' which maps directly to the main input fields and adds conditional guidance beyond the raw 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?

The description clearly states the tool's purpose as a carrier/broker/dealer registration lifecycle check for England, enumerating the exact lifecycle actions it covers. It distinguishes itself from siblings by explicitly saying it is not for site permit changes or DWT reporting readiness.

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

Usage Guidelines5/5

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

It explicitly tells the agent when to select the tool ('Select when the unresolved question is a new registration, renewal, detail/activity change, legal-type change, or lower-to-upper change') and when not to use it. The exclusions map directly to sibling tools like waste_permit_change_preflight and waste_digital_tracking_readiness, providing clear routing guidance.

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

waste_digital_tracking_readinessA
Read-onlyIdempotent
Inspect

FREE DIGITAL WASTE TRACKING RECEIVING-SITE READINESS tool for England phase 1. Select only when the question is whether a waste receiving site is in the permitted/licensed receiving-site scope and ready for receipt reporting around the 1 October 2026 mandatory start. Supply receiving authorisation, whether controlled waste is received, reporting-method readiness, and optionally an as-of date. Returns phase-1 scope/readiness, findings and evidence; it never submits DWT records. Do NOT use for carrier registration or permit-change comparison.

ParametersJSON Schema
NameRequiredDescriptionDefault
scenarioYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it 'never submits DWT records', which reinforces the read-only nature beyond annotations. It also states the scope is 'England phase 1 only' and 'returns phase-1 scope/readiness, findings and evidence', which is useful. No contradiction with annotations. The description does not detail side effects, but given the annotations, this is adequate.

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?

The description is a single dense paragraph but front-loads the tool's purpose and key constraint ('FREE... for England phase 1'). It avoids fluff and every sentence adds value: scope condition, required inputs, return value, and exclusions. It could be slightly reorganized for readability but is efficient, not overly verbose.

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

Completeness4/5

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

The tool is moderately complex with multiple nested parameters, but the description covers the main inputs, scope, and exclusions. With an output schema present, the description need not explain return values in detail. The description handles the key contextual aspects: the tool is read-only, returns evidence, and is limited to England phase-1. Minor gaps include not detailing how findings are structured or how to handle edge cases like null authorisation, but the output schema and param descriptions compensate. Overall, it is complete enough for selection and invocation.

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 description coverage is 0%, so the description must compensate for the lack of per-parameter documentation. The description lists all key inputs: 'receiving authorisation, whether controlled waste is received, reporting-method readiness, and optionally an as-of date.' This aligns with the five nested properties, providing semantic meaning beyond parameter names. It also gives guidance on using 'as-of date' for optionality. Since there are no enums with descriptions, this compensates well.

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 a specific purpose: checking receiving-site readiness for England phase 1 of digital waste tracking, with a specific verb 'select' and resource 'receiving-site'. It explicitly distinguishes from sibling tools by naming exclusions ('Do NOT use for carrier registration or permit-change comparison'). It also states a clear scope condition ('only when the question is whether...') and key constraints (never submits DWT records).

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 clear guidance on when to use the tool: only for checking receiving-site readiness with the specific phase-1 scope. It also gives explicit 'Do NOT use' instructions for carrier registration and permit-change comparison, which map to siblings like waste_carrier_broker_dealer_preflight and waste_permit_change_preflight. However, it does not enumerate all sibling alternatives nor elaborate on edge cases, but the primary exclusion is clear.

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

waste_permit_change_preflightA
Read-onlyIdempotent
Inspect

FREE PERMIT-CHANGE IMPACT PREFLIGHT for an EXISTING England waste operation when both current and proposed operating facts are available. Compare modelled fields such as location, activities, waste types, quantity, storage, treatment or operating hours. Returns changed fields, findings, official evidence and review actions; it is read-only and does not vary a permit or decide that a variation/new permit is legally required. Do NOT use for a brand-new operation route, carrier registration, or DWT receipt-reporting readiness.

ParametersJSON Schema
NameRequiredDescriptionDefault
scenarioYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds meaningful context beyond annotations: 'it is read-only and does not vary a permit or decide that a variation/new permit is legally required', and it discloses the return content ('Returns changed fields, findings, official evidence and review actions'). This adds value without contradicting annotations.

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?

The description is two sentences plus a 'Do NOT use' sentence. Every sentence carries essential scope, behavioral, or exclusion information. It is not overly verbose, though it could be tightened slightly by removing redundant phrases like 'FREE' and 'official evidence' without losing meaning. Still, it is well structured and front-loaded with the core purpose.

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

Completeness4/5

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

For a tool with a nested input schema and an output schema, the description covers the essential operational context: when to use, what it does, what it returns, and what it doesn't decide. It doesn't explain the nested schema structure in detail, but the schema descriptions and output schema are present. The main gap is not explaining the 'found in official evidence' aspect, but overall it is complete enough for correct invocation.

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 description coverage is 0% according to context signals, so the description must compensate. It does by naming the modelled fields (location, activities, waste types, quantity, storage, treatment, operating hours) which map to the PermitOperationFacts properties, and by explaining the current/proposed comparison that maps to the scenario structure. It doesn't detail each parameter, but it provides the semantic link needed to understand what inputs are compared.

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 opens with 'FREE PERMIT-CHANGE IMPACT PREFLIGHT for an EXISTING England waste operation' and explicitly states it compares modelled fields like location, activities, waste types, quantity, storage, treatment, and operating hours. This clearly defines the verb (preflight), resource (permit-change impact), and scope. It also distinguishes from siblings by listing exclusions ('brand-new operation route, carrier registration, DWT receipt-reporting readiness').

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

Usage Guidelines5/5

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

The description explicitly states when to use: 'when both current and proposed operating facts are available' for an 'EXISTING England waste operation'. It also gives when-not guidance: 'Do NOT use for a brand-new operation route, carrier registration, or DWT receipt-reporting readiness', which maps directly to sibling tools. This is explicit when/when-not guidance with alternative categories.

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

waste_rule_catalogA
Read-onlyIdempotent
Inspect

FREE RULE CATALOG tool. Use before a case-specific preflight when an agent needs the exact supported role IDs, activity IDs, and bounded route names accepted by this service. Do NOT use it to decide a user's case; use waste_rule_preflight after collecting the relevant facts.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds some scoping context ('exact supported role IDs, activity IDs, and bounded route names'), but 'bounded' largely restates openWorldHint=false, and the description does not add meaningful behavioral detail beyond what the annotations and title already provide.

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?

The description is two tight sentences with the core purpose front-loaded and the exclusion guidance immediately following. Every sentence contributes actionable information, with no filler or repetition.

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 zero-parameter read-only catalog with an output schema and annotations covering its behavioral profile, the description is complete. It tells the agent what the tool provides, when to call it, and when to use a sibling tool instead.

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 the empty input schema is fully self-describing with 100% schema description coverage. There are no parameter semantics to elaborate on, so the baseline of 4 applies.

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 identifies the tool as a rule catalog that returns exact supported role IDs, activity IDs, and bounded route names. It distinguishes itself from case-specific preflight tools by naming waste_rule_preflight explicitly, so an agent can tell when to use this catalog instead of a preflight.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: use it before a case-specific preflight when exact identifiers are needed. It also provides a clear when-not-to-use directive and names the alternative tool, waste_rule_preflight, for deciding a user's case after facts are collected.

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

waste_rule_preflightA
Read-onlyIdempotent
Inspect

FREE GENERAL ENTRY TOOL for a CURRENT England waste operation when the regulatory route is still uncertain. Provide nation, role, one or more modelled activities, and any known site/waste/authorisation facts. Returns a deterministic route, missing facts, findings, evidence and next actions; it is read-only and does not submit anything. Do NOT use when the question is specifically carrier/broker/dealer registration, DWT receiving-site readiness, or a current-vs-proposed permit change; use the corresponding narrow tool instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
scenarioYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already mark readOnlyHint=true, idempotentHint=true, and destructiveHint=false; the description reinforces this by saying 'it is read-only and does not submit anything.' It adds value beyond annotations by describing the deterministic route, missing facts, findings, evidence, and next actions returned.

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?

Three sentences with no filler: purpose and triggering condition, required inputs, output behavior, and exclusions. It front-loads the core scope and routes to alternatives in a tight, efficient paragraph.

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 read-only preflight tool with an output schema and a sibling family, the description covers purpose, jurisdiction, usage exclusions, input summary, and output behavior. Nothing needed to select or call the tool correctly is missing.

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

Parameters3/5

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

With top-level schema description coverage at 0%, the description must compensate, and it names the key inputs: nation, role, one or more modelled activities, and known site/waste/authorisation facts. However, it does not explain codelists, null/default behavior, or the 'do not infer' warnings, so compensation is partial.

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 opens with 'FREE GENERAL ENTRY TOOL for a CURRENT England waste operation when the regulatory route is still uncertain,' clearly stating the operation, jurisdiction, timing, and trigger. It also distinguishes itself from sibling tools by naming specific exclusions and directing to the corresponding narrow tools.

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

Usage Guidelines5/5

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

It explicitly states when to use the tool ('when the regulatory route is still uncertain') and lists three concrete exclusions: carrier/broker/dealer registration, DWT receiving-site readiness, and current-vs-proposed permit change. The instruction to use the corresponding narrow tool is unambiguous.

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

waste_service_infoA
Read-onlyIdempotent
Inspect

FREE SERVICE/DISCOVERY metadata tool. Use for questions about this connector's England scope, available tools, payment-free public-AI surface, fail-closed behavior, and safety boundaries. Do NOT use for evidence freshness; use waste_source_status. Do NOT use for a case-specific regulatory route; use waste_rule_preflight or the narrower registration, DWT, or permit-change tool.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context such as 'FREE SERVICE/DISCOVERY metadata tool', 'payment-free public-AI surface', and 'fail-closed behavior', which inform the agent about access and operational expectations 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.

Conciseness5/5

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

The description is front-loaded with the core purpose and then provides concise, high-value usage boundaries. Every sentence earns its place by distinguishing this tool from siblings and clarifying its scope without unnecessary fluff.

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 the tool has no parameters and an output schema exists, the description fully covers what an agent needs: what the tool is for, when to use it, when not to use it, and which alternatives to choose. No critical context is missing.

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 input schema has zero parameters, so the baseline is 4. The description does not need to explain parameters; it appropriately focuses on the tool's purpose and routing, which is the relevant semantic guidance here.

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 purpose: a free service/discovery metadata tool for questions about the connector's England scope, available tools, payment-free public-AI surface, fail-closed behavior, and safety boundaries. It clearly distinguishes itself from siblings by naming what it is not for and steering to alternative tools.

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

Usage Guidelines5/5

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

The description explicitly lists when to use the tool and gives concrete do-not-use cases with named alternatives: waste_source_status for evidence freshness, and waste_rule_preflight or narrower tools for case-specific regulatory routes. This leaves little ambiguity about tool selection.

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

waste_source_statusA
Read-onlyIdempotent
Inspect

FREE EVIDENCE-HEALTH tool. Use only to check whether the reviewed official GOV.UK / Environment Agency evidence is fresh, unchanged, available and decision-usable. It returns source-health status and never makes a waste-route or permit conclusion. Do NOT use for operational routing; use waste_rule_preflight or a narrower workflow tool.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds the important behavioral boundary that it 'never makes a waste-route or permit conclusion' and returns only 'source-health status.' This goes beyond the annotations and helps the agent understand side effects, though it does not elaborate on response format or edge cases.

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?

The description is front-loaded with the core purpose and provides essential exclusions in three sentences. The phrase 'FREE EVIDENCE-HEALTH tool' is slightly unconventional but not bloated. Overall it is efficient and well-structured for quick agent parsing.

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

Completeness4/5

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

For a zero-parameter, read-only tool with an output schema and strong annotations, the description covers the necessary aspects: purpose, usage boundaries, and what it returns. It does not need to explain return structure because the output schema exists. Slight gap: it doesn't clarify what 'fresh' or 'decision-usable' means operationally, but that is likely encoded in the output schema.

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?

With 0 parameters and 100% schema coverage, the baseline is 4. The description has no parameters to describe, so it correctly adds no parameter-specific detail. The mention of what it checks (freshness, unchanged, availability) is conceptual context rather than parameter semantics.

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 verb and resource: 'check whether the reviewed official GOV.UK / Environment Agency evidence is fresh, unchanged, available and decision-usable.' It differentiates from siblings by explicitly saying it never makes a waste-route or permit conclusion, effectively distinguishing it from tools like waste_rule_preflight.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance ('Use only to check...') and clear when-not-to-use instructions ('Do NOT use for operational routing; use waste_rule_preflight or a narrower workflow tool'). It names the alternative, leaving no ambiguity about tool selection.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedwaste_rule_preflight1 field changed
      • changedInput schema / $defs / WasteRuleScenario / properties / nation / description
        Previous value: -"UK nation for the operation. This public preflight currently supports England only and never infers jurisdiction."New value: +"UK nation for the operation. This service currently supports England only and never infers jurisdiction."
  2. 10 tool updates
    • Removedcarrier_broker_dealer_registration_preflight
    • Removeddigital_waste_tracking_receipt_readiness
    • Removedlist_waste_rules
    • Removedpermit_change_impact
    • Addedwaste_carrier_broker_dealer_preflight
    • Addedwaste_digital_tracking_readiness
    • Addedwaste_permit_change_preflight
    • Addedwaste_rule_catalog
    • Removedwaste_rule_info
    • Addedwaste_service_info
  3. 4 tool updates
    • Changedcarrier_broker_dealer_registration_preflight5 fields changed
      • addedInput schema / $defs
        Added value: +{
+  "CarrierRegistrationScenario": {
+    "additionalProperties": false,
+    "properties": {
+      "action": {
+        "default": "new_registration",
+        "description": "Registration lifecycle action. Use renew only for an existing registration; use change_* only for an existing registration change.",
+        "enum": [
+          "new_registration",
+          "renew",
+          "change_details",
+          "change_activity",
+          "change_legal_type",
+          "lower_to_upper"
+        ],
+        "title": "Action",
+        "type": "string"
+      },
+      "construction_demolition_waste": {
+        "anyOf": [
+          {
+            "type": "boolean"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "For an own-waste carrier, whether construction or demolition waste is carried; this affects the current route.",
+        "title": "Construction Demolition Waste"
+      },
+      "existing_registration_tier": {
+        "anyOf": [
+          {
+            "enum": [
+              "upper",
+              "lower"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Existing registration tier for renewal checks. Do not infer the tier from the user's business type.",
+        "title": "Existing Registration Tier"
+      },
+      "nation": {
+        "anyOf": [
+          {
+            "const": "England",
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "UK nation. This workflow currently supports England only.",
+        "title": "Nation"
+      },
+      "own_waste_only": {
+        "anyOf": [
+          {
+            "type": "boolean"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "For carriers, whether the business transports only waste it produces itself. Leave null if not established.",
+        "title": "Own Waste Only"
+      },
+      "role": {
+        "anyOf": [
+          {
+            "enum": [
+              "carrier",
+              "broker",
+              "dealer"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Registration role being checked: carrier, broker, or dealer.",
+        "title": "Role"
+      }
+    },
+    "title": "CarrierRegistrationScenario",
+    "type": "object"
+  }
+}
      • addedInput schema / properties / scenario / $ref
        Added value: +"#/$defs/CarrierRegistrationScenario"
      • removedInput schema / properties / scenario / additionalProperties
        Removed value: -true
      • removedInput schema / properties / scenario / title
        Removed value: -"Scenario"
      • removedInput schema / properties / scenario / type
        Removed value: -"object"
    • Changeddigital_waste_tracking_receipt_readiness5 fields changed
      • addedInput schema / $defs
        Added value: +{
+  "DigitalTrackingScenario": {
+    "additionalProperties": false,
+    "properties": {
+      "as_of_date": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Optional assessment date in YYYY-MM-DD. Omit to use the service's current date.",
+        "title": "As Of Date"
+      },
+      "nation": {
+        "anyOf": [
+          {
+            "const": "England",
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "UK nation. This workflow models England phase-1 receiving-site timing only.",
+        "title": "Nation"
+      },
+      "receives_controlled_waste": {
+        "anyOf": [
+          {
+            "type": "boolean"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Whether the site receives controlled waste; required to determine phase-1 receiving-site scope.",
+        "title": "Receives Controlled Waste"
+      },
+      "receiving_authorisation": {
+        "anyOf": [
+          {
+            "enum": [
+              "permit",
+              "permitted",
+              "licence",
+              "licensed",
+              "exemption",
+              "registered_exemption",
+              "other"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Receiving-site authorisation. Do not infer authorisation from the fact that a site receives waste.",
+        "title": "Receiving Authorisation"
+      },
+      "reporting_method_ready": {
+        "anyOf": [
+          {
+            "type": "boolean"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Whether an operational receipt-reporting route is ready. Leave null if readiness has not been confirmed.",
+        "title": "Reporting Method Ready"
+      }
+    },
+    "title": "DigitalTrackingScenario",
+    "type": "object"
+  }
+}
      • addedInput schema / properties / scenario / $ref
        Added value: +"#/$defs/DigitalTrackingScenario"
      • removedInput schema / properties / scenario / additionalProperties
        Removed value: -true
      • removedInput schema / properties / scenario / title
        Removed value: -"Scenario"
      • removedInput schema / properties / scenario / type
        Removed value: -"object"
    • Changedpermit_change_impact5 fields changed
      • addedInput schema / $defs
        Added value: +{
+  "PermitChangeScenario": {
+    "additionalProperties": false,
+    "properties": {
+      "current": {
+        "$ref": "#/$defs/PermitOperationFacts",
+        "description": "Current operating facts. Supply only facts actually known from the existing operation/authorisation."
+      },
+      "nation": {
+        "anyOf": [
+          {
+            "const": "England",
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "UK nation. This workflow currently supports England only.",
+        "title": "Nation"
+      },
+      "proposed": {
+        "$ref": "#/$defs/PermitOperationFacts",
+        "description": "Proposed operating facts to compare against current facts. The tool identifies changed modelled fields but does not decide that a permit variation is legally required."
+      }
+    },
+    "required": [
+      "current",
+      "proposed"
+    ],
+    "title": "PermitChangeScenario",
+    "type": "object"
+  },
+  "PermitOperationFacts": {
+    "additionalProperties": false,
+    "properties": {
+      "activities": {
+        "anyOf": [
+          {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Current or proposed waste activities.",
+        "title": "Activities"
+      },
+      "hazardous_status": {
+        "anyOf": [
+          {
+            "type": "boolean"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Known hazardous-waste status; never infer it.",
+        "title": "Hazardous Status"
+      },
+      "maximum_quantity": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "integer"
+          },
+          {
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Current or proposed maximum quantity, preserving the user's unit/context.",
+        "title": "Maximum Quantity"
+      },
+      "operating_hours": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Current or proposed operating hours.",
+        "title": "Operating Hours"
+      },
+      "site_location": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Current or proposed site location.",
+        "title": "Site Location"
+      },
+      "storage_method": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Current or proposed storage method.",
+        "title": "Storage Method"
+      },
+      "treatment_method": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Current or proposed treatment method.",
+        "title": "Treatment Method"
+      },
+      "waste_types": {
+        "anyOf": [
+          {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Current or proposed user-supplied waste types/codes.",
+        "title": "Waste Types"
+      }
+    },
+    "title": "PermitOperationFacts",
+    "type": "object"
+  }
+}
      • addedInput schema / properties / scenario / $ref
        Added value: +"#/$defs/PermitChangeScenario"
      • removedInput schema / properties / scenario / additionalProperties
        Removed value: -true
      • removedInput schema / properties / scenario / title
        Removed value: -"Scenario"
      • removedInput schema / properties / scenario / type
        Removed value: -"object"
    • Changedwaste_rule_preflight5 fields changed
      • addedInput schema / $defs
        Added value: +{
+  "WasteRuleScenario": {
+    "additionalProperties": false,
+    "properties": {
+      "activities": {
+        "description": "One or more modelled activities. Do not invent waste codes or hazardous status from an activity label.",
+        "items": {
+          "enum": [
+            "produce_controlled_waste",
+            "transport_waste",
+            "arrange_waste",
+            "receive_waste",
+            "store_waste",
+            "treat_recover_dispose_waste"
+          ],
+          "type": "string"
+        },
+        "title": "Activities",
+        "type": "array"
+      },
+      "authorisation_status": {
+        "anyOf": [
+          {
+            "enum": [
+              "permit",
+              "exemption",
+              "licence",
+              "none",
+              "other"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Current receiving/operator authorisation when known. Do not infer permit or exemption status.",
+        "title": "Authorisation Status"
+      },
+      "hazardous_status": {
+        "anyOf": [
+          {
+            "type": "boolean"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Whether hazardous waste is involved, only when explicitly known from the user's facts; otherwise leave null.",
+        "title": "Hazardous Status"
+      },
+      "nation": {
+        "anyOf": [
+          {
+            "const": "England",
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "UK nation for the operation. This public preflight currently supports England only and never infers jurisdiction.",
+        "title": "Nation"
+      },
+      "role": {
+        "anyOf": [
+          {
+            "enum": [
+              "producer",
+              "carrier",
+              "broker",
+              "dealer",
+              "receiver",
+              "operator"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Primary waste role. Use receiver/operator for sites taking or operating on waste; carrier/broker/dealer for movement or arranging roles.",
+        "title": "Role"
+      },
+      "site_location": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Site or sufficiently precise operating location in England when location matters to the route.",
+        "title": "Site Location"
+      },
+      "waste_types": {
+        "anyOf": [
+          {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "User-supplied waste types or codes. Do not infer EWC codes from free text.",
+        "title": "Waste Types"
+      }
+    },
+    "title": "WasteRuleScenario",
+    "type": "object"
+  }
+}
      • addedInput schema / properties / scenario / $ref
        Added value: +"#/$defs/WasteRuleScenario"
      • removedInput schema / properties / scenario / additionalProperties
        Removed value: -true
      • removedInput schema / properties / scenario / title
        Removed value: -"Scenario"
      • removedInput schema / properties / scenario / type
        Removed value: -"object"
  4. 7 tool updates
    • First observedcarrier_broker_dealer_registration_preflight
    • First observeddigital_waste_tracking_receipt_readiness
    • First observedlist_waste_rules
    • First observedpermit_change_impact
    • First observedwaste_rule_info
    • First observedwaste_rule_preflight
    • First observedwaste_source_status

Publisher details

Operator
RegEvidenceHub · Publisher source
Operator website
https://regevidencehub.com · Publisher source
Vendor relationship
Independent · Publisher source
Documentation
https://github.com/ChanghuLiu/uk-waste-rule-mcp · Publisher source
Trust center
Not available
Restrictions
England only. Read-only regulatory preflight using reviewed official GOV.UK and Environment Agency sources. No account, API key, or payment is required on this public connector. It does not submit permits, exemptions, registrations, or Digital Waste Tracking records, and it does not provide Environment Agency approval or legal advice. · Publisher source

Related MCP Connectors

Related MCP Servers

  • England Works Watch

    ChanghuLiu
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents and employer workflows to assess Skilled Worker sponsor compliance change impacts, returning deterministic, evidence-linked decisions with rule versions and official GOV.UK sources, including batch assessments and fail-closed handling for insufficient input.
    -

  • Muckaway AI MCP

    CSOAI-ORG
    A
    license
    Not graded
    quality
    B
    maintenance
    Muckaway AI MCP provides tools for UK waste management compliance, including waste classification, disposal facility lookup, duty of care documentation, and waste transfer notes.
    3 npm
    32 PyPI
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources