RegEvidenceHub Taxi

Server Details

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

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-21 15:54
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.6/5.0

Scored 2026-09-20 19:35 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: comparing across authorities, checking source status, listing supported authorities, running a one-authority preflight, and explaining the toolset. There is no meaningful overlap or ambiguity among the five tools.

Naming Consistency2/5

Naming is inconsistent: 'compare_licensing_requirements' and 'list_supported_authorities' use verb_noun structure, while 'licensing_source_status', 'taxi_licence_preflight', and 'taxi_phv_info' are noun phrases without a clear verb pattern. Also mixes British 'licence' with American 'licensing'.

Tool Count5/5

Five tools is well-scoped for a focused Taxi/PHV licensing information server. Each tool covers a distinct need without bloat or thinness.

Completeness5/5

The toolset covers all obvious needs: discoverability of authorities, per-authority preflight, cross-authority comparison, source freshness verification, and user guidance. No major dead ends or missing operations for a read-only advisory service.

Available Tools

5 tools

compare_licensing_requirementsA

Read-onlyIdempotent

Inspect

Run a payment-free deterministic comparison across supported authorities.

ParametersJSON Schema

Name	Required	Description	Default
`payload`	Yes	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.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.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=false, so the safety profile is covered. The description adds 'payment-free' and 'deterministic', which are meaningful behavioral traits beyond the annotations, even though it does not describe error handling or edge-case behavior.

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 compact sentence with no filler. It is slightly underspecified because behavioral modifiers like 'payment-free' and 'deterministic' appear before the actual comparison resource, but overall it is appropriately concise for a tool with a rich schema.

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 description, schema, annotations, and output schema together provide enough information for an agent to invoke the tool correctly. The only notable omission is that the description does not explicitly state that the comparison determines licensing requirement matches for an applicant/fleet, but this is recoverable from the tool name and schema examples.

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 has 100% description coverage, including a detailed payload object, nested applicant properties, authorities constraints, and the instruction to use exact names from list_supported_authorities. The tool description itself adds no extra parameter-level meaning, so the schema bears the weight and the baseline score applies.

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

Purpose4/5

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

The description names a comparison action applied to 'supported authorities', making it clear this is a multi-authority licensing comparison tool. However, it does not explicitly mention taxi/PHV licensing or that the comparison is based on applicant facts; that context is recovered mainly from the tool name, annotations title, and schema.

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

Usage Guidelines3/5

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

The phrase 'across supported authorities' and the payload description's instruction to call list_supported_authorities first imply the intended workflow. The tool description itself gives no explicit guidance on when to choose this tool over siblings such as taxi_licence_preflight, licensing_source_status, or taxi_phv_info.

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

licensing_source_statusC

Read-onlyIdempotent

Inspect

Check official-source freshness, conflicts, and review state.

ParametersJSON Schema

Name	Required	Description	Default
`authority`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already specify readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds 'review state' and 'conflicts', which are useful but not extensive. With annotations covering safety, 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, concise sentence that gets to the point. It is not overly verbose and is front-loaded with the core action. Slight improvement could be a bit more detail, but for its length it is well structured.

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

Completeness3/5

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

Given the tool's complexity is low (1 optional param, no nested objects) and it has an output schema (which presumably explains return values), the description is mostly complete. It covers the main aspects (freshness, conflicts, review state) but lacks detail on what 'conflicts' means or what a typical use case is.

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 0%, so the description must compensate. The description mentions 'source' and 'authority' but does not explicitly explain the 'authority' parameter or its format. With only one parameter and default null, it is partially self-explanatory, but more clarity would be helpful.

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

Purpose3/5

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

The description states a clear purpose: checking source freshness, conflicts, and review state. However, it is somewhat vague about what 'source' refers to and does not explicitly distinguish it from siblings, though the context of licensing suggests it is about licensing sources.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The description implies it is for checking status, but does not mention when to prefer it over compare_licensing_requirements or taxi_phv_info. An agent would have to infer its role.

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

List authorities covered by the deterministic Taxi/PHV rule bundle.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
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, idempotentHint, and destructiveHint, so the description does not need to restate those. It adds mild context by calling the rule bundle 'deterministic', implying a stable, predictable list. This is useful but not a major addition beyond 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 a single, front-loaded sentence with no filler. Every word contributes to identifying the tool's scope and output subject, making it appropriately concise.

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-argument read-only tool, the description fully covers the essential context: what is listed and under which bundle. Annotations cover safety semantics, and the existing output schema covers return structure, so nothing important 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 tool has zero parameters and an empty input schema, so there is no semantic burden for the description to carry. The baseline of 4 for a parameterless tool applies; the description adds nothing about parameters because none exist.

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 clear verb ('List') and a specific resource ('authorities covered by the deterministic Taxi/PHV rule bundle'). This distinguishes it from sibling tools like compare_licensing_requirements or taxi_phv_info, which clearly serve different purposes.

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

Usage Guidelines3/5

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

No explicit when-to-use or when-not-to-use guidance is given, and no alternatives are named. However, the purpose is self-evident for a zero-parameter listing tool: use it when you need the set of supported authorities. This is implied rather than stated.

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

