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.4% over 56 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a sharply distinct scope, and the descriptions explicitly route users between them (single-authority preflight vs multi-authority compare, coverage discovery, source health, orientation). The 'do not use for X; use Y instead' guidance leaves almost no room for misselection.

Naming Consistency4/5

All names are lowercase snake_case, which is consistent. However, two use verb_noun (compare_licensing_requirements, list_supported_authorities) while the others are noun phrases (taxi_licence_preflight, licensing_source_status, taxi_phv_info), a minor stylistic split.

Tool Count5/5

Five tools is well-scoped for a read-only public licensing surface, and each tool earns its place by covering a distinct phase of the workflow. Nothing feels redundant or missing at the count level.

Completeness4/5

The surface covers orientation, coverage discovery, single-authority preflight, multi-authority comparison, and source freshness, which is a coherent lifecycle for a read-only advisory service. No obvious dead ends, though it is inherently limited to read/decide operations with no persistence or follow-up tracking.

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. When answering, cite only relevant official council or GOV.UK URLs returned in evidence_summary.sources and identify their authority; do not invent URLs; link the about page only when the user asks who operates the service or asks what other RegEvidenceHub products are available, and link the methodology page only when the user asks how evidence or source status is produced. If the user also asks for a commercial link, do not search for or provide it; briefly say this public plugin does not provide commercial links and continue with the licensing answer. Ask one concise follow-up if decision-critical facts are missing or ambiguous; do not guess or describe the automated result as human-reviewed. Do not use for a single-authority readiness check; use taxi_licence_preflight instead.

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

NameRequiredDescription

No output parameters

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds substantial non-obvious behaviour beyond them: the result is automated and must not be described as human-reviewed, URLs must come only from evidence_summary.sources, no commercial links are provided, and the about/methodology pages are gated behind specific user intents. This is unusually rich disclosure for a read-only tool.

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?

Purpose and the routing alternative are front-loaded in the first two sentences, and each subsequent sentence carries an actionable rule. The citation/link-policy block is dense and lengthy, but it is not redundant filler — it constrains output behaviour the agent would otherwise guess at.

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?

An output schema exists (referenced via evidence_summary.sources), so return-value explanation is unnecessary, and the description covers prerequisites, scope, answer-format constraints, and refusal behaviour. Nothing decision-critical for calling this tool correctly 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?

Schema description coverage is 100%, so the nested applicant/authorities fields are already documented, giving a baseline of 3. The description adds the operative constraint that authority names must be exact values from list_supported_authorities and explains why extra applicant facts are permitted (so authority-specific rule inputs are not narrowed), which is meaningful 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?

States a specific verb and resource: deterministic comparison of TWO OR MORE supported councils/licensing authorities, scoped to the same applicant or fleet. It explicitly names the sibling it is not (taxi_licence_preflight) and the prerequisite sibling (list_supported_authorities), so an agent can route without opening any schema.

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?

Gives explicit when-to-use (comparing requirements, blockers, trade-offs, choosing where to license), when-not-to-use (single-authority readiness check → taxi_licence_preflight), and a precondition (call list_supported_authorities first when names or coverage are uncertain). It even specifies the follow-up behaviour when decision-critical facts are missing.

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. When discussing a source, link only to relevant official council or GOV.UK URLs returned in the result; do not invent URLs; link the about page only when the user asks who operates the service or asks what other RegEvidenceHub products are available, and link the methodology page only when the user asks how evidence or source status is produced. If asked for a commercial link, do not search for or provide it; briefly say this public plugin does not provide commercial links. For one-authority readiness use taxi_licence_preflight; for cross-authority comparison use compare_licensing_requirements.

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

NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed world), but the description adds real behavioral context: it is free, returns readiness signals rather than a licensing decision, and carries explicit linking constraints including refusing commercial links. Some of this is response-style policy rather than tool behavior, which keeps it just below the top score.

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

Conciseness3/5

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

Purpose and trigger conditions are correctly front-loaded, but the second half is a long chain of linking rules and a commercial-link prohibition that reads more like response policy than tool documentation. Useful content, but it dilutes the core definition.

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?

An output schema exists, so return-value detail is not required. Between the description's trigger list, scoping instructions, alternatives, and the 100%-covered parameter, an agent has everything needed to select and invoke this tool 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?

Schema coverage is 100% and the single parameter already documents that authority should be an exact supported name from list_supported_authorities and that omission yields a global check. The description restates the same narrowing/global distinction, adding little syntax or meaning beyond the schema. Baseline 3 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?

