Skip to main content
Glama

RegEvidenceHub Taxi

by io.github.ChanghuLiu
OverviewDiscussionsAdmin

Server Details

RegEvidenceHub Taxi: England taxi/PHV licensing preflight and council comparison.

Ownership verified
Status
Healthy
Uptime
99.1% over 38 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.6/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose and the descriptions explicitly cross-reference when to use one tool versus another. The one-vs-many authority split between taxi_licence_preflight and compare_licensing_requirements removes the main potential ambiguity.

Naming Consistency3/5

Naming is mixed: compare_licensing_requirements and list_supported_authorities use a verb_noun pattern, while licensing_source_status, taxi_licence_preflight, and taxi_phv_info are noun-like compound names. The names are readable and semantically meaningful, but there is no uniform convention across the set.

Tool Count5/5

Five tools is well-scoped for a focused taxi-licensing advisory surface. Each tool covers a distinct user need without redundancy, and the count does not feel thin or bloated.

Completeness5/5

The tool set covers orientation, coverage discovery, single-authority preflight checks, multi-authority comparison, and evidence-source health checks. For a read-only decision-support surface, this is complete and leaves no obvious dead end in the main user workflows.

Available Tools

5 tools
compare_licensing_requirementsA
Read-onlyIdempotent
Inspect

Free deterministic comparison for TWO OR MORE supported councils/licensing authorities on this public AI surface. Use when the user wants requirements, blockers or trade-offs compared for the same applicant or fleet, or is choosing where to license. Call list_supported_authorities first if authority names or coverage are uncertain. Do not use for a single-authority readiness check; use taxi_licence_preflight instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
payloadYesCross-authority comparison request. Call list_supported_authorities first, then supply one or more exact authority names plus the applicant facts to compare. Additional applicant facts are allowed so authority-specific rule inputs are not narrowed.

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, so the safety profile is covered. The description adds 'Free deterministic comparison' – providing cost and determinism guarantees – and 'public AI surface' context, which is extra behavioral information beyond annotations. No contradiction with 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?

Four sentences, no filler, front-loaded with the core purpose and scoping. The exclusion and prerequisite are placed early. Every sentence earns its place, making it efficient and easy to parse.

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 comparison tool with a rich input schema and an output schema, the description covers purpose, usage, exclusions, and prerequisites. Nothing essential for correct invocation is missing. The slight 'two or more' vs schema minItems is a minor semantic nuance, not a completeness gap.

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?

Schema coverage is 100% (the payload has a detailed description covering the structure and additional facts allowed). The description adds the 'TWO OR MORE' constraint not present in the schema (which allows one authority via minItems:1), providing extra meaning but also creating a slight inconsistency. Since schema does heavy lifting, baseline 3 is appropriate.

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: 'comparison for TWO OR MORE supported councils/licensing authorities'. It clearly distinguishes from siblings by naming the alternative for single-authority checks (taxi_licence_preflight) and the prerequisite (list_supported_authorities). This leaves no ambiguity about what the tool does.

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?

Explicit when-to-use guidance: 'when the user wants requirements, blockers or trade-offs compared for the same applicant or fleet, or is choosing where to license'. Also explicit when-not-to-use: 'Do not use for a single-authority readiness check' with a named alternative, and instructs to call list_supported_authorities first if uncertain. This is exemplary usage routing.

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

licensing_source_statusA
Read-onlyIdempotent
Inspect

Free official-source health and freshness tool. Use when the user asks whether licensing evidence is current, stale, changed, conflicted, inaccessible, under review, or safe to rely on. Pass a supported authority name to narrow the check; omit authority for the global view. It returns source/review readiness signals, not an applicant or vehicle licensing decision. For one-authority readiness use taxi_licence_preflight; for cross-authority comparison use compare_licensing_requirements.