Run a payment-free deterministic one-authority licensing preflight.

ParametersJSON Schema

Name	Required	Description	Default
`payload`	Yes	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.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds valuable non-obvious traits—'payment-free' and 'deterministic'—that are not present in the annotations. It does not detail auth or rate limits, but the annotation coverage lowers 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?

The description is a single 7-word sentence with no filler. It front-loads the action and the most decision-relevant qualifiers: payment-free, deterministic, one-authority.

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 read-only preflight tool with rich annotations, a full output schema, and a well-documented input schema, the description covers the essential decision factors. It is slightly light on explicit sibling differentiation, but the 'one-authority' scope and schema's list_supported_authorities hint make it adequately complete.

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% and the payload's nested schema already provides detailed parameter semantics, including the requirement to use exact authority names and allow additional facts. The tool description itself adds no parameter-level meaning, so 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 action ('Run'), a specific resource ('licensing preflight'), and clear scope constraints ('one-authority', 'payment-free', 'deterministic'). This makes it easy to distinguish from sibling tools like compare_licensing_requirements, list_supported_authorities, and taxi_phv_info.

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

Usage Guidelines3/5

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

Usage context is only implied: 'one-authority' suggests it is not for comparing licensing requirements, and the schema says to start by calling list_supported_authorities. However, the description itself gives no explicit when-to-use or when-not-to-use guidance and does not name any alternative tools.

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

taxi_phv_infoB

Read-onlyIdempotent

Inspect

Explain the public payment-free Taxi/PHV licensing tools and their safety boundary.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/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 the 'safety boundary' concept, but it does not elaborate on what that boundary is or what kind of response the caller should expect, adding only minimal value 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.

Conciseness4/5

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

The description is a single sentence that starts with the key action 'Explain' and contains no filler. It is concise, though the phrase 'public payment-free' is slightly awkward and could be clearer without adding length.

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

Completeness3/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 strong safety annotations, the purpose is minimally present. However, the description leaves 'safety boundary' vague and provides no contextual link to the sibling tools, so an agent is not fully equipped to decide when this tool is the right choice.

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 properties, so there are no parameters to document. The 0-parameter baseline of 4 applies, and the description does not need to compensate for any missing parameter details.

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

Purpose4/5

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

The description uses the verb 'Explain' and names a specific domain ('public payment-free Taxi/PHV licensing tools and their safety boundary'), making it distinguishable from the operational siblings like compare_licensing_requirements and taxi_licence_preflight. It is not a top score because it does not explicitly name a sibling or fully clarify what 'public payment-free' modifies.

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

Usage Guidelines2/5

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

There is no guidance about when to use this tool versus the sibling tools. The description tells what the tool does but never says 'use this when...' or 'for specific requirements use compare_licensing_requirements.' The use case must be inferred from the word 'Explain' and the tool name.

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.

4 tool updatesSep 20, 2026

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"
+}

2 tool updatesSep 5, 2026

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"
```

5 tool updatesSep 1, 2026
- First observedcompare_licensing_requirements
- First observedlicensing_source_status
- First observedlist_supported_authorities
- First observedtaxi_licence_preflight
- First observedtaxi_phv_info

Related MCP Connectors

RegEvidenceHub Premises A
io.github.ChanghuLiu
RegEvidenceHub Premises: UK premises-licensing preflight for supported authorities.
Legal & Compliance Government Data
41
RegEvidenceHub CQC A
io.github.ChanghuLiu
RegEvidenceHub CQC: England provider-registration and statutory-notification preflight.
Biology & Medicine Government Data Legal & Compliance
41
RegEvidenceHub Sponsor A
io.github.ChanghuLiu
RegEvidenceHub Sponsor: UK Skilled Worker sponsor-change preflight with GOV.UK evidence.
Legal & Compliance Government Data Open Data
41
snaptoll A
com.snaptoll
UK tolls & charges: DVLA vehicle checks (ULEZ/CAZ/MOT/tax), prices, penalties, pay-by deadlines.
Travel & Transportation Government Data Finance
32

Related MCP Servers

haulage-uk-compliance-mcp
Travel & Transportation Government Data
CSOAI-ORG
A
license
Not graded
quality
D
maintenance
Enables UK haulage compliance checks including operator licence verification, tachograph auditing, drivers' hours calculations, and DVSA roadside inspection support.
Updated 3 months ago (2026-06-26 05:32 UTC)
54 PyPI
MIT
Praesago
Real Estate Open Data Research & Data
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.
Updated 2 months ago (2026-07-28 22:54 UTC)
7
MIT
uk-rates-thresholds
Government Data Open Data
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.
Updated a month ago (2026-08-14 10:27 UTC)
-
meok-tacho-audit-mcp
Legal & Compliance Monitoring Travel & Transportation
CSOAI-ORG
A
license
Not graded
quality
D
maintenance
Enables UK haulage compliance managers to audit tachographs, drivers' hours, and DVSA OCRS scores, preventing red status and generating public inquiry briefs.
Updated 3 months ago (2026-06-16 05:46 UTC)
39 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

Need Help?