Skip to main content
Glama
Sign In
UK Due Diligence

UK Due Diligence

by paulieb89
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Search Disqualified Directors

disqualified_search
Read-onlyIdempotent

Search for individuals banned from acting as UK company directors. Enter a person's name to find disqualification matches and officer IDs for further profile checks.

Instructions

Check whether a named individual is banned from acting as a UK company director.

Use this tool when asked to check disqualified, banned, or barred directors. Query must be an individual's name (e.g. "Richard Howson") — NOT a company name, which always returns zero results.

Returns names, dates of birth, match snippets (often empty), and officer IDs that can be used with disqualified_profile for full details. The disqualification periods come from disqualified_profile.

Input Schema

NameRequiredDescriptionDefault
nameNoAlias for query — the person's name.
queryNoPerson's name to search for, e.g. query='Richard Howson'. NOT a company name.
start_indexNoPagination offset (0-based). Default 0.
items_per_pageNoResults per page (max 100). Default 20.

Output Schema

NameRequiredDescriptionDefault
itemsNoMatching disqualified officer records.
queryYesSearch query applied.
has_moreYesTrue if more items may exist beyond this page. Re-call with start_index=start_index+items_per_page to continue.
returnedYesItems actually returned on this page.
start_indexYesPagination offset for this page.
total_resultsYesTotal matching records upstream at Companies House.
items_per_pageYesPage size requested.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.1.1
    • addedInput schema / properties / name
      Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 200,
+      "minLength": 2,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Alias for query — the person's name."
+}
    • addedInput schema / properties / query / anyOf
      Added value: +[
+  {
+    "maxLength": 200,
+    "minLength": 2,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / query / default
      Added value: +null
    • changedInput schema / properties / query / description
      Previous value: -"Name of the person to search for"New value: +"Person's name to search for, e.g. query='Richard Howson'. NOT a company name."
    • removedInput schema / properties / query / maxLength
      Removed value: -200
    • removedInput schema / properties / query / minLength
      Removed value: -2
    • removedInput schema / properties / query / type
      Removed value: -"string"
    • removedInput schema / required
      Removed value: -[
-  "query"
-]
  2. Addedv1.0.6
  3. Removedv1.0.1
  4. First observedv1.0.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: it discloses the return fields, warns that match snippets are often empty, and states that disqualification periods live in disqualified_profile rather than here, which prevents a wasted follow-up read of the wrong tool's output.

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 tight paragraphs, purpose first, then when to use, then the critical input constraint, then return shape. No filler and nothing buried.

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?

Complete for a read-only search: purpose, trigger, input constraint, expected return fields, and where to go for the missing detail are all present. With annotations and an output schema carrying the rest, an agent has everything needed to call it correctly on the first attempt.

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 schema already documents both `name`/`query` aliases, the example name, the company-name exclusion, and pagination bounds. The description largely restates the person-vs-company constraint that the schema already states, so it adds little parameter meaning beyond the baseline.

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: checking whether a named individual is banned as a UK company director. This is clearly distinct from sibling tools like company_search or disqualified_profile, which retrieves detail rather than searching.

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?

Explicitly says when to use it ('when asked to check disqualified, banned, or barred directors') and states a hard negative constraint: the query must be an individual's name, never a company name, because that always returns zero results. It also names the follow-up tool (disqualified_profile) for full detail.

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

Deploy Server

Other Tools