ParametersJSON Schema
NameRequiredDescriptionDefault
authorityNoExact supported licensing-authority name returned by list_supported_authorities. Omit this parameter for a global source-health and review-readiness check.

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, and destructiveHint=false. The description adds useful behavioral context beyond that: it is free, uses official sources, returns source/review readiness signals rather than licensing decisions, and supports both global and authority-scoped checks. This is meaningful but not exhaustive, so a 4 is appropriate.

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 states what the tool is in the first clause, gives usage triggers, explains parameter behavior, and then routes to alternatives. Every sentence earns its place with no redundancy.

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 low-complexity, one-optional-parameter tool with an output schema and read-only annotations, the description covers the core purpose, usage conditions, parameter behavior, output semantics, and sibling distinctions. Nothing critical is missing for an agent 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.

Parameters3/5

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

The input schema already documents the single optional authority parameter at 100% coverage, including that it expects an exact supported authority name from list_supported_authorities and can be omitted for a global check. The description reinforces this but adds little semantic information beyond 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?

The description clearly identifies the tool as a source-health and freshness checker for licensing evidence, listing concrete user intents it serves (current, stale, changed, conflicted, inaccessible, under review, safe to rely on). It also explicitly distinguishes itself from siblings and clarifies what it does not return (an applicant or vehicle licensing decision).

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 gives explicit when-to-use guidance tied to user intent, explains how to narrow the check via a supported authority name versus the global view, and names specific sibling alternatives: taxi_licence_preflight for one-authority readiness and compare_licensing_requirements for cross-authority comparison. This fully routes the agent to the correct tool.

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

list_supported_authoritiesA
Read-onlyIdempotent
Inspect

Free coverage-discovery tool. Use when the user asks which councils or licensing authorities are supported, whether a named authority is covered, or when the authority name should be normalized before another call. It returns supported authority names and does not assess eligibility. After selecting one authority use taxi_licence_preflight; for two or more authorities use compare_licensing_requirements.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.6/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. The description adds valuable context beyond these: the 'does not assess eligibility' limitation (a behavioral constraint that prevents misuse) and the normalization behavior before another call. This is meaningful added context, though it doesn't address rate limits or data freshness.

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?

Four sentences, each earning its place: purpose, when-to-use, a behavioral caveat, and routing guidance. It is front-loaded with the key phrase 'Free coverage-discovery tool' and avoids filler. Slightly longer than minimal, but every sentence carries distinct information.

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 0-parameter tool with an output schema and complete annotations, the description covers everything an agent needs: what it returns, what it does not do, when to invoke it, and how to route to the correct sibling afterward. Nothing essential 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?

With 0 parameters, the baseline is 4. There is nothing to document, and the description correctly implies the tool takes no input and simply enumerates supported authorities. Schema coverage is trivially 100% since there are no params.

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: it's a 'coverage-discovery tool' that 'returns supported authority names.' It explicitly distinguishes itself by stating what it does NOT do ('does not assess eligibility') and is clearly differentiated from siblings by naming them directly. The title 'List supported taxi PHV authorities' reinforces the purpose.

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 when the user asks which councils or licensing authorities are supported, whether a named authority is covered, or when the authority name should be normalized before another call.' It also provides routing rules to two siblings: 'After selecting one authority use taxi_licence_preflight; for two or more authorities use compare_licensing_requirements.' This is exemplary routing guidance.

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

taxi_licence_preflightA
Read-onlyIdempotent
Inspect

Free deterministic decision preflight for ONE supported council/licensing authority on this public AI surface. Use when the user wants applicant, driver, vehicle or fleet readiness, applicable requirements or blockers, missing facts, and next actions before submission or onboarding. Call list_supported_authorities first if coverage or the exact authority name is uncertain. Do not use for multiple-authority comparison; use compare_licensing_requirements instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
payloadYesOne-authority applicant/fleet preflight facts. Start by calling list_supported_authorities and use the returned authority name exactly. Additional authority-specific facts are allowed and are evaluated only when the evidence-backed rule bundle declares them.

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, so the safety profile is covered. The description adds the deterministic nature, the one-authority constraint, and the need to verify authority coverage via list_supported_authorities. It does not describe error behavior for unsupported authorities, but the annotation coverage lowers the burden.

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 three sentences, with each sentence carrying distinct value: what the tool does, when to use it, and when to use an alternative. It is front-loaded and free of filler.

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 nested payload, full schema documentation, output schema, and strong annotations, the description covers purpose, usage, scoping, and routing to sibling tools. Nothing an agent needs to invoke this 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?