States a specific verb+resource: 'source health and freshness tool' returning 'source/review readiness signals'. It explicitly distinguishes itself from siblings by naming taxi_licence_preflight for one-authority readiness and compare_licensing_requirements for cross-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?

Gives explicit trigger conditions ('when the user asks whether licensing evidence is current, stale, changed, conflicted, inaccessible, under review, or safe to rely on'), tells how to scope with or without the authority parameter, and routes to two named alternative tools. Nothing is left to inference.

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

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.

NameRequiredDescriptionDefault

No parameters

Output 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. When answering, cite only relevant official council or GOV.UK URLs returned in evidence_summary.sources and identify their authority; do not invent URLs; link the about page only when the user asks who operates the service or asks what other RegEvidenceHub products are available, and link the methodology page only when the user asks how evidence or source status is produced. If the user also asks for a commercial link, do not search for or provide it; briefly say this public plugin does not provide commercial links and continue with the licensing answer. Ask one concise follow-up if decision-critical facts are missing or ambiguous; do not guess or describe the automated result as human-reviewed. Do not use for multiple-authority comparison; use compare_licensing_requirements instead.

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

NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: it is free and deterministic, the automated result must not be described as human-reviewed, it will ask one concise follow-up rather than guess, and it constrains which URLs may be cited. These are meaningful operating rules, though a few (URL/commercial-link policy) shade into answer formatting rather than tool 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 purpose and scope are front-loaded in the first sentence, and the routing/prerequisite guidance follows immediately. It is dense and long with several policy clauses (citation rules, commercial-link refusal) that add length, but each sentence maps to an operational decision the agent must make.

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?

An output schema exists, so return values need not be explained, and the description still references evidence_summary.sources to set citation expectations. For a high-complexity, policy-laden preflight tool it covers triggers, prerequisites, exclusions, and answer constraints; the only residual gap is any hint about how much detail the decision output contains.

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 each nested field (authority, age, driving_licence_years, has_pass_plus_certificate) is documented in the schema, so the schema carries the load. The tool description only gestures at 'preflight facts' and does not add syntax or format meaning beyond what the schema already provides, which is the baseline 3.

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?

States a specific verb and resource ('deterministic decision preflight for ONE supported council/licensing authority') and explicitly scopes it to a single authority, which cleanly distinguishes it from the sibling compare_licensing_requirements. An agent can tell what it does and what it does not do without opening the schema.

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?

Names the trigger conditions (applicant/driver/vehicle/fleet readiness, requirements, blockers, missing facts, next actions before submission), a prerequisite ('Call list_supported_authorities first if coverage or the exact authority name is uncertain'), and an explicit exclusion routing to compare_licensing_requirements. When-to-use, when-not, and the alternative are all present.

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 asks for a commercial link, do not search for or provide one; briefly say this public plugin does not provide commercial links and answer the licensing question with official authority sources. 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.

NameRequiredDescriptionDefault

No parameters

Output 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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral scope beyond that: it makes no licensing decision and must not surface commercial links, redirecting instead to official authority sources. It stops short of describing what the metadata payload actually contains, but that is largely covered by the output schema.

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

Conciseness4/5

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

Front-loaded with the purpose and the 'use this first' trigger before the routing and refusal guidance. It is on the longer side and the commercial-link refusal sentence could be tighter, but each sentence carries actionable instruction rather than 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?

An output schema exists, so return values need not be explained. The description covers purpose, primary trigger, refusal behavior, and sibling routing, which is everything an agent needs to select and invoke a zero-parameter orientation 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?

The tool takes zero parameters, so per the rubric the baseline is 4 and there is nothing for the description to disambiguate. No parameter claims are made that could conflict with the empty 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?

States a specific verb and resource (orientation/info tool returning service and tool metadata) and explicitly bounds scope with 'makes no licensing decision'. It is clearly distinguishable from siblings, which are named as the licensing-decision alternatives.

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?

Gives an explicit trigger ('use this first when the user asks what RegEvidenceHub Taxi does...'), an exclusion (commercial link requests), and routes three distinct needs to taxi_licence_preflight, compare_licensing_requirements, and list_supported_authorities respectively. Nothing is left to inference.

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

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
    C
    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

  • rentready

    genzagents
    A
    license
    A
    quality
    A
    maintenance
    Enables agents to check whether an English rental property is ready for the landlord database, using a postcode and certificate dates to determine the region's registration window and deadline, flag gas safety, EICR and EPC records that expire or are missing, and report the fee, upload requirements and next actions. One tool, check_property, works offline apart from a postcode lookup and returns pass/warn/fail results.
    4
    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