UK Due Diligence
Server Details
UK due diligence — Companies House, Charity Commission, Land Registry, Gazette, HMRC VAT
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- paulieb89/uk-due-diligence-mcp
- GitHub Stars
- 2
- Server Listing
- UK Due Diligence
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 16 of 16 tools scored. Lowest: 3.8/5.
Each tool targets a distinct resource or action: charities, companies, disqualified directors, gazette, land registry, VAT, and prompts. The only potential overlap between `search` (multi-register) and individual searches is clearly disambiguated by descriptions.
Most tools follow a domain_verb pattern (charity_search, company_profile), but there are exceptions: `fetch`, `search`, and `gazette_insolvency` (domain_noun). Overall consistent enough to predict tool purpose.
16 tools cover the due diligence domain well—search, profiles, officers, PSC, disqualifications, gazette, land, VAT, and prompts. Each tool serves a clear need without bloat.
The set provides a complete read-only due diligence workflow: searching across registers, fetching full profiles, checking officers, PSC, disqualifications, land titles, VAT validation, and gazette insolvency. No obvious gaps for the stated purpose.
Available Tools
16 toolscharity_profileGet Charity ProfileARead-onlyIdempotentInspect
Fetch the full Charity Commission profile for a charity number.
Returns trustees, latest income/expenditure, insolvency flags, governing document type, classifications, and countries of operation. Use charity_search first to find the charity number.
| Name | Required | Description | Default |
|---|---|---|---|
| charity_number | Yes | Charity Commission registration number (e.g. '1234567'). Returned by charity_search. |
Output Schema
| Name | Required | Description |
|---|---|---|
| address | No | Registered address of the charity (joined address lines). |
| insolvent | No | True if the charity is flagged as insolvent. |
| reg_status | No | Registration status code ('R', 'RM'). |
| charity_name | No | Registered charity name. |
| charity_type | No | Charity type. |
| latest_income | No | Latest filed annual income in GBP. |
| trustee_names | No | Trustees on record. Truncated to 30 entries. |
| charity_number | Yes | Charity registration number. |
| who_what_where | No | Who/What/Where classification entries. The list may be truncated truncated to 50 entries. |
| reg_status_label | No | Human-readable registration status. |
| in_administration | No | True if the charity is in administration. |
| latest_expenditure | No | Latest filed annual expenditure in GBP. |
| trustee_names_total | No | Total trustees upstream before truncation. |
| date_of_registration | No | Date of first registration. |
| who_what_where_total | No | Total classification entries upstream before truncation. |
| charity_co_reg_number | No | Companies House number for charities also registered as companies (Charitable Incorporated Organisations, etc.). |
| countries_of_operation | No | Countries the charity operates in (capped at 10 upstream). |
| trustee_names_truncated | No | True if the trustee list was truncated. |
| who_what_where_truncated | No | True if the classification list was truncated. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. Description adds specific returned fields (trustees, income, etc.), providing additional behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load purpose and then detail returns, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and output schema present, description provides all necessary context for agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers parameter fully (100%). Description adds helpful context: format example and that value comes from charity_search, which aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it fetches the full charity profile for a charity number, listing specific data returned. Distinguishes from sibling charity_search by implying that tool finds the number.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use charity_search first to find the charity number, providing clear when-to-use guidance and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
charity_searchSearch Charity Commission RegisterARead-onlyIdempotentInspect
Search the Charity Commission register of England and Wales by name or keyword.
Returns matching charities with registration number, status, and
registration date. Use charity_profile for full details once you
have the charity number. The upstream searchCharityName endpoint
returns the full list in one shot — pagination is applied
client-side via offset/limit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max items to return in this page. Default 20; raise to 100 for bulk views. | |
| query | Yes | Charity name or keyword to search for | |
| offset | No | Number of items to skip before this page. Default 0. |
Output Schema
| Name | Required | Description |
|---|---|---|
| limit | Yes | Max items requested for this page. |
| query | Yes | Search term applied. |
| total | Yes | Total matches returned by upstream. |
| offset | Yes | Number of items skipped before this page (client-side). |
| has_more | Yes | True if more items may exist beyond this page. Re-call with offset=offset+returned to continue. |
| returned | Yes | Items actually returned on this page. |
| charities | No | Matching charity records. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, etc.), the description adds that the 'searchCharityName' endpoint returns the full list with client-side pagination, and specifies return fields (registration number, status, registration date). No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: stating the action, specifying return fields and linking to sibling, and explaining pagination behavior. No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately outlines expected return fields and pagination behavior. It could potentially mention error conditions, but overall it is complete for the tool's intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds value by explaining that offset/limit are for client-side pagination and that limit can be raised to 100 for bulk views. This aids the agent in parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Search the Charity Commission register of England and Wales by name or keyword.' It clearly distinguishes from sibling tool charity_profile, which is for full details after obtaining the charity number.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using charity_profile for full details once the charity number is known, and explains that the upstream endpoint returns the full list in one shot with client-side pagination. This informs the agent about when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company_officersGet Company OfficersARead-onlyIdempotentInspect
Fetch active officers for a Companies House company number.
Returns directors, secretaries, and other active officers with appointment dates, nationality, and country of residence. Resigned officers are excluded. Pagination is handled internally — do NOT pass items_per_page or start_index; this tool takes only company_number.
| Name | Required | Description | Default |
|---|---|---|---|
| start_index | No | Ignored — all officers are returned in one call. | |
| company_number | Yes | Companies House company number (8 digits, e.g. '03782379'). Returned by company_search. | |
| items_per_page | No | Ignored — pagination is handled internally. Only accepted to avoid call failures. |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total officers returned (filtered by include_resigned). |
| officers | No | Officer records. |
| company_number | Yes | Companies House company number. |
| include_resigned | Yes | Whether resigned officers were included in this result. |
| high_appointment_count_flag | No | Number of active officers with 10+ total appointments, or null if appointment counts were not fetched. Non-zero values are a nominee/phoenix director risk signal. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint false), the description reveals that resigned officers are excluded, pagination is internal, and the ignored parameters are accepted only to avoid failures. It adds meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences plus a clear instruction about parameters. No wasted words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description covers what is returned, what is excluded, and how pagination works. It is fully adequate for agent comprehension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context for company_number (linking to company_search) and reinforces that the other parameters are ignored, which helps prevent incorrect use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch active officers for a Companies House company number' and specifies the types of officers (directors, secretaries) and fields returned. It distinguishes from siblings like company_profile and company_psc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns not to pass items_per_page or start_index, stating the tool takes only company_number. While it doesn't explicitly compare with siblings, the guidance is clear and prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company_profileGet Company ProfileARead-onlyIdempotentInspect
Fetch the full Companies House profile for a company number.
Returns status, registered address, SIC codes, filing compliance (overdue accounts and confirmation statement flags), and whether the company has outstanding charges. Use company_search first to find the company number.
| Name | Required | Description | Default |
|---|---|---|---|
| company_number | Yes | Companies House company number (8 digits, e.g. '03782379'). Returned by company_search. |
Output Schema
| Name | Required | Description |
|---|---|---|
| accounts | No | Accounts filing status and due dates. |
| sic_codes | No | Standard Industrial Classification codes. |
| has_charges | No | True if the company has outstanding registered charges (secured debt), derived from the /charges endpoint. A due diligence signal. |
| company_name | No | Registered company name. |
| company_type | No | Companies House company type code. |
| company_number | Yes | Companies House company number. |
| company_status | No | Current status (active, dissolved, in liquidation, etc.). |
| date_of_creation | No | Incorporation date (ISO YYYY-MM-DD). |
| confirmation_statement | No | Confirmation statement filing status and next due date. |
| registered_office_address | No | Registered office address as returned by Companies House. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint. The description adds specific return fields (status, address, SIC codes, filing compliance, charges), providing behavioral context beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, listing return fields and usage hint. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return details are not needed. The description covers key fields and usage. It could mention other siblings but is complete enough for a profile tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for company_number. The description reinforces the parameter by linking to company_search but adds no new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch the full Companies House profile for a company number' using a specific verb and resource. It distinguishes from siblings like charity_profile and company_search by focusing on company profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Use company_search first to find the company number,' providing clear usage context and a direct reference to a sibling tool. It lacks when-not-to-use guidance but is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company_pscGet Persons with Significant ControlARead-onlyIdempotentInspect
Fetch Persons with Significant Control (beneficial ownership) for a company.
Returns PSC entries with natures of control, nationality, and country of residence. Flags overseas corporate PSC entries as a beneficial ownership risk signal. Returns an explanatory note for widely-held PLCs with no registrable PSC.
| Name | Required | Description | Default |
|---|---|---|---|
| company_number | Yes | Companies House company number (8 digits, e.g. '03782379'). Returned by company_search. |
Output Schema
| Name | Required | Description |
|---|---|---|
| psc | No | Persons with Significant Control records. |
| note | No | Explanatory note when total=0. Typical for widely-held listed PLCs where no single person or entity holds 25%+ of shares or voting rights. |
| total | Yes | Total PSC entries returned for this company. |
| company_number | Yes | Companies House company number. |
| overseas_corporate_psc_flag | No | Number of corporate PSCs registered outside the UK. Non-zero values indicate an offshore beneficial ownership chain. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and non-destructive nature. The description adds behavioral context: it flags overseas entries as risk signals and returns explanatory notes for PLCs without registrable PSC. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose. Every sentence adds value—no fluff or redundancy. Ideal length for an agent to quickly understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, existing output schema, and comprehensive annotations, the description fully covers the tool's behavior (what it returns, special cases). No gaps for an agent to misinterpret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'company_number' is well described in the input schema (format, length, example, source). With 100% schema coverage, the description adds no further semantic value, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches Persons with Significant Control for a company, specifying the resource, verb, and return fields (natures of control, nationality, residence, risk flags). It distinguishes from sibling tools like company_officers by focusing on beneficial ownership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use, including special cases like overseas corporate entries and widely-held PLCs. However, it does not explicitly state when not to use or name alternative tools, leaving some ambiguity for agents comparing against siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company_searchSearch Companies HouseARead-onlyIdempotentInspect
Search the Companies House register by company name or keyword.
Returns a paginated list of matching companies with name, number, status, SIC codes, incorporation date, and registered address. Use company_profile for the full record once you have the company number. Re-call with start_index=start_index+items_per_page to fetch the next page.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company name or keyword to search for | |
| start_index | No | Pagination offset. Default 0. | |
| company_type | No | Filter by company type (e.g. 'ltd', 'llp'). Omit to search all. | |
| company_status | No | Filter by company status (e.g. 'active', 'dissolved'). Omit to search all. | |
| items_per_page | No | Number of results to return (max 100). Default 20. |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | No | Matching companies. Use the `company_number` field to call company_profile, company_officers, or company_psc for full detail. |
| query | Yes | The query string that was searched. |
| has_more | Yes | True if more results exist beyond this page. Re-call with start_index=start_index+items_per_page to fetch the next page. |
| returned | Yes | Number of items actually returned on this page. |
| start_index | Yes | Number of results skipped before this page (upstream start_index). |
| total_results | Yes | Total matching companies in Companies House (server-side). |
| items_per_page | Yes | Page size requested from the API for this call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds that results are paginated and lists returned fields (name, number, status, SIC codes, incorporation date, address). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no unnecessary words. Efficiently conveys core information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and annotations are present, description covers usage and return structure well. Could mention pagination limits or default items_per_page but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add significant new info about parameters beyond what the schema provides, though it reinforces pagination behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search the Companies House register by company name or keyword' with specific verb 'Search' and resource 'Companies House register'. It distinguishes from sibling tools like company_profile for full records and charity_search for charities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use company_profile for full record once you have company number, and explains how to paginate by adjusting start_index. Does not explicitly state when not to use, but sibling context offers alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
disqualified_profileGet Disqualified Director ProfileARead-onlyIdempotentInspect
Fetch the full disqualification record for a director by officer ID.
Returns all disqualification orders: reason, Act/section cited, disqualification period, and associated company names. Use disqualified_search first to find the officer ID.
| Name | Required | Description | Default |
|---|---|---|---|
| officer_id | Yes | Companies House officer ID. Returned by disqualified_search. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | Officer name. |
| surname | No | Family name, if split upstream. |
| forename | No | Given name, if split upstream. |
| officer_id | Yes | Companies House officer ID looked up. |
| nationality | No | Declared nationality. |
| officer_kind | Yes | Which CH endpoint returned the record: 'natural' (individual) or 'corporate' (legal entity). |
| date_of_birth | No | Date of birth on record. |
| disqualifications | No | All disqualification orders attached to this officer. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds detail on what is returned (all disqualification orders with reasons, periods, etc.), providing additional behavioral transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences: first states purpose, second explains return content and prerequisite. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description fully covers what the tool does, how to prepare input, and what to expect in the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage and already describes the officer_id parameter. The description adds value by linking the parameter to 'disqualified_search', clarifying its origin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches the full disqualification record for a director by officer ID. It specifies the verb, resource, and identifier, and distinguishes itself from the sibling 'disqualified_search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use 'disqualified_search first to find the officer ID', providing clear when-to-use context and a prerequisite step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
disqualified_searchSearch Disqualified DirectorsARead-onlyIdempotentInspect
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, disqualification period snippets, and officer IDs that can be used with disqualified_profile for full details.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Name of the person to search for | |
| start_index | No | Pagination offset (0-based). Default 0. | |
| items_per_page | No | Results per page (max 100). Default 20. |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | No | Matching disqualified officer records. |
| query | Yes | Search query applied. |
| has_more | Yes | True if more items may exist beyond this page. Re-call with start_index=start_index+items_per_page to continue. |
| returned | Yes | Items actually returned on this page. |
| start_index | Yes | Pagination offset for this page. |
| total_results | Yes | Total matching records upstream at Companies House. |
| items_per_page | Yes | Page size requested. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. Description adds context about return fields (names, DOB, disqualification snippets, officer IDs) and how to use them with disqualified_profile. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, front-loaded with purpose. Each sentence adds necessary information without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations and an output schema, the description covers purpose, usage, and behavioral hints comprehensively. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description does not add extra parameter-level details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if a named individual is banned as a UK company director, with a specific verb-resource combination. It distinguishes from sibling tools like disqualified_profile and company_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (for disqualified/banned/barred directors) and provides a crucial rule: query must be an individual's name, not a company name. References sibling tool disqualified_profile for full details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetchFetch Full Record from UK Due Diligence RegisterARead-onlyIdempotentInspect
Fetch the full record for an ID returned by search.
Routes by prefix to the appropriate register:
company:{number} → Companies House full profile
charity:{number} → Charity Commission full profile
disqualification:{officer_id} → Disqualified director full record
notice:{notice_id} → Gazette notice full legal text
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Prefixed record ID returned by search. Format: company:{number}, charity:{number}, disqualification:{officer_id}, or notice:{notice_id} |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds transparency about routing behavior based on prefix, which is beyond what annotations provide. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and front-loaded: one sentence for purpose, then bulleted list for routing. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not explain return values. It thoroughly covers routing logic for all prefix types, making it complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'id' has a detailed description with format examples. The description complements by explaining how prefixes route to different registers, adding context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'full record for an ID returned by search'. It distinguishes from sibling tools by explaining routing by prefix to different registers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use (after search returns IDs) and provides routing logic for different prefixes. While it doesn't explicitly state when not to use, the context is clear. Alternatives are implicit in the routing but not named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gazette_insolvencySearch Gazette Corporate Insolvency NoticesARead-onlyIdempotentInspect
Search The Gazette's insolvency notice index by entity name.
Searches the Gazette's insolvency endpoint which covers corporate notice codes: winding-up orders (2443), administration orders (2448), liquidator appointments (2452), striking-off notices (2460), and more. Results are sorted by severity — winding-up orders and administration orders appear first.
Each result includes a notice_numeric_id. Read the full legal wording via the notice://{notice_numeric_id} resource.
The Gazette is the official UK public record. A notice here means the event has been formally published and is legally effective.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | Filter notices up to this date (YYYY-MM-DD) | |
| start_date | No | Filter notices from this date (YYYY-MM-DD) | |
| entity_name | Yes | Company or individual name to search for in Gazette insolvency notices | |
| max_notices | No | Cap on notices returned, applied after severity/date sort. Default 20. The Gazette insolvency feed returns up to 100 results per search — raise to 100 to see the full set. | |
| notice_type | No | Filter by notice code (e.g. '2441' winding-up petition, '2443' winding-up order, '2448' administration order, '2460' striking-off). Omit to search all. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notices | No | Matching notices, sorted by severity (desc) then date (desc). |
| end_date | No | Upper bound of the date range filter, if any. |
| start_date | No | Lower bound of the date range filter, if any. |
| entity_name | Yes | Entity name that was searched. |
| total_notices | Yes | Total notices returned after deduplication, sorting, and cap. |
| max_notices_cap | Yes | The max_notices cap applied. Upstream may have more matching notices. |
| notice_type_filter | No | Notice code filter applied, or null if all codes searched. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds key behaviors: results are sorted by severity, covers specific notice codes, and that a notice in The Gazette is legally effective. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Seven sentences, each contributing meaningfully: purpose, codes, sorting, usage of notice ID, legal significance. No redundant or vague phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and an output schema, the description covers purpose, usage, filters, result interpretation, and legal context. It fully enables correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameters are well-described. The description adds value by explaining sort order, the importance of notice_numeric_id, and how to access full legal wording via notice:// resource, exceeding baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches The Gazette's insolvency notice index by entity name. It lists specific notice codes covered, distinguishing it from sibling tools like gazette_notice (which reads a specific notice) and other search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (search by entity name, with date and type filters) and hints at when to use the sibling gazette_notice (to read full wording via notice_numeric_id). However, it does not explicitly state when not to use this tool or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gazette_noticeGet Gazette Notice Full TextARead-onlyIdempotentInspect
Fetch the full legal wording of a Gazette notice by numeric notice ID.
Returns the complete JSON-LD linked-data record for the notice: parties, legal basis, court, and full text. Use gazette_insolvency first to find notice_numeric_id values.
| Name | Required | Description | Default |
|---|---|---|---|
| notice_id | Yes | Numeric Gazette notice ID. Returned as notice_numeric_id by gazette_insolvency. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. Description adds that it returns a 'complete JSON-LD linked-data record' with parties, legal basis, court, and full text, which is valuable 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: first for purpose, second for return content and usage guidance. Front-loaded and no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description need not explain return values. It covers the purpose, prerequisite, and parameter origin. Complete for a simple one-param tool with rich annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description restates that notice_id is numeric and mentions the sibling tool for finding it, which adds slight context but doesn't significantly enhance understanding beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch the full legal wording of a Gazette notice by numeric notice ID.' It specifies the verb, resource, and input. It distinguishes from sibling gazette_insolvency by positioning it as a prerequisite tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instruction: 'Use gazette_insolvency first to find notice_numeric_id values.' This tells the agent the correct workflow. Missing explicit when-not-to-use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_promptAInspect
Get a prompt by name with optional arguments.
Returns the rendered prompt as JSON with a messages array. Arguments should be provided as a dict mapping argument names to values.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the prompt to get | |
| arguments | No | Optional arguments for the prompt |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It does disclose the output format ('JSON with a messages array'), but omits behavioral details like side effects, rate limits, or error handling. Adequate for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no redundant information. Every sentence is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has an output schema (though not detailed here), and description partially explains return format. For a tool with 2 params and no nested objects, the description is fairly complete, though missing notes on error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described in schema). The description adds value by specifying that arguments should be a dict mapping names to values, which goes beyond the schema's generic 'Optional arguments for the prompt'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get', the resource 'prompt by name', and mentions optional arguments. It distinguishes from sibling 'list_prompts' which likely returns all prompts, while this retrieves one by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., list_prompts). No mention of prerequisites, appropriate contexts, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
land_title_searchSearch Price Paid Transactions by PostcodeARead-onlyIdempotentInspect
Search HM Land Registry Price Paid Index by postcode or address.
Returns up to 10 recent sale transactions for the postcode: price, date, address, property type, and tenure (Freehold/Leasehold). Covers England and Wales only. Postcode gives the most reliable results — a full address is also accepted and the postcode is extracted automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| address_or_postcode | Yes | UK property address or postcode. Postcode is most reliable: e.g. 'NG1 1AB'. Full address also accepted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Number of Price Paid transactions returned. Capped at 10 by the upstream SPARQL query. |
| postcode | Yes | Normalised UK postcode extracted from the input. |
| transactions | No | Recent Price Paid transactions for the postcode, sorted newest first. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds value by specifying a 10-result limit, England/Wales coverage, and automatic postcode extraction from full addresses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first states action and resource, second details returns, third clarifies scope and input behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool simplicity (1 parameter), rich annotations, and presence of output schema, the description fully covers purpose, returned data, limits, and input handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes the parameter with min/max length and full description. The description complements by explaining input reliability and automatic postcode extraction, adding semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches HM Land Registry Price Paid Index by postcode or address, listing returned data fields. It distinctly separates from sibling tools that deal with company or charity data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates use for land registry price data, but lacks explicit when not to use or alternative tool references. The sibling list suggests uniqueness, but no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_promptsAInspect
List all available prompts.
Returns JSON with prompt metadata including name, description, and optional arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the tool returns JSON with name, description, and optional arguments, but omits details like read-only nature, side effects, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb 'List', and every word adds value. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and an existing output schema, the description covers the essential return fields (name, description, optional arguments). It is sufficiently complete for an agent to understand the tool's purpose and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so baseline is 4. The description adds no parameter info, but none is needed; it does mention 'optional arguments' in the output, which subtly indicates the output structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all available prompts', distinguishing it from sibling tools like 'get_prompt' which targets individual prompts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool (listing all prompts) but does not explicitly exclude scenarios or mention alternatives like 'get_prompt' for individual prompt retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch UK Due Diligence RegistersARead-onlyIdempotentInspect
Search across all UK due diligence registers simultaneously.
Searches Companies House, Charity Commission, disqualified directors, and Gazette insolvency notices in parallel. Returns a list of result IDs — use fetch with each ID to retrieve the full record.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company name, charity name, director name, or keyword to search for across all UK due diligence registers |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds that the search runs in parallel across registers and returns a list of result IDs, which complements the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, clear sentences. Front-loaded with the main action and key registers, immediately followed by the return format and next steps. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter), presence of an output schema, and annotations, the description fully covers what the tool does, what it returns, and how to proceed (using fetch). Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for 'query' that matches the tool description. The description does not add new semantic information beyond the schema; thus baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches across all UK due diligence registers simultaneously, listing specific registers (Companies House, Charity Commission, disqualified directors, Gazette insolvency notices). Distinguishes from sibling tools like company_search, charity_search, etc., which are single-register searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes the tool's broad search scope and provides a clear follow-up action: use fetch with each returned ID to get full records. Implicitly guides when to use this tool vs. single-register siblings, though not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vat_validateValidate UK VAT Number (HMRC)ARead-onlyIdempotentInspect
Validate a UK VAT number against the HMRC register.
Returns the trading name and address as registered with HMRC for VAT purposes. The VAT-registered trading address often differs from the Companies House registered address — that discrepancy is a due diligence signal worth noting.
| Name | Required | Description | Default |
|---|---|---|---|
| vat_number | Yes | UK VAT registration number. Accepts: 'GB123456789', '123456789', 'GB 123 456 789'. GB prefix and spaces normalised automatically. |
Output Schema
| Name | Required | Description |
|---|---|---|
| valid | Yes | True if HMRC confirmed the VAT number is currently registered. False means HMRC returned 404 (not registered / deregistered). |
| vat_number | Yes | Canonical VAT number in 'GB<9 digits>' format. |
| trading_name | No | Trading name registered with HMRC for VAT. Compare with the Companies House name — discrepancies are a due diligence signal. |
| registered_address | No | VAT-registered trading address. May differ from the Companies House registered office address. |
| consultation_number | No | HMRC consultation reference number for this lookup. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that it returns trading name and address and notes a common discrepancy, providing useful context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no unnecessary words. Every sentence provides value: purpose, return value, and a due diligence note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description sufficiently covers what the tool does and returns. The added note about address discrepancy is valuable context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage on the sole parameter, so the description does not need to add detail. The schema already describes the parameter, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('validate') and the resource ('UK VAT number against the HMRC register'). It distinguishes from sibling tools that focus on charity or company info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for VAT validation and notes return value, but does not explicitly state when to use or not use vs alternatives. Sibling tools are different, so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.