Schema description coverage is 100%, so the schema fully documents the payload parameters. The description reinforces the one-authority constraint and the list_supported_authorities prerequisite, which is useful but does not materially extend parameter semantics beyond what the schema already states.

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 names the operation ('decision preflight'), scope ('ONE supported council/licensing authority'), and expected outputs (readiness, requirements, blockers, missing facts, next actions). It also distinguishes itself from compare_licensing_requirements by explicitly excluding multiple-authority comparison.

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 states clear use cases ('when the user wants applicant, driver, vehicle or fleet readiness...'), a prerequisite ('Call list_supported_authorities first if coverage or the exact authority name is uncertain'), and an explicit alternative when not to use the tool ('use compare_licensing_requirements instead'). This is comprehensive routing guidance.

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

taxi_phv_infoA
Read-onlyIdempotent
Inspect

Free orientation tool for the public AI surface. Use this first when the user asks what RegEvidenceHub Taxi does, which tools are available, or what the evidence-safety boundary is. It returns service/tool metadata and makes no licensing decision. If the user wants one-authority readiness, use taxi_licence_preflight; for multiple authorities, use compare_licensing_requirements; for coverage discovery, use list_supported_authorities.

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?

Beyond the readOnlyHint/idempotentHint annotations, the description discloses that the tool returns metadata and makes no licensing decision, clarifying its non-decisional scope. It doesn't describe return details, but annotations and output schema reduce that burden.

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 front-load the core guidance and immediately state when to use the tool, followed by compact sibling routing. No filler.

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 informational tool with read-only annotations and an output schema, the description covers purpose, use timing, and the main alternatives. Nothing an agent needs to decide whether to call it 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?

There are zero parameters, so no parameter documentation is required. The description accurately conveys that calls require no arguments.

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 identifies a specific purpose: an orientation/help tool for RegEvidenceHub Taxi, and explicitly says it returns service/tool metadata and makes no licensing decision. It differentiates itself from siblings by naming them.

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?

Provides explicit routing conditions: use this first for general questions about what the service does, available tools, or the evidence-safety boundary. It names alternatives for one-authority readiness, multiple authorities, and coverage discovery.

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
    • Changedlicensing_source_status1 field changed
      • addedInput schema / properties / authority / description
        Added value: +"Exact supported licensing-authority name returned by list_supported_authorities. Omit this parameter for a global source-health and review-readiness check."
  2. 4 tool updates
    • Changedcompare_licensing_requirements1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "compare_licensing_requirementsDictOutput",
+  "type": "object"
+}
    • Changedlicensing_source_status1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "licensing_source_statusDictOutput",
+  "type": "object"
+}
    • Changedlist_supported_authorities1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "list_supported_authoritiesDictOutput",
+  "type": "object"
+}
    • Changedtaxi_licence_preflight1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "taxi_licence_preflightDictOutput",
