UK sanctions, export controls, Companies House owners, FCA register and property checks.
Scored across 11 tools
Most tools target clearly distinct compliance resources: company data, property data, FCA firms, sanctions screening, and export controls. There is minor overlap between screen_sanctions and screen_export_controls, and run_suite_check bundles several individual checks, but the descriptions make the boundaries reasonably clear.
All names use snake_case, but they mix noun-first resource names (company_profile, fca_firm, postcode_report) with verb-first action names (screen_sanctions, run_suite_check, fca_search_firms). The set is readable, but the pattern is not predictable.
Eleven tools is a reasonable size for a UK compliance-checking server spanning companies, property, FCA, sanctions, and export controls. run_suite_check aggregates existing capabilities, which adds slight redundancy, but the count is not excessive.
The surface covers core company, property, FCA, sanctions, and export-control checks, but notable gaps remain. There is no company-name search tool, and PEP/adverse media screening is explicitly excluded from run_suite_check, which are significant omissions for compliance workflows.
Who owns and controls a UK company: the people with significant control, walked up through any corporate owners, with the ultimate beneficial owners worked out. Paid per call from your Stratum API balance, or use a test key.
| Name | Required | Description | Default |
|---|---|---|---|
| companyNumber | Yes | Companies House number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely non-structured context: this is a paid, per-call billed endpoint drawing on a Stratum API balance, with a test-key path. It omits anything about depth limits, latency, or what a missing/foreign company number returns.
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?
A single sentence that leads with the resource and the derived value, then appends the cost/access note. No filler, no repetition of the title, and the most decision-relevant content is front-loaded.
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 one-parameter lookup with no output schema, the description supplies a good mental model of the return (PSC list, corporate ownership chain, UBO derivation) plus the billing model. It falls short only on result shape and edge-case behavior, which are minor for a read-only lookup.
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?
One required parameter at 100% schema description coverage, so the schema already explains companyNumber. The description adds no format hints, validation behavior, or jurisdiction caveat beyond the implicit 'UK company' framing. Baseline 3 applies since the schema does the work.
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?
Names a specific resource (UK company ownership and control) and describes the actual output concept: PSCs, corporate owner chains walked up, and derived ultimate beneficial owners. That is far more specific than a name restatement, though it never names the sibling it differs from (company_profile, company_risk_score).
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 when it is useful (you need ownership/UBO structure rather than a general profile), but gives no explicit when-to-use/when-not or named alternatives among the ten siblings. The only concrete guidance is the payment/test-key note, which is billing guidance rather than selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Companies House record for a UK company: its details, its active officers and warning flags. Paid per call from your Stratum API balance, or use a test key.
| Name | Required | Description | Default |
|---|---|---|---|
| companyNumber | Yes | Companies House number, for example 00445790. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as a read-only, idempotent, open-world call, so the safety profile is covered. The description adds genuinely new operational context with 'Paid per call from your Stratum API balance, or use a test key', which an agent needs in order to warn about cost. It stops short of explaining billing on failed lookups or what 'warning flags' actually contains.
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: the first front-loads what the tool returns, the second delivers the cost warning. No filler, no redundancy with the title.
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 single-parameter lookup with no output schema, the description is largely sufficient: it discloses the payload contents and the billing model. Minor gaps remain around failure behavior for unknown company numbers and whether officer listings are paginated or complete.
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?
Only one parameter, companyNumber, and the schema already documents it at 100% coverage with an example. The description adds nothing about the identifier format, so baseline 3 applies since the schema carries the full burden.
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?
Names a specific verb-less but concrete resource: the Companies House record for a UK company, and enumerates its contents (details, active officers, warning flags). This separates it reasonably from siblings like company_owners and company_risk_score, though the overlap with 'active officers' versus a dedicated owners tool is not addressed.
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 statement of when to use this versus company_owners, company_risk_score, or fca_firm, and no prerequisites such as valid registration numbers or key requirements beyond the passing 'use a test key'. The only guidance is a billing note, which is cost information rather than usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A risk score for a UK company with the factors behind it (overdue accounts, charges, officer turnover, insolvency history, company age and status). Paid per call from your Stratum API balance, or use a test key.
| Name | Required | Description | Default |
|---|---|---|---|
| companyNumber | Yes | Companies House number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely new behavioral context not in the annotations: the call is metered against a Stratum API balance and a test key option exists, which materially affects invocation decisions. It stops short of stating cost amount or any rate limits.
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?
Front-loaded with the deliverable, followed by a compact parenthetical of contributing factors and a short billing note. Every sentence earns its place; the factor list is slightly dense but informative rather than wasteful.
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?
With no output schema, the description usefully enumerates what the result contains (the score plus its contributing factors), which is the key thing an agent needs. It omits score scale/range and response shape, a minor but real gap for a tool whose output is its entire value.
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?
Single required parameter with 100% schema description coverage ('Companies House number'), so the schema already carries the semantics. The description adds nothing about the format or validation of companyNumber; baseline 3 applies when the schema does the heavy lifting.
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?
States the specific resource ('a risk score for a UK company') and enumerates the factors it returns (overdue accounts, charges, officer turnover, insolvency history, age, status). This clearly separates it from siblings like company_profile or company_owners, which return raw data rather than a derived score, though the description never names those alternatives explicitly.
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?
Usage is implied by the resource ('risk score for a UK company'), and the billing note nudges the agent to consider cost before calling. However, there is no explicit when-to-use/when-not guidance and no reference to the sibling tools that return overlapping company data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The latest EPC for a property, with the rating and whether it meets the minimum energy standard for letting (MEES). Paid per call from your Stratum API balance, or use a test key.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | UK postcode. | |
| addressLine1 | No | First line of the address, to pick the right property at the postcode. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds genuinely new behavioral context: this is a metered call charged against a Stratum API balance, with a test key available — information that affects whether and how often an agent invokes it. It stops short of saying what happens when no certificate exists for the postcode.
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?
A single front-loaded sentence: what it returns first, billing context second. No restatement of the name or title, no 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?
For a 2-parameter read tool with full schema coverage and an output-free annotations set, the description is nearly complete — it names the returned values and the cost model. The one meaningful gap is the no-EPC-found case, which no structured field covers.
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 both parameters (postcode required, addressLine1 optional for disambiguation) are described in the schema itself. The description adds no parameter-level meaning, so the baseline 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?
States a specific resource (the latest EPC for a property) and the two values returned (rating and MEES compliance), so an agent knows exactly what it fetches. It does not explicitly differentiate itself from the sibling postcode_report, which also takes a postcode, so the sibling boundary is left implicit.
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?
Usage is only implied by the resource name — an agent infers 'call this when you need an EPC/MEES check for a UK property'. There is no when-not guidance (e.g. what to do if the property has no EPC) and no mention of the alternative postcode_report for broader property data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A firm on the FCA register by its FRN: authorisation status, addresses, and whether it appears on the FCA Warning List. Paid per call from your Stratum API balance, or use a test key.
| Name | Required | Description | Default |
|---|---|---|---|
| frn | Yes | Firm Reference Number, 6 or 7 digits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the description doesn't need to re-explain safety. It adds genuinely useful non-obvious context instead: each call is billed against a Stratum API balance, and a test key is available for non-billable use. It does not explain behaviour on an invalid or not-found FRN, which keeps it short of a 5.
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?
One sentence, front-loaded with what the tool returns, then the billing note. Every clause carries information an agent would otherwise have to discover: the resource, the key, the returned fields, and the cost model.
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?
With no output schema, the description steps in and names the fields returned, which is exactly what an agent needs to decide whether to call it. For a single-parameter read tool with full annotations that is nearly complete; only not-found/error behaviour and any response shape detail are missing.
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% and the single parameter already documents the 'Firm Reference Number, 6 or 7 digits' format. The description only restates the identifier as 'FRN' and adds no further syntax, derived-value or edge-case guidance, so the schema is doing all the work — baseline 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?
States a concrete resource (a single firm on the FCA register), the lookup key (its FRN), and the payload it returns (authorisation status, addresses, Warning List presence). The 'one firm ... by its FRN' phrasing implicitly separates it from the sibling fca_search_firms, though that contrast is never made explicit.
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?
Usage is only implied: an agent can infer this is for when you already hold an FRN rather than a name. There is no explicit 'use this instead of fca_search_firms when...' routing, and no statement of preconditions such as needing a valid FRN or what to do if only a firm name is known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the FCA Financial Services Register by firm name. Returns matching firms with their FRN and status. Paid per call from your Stratum API balance, or use a test key.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Firm name, at least 2 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: pricing ('Paid per call from your Stratum API balance, or use a test key') and the shape of the result. It omits result limits or pagination behavior for a broad name match.
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, zero waste, with the operation and return content front-loaded and the billing note last where it belongs.
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 one-parameter read tool with no output schema, the description covers what it does, what it returns, and the cost model. Only matching semantics (partial vs exact) and any result cap are left unstated.
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 the name parameter's meaning and 2-character minimum are already documented. The description only restates 'by firm name', adding no syntax or matching-behavior detail (exact vs partial match) 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?
States a specific verb (search) and resource (FCA Financial Services Register) scoped to firm name, and tells the agent what comes back (FRN and status). It doesn't name the sibling fca_firm, so an agent must infer the search-vs-lookup split, which keeps it short of a 5.
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?
Usage is implied by 'by firm name' — an agent with a name in hand knows to call it — but there is no explicit when-to-use framing and no routing to fca_firm for callers who already have an FRN. Minimum-viable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flood risk, crime, deprivation, coal mining, radon, contaminated land and Japanese knotweed records for a UK postcode. Paid per call from your Stratum API balance, or use a test key.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | UK postcode, for example TA7 0RB. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral information: this is a metered call charged to a Stratum API balance, with a test-key alternative — a cost/auth trait no structured field conveys. It stops short of describing the response shape or what happens when a postcode has no records.
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, no filler, and the highest-value information (what data domains are returned) is front-loaded. The billing caveat is correctly placed second as a secondary constraint.
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 one-parameter read-only lookup this is nearly complete: the agent knows the scope, the domains covered, and the cost model. The remaining gap is return-value description — there is no output schema, so the agent must guess the structure and size of the multi-domain payload it is paying for.
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?
There is a single parameter with 100% schema description coverage ('UK postcode, for example TA7 0RB'), so the schema already carries the semantics. The description adds nothing about format normalization, case, or partial-postcode handling beyond what the schema states, so the baseline 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?
The description names a concrete resource (a UK postcode report) and enumerates exactly what the report covers: flood risk, crime, deprivation, coal mining, radon, contaminated land and Japanese knotweed. That makes it trivially distinguishable from every sibling (company_*, fca_*, sanctions_*, epc_for_address), though it never explicitly states the differentiation, which keeps it just below a 5.
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?
Usage is only implied: an agent can infer this is the tool for property/area due diligence on a UK postcode. No when-to-use, when-not-to-use, or alternative is stated — it never tells the agent whether to prefer epc_for_address, run_suite_check, or another sibling when scopes overlap. The only explicit operational guidance is the billing note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs a whole job in one call and issues one signed certificate: a letting (tenant, landlord, guarantor), a sale (buyer, seller), a finance client (client, director, counterparty) or an export shipment (buyer, consignee, endUser, intermediateConsignee, forwarder, supplier, with a destination). Everyone named is screened for sanctions, each company with a number gets its owners screened, and a property postcode adds the property risk pack; an export shipment screens each party against the US export lists too and reads the UK and US measures on the destination (a screening record, not a licensing decision). PAID from your Stratum API balance (free on a test key): confirm with the user first. PEP and adverse media are not run from here.
| Name | Required | Description | Default |
|---|---|---|---|
| goods | No | Export: the goods as the firm describes them (never classified). | |
| suite | Yes | ||
| parties | Yes | The people and companies on the job. | |
| postcode | No | Letting or sale: the property postcode (adds the property risk pack). | |
| matterRef | No | Your own reference for the job, printed on the certificate. | |
| issuerName | No | The firm the certificate names as issuer, if not your account firm. | |
| destination | No | Export: the two-letter ISO code of the destination country. | |
| addressLine1 | No | Letting or sale: the first line of the property address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: paid from the Stratum API balance (free on a test key), requires user confirmation, produces a signed certificate, adds a property risk pack when a postcode is given, screens owners of numbered companies, and frames output as "a screening record, not a licensing decision." That cost, confirmation and scope-disclaimer information is exactly what annotations cannot convey.
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?
Front-loads the core action and cost/confirmation warning early, and every clause carries information. It is a dense run-on paragraph rather than scannable structure, which costs it a point, but there is little 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?
For an 8-parameter, non-idempotent, paid, open-world tool with no output schema, the description covers what is checked, what is deliberately excluded, what the deliverable is (one signed certificate), and who pays. Nothing an agent needs before invoking or confirming with the user is missing.
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 88%, so the baseline is 3, but the description goes further by tying parameters to conditional behavior: which roles each suite expects, that a companyNumber triggers owner screening, that a postcode adds the property risk pack, and that destination drives UK/US measures. That is meaning beyond the schema's field-level text.
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?
Opens with a specific verb and outcome ("Runs a whole job in one call and issues one signed certificate") and then enumerates the four suites and their party roles. An agent can immediately distinguish this bundled job tool from single-purpose siblings like screen_sanctions, postcode_report or fca_firm.
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?
Clear context for use — one call covering an entire letting/sale/finance/export job — plus explicit exclusions ("PEP and adverse media are not run from here") and the precondition "confirm with the user first" before spending. It never explicitly names the sibling to use for a single-party check, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The sanctions lists Stratum screens against, how many entries each has and when each was last refreshed. Free with any key that can screen.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the bar is lower, and the description adds genuinely new behavioral context: the pricing/access model (free with any screening-capable key). It also discloses the shape of what is returned (lists, entry counts, refresh dates), which matters since no output schema exists.
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 compact sentences, front-loaded with what the tool returns before the access note. Every clause carries information and nothing is padded.
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?
With no input parameters, no output schema, and annotations covering the safety profile, the description supplies exactly the missing pieces: what the response contains and what it costs to call. Nothing an agent needs to invoke it correctly is absent.
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 tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. No parameter semantics are needed or missing.
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 names a specific resource and states precisely what is returned: the lists screened against, entry counts per list, and last-refresh timestamps. It is clearly a metadata/introspection tool, distinct from screening siblings like screen_sanctions, though it never names those siblings to make the contrast explicit.
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?
"Free with any key that can screen" gives an entitlement/cost note that implies when the tool is safely callable, but there is no explicit when-to-use vs. when-not guidance relative to screen_sanctions or screen_export_controls. Usage is only implied by the descriptive purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a buyer, consignee or supplier against six US export-control lists (including the Entity List) and the UK, UN, EU and OFAC sanctions lists. Paid per call from your Stratum API balance, or use a test key.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Full name as you hold it, for a person or an organisation. | |
| type | No | person, entity (organisation) or any. Default any. | |
| country | No | Two-letter ISO country code of the party, if known. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive behavior, so the safety profile is well covered. The description does add one trait beyond the annotations — per-call charging against an API balance and a test-key mode — which is genuinely useful pre-call context. It stops short of describing match semantics, thresholds or what a hit looks like.
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, tightly front-loaded with the lists covered, then the cost/access note. No filler and nothing repeated from the schema.
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 read-only screening call with full schema coverage and no output schema, the description covers what is screened, against which lists, and the billing model. It lacks any statement of return shape or match-confidence behavior and gives no routing guidance among the three overlapping screening siblings, which keeps it short of complete.
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% and all three parameters (name, type enum, country) are documented in the schema. The description adds no format, defaulting or matching detail beyond that, so the baseline 3 for full schema coverage 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?
States a specific verb (screen) and enumerates the resources covered: six US export-control lists including the Entity List, plus UK, UN, EU and OFAC sanctions lists. This is far more concrete than the sibling names screen_sanctions or sanctions_lists, but it never explicitly says how it differs from those siblings, so an agent must infer the split.
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 phrase 'screen a buyer, consignee or supplier' implies the intended use case, which is useful implied guidance. However, there is no explicit when-to-use versus screen_sanctions, sanctions_lists or run_suite_check, and no exclusions or prerequisites beyond the billing note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a person or organisation against the UK, UN, EU and US OFAC sanctions lists, refreshed daily from the official sources. Returns possible matches with a score and the listing, and names every list screened with its date. Paid per call from your Stratum API balance, or use a test key.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Full name as you hold it, for a person or an organisation. | |
| type | No | person, entity (organisation) or any. Default any. | |
| dateOfBirth | No | YYYY-MM-DD, YYYY-MM or YYYY. Sharpens a person match. | |
| nationality | No | Two-letter ISO country code, for example GB. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description focuses on what they cannot: data freshness ('refreshed daily from the official sources'), the shape of results (possible matches with a score plus the listing), and the commercial model ('Paid per call from your Stratum API balance, or use a test key'). Cost-per-call and test-key fallback are genuinely useful operational context not encoded anywhere else.
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 tightly packed sentences: capability and sources first, then return shape, then billing. No filler, no restatement of the title, and the least obvious fact (per-call cost) is held to the end where it is still visible.
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?
With no output schema, the description responsibly states what comes back (scored matches plus the listing, and every list screened with its date). Billing and freshness are covered. Minor gap: no mention of what a no-match response looks like or how scores should be thresholded, which matters for a screening 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 description coverage is 100%, so every parameter (name, type, dateOfBirth, nationality) is already documented with examples and formats. The description only restates that the subject can be a person or organisation, adding no format, default, or edge-case guidance 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?
Specific verb ('Screen') plus a precisely bounded resource (a person or organisation against UK, UN, EU and US OFAC lists). The named sources and daily refresh make it unmistakably distinct from sibling tools like sanctions_lists (which likely enumerates lists) and screen_export_controls (a different screening regime).
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?
Usage is implied: you screen a person or organisation when you need to check them against sanctions lists, and the 'type' semantics are echoed ('person or organisation'). But it never states when to prefer this over screen_export_controls or sanctions_lists, nor any prerequisites such as key/balance requirements for first-time callers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
run_suite_check5 fields changedInput schema / properties / destinationAdded value: +{
+ "description": "Export: the two-letter ISO code of the destination country.",
+ "type": "string"
+}Input schema / properties / goodsAdded value: +{
+ "description": "Export: the goods as the firm describes them (never classified).",
+ "type": "string"
+}Input schema / properties / parties / items / properties / countryAdded value: +{
+ "description": "Export: the two-letter ISO code of the country the party is in.",
+ "type": "string"
+}Input schema / properties / parties / items / properties / role / descriptionPrevious value: -"letting: tenant, landlord, guarantor. sale: buyer, seller, payer. finance: client, director, counterparty."New value: +"letting: tenant, landlord, guarantor. sale: buyer, seller, payer. finance: client, director, counterparty. export: buyer, consignee, endUser, intermediateConsignee, forwarder, supplier."Input schema / properties / suite / enumPrevious value: -[
- "letting",
- "sale",
- "finance"
-]New value: +[
+ "letting",
+ "sale",
+ "finance",
+ "export"
+]company_ownerscompany_profilecompany_risk_scoreepc_for_addressfca_firmfca_search_firmspostcode_reportrun_suite_checksanctions_listsscreen_export_controlsscreen_sanctionsUK company register lookups plus US, EU and UN sanctions screening. Every answer cites source.
Company intelligence via UK Companies House and risk screening across 386 risk data sources.
Companies House, Gazette notices, sanctions screening, LEIs and UK legislation.
UK public-record company intelligence: Companies House, payments, contracts, registers, watch lists
Add one secure layer between your agents and this server.
