Skip to main content
Glama
kaylum54

companies-house-screening-mcp

by kaylum54

Screen a list of companies

screen_companies
Read-onlyIdempotent

Batch-screen up to 50 companies against Companies House in one request. Returns status, age, and signal flags per company, with unresolved names and skipped entries explained.

Instructions

Use this whenever the question is about MORE THAN ONE company — a list, a comparison, "which of these", a batch from procurement, anything with several names or numbers in it. Prefer it over calling company_snapshot repeatedly: it costs a quarter of the requests and returns a table you can read at a glance. Screens up to 50 companies and returns one row each: status, age, and which signals were found. Names that match more than one company are never guessed at; they come back under unresolved with their candidates so you can ask which was meant. Anything skipped for want of rate-limit budget comes back under not_screened with the reason, so the table is never quietly shorter than the list you passed in. Rows carry signal codes only — call company_snapshot on one company number for the detail behind them. Officers are excluded by default because they cost an extra request per company; sections_used says what the signals could see.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
companiesYesCompany names or numbers. Mixed input is fine. Maximum 50 per call.
include_chargesNoInclude charges. On by default.
include_officersNoFetch officers too, enabling the no_active_officers and recent_officer_departures signals. Off by default: it adds one request per company.
include_insolvencyNoInclude insolvency cases. On by default.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
metaYesProvenance and budget for this answer.
screenedYes
requestedYes
unresolvedYesInputs that could not be resolved to exactly one company. Never guessed at.
not_screenedYesInputs deliberately skipped, with the reason. Nothing is dropped silently.
sections_usedYesSignals in this table can only reflect these sections. Officers are off by default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.4.0
    • addedInput schema / properties / companies / items / maxLength
      Added value: +256
    • changedOutput schema / properties / meta / properties / licence / description
      Previous value: -"Companies House data is Open Government Licence v3.0."New value: +"OGL v3.0 applies to eligible public-sector information. Personal data and other OGL exclusions are not licensed by this label; applicable data-protection duties still apply."
    • addedOutput schema / properties / screened / items / properties / meta
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Provenance and budget for this answer.",
      +  "properties": {
      +    "age_seconds": {
      +      "description": "How long ago the cached answer was retrieved. Absent for a live answer.",
      +      "type": "number"
      +    },
      +    "cached": {
      +      "description": "Answer came from the local cache rather than a live request.",
      +      "type": "boolean"
      +    },
      +    "licence": {
      +      "const": "OGL-v3.0",
      +      "description": "OGL v3.0 applies to eligible public-sector information. Personal data and other OGL exclusions are not licensed by this label; applicable data-protection duties still apply.",
      +      "type": "string"
      +    },
      +    "rate_limit_remaining": {
      +      "description": "Requests still available in the current five-minute window. Pace long runs by this.",
      +      "type": "number"
      +    },
      +    "rate_limit_resets_in_ms": {
      +      "description": "Milliseconds until more budget becomes available.",
      +      "type": "number"
      +    },
      +    "stale": {
      +      "description": "Answer came from an expired cache entry because Companies House was unreachable. Treat the data as possibly out of date.",
      +      "type": "boolean"
      +    }
      +  },
      +  "required": [
      +    "cached",
      +    "stale",
      +    "rate_limit_remaining",
      +    "rate_limit_resets_in_ms",
      +    "licence"
      +  ],
      +  "type": "object"
      +}
    • addedOutput schema / properties / screened / items / properties / officers_pagination
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Officer page coverage when officers were requested.",
      +  "properties": {
      +    "has_more": {
      +      "description": "More records exist. Call again with start_index advanced by `returned`.",
      +      "type": "boolean"
      +    },
      +    "items_per_page": {
      +      "type": "number"
      +    },
      +    "returned": {
      +      "description": "How many records are in this response.",
      +      "type": "number"
      +    },
      +    "start_index": {
      +      "type": "number"
      +    },
      +    "total_results": {
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "start_index",
      +    "items_per_page",
      +    "total_results",
      +    "returned",
      +    "has_more"
      +  ],
      +  "type": "object"
      +}
    • addedOutput schema / properties / screened / items / properties / sections_included
      Added value: +{
      +  "description": "Sections actually fetched for this company.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / screened / items / properties / sections_unavailable
      Added value: +{
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "code": {
      +        "description": "The error code from the failed request.",
      +        "type": "string"
      +      },
      +      "message": {
      +        "type": "string"
      +      },
      +      "section": {
      +        "description": "Which part of the snapshot could not be read.",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "section",
      +      "code",
      +      "message"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • changedOutput schema / properties / screened / items / properties / signal_codes / items / enum
      Previous value: -[
      -  "dissolved",
      -  "insolvency_proceedings",
      -  "not_active",
      -  "insolvency_history",
      -  "accounts_overdue",
      -  "confirmation_statement_overdue",
      -  "outstanding_charges",
      -  "floating_charge_over_all_assets",
      -  "no_active_officers",
      -  "recent_officer_departures",
      -  "incorporated_within_last_year",
      -  "registered_office_in_dispute"
      -]New value: +[
      +  "dissolved",
      +  "insolvency_proceedings",
      +  "not_active",
      +  "insolvency_history",
      +  "accounts_overdue",
      +  "confirmation_statement_overdue",
      +  "outstanding_charges",
      +  "part_satisfied_charges",
      +  "floating_charge_over_all_assets",
      +  "no_active_officers",
      +  "recent_officer_departures",
      +  "incorporated_within_last_year",
      +  "registered_office_in_dispute"
      +]
    • changedOutput schema / properties / screened / items / required
      Previous value: -[
      -  "input",
      -  "company_number",
      -  "name",
      -  "signal_codes",
      -  "signal_count"
      -]New value: +[
      +  "input",
      +  "company_number",
      +  "name",
      +  "signal_codes",
      +  "signal_count",
      +  "sections_included",
      +  "sections_unavailable",
      +  "meta"
      +]
  2. First observedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark this read-only/idempotent, but the description adds substantial behavioral context: one row per company, signal codes only, unresolved names returned with candidates rather than guessed, not_screened entries with reasons for rate-limit skips, and officer handling with cost implications. None of this is visible in 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.

Conciseness5/5

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

Dense but every sentence contributes: usage guidance is front-loaded, the alternative is named early, and edge-case behaviors are explained in logical order. No filler or repetition of schema content.

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

Completeness5/5

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

Given the tool's complexity and the presence of an output schema, the description covers all necessary operational details: limits, return shape, unresolved/not_screened behavior, signal-code usage, and officer cost trade-offs. Nothing an agent needs to safely invoke it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful context beyond the schema: it explains that names matching multiple companies are not guessed, unresolved results include candidates, and include_officers carries an extra request cost. This helps an agent choose parameters more wisely.

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?

Description states a specific verb and resource ('Screen a list of companies') and immediately clarifies it is for MORE THAN ONE company. It explicitly contrasts with company_snapshot, so an agent can distinguish the intended use without inspecting schemas.

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

Usage Guidelines5/5

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

Provides explicit when-to-use conditions: lists, comparisons, batches, and anything with several names or numbers. It also names the alternatives (company_snapshot for detail, repeated calls as the less efficient option) and explains when to switch.

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