+  "type": "object"
+}
  3. 2 tool updates
    • Changedcompare_licensing_requirements6 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / payload / description
        Added value: +"Cross-authority comparison request. Call list_supported_authorities first, then supply one or more exact authority names plus the applicant facts to compare. Additional applicant facts are allowed so authority-specific rule inputs are not narrowed."
      • addedInput schema / properties / payload / examples
        Added value: +[
+  {
+    "applicant": {
+      "age": 30,
+      "driving_licence_years": 4,
+      "has_pass_plus_certificate": true
+    },
+    "authorities": [
+      "City of Bradford Metropolitan District Council",
+      "Cambridge City Council"
+    ]
+  }
+]
      • addedInput schema / properties / payload / properties
        Added value: +{
+  "applicant": {
+    "additionalProperties": true,
+    "description": "Applicant/fleet facts applied consistently to every authority in the comparison.",
+    "examples": [
+      {
+        "age": 30,
+        "driving_licence_years": 4,
+        "has_pass_plus_certificate": true
+      }
+    ],
+    "properties": {
+      "age": {
+        "description": "Applicant age in years when relevant to the authority rule being checked.",
+        "minimum": 0,
+        "type": "number"
+      },
+      "driving_licence_years": {
+        "description": "Completed years the applicant has held the driving licence, when known.",
+        "minimum": 0,
+        "type": "number"
+      },
+      "has_pass_plus_certificate": {
+        "description": "Whether the applicant has a Pass Plus certificate, when relevant.",
+        "type": "boolean"
+      }
+    },
+    "type": "object"
+  },
+  "authorities": {
+    "description": "Exact supported authority names returned by list_supported_authorities.",
+    "items": {
+      "minLength": 1,
+      "type": "string"
+    },
+    "minItems": 1,
+    "type": "array",
+    "uniqueItems": true
+  }
+}
      • addedInput schema / properties / payload / required
        Added value: +[
+  "authorities",
+  "applicant"
+]
      • removedInput schema / properties / payload / title
        Removed value: -"Payload"
    • Changedtaxi_licence_preflight6 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / payload / description
        Added value: +"One-authority applicant/fleet preflight facts. Start by calling list_supported_authorities and use the returned authority name exactly. Additional authority-specific facts are allowed and are evaluated only when the evidence-backed rule bundle declares them."
      • addedInput schema / properties / payload / examples
        Added value: +[
+  {
+    "age": 30,
+    "authority": "City of Bradford Metropolitan District Council",
+    "driving_licence_years": 4,
+    "has_pass_plus_certificate": true
+  }
+]
      • addedInput schema / properties / payload / properties
        Added value: +{
+  "age": {
+    "description": "Applicant age in years when relevant to the authority rule being checked.",
+    "minimum": 0,
+    "type": "number"
+  },
+  "authority": {
+    "description": "Exact supported licensing-authority name returned by list_supported_authorities.",
+    "minLength": 1,
+    "type": "string"
+  },
+  "driving_licence_years": {
+    "description": "Completed years the applicant has held the driving licence, when known.",
+    "minimum": 0,
+    "type": "number"
+  },
+  "has_pass_plus_certificate": {
+    "description": "Whether the applicant has a Pass Plus certificate, when relevant.",
+    "type": "boolean"
+  }
+}
      • addedInput schema / properties / payload / required
        Added value: +[
+  "authority"
+]
      • removedInput schema / properties / payload / title
        Removed value: -"Payload"
  4. 5 tool updates
    • First observedcompare_licensing_requirements
    • First observedlicensing_source_status
    • First observedlist_supported_authorities
    • First observedtaxi_licence_preflight
    • First observedtaxi_phv_info

Publisher details

Operator
RegEvidenceHub · Publisher source
Operator website
https://www.regevidencehub.com · Publisher source
Vendor relationship
Independent
Documentation
https://taxi.regevidencehub.com · Publisher source
Trust center
Not available
Restrictions
Free discovery and source-status tools require no authentication. Decision tools such as taxi licence preflight and authority comparison may require x402 payment. Coverage is limited to supported England taxi/PHV licensing authorities and official-source evidence available to the service. · Publisher source

Related MCP Connectors

Related MCP Servers

  • Praesago

    marlybone
    A
    license
    A
    quality
    A
    maintenance
    UK property area intelligence: validated trajectory scores, gentrification early-warning and area screening for 2,292 England & Wales postcode districts, from 30+ government data sources.
    7
    MIT

  • uk-rates-thresholds

    Neonswitched
    F
    license
    Not graded
    quality
    B
    maintenance
    Query current and historical UK official figures (tax bands, minimum wage, benefits, energy price cap and 100+ more) with effective dates and links to official government sources. Data refreshed whenever the official sources change.
    -
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