Vendor checks: sanctions lists, SEC filings, domain age and a due-diligence report with sources.
Scored across 6 tools
Most tools have distinct roles: search_company resolves names to CIKs, company_profile fetches full SEC records, domain_age checks domain signals, screen_sanctions screens names, and state_registry_link provides registry links. The due_diligence_report aggregates several of these into one call, which could cause misselection if an agent only needs a single screen, but the 'one-call' framing clearly marks it as a composite.
All names use consistent snake_case with descriptive, domain-appropriate terms. However, the set mixes verb_noun patterns (screen_sanctions, search_company) with noun_phrase patterns (company_profile, domain_age, due_diligence_report, state_registry_link), which is a minor deviation from a single predictable verb_noun convention.
Six tools is well-scoped for a due-diligence server, covering granular lookups (company, domain, sanctions, state registry), a resolver, and an aggregate report. Each tool earns its place without redundancy or bloat.
The surface covers core due-diligence needs: company search and profiling, sanctions screening, domain signals, state registry lookup, and an aggregate report that adds federal exclusions and a verdict. The only minor gap is a standalone federal-exclusions screen, though it is included inside due_diligence_report.
Full SEC EDGAR record for one company, given its CIK, ticker or name (best match): legal name, industry (SIC), state of incorporation, business address, 3 fiscal years of revenue, net income, total assets and cash, and its recent 10-K, 10-Q and 8-K filings with links. Use search_company first if you only have a partial or ambiguous name.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | SEC CIK number | |
| name | No | Company name (fuzzy) | |
| ticker | No | Stock ticker |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real context beyond them: the upstream source is SEC EDGAR, name lookups resolve to a best match rather than failing, and the response bundles filings with links. It stops short of saying what happens on zero matches or how many filings 'recent' means.
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 filler. The scope statement and returned-field inventory come first, and the routing instruction to search_company is placed last where it acts as a guard rather than a preamble.
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 carries the return-value burden and does so by enumerating the fields and filing types returned. Remaining gaps are minor: the window/breadth of 'recent' filings is undefined and the behavior on no-match or ambiguous best-match results is not described.
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 the baseline is 3. The description adds meaning beyond the one-line schema entries by noting that name matching is fuzzy/best-match and by implying the three identifiers are interchangeable resolution paths for the same record.
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 and resource ('Full SEC EDGAR record for one company') and names the accepted identifiers (CIK, ticker, name). It then enumerates the exact payload — legal name, SIC, incorporation state, address, 3 years of financials, recent 10-K/10-Q/8-K filings — so an agent can distinguish it from siblings like due_diligence_report without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent to an alternative: 'Use search_company first if you only have a partial or ambiguous name.' The condition that selects the sibling is stated, and the parenthetical '(best match)' warns about fuzzy resolution when no exact identifier is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Domain registration date, age, registrar (RDAP) and email-auth records (MX, SPF, DMARC), which are common fraud signals.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain, URL, or email address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine value about the underlying data sources (RDAP, MX/SPF/DMARC) and their interpretation as fraud signals, but says nothing about rate limits, failed or unresolvable lookups, or freshness of the 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?
One compact sentence that front-loads the returned data categories before the interpretive note. Nothing is padded, though it is a noun phrase rather than a verb-led statement of 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?
With no output schema, the description carries the burden of describing the response, and it does so by listing the four data families returned. For a single-parameter read-only lookup that is nearly sufficient; only error behaviour and result formatting are unaddressed.
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 that it accepts 'Domain, URL, or email address'. The description adds no additional input semantics beyond what the schema states, so the baseline 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?
The description names a specific resource (a domain) and enumerates exactly what is retrieved: registration date, age, registrar via RDAP, and email-auth records (MX, SPF, DMARC). That is far more informative than a bare 'look up a domain'. It stops short of explicitly contrasting itself with siblings like company_profile or due_diligence_report, so it earns a 4 rather than 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?
The trailing clause 'which are common fraud signals' hints at a fraud/vetting context, but no sentence says when to reach for this tool, when to prefer a sibling such as company_profile or screen_sanctions, or what prerequisites exist. Usage is left almost entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call due-diligence report: SEC profile (if public), sanctions screen, federal exclusions, domain signals, and state registry link, with a red-flag summary, a verdict (clear / review / hold; rules at https://mcp.pyxmark.com/#verdict) and source links. An agent should not pay or onboard on 'hold', and should ask a person on 'review'. Informational only, not a compliance determination. Results come from public government lists and filings, may be incomplete or out of date, and fuzzy name matches can be false positives or miss variants. Verify every potential match against the official source before acting.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | SEC CIK | |
| dob | No | Optional: date of birth (YYYY-MM-DD) of the person, to tell them apart from others with the same name | |
| ids | No | Optional: identifiers to match against the lists: company registration or tax numbers, passport or national ID numbers, vessel IMO numbers, SWIFT/BIC codes, crypto addresses | |
| name | No | Company or person name | |
| No | Optional: contact email, matched against emails and domains the lists give | ||
| phone | No | Optional: phone number, matched on its last 9 digits against phones the lists give | |
| state | No | US state of incorporation/registration | |
| domain | No | Company website or email domain | |
| owners | No | Optional: owners and their share (percent). Each is screened; listed owners holding 50% or more in total make the company blocked under the OFAC 50 percent rule | |
| ticker | No | Ticker | |
| address | No | Optional: street address or city (free text). Flags addresses in comprehensively sanctioned regions: Crimea, the so-called DNR/LNR, Iran, North Korea, Cuba (Syria is flagged for review) | |
| country | No | Optional: country where the person lives or the organisation is based | |
| website | No | Optional: website or domain, matched against websites the lists give | |
| birth_year | No | Optional: birth year, if the full date isn't known | |
| nationality | No | Optional: the person's nationality (country name or ISO code) | |
| subject_type | No | Optional: whether the name is a company or a person. Defaults to company when the name has a legal suffix such as Inc or LLC (or, in a report, when it is an SEC-registered company); then person, vessel and aircraft entries must match almost exactly. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so safety is covered. The description adds substantial beyond that: what a verdict means operationally, which regions are flagged, that results come from public government lists and filings and may be stale, that fuzzy name matches can produce false positives or miss variants, and the explicit 'informational only, not a compliance determination' disclaimer.
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 value proposition and output contents are front-loaded, and the middle sentences on verdict rules earn their place. It runs five sentences and the closing caveat sentence is somewhat dense, but nothing is 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?
No output schema exists, yet the description effectively describes the return shape (red-flag summary, verdict, source links) and links to verdict rules. With 16 parameters and 100% schema coverage plus annotations, the only missing layer is return data, which is addressed.
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 schema descriptions themselves carry rich matching semantics (last-9-digit phone matching, OFAC 50 percent rule on owners, sanctioned-region address flags). The prose adds no parameter-level detail beyond the schema, 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 the specific verb and deliverable ('One-call due-diligence report') and enumerates its components: SEC profile, sanctions screen, federal exclusions, domain signals, state registry link, red-flag summary, verdict, and source links. The 'one-call' framing cleanly distinguishes it from the granular siblings (screen_sanctions, company_profile, domain_age, state_registry_link) as the aggregating 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?
It gives concrete decision rules for acting on output: do not pay or onboard on 'hold', ask a person on 'review', and verify every match against the official source before acting. It stops short of naming when to use this aggregation versus the individual sibling tools, which is the one selection gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fuzzy-screen a person or organisation name against OFAC SDN + Consolidated, UN, EU, and UK sanctions lists. Returns up to 15 scored matches with source links; if more match, the summary says so and suggests a more specific query. Optional dob/birth_year, nationality and country set aside same-name matches whose listed details differ (rules at https://mcp.pyxmark.com/#details). Optional address, email, phone, website, ids and owners are matched against the details the lists give (identifier matches, sanctioned regions, the 50 percent rule); the assessment field sums it up as hold / review / clear. Informational only, not a compliance determination. Results come from public government lists and filings, may be incomplete or out of date, and fuzzy name matches can be false positives or miss variants. Verify every potential match against the official source before acting.
| Name | Required | Description | Default |
|---|---|---|---|
| dob | No | Optional: date of birth (YYYY-MM-DD) of the person, to tell them apart from others with the same name | |
| ids | No | Optional: identifiers to match against the lists: company registration or tax numbers, passport or national ID numbers, vessel IMO numbers, SWIFT/BIC codes, crypto addresses | |
| name | Yes | Person or organisation name | |
| No | Optional: contact email, matched against emails and domains the lists give | ||
| phone | No | Optional: phone number, matched on its last 9 digits against phones the lists give | |
| owners | No | Optional: owners and their share (percent). Each is screened; listed owners holding 50% or more in total make the company blocked under the OFAC 50 percent rule | |
| address | No | Optional: street address or city (free text). Flags addresses in comprehensively sanctioned regions: Crimea, the so-called DNR/LNR, Iran, North Korea, Cuba (Syria is flagged for review) | |
| country | No | Optional: country where the person lives or the organisation is based | |
| website | No | Optional: website or domain, matched against websites the lists give | |
| threshold | No | Minimum match score 0-1 (default 0.88) | |
| birth_year | No | Optional: birth year, if the full date isn't known | |
| nationality | No | Optional: the person's nationality (country name or ISO code) | |
| subject_type | No | Optional: whether the name is a company or a person. Defaults to company when the name has a legal suffix such as Inc or LLC (or, in a report, when it is an SEC-registered company); then person, vessel and aircraft entries must match almost exactly. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it caps results at 15 with truncation messaging, defines the assessment field values (hold/review/clear), explains how disambiguating inputs alter matching, and discloses false-positive/variant risk, data staleness, and the verify-against-source requirement. No annotation 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?
Front-loaded with purpose and return shape, then disambiguators, matchers, assessment, and caveats in a logical order with no filler. It is dense and longish for a single paragraph, but nearly every clause carries information an agent needs for a compliance-adjacent tool.
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?
There is no output schema, so the description carries the return-value burden and does so: up to 15 scored matches with source links, truncation behavior, and the hold/review/clear assessment. Combined with the disambiguation rules and legal caveats, an agent has everything needed to call and interpret this 13-parameter 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%, so the baseline is 3, but the description adds real semantics beyond the schema: address flags comprehensively sanctioned regions (with the specific list), owner percentages trigger the OFAC 50 percent rule, phone matches on the last 9 digits, and dob/nationality/country suppress same-name entries whose listed details differ. This meaningfully enriches understanding of what each input does to the result set.
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 (fuzzy-screen) plus the exact resource and scope: a person or organisation name against OFAC SDN + Consolidated, UN, EU, and UK lists. It also names what comes back (scored matches with source links), which distinguishes it immediately from siblings like company_profile, search_company, or due_diligence_report.
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?
Gives clear context for when each optional input helps (dob/birth_year/nationality/country to set aside same-name matches, owners for the 50 percent rule) and warns that it is informational only, not a compliance determination. It stops short of naming sibling tools or stating when a different tool is the better choice, so it is strong but not fully routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up which SEC-registered company a name, ticker or CIK refers to. Returns up to 10 candidates, each with its CIK, tickers and a match score, and nothing else. Use it to pick the right CIK when a name is ambiguous, then call company_profile with that CIK for the details.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company name, ticker, or CIK |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the result shape ('up to 10 candidates... and nothing else'), which sets an expectation about the cap and that no extra fields come back.
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 with no filler; the lookup scope leads and the disambiguation workflow follows. Every clause carries information the agent needs.
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?
There is no output schema, so the description takes on the burden of describing the return value (candidates with CIK, tickers, match score, capped at 10) and does so. For a single-parameter read-only lookup, nothing material 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 description coverage is 100% and there is only one parameter, so the schema already documents that 'query' accepts a name, ticker or CIK. The description mirrors rather than extends that, making the baseline 3 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?
States a specific verb and resource ('Look up which SEC-registered company a name, ticker or CIK refers to'), and names the follow-on sibling company_profile, so an agent can place it in the workflow without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the trigger condition ('when a name is ambiguous') and the next step ('then call company_profile with that CIK for the details'), which is exactly the when/when-not/alternative guidance the dimension asks for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Official Secretary of State business-search link for a US state, to verify a private company's status, formation date, and registered agent.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter code or state name | |
| company | No | Company name (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint false, non-open-world). The description usefully signals that this yields a link rather than fetched company data, which matters behaviorally, but it never states that the agent must follow the link externally or what the response 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?
A single well-formed sentence that front-loads the resource and follows with the purpose. No filler, though the clause list at the end is slightly dense.
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, no-output-schema link tool, the description is nearly adequate, but it leaves the return contract ambiguous — does it emit a URL string, a list, or metadata? An agent cannot fully predict the result.
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 both parameters (state, company) are already documented structurally; the description adds no format, casing, or optionality detail beyond what the schema provides. 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 (official Secretary of State business-search link for a US state) and the intent behind it (verify status, formation date, registered agent). It is distinguishable from siblings like search_company or company_profile, though it never explicitly contrasts with them.
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 'to verify a private company's status, formation date, and registered agent' implies why an agent would reach for this tool, but there is no explicit when-to-use vs. when-to-use-a-sibling guidance, even though search_company and due_diligence_report overlap heavily with this intent.
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.
company_profiledomain_agedue_diligence_reportscreen_sanctionssearch_companystate_registry_linkContract and agent-package scans, phishing URL and OFAC checks, domain and header checks.
Screen counterparties and enrich companies for AI agents — sanctions checks, cited sources.
Screen names against OFAC, EU and UN lists; check CVEs, domain DNS and WHOIS, and public tenders
SEC red-flag alerts & company dossiers, token risk, wallet checks, x402 preflight, scraping, OFAC.
Add one secure layer between your agents and this server.