Synpareia Trust Toolkitofficial
A
licenseA
qualityB
maintenanceVerifiable dealings with other agents: prove what you did, vet who you deal with, bind agreements
36
63 PyPI
Apache 2.0
Jid: the trust API for AI agents
by com.jid
Server Details
Verify a business before an agent pays, signs or buys: registry-cited decision and signed receipt.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 22 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4/5.0
Scored across 7 tools
Disambiguation4/5
Most tools target distinct resources (email headers, business files, receipts) or distinct actions (search, verify, screen, qualify). However, `screen` and `qualify_counterparty` overlap in assessing a counterparty from an email/domain and returning an engage recommendation, which could cause misselection despite detailed descriptions.
Naming Consistency4/5
Tools predominantly follow a snake_case verb_noun pattern (`check_email`, `get_business_file`, `qualify_counterparty`, `search_business`, `verify_business`). The lone bare verb `screen` breaks the pattern slightly, so naming is mostly but not entirely consistent.
Tool Count5/5
Seven tools are well-scoped for a trust API: each covers a distinct capability (email check, business search/file lookup, receipt retrieval, screening, qualification, verification). The count is comfortably within the ideal 3–15 range with no obvious redundancy.
Completeness4/5
The surface covers the core trust workflow: search a business, retrieve its file, screen/qualify a counterparty, verify against registry facts, check email headers, and retrieve signed receipts. Minor gaps remain, such as no receipt listing/search or bulk operations, but agents can work around them.
Available Tools
7 toolscheck_emailIs this e-mail really from who it says? (SPF, DKIM, DMARC, lookalike sender)ARead-onlyInspect
Checks whether an e-mail is from who it claims. Input: the raw headers of a message (as shown by Show original or View source). Returns checks and a read (headline, recommendation engage | verify_first | do_not_engage, failed checks, lookup links): DMARC/SPF/DKIM as the receiving server recorded them, DKIM alignment with From, Reply-To going to another domain, and a From domain or display name that imitates a known business. The headers are processed in memory and never stored. Deterministic, no AI. Counts as 1 check with a key; free tier without one.
| Name | Required | Description | Default |
|---|---|---|---|
| headers | Yes | The raw message headers, as one string (the body is not needed) |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Terms of use for the facts |
| read | Yes | What a person sees: headline, recommendation, failed checks and lookup links |
| checks | Yes | |
| checked_at | No | |
| checks_used | Yes | |
| from_domain | Yes | |
| rules_version | No | |
| authentication | No | |
| reply_to_domain | No |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing privacy handling ('processed in memory and never stored'), determinism ('Deterministic, no AI'), and the cost model ('Counts as 1 check with a key; free tier without one'). These are exactly the operational traits an agent needs and that readOnlyHint/openWorldHint 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core question in the first sentence, then groups input, output, method, and cost into tight clauses. Length is justified by the number of distinct facts conveyed; no filler sentences.
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?
Covers purpose, input source, return shape, evaluation method, privacy, and billing for a single-parameter tool. Return values are described even though an output schema exists, which is redundant but harmless; nothing an agent needs to call it correctly 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 real semantic value: it identifies the argument as raw message headers obtainable via 'Show original or View source' and clarifies the body is not needed. That reduces the chance of a caller passing a parsed/partial header set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (checks whether an e-mail is from who it claims) and enumerates the exact signals evaluated: DMARC/SPF/DKIM as recorded by the receiving server, DKIM alignment with From, Reply-To domain mismatch, and lookalike sender. An agent can distinguish this from the business-verification siblings at a glance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete context for when to invoke it: 'Input: the raw headers of a message (as shown by Show original or View source).' It does not state when NOT to use it or name an alternative sibling, but the sibling set (business/file/receipt lookups) is far enough away that routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_business_fileGet a business fileARead-onlyIdempotentInspect
The Jid file for one business. Default (compact): status with its flags, identifiers, verified websites, the top facts with source and verification date, counts and the latest changes. With detail "full": every current fact with its source, verification date, next check and confidence, owner statements (labelled self-reported), possible matches and the change history.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Jid file id from search_business, e.g. gland-pharma-limited-j9nehi | |
| detail | No | compact (default): the verdict, status, identifiers and top facts with sources; full: every fact with its provenance |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| kind | No | |
| name | Yes | |
| note | Yes | Terms of use for the facts |
| counts | No | |
| status | Yes | |
| location | No | |
| full_file | No | |
| top_facts | No | |
| facts_total | No | |
| identifiers | No | |
| owner_status | No | claimed | public_record |
| recent_changes | No | |
| file_checked_at | No | |
| identifiers_total | No | |
| websites_verified | No |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds real value beyond that by disclosing the compact vs full content profile and flagging that owner statements are self-reported, a trust-relevant trait not captured 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the default mode before the expanded mode, and every clause enumerates actual returned fields rather than padding. It is dense but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is not strictly required, and annotations cover the safety profile; the description nonetheless rounds out the picture with detail-mode contents and provenance caveats. The only untouched area is sibling-relative routing guidance.
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 meaningfully enriches the 'detail' enum by enumerating the concrete fields returned in each mode (e.g. 'next check and confidence', 'change history') beyond the schema's one-line gloss. The id parameter's origin is also reinforced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource ('the Jid file for one business') and enumerates what the payload contains at each detail level, so the agent knows exactly what it retrieves. It does not explicitly contrast itself with siblings like search_business or verify_business, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the id parameter description points at search_business as the source of the id, which hints at the workflow (search then fetch), but there is no explicit statement of when to use this tool versus verify_business or screen. Adequate but with a clear routing gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_receiptGet a verification receiptARead-onlyIdempotentInspect
Returns a stored, Ed25519-signed verification receipt by receipt_id: the inputs, decision, reasons, fact ids and value hashes, rules version and time of the check. Free; does not count as a check.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | Yes | rcpt_... from verify_business |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| verify | No | |
| signature | Yes | |
| statement | Yes | The signed statement: inputs, decision, reasons, fact ids and value hashes, rules version, time |
| receipt_id | Yes | |
| retained_until_about | No |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds meaningful non-annotation context: the receipt is Ed25519-signed and retrieval is free and does not consume a check. It also lists stored fields, though some of that may overlap with the existing output schema.
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?
The description is two tight sentences with zero waste. It front-loads the core operation and appends the cost/quota distinction, making it easy to scan.
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?
For a simple one-parameter read operation with rich annotations and an output schema, the description is complete enough. It explains the retrieval, signature, cost behavior, and stored contents without unnecessary detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single required parameter, so the schema already explains that receipt_id is a 'rcpt_... from verify_business.' The description adds no format or origin detail beyond naming the parameter, making the baseline 3 appropriate.
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?
The description states a specific verb and resource: 'Returns a stored, Ed25519-signed verification receipt by receipt_id.' It lists the exact contents (inputs, decision, reasons, fact ids, value hashes, rules version, time), and 'Free; does not count as a check' implicitly separates it from check-performing siblings like verify_business.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the tool retrieves an existing receipt, and 'Free; does not count as a check' hints at when to prefer it over running a new verification. However, there is no explicit when/when-not guidance or named alternative in the description itself; the sibling link only appears in the schema's receipt_id description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qualify_counterpartyQualify a business lead or counterpartyARead-onlyInspect
Qualifies a business that made contact (a form submission, an inquiry, an outreach reply). Input: the sender's e-mail (or the company domain), the company name if given, and the context (form type, message, stated value, stated role). Jid checks the domain (MX, SPF, DMARC, registration date over RDAP, the website), matches it to a Jid business file, reads that file's registrations, licences, filings, capital raises, loans and adverse records, and returns signals (each with source, source_url, verified_at), three scores (legitimacy, capacity, consistency, 0 to 100 with reasons), checks (each pass, fail or unknown with one line of evidence) and a read: a one-line headline ("Passed all 7 checks Jid could run. Recommendation: engage."), the recommendation (engage, verify_first, do_not_engage), the failed checks and up to 4 links to verify by hand, plus a signed receipt reference. detail "full" adds each signal's raw value, each check's lookup link and the full signed receipt. Businesses only: personal webmail or no matched business returns individual_or_unverified with no scores. A possible list match is returned as 'review', not as a finding. Counts as 2 checks with a key; free tier without one. Not intended for credit, employment, insurance or housing decisions about any person.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | The submitting website's domain (binds the signal token) | |
| No | Sender's e-mail address | ||
| detail | No | compact (default): signals without raw values and a receipt reference; full: raw signal values and the full signed receipt | |
| domain | No | Company domain, when no e-mail is available | |
| ip_asn | No | ASN of the submitting network, to recognise hosting and VPN networks | |
| policy | No | How cautious `engage` is (default balanced) | |
| signal | No | Jid Signals token (the form's jid_signal field): Jid's own reading of the visitor's location; replaces the ip_* fields when it verifies | |
| country | No | Stated country, ISO 3166-1 alpha-2 | |
| message | No | The submission's free text (hashed, never stored) | |
| summary | No | Add a short plain-English summary grounded in the signals (with an API key only) | |
| activity | No | Regulated activity whose licences matter, if any | |
| form_type | Yes | What kind of submission this is | |
| ip_region | No | Region the submission came from (ISO 3166-2, e.g. US-CA or CA) | |
| ip_country | No | Country the submission came from, ISO alpha-2 (location consistency check) | |
| stated_role | No | The sender's stated role | |
| company_name | No | Company name as stated by the sender | |
| stated_value | No | Deal or purchase size the sender states, USD | |
| stated_country | No | Country the submitter stated (same as country) | |
| claimed_website | No | For vendor_claim / listing_claim: the website of the business or listing being claimed (enables the affiliation check) | |
| browser_timezone | No | IANA time zone reported by the submitter's browser |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| note | Yes | Terms of use for the facts |
| read | Yes | What a person sees: headline, recommendation, failed checks and lookup links |
| checks | Yes | |
| entity | No | |
| receipt | No | |
| signals | Yes | |
| summary | No | |
| capacity | No | |
| assessment | Yes | business | individual_or_unverified |
| checked_at | No | |
| legitimacy | No | |
| checks_used | Yes | |
| consistency | No | |
| recommendation | Yes | engage | verify_first | do_not_engage, with the reason |
| questions_to_ask | No | |
| suggested_next_step | No |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/non-destructive, but the description adds non-obvious behavior: this consumes 2 checks with an API key (free tier without one), a possible list match is returned as 'review' not a finding, and personal webmail/no-match degrades to individual_or_unverified with no scores. It also discloses the exact checks and receipt output, though much of that overlaps the existing output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded, but the body is a dense run-on that enumerates return contents (signals, three scores, checks, read, receipt) already covered by the output schema, spending length on redundant detail rather than call-relevant guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 20-parameter tool with rich annotations and an output schema, the description supplies the missing decision context: eligibility (businesses only), degraded outcomes, billing cost, and prohibited use cases. Return-value explanation is largely redundant with the output schema, so it is thorough but not fully lean.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 20 parameters, including enums. The description adds only marginal meaning (context inputs such as form type/message/stated value/stated role, and that the signal token replaces ip_* fields); baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (qualifies) and resource (a business that made contact) and scopes it clearly to inbound submissions like form submissions, inquiries and outreach replies. It is distinguishable from outbound-style siblings such as verify_business or search_business, though it names no sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear triggering context (a business that made contact) plus explicit exclusions: 'Businesses only', personal webmail returns individual_or_unverified, and 'Not intended for credit, employment, insurance or housing decisions about any person.' It stops short of naming alternative tools for adjacent jobs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screenShould I engage? (screen a lead, sender, vendor or website)ARead-onlyInspect
Screens a lead, sender, vendor or website and returns an engage-or-not answer. Input: any of domain, url, email, phone or company_name, the context (lead, inbound_email, partnership, vendor, purchase, marketplace_seller, agent_action), an optional amount (USD) and a policy (strict, balanced, permissive; default balanced). Returns engage (true or false), risk (low, medium, high, unknown), confidence 0 to 1, subject_type, reasons (each with source and evidence), mitigations, checks, a read (headline, recommendation engage | verify_first | do_not_engage, failed checks, lookup links) and a signed receipt_id. Deterministic, no AI in the decision, usually under a second. A possible sanctions name match returns engage=false with 'manual review', not a finding. For individuals only technical checks of the address, phone or domain run. engage is advisory. Rules: https://jid.com/screen-rules. Counts as 1 check with a key; free tier without one.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Website or page URL (purchase checks: only the host is used) | |
| site | No | The submitting website's domain (binds the signal token) | |
| No | Sender e-mail address (hashed on the receipt, never stored) | ||
| phone | No | Phone number, ideally in +E.164 | |
| amount | No | Amount at stake, USD | |
| domain | No | Company domain | |
| ip_asn | No | ASN of the request's network, to recognise hosting and VPN networks | |
| policy | No | strict, balanced (default) or permissive | |
| signal | No | Jid Signals token (the form's jid_signal field): Jid's own reading of the visitor's location; replaces the ip_* fields when it verifies | |
| context | No | What engaging means here; default lead (purchase when only a url or domain is given) | |
| country | No | Default country for a phone number without +, ISO alpha-2 | |
| ip_region | No | Region of the request (ISO 3166-2, e.g. US-CA or CA) | |
| ip_country | No | Country the request came from (ISO alpha-2), for the location consistency check | |
| company_name | No | Company name as stated | |
| stated_country | No | Country the counterparty stated | |
| browser_timezone | No | IANA time zone reported by the browser |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Terms of use for the facts |
| read | Yes | What a person sees: headline, recommendation, failed checks and lookup links |
| risk | Yes | low | medium | high | unknown |
| checks | Yes | |
| engage | Yes | |
| entity | No | |
| policy | No | |
| context | No | |
| reasons | Yes | |
| summary | No | |
| rules_url | No | |
| checked_at | No | |
| confidence | Yes | |
| receipt_id | Yes | |
| checks_used | Yes | |
| mitigations | No | |
| receipt_url | No | |
| subject_type | Yes |
TDQS
A3.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly/openWorld/idempotent=false/destructive=false; the description goes well beyond them, disclosing determinism ('no AI in the decision'), sub-second latency, an explicit edge case (sanctions name match returns engage=false with 'manual review', not a finding), a scope limitation (for individuals only technical checks run), advisory status of the verdict, and the cost model. That is exactly the behavioral context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is long, but front-loaded with purpose and inputs before returns and rules, and nearly every clause carries information (latency, determinism, billing, advisory status). The returns enumeration is somewhat redundant given an output schema exists and makes the prose denser than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter, zero-required tool with an output schema, the description supplies what the schema cannot: which identifiers are acceptable, the decision semantics, edge cases, and cost. It does not explain how the ip_*/signal fields interact with the main identifiers, which is the main remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each of the 16 fields is documented in-schema, so the baseline is 3. The description does add value by stating that any of domain/url/email/phone/company_name is acceptable input (important because the schema marks zero required fields) and by explaining the context enum's meaning, but it adds no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource ('Screens a lead, sender, vendor or website') and the concrete decision it returns ('engage-or-not answer'), which is far more than a tautology. It never names or contrasts the closest siblings (check_email, qualify_counterparty, verify_business), so an agent must infer which screener to pick from scope alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the enumerated context values (lead, inbound_email, partnership, vendor, purchase, marketplace_seller, agent_action) and their default ('default lead (purchase when only a url or domain is given)'), but there is no explicit when-to-use vs alternatives guidance against sibling tools. The billing note ('Counts as 1 check with a key; free tier without one') is operational, not a selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_businessSearch businessesARead-onlyIdempotentInspect
Finds Jid business files by name or by any registry number (FEI, LEI, SEC CIK, DUNS, NDC labeler code, state licence or entity number, French SIREN or SIRET). Returns candidate files with status and match evidence. For a French company pass country "FR": the SIRENE register is searched live and files are created on demand.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Business name or registry number | |
| country | No | ISO country code. "FR" also searches the French SIRENE register live (a SIREN or SIRET is looked up there anyway). |
Output Schema
| Name | Required | Description |
|---|---|---|
| next | Yes | |
| query | Yes | |
| results | Yes |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already covering the read-only/idempotent safety profile, the description adds real behavioral context: results are candidates with status and match evidence, and FR searches hit the live SIRENE register with files created on demand. Minor tension exists with readOnlyHint since on-demand file creation is a side effect, but the tool remains non-destructive and idempotent from the caller's view.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences that front-load purpose, then result shape, then the FR special case; every sentence carries information. It loses a point for re-stating the SIRENE/FR behavior already present in the country parameter's schema description.
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?
For a two-parameter search tool with an output schema, the description covers purpose, accepted identifier types, result shape, and the one non-obvious behavioral branch (live FR lookup with file creation). Nothing material is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are fully documented in the schema, including the FR/SIRENE nuance. The description largely restates that same FR detail rather than adding new meaning about query format (e.g., normalization, partial matching), so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Finds Jid business files') and enumerates the identifier types it accepts (FEI, LEI, SEC CIK, DUNS, NDC, SIREN/SIRET), which makes the scope concrete. It does not, however, explicitly differentiate itself from siblings like get_business_file or verify_business, leaving that distinction to be inferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is one actionable usage rule ('For a French company pass country "FR"'), which tells the agent how to trigger live SIRENE lookup. Beyond that, no guidance is given on when to search here versus calling get_business_file or verify_business, and no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_businessVerify a business before actingARead-onlyInspect
Verifies a business against the registry facts Jid holds. Input: a Jid id (or a name or registry number) and, optionally, an activity, jurisdiction and amount. With an activity it returns a decision (proceed, review, stop or insufficient_data) with reasons: each names the requirement, met (true, false or unknown), the fact ids, source, verified_at and fresh_until, plus a signed receipt_id. Without an activity it returns the status and the top cited facts. Default output is compact (verdict, reasons, status, identifiers, top facts, receipt reference); detail "full" adds every cited fact and the full signed receipt. Activities: general_commerce (General commerce (default)); sell_prescription_drugs (Sell prescription drugs); manufacture_drugs (Manufacture drugs); sell_medical_devices (Sell medical devices); haul_freight (Haul freight (for-hire motor carrier)); broker_freight (Broker freight); sell_alcohol (Sell alcohol (wholesale or import)); produce_spirits (Produce distilled spirits); provide_investment_advice (Provide investment advice); accept_deposits (Accept deposits); lend (Lend); bill_medicare_medicaid (Bill Medicare or Medicaid); healthcare_supplier (Health care supplier); federal_contracting (Federal contracting); charitable_solicitation (Charitable solicitation); construction (Construction or home improvement (contractor)); operate_psilocybin_healing_center (Operate a psilocybin healing or service centre (CO, OR)).
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Jid file id (preferred) | |
| query | No | Name or registry number, used when no id is known | |
| amount | No | Transaction amount, recorded on the receipt as context only | |
| detail | No | compact (default): the verdict, status, identifiers and top facts with sources; full: every fact with its provenance | |
| activity | No | What the business is about to do for you. Defaults to general_commerce when jurisdiction or amount is given. | |
| currency | No | ISO 4217 currency of amount, default USD | |
| jurisdiction | No | US state as US-XX (for example US-CO) or an ISO country code |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| file | No | With an activity: the business the decision is about |
| name | No | |
| note | No | Terms of use for the facts |
| query | No | |
| result | No | |
| status | No | |
| message | No | |
| receipt | No | |
| decision | No | With an activity: the decision object; with no file matched: "insufficient_data" |
| full_file | No | |
| top_facts | No | |
| facts_total | No | |
| identifiers | No | |
| owner_status | No | claimed | public_record |
| resolved_from | No | |
| file_checked_at | No | |
| identifiers_total | No | |
| websites_verified | No |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and idempotentHint=false, so safety is covered. The description adds substantial context beyond them: the four possible decisions, the reason structure (requirement, met, fact ids, source, verified_at, fresh_until), the signed receipt_id, and the compact-vs-full detail behavior. This is solid added context on a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and input are front-loaded, which is good, but the body is a dense run-on covering input, two output modes and a full re-listing of all seventeen activities. The activity list largely duplicates the enum descriptions already in the schema, which is redundant bulk on an otherwise well-organized description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values did not need spelling out, yet the description does so and does it coherently. For a zero-required-parameter tool with rich enum and output definitions, the main remaining gap is the absence of sibling/tool-selection context (qualify_counterparty, screen, get_business_file), which leaves an agent with ambiguity about which tool to reach for.
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 description coverage is 100%, so the schema already carries baseline meaning for all seven parameters. The description still adds value by explaining the conditional effect of activity (with it you get a decision, without it you get status) and the default-to-general_commerce-on-jurisdiction-or-amount rule. It also expands the activity enum values with human-readable meanings, though the schema partly duplicates this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Verifies a business against the registry facts Jid holds,' with concrete detail on what inputs it takes and what it returns. It is clear on its own but never distinguishes itself from similar-looking siblings such as qualify_counterparty or screen, so an agent cannot tell them apart from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the title ('before acting') and by the conditional behavior described (with an activity you get a decision; without one you get status and top facts), which is useful invocation guidance. However, there is no explicit when-to-use vs when-not, and no mention of the alternative tools (qualify_counterparty, screen) an agent should weigh this against.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
search_business1 field changed- added
Input schema / properties / countryAdded value: +{ + "description": "ISO country code. \"FR\" also searches the French SIRENE register live (a SIREN or SIRET is looked up there anyway).", + "maxLength": 2, + "minLength": 2, + "type": "string" +}
7 tool updates
- Changed
check_email1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "authentication": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "dmarc": { + "type": [ + "string", + "null" + ] + }, + "spf": { + "type": [ + "string", + "null" + ] + } + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "checked_at": { + "type": "string" + }, + "checks": { + "items": { + "additionalProperties": {}, + "properties": { + "evidence": { + "type": "string" + }, + "id": { + "type": "string" + }, + "severity": { + "type": "string" + }, + "status": { + "description": "pass | fail | unknown | not_applicable", + "type": "string" + } + }, + "required": [ + "id", + "status" + ], + "type": "object" + }, + "type": "array" + }, + "checks_used": { + "type": "number" + }, + "from_domain": { + "type": [ + "string", + "null" + ] + }, + "note": { + "description": "Terms of use for the facts", + "type": "string" + }, + "read": { + "additionalProperties": {}, + "description": "What a person sees: headline, recommendation, failed checks and lookup links", + "properties": { + "failed": { + "description": "Failed checks, worst first, at most 3", + "items": { + "additionalProperties": {}, + "properties": { + "evidence": { + "type": "string" + }, + "label": { + "type": "string" + }, + "lookup": { + "additionalProperties": {}, + "properties": { + "label": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + } + }, + "required": [ + "label", + "evidence" + ], + "type": "object" + }, + "type": "array" + }, + "headline": { + "description": "One line, e.g. \"Passed all 7 checks Jid could run. Recommendation: engage.\"", + "type": "string" + }, + "not_checked": { + "items": { + "type": "string" + }, + "type": "array" + }, + "passed": { + "type": "number" + }, + "reason": { + "type": "string" + }, + "recommendation": { + "description": "engage | verify_first | do_not_engage", + "type": "string" + }, + "total": { + "type": "number" + } + }, + "required": [ + "headline", + "recommendation", + "passed", + "total", + "failed" + ], + "type": "object" + }, + "reply_to_domain": { + "type": [ + "string", + "null" + ] + }, + "rules_version": { + "type": "string" + } + }, + "required": [ + "read", + "checks", + "from_domain", + "checks_used", + "note" + ], + "type": "object" +}
- Changed
get_business_file2 fields changed- added
Input schema / properties / detailAdded value: +{ + "description": "compact (default): the verdict, status, identifiers and top facts with sources; full: every fact with its provenance", + "enum": [ + "compact", + "full" + ], + "type": "string" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "counts": { + "additionalProperties": {}, + "properties": { + "context_facts": { + "type": "number" + }, + "events": { + "type": "number" + }, + "facts": { + "type": "number" + }, + "possible_matches": { + "type": "number" + }, + "self_reported": { + "type": "number" + } + }, + "required": [ + "facts", + "context_facts", + "self_reported", + "possible_matches", + "events" + ], + "type": "object" + }, + "facts_total": { + "type": "number" + }, + "file_checked_at": { + "type": [ + "string", + "null" + ] + }, + "full_file": { + "additionalProperties": {}, + "properties": { + "api": { + "type": "string" + }, + "detail_full": { + "type": "string" + }, + "page": { + "type": "string" + } + }, + "required": [ + "page", + "api" + ], + "type": "object" + }, + "id": { + "type": "string" + }, + "identifiers": { + "items": { + "additionalProperties": {}, + "properties": { + "type": { + "type": "string" + }, + "value": {} + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + "type": "array" + }, + "identifiers_total": { + "type": "number" + }, + "kind": { + "type": [ + "string", + "null" + ] + }, + "location": { + "additionalProperties": {}, + "properties": { + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": [ + "string", + "null" + ] + }, + "region": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "country", + "region", + "city" + ], + "type": "object" + }, + "name": { + "type": "string" + }, + "note": { + "description": "Terms of use for the facts", + "type": "string" + }, + "owner_status": { + "description": "claimed | public_record", + "type": "string" + }, + "recent_changes": { + "items": { + "additionalProperties": {}, + "properties": { + "occurred_at": { + "type": [ + "string", + "null" + ] + }, + "source": { + "type": [ + "string", + "null" + ] + }, + "summary": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "occurred_at", + "summary", + "source" + ], + "type": "object" + }, + "type": "array" + }, + "status": { + "additionalProperties": {}, + "properties": { + "flags": { + "description": "Compact: \"tone: label\" strings; full: objects", + "items": {}, + "type": "array" + }, + "rules": { + "type": "string" + }, + "status": { + "type": "string" + }, + "summary": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "status" + ], + "type": "object" + }, + "top_facts": { + "items": { + "additionalProperties": {}, + "properties": { + "label": { + "type": "string" + }, + "predicate": { + "type": "string" + }, + "source": { + "type": "string" + }, + "source_url": { + "type": [ + "string", + "null" + ] + }, + "value": {}, + "value_truncated": { + "const": true, + "type": "boolean" + }, + "verified_at": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "predicate", + "value" + ], + "type": "object" + }, + "type": "array" + }, + "url": { + "type": "string" + }, + "websites_verified": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "id", + "name", + "url", + "status", + "note" + ], + "type": "object" +}
- Changed
get_receipt1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "receipt_id": { + "type": "string" + }, + "retained_until_about": { + "type": "string" + }, + "signature": { + "additionalProperties": {}, + "properties": { + "alg": { + "type": "string" + }, + "canonicalization": { + "type": "string" + }, + "kid": { + "type": "string" + }, + "sig": { + "type": "string" + } + }, + "required": [ + "alg", + "kid", + "sig" + ], + "type": "object" + }, + "statement": { + "additionalProperties": {}, + "description": "The signed statement: inputs, decision, reasons, fact ids and value hashes, rules version, time", + "properties": {}, + "type": "object" + }, + "url": { + "type": "string" + }, + "verify": { + "type": "string" + } + }, + "required": [ + "receipt_id", + "url", + "statement", + "signature" + ], + "type": "object" +}
- Changed
qualify_counterparty3 fields changed- added
Input schema / properties / detailAdded value: +{ + "description": "compact (default): signals without raw values and a receipt reference; full: raw signal values and the full signed receipt", + "enum": [ + "compact", + "full" + ], + "type": "string" +} - changed
Input schema / properties / summary / descriptionPrevious value: -"Add a short plain-English summary grounded in the signals"New value: +"Add a short plain-English summary grounded in the signals (with an API key only)" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "assessment": { + "description": "business | individual_or_unverified", + "type": "string" + }, + "capacity": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "reasons": { + "items": {}, + "type": "array" + }, + "score": { + "type": [ + "number", + "null" + ] + } + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "checked_at": { + "type": "string" + }, + "checks": { + "items": { + "additionalProperties": {}, + "properties": { + "evidence": { + "type": "string" + }, + "id": { + "type": "string" + }, + "severity": { + "type": "string" + }, + "status": { + "description": "pass | fail | unknown | not_applicable", + "type": "string" + } + }, + "required": [ + "id", + "status" + ], + "type": "object" + }, + "type": "array" + }, + "checks_used": { + "type": "number" + }, + "consistency": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "reasons": { + "items": {}, + "type": "array" + }, + "score": { + "type": [ + "number", + "null" + ] + } + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "entity": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "id": { + "type": "string" + }, + "relied_on": { + "type": "boolean" + }, + "url": { + "type": "string" + } + }, + "required": [ + "id" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "id": { + "type": "string" + }, + "legitimacy": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "reasons": { + "items": {}, + "type": "array" + }, + "score": { + "type": [ + "number", + "null" + ] + } + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "note": { + "description": "Terms of use for the facts", + "type": "string" + }, + "questions_to_ask": { + "items": { + "type": "string" + }, + "type": "array" + }, + "read": { + "additionalProperties": {}, + "description": "What a person sees: headline, recommendation, failed checks and lookup links", + "properties": { + "failed": { + "description": "Failed checks, worst first, at most 3", + "items": { + "additionalProperties": {}, + "properties": { + "evidence": { + "type": "string" + }, + "label": { + "type": "string" + }, + "lookup": { + "additionalProperties": {}, + "properties": { + "label": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + } + }, + "required": [ + "label", + "evidence" + ], + "type": "object" + }, + "type": "array" + }, + "headline": { + "description": "One line, e.g. \"Passed all 7 checks Jid could run. Recommendation: engage.\"", + "type": "string" + }, + "not_checked": { + "items": { + "type": "string" + }, + "type": "array" + }, + "passed": { + "type": "number" + }, + "reason": { + "type": "string" + }, + "recommendation": { + "description": "engage | verify_first | do_not_engage", + "type": "string" + }, + "total": { + "type": "number" + } + }, + "required": [ + "headline", + "recommendation", + "passed", + "total", + "failed" + ], + "type": "object" + }, + "receipt": { + "anyOf": [ + { + "additionalProperties": {}, + "description": "Signed receipt reference; get_receipt returns the full signed statement", + "properties": { + "issued_at": { + "type": "string" + }, + "keys": { + "type": "string" + }, + "receipt_id": { + "type": "string" + }, + "signature": { + "additionalProperties": {}, + "properties": { + "alg": { + "type": "string" + }, + "kid": { + "type": "string" + } + }, + "required": [ + "alg", + "kid" + ], + "type": "object" + }, + "url": { + "type": "string" + }, + "verify_url": { + "type": "string" + } + }, + "required": [ + "receipt_id" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": {}, + "type": "object" + } + ] + }, + "recommendation": { + "description": "engage | verify_first | do_not_engage, with the reason" + }, + "signals": { + "items": { + "additionalProperties": {}, + "properties": { + "detail": {}, + "effect": {}, + "name": { + "type": "string" + }, + "source": {}, + "source_url": { + "type": [ + "string", + "null" + ] + }, + "verified_at": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "name" + ], + "type": "object" + }, + "type": "array" + }, + "suggested_next_step": { + "type": "string" + }, + "summary": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "id", + "assessment", + "recommendation", + "read", + "signals", + "checks", + "checks_used", + "note" + ], + "type": "object" +}
- Changed
screen1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "checked_at": { + "type": "string" + }, + "checks": { + "items": { + "additionalProperties": {}, + "properties": { + "evidence": { + "type": "string" + }, + "id": { + "type": "string" + }, + "severity": { + "type": "string" + }, + "status": { + "description": "pass | fail | unknown | not_applicable", + "type": "string" + } + }, + "required": [ + "id", + "status" + ], + "type": "object" + }, + "type": "array" + }, + "checks_used": { + "type": "number" + }, + "confidence": { + "type": "number" + }, + "context": { + "type": "string" + }, + "engage": { + "type": "boolean" + }, + "entity": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "id", + "name", + "url" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "mitigations": { + "items": {}, + "type": "array" + }, + "note": { + "description": "Terms of use for the facts", + "type": "string" + }, + "policy": { + "type": "string" + }, + "read": { + "additionalProperties": {}, + "description": "What a person sees: headline, recommendation, failed checks and lookup links", + "properties": { + "failed": { + "description": "Failed checks, worst first, at most 3", + "items": { + "additionalProperties": {}, + "properties": { + "evidence": { + "type": "string" + }, + "label": { + "type": "string" + }, + "lookup": { + "additionalProperties": {}, + "properties": { + "label": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + } + }, + "required": [ + "label", + "evidence" + ], + "type": "object" + }, + "type": "array" + }, + "headline": { + "description": "One line, e.g. \"Passed all 7 checks Jid could run. Recommendation: engage.\"", + "type": "string" + }, + "not_checked": { + "items": { + "type": "string" + }, + "type": "array" + }, + "passed": { + "type": "number" + }, + "reason": { + "type": "string" + }, + "recommendation": { + "description": "engage | verify_first | do_not_engage", + "type": "string" + }, + "total": { + "type": "number" + } + }, + "required": [ + "headline", + "recommendation", + "passed", + "total", + "failed" + ], + "type": "object" + }, + "reasons": { + "items": {}, + "type": "array" + }, + "receipt_id": { + "type": "string" + }, + "receipt_url": { + "type": "string" + }, + "risk": { + "description": "low | medium | high | unknown", + "type": "string" + }, + "rules_url": { + "type": "string" + }, + "subject_type": { + "type": "string" + }, + "summary": { + "type": "string" + } + }, + "required": [ + "engage", + "risk", + "confidence", + "subject_type", + "reasons", + "read", + "checks", + "receipt_id", + "checks_used", + "note" + ], + "type": "object" +}
- Changed
search_business1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "next": { + "type": "string" + }, + "query": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": {}, + "properties": { + "facts": { + "type": [ + "number", + "null" + ] + }, + "id": { + "description": "Jid file id for verify_business / get_business_file", + "type": "string" + }, + "location": { + "type": "string" + }, + "matched_on": {}, + "name": { + "type": "string" + }, + "sources": { + "type": [ + "number", + "null" + ] + }, + "status": { + "type": [ + "string", + "null" + ] + }, + "status_summary": { + "type": [ + "string", + "null" + ] + }, + "url": { + "type": "string" + } + }, + "required": [ + "id", + "name", + "location", + "status", + "url" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "query", + "results", + "next" + ], + "type": "object" +}
- Changed
verify_business2 fields changed- added
Input schema / properties / detailAdded value: +{ + "description": "compact (default): the verdict, status, identifiers and top facts with sources; full: every fact with its provenance", + "enum": [ + "compact", + "full" + ], + "type": "string" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": {}, + "properties": { + "decision": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "activity": { + "type": "string" + }, + "amount": { + "type": [ + "number", + "null" + ] + }, + "currency": { + "type": [ + "string", + "null" + ] + }, + "decision": { + "description": "proceed | review | stop | insufficient_data", + "type": "string" + }, + "jurisdiction": { + "type": [ + "string", + "null" + ] + }, + "not_legal_advice": {}, + "notes": { + "items": { + "type": "string" + }, + "type": "array" + }, + "reasons": { + "items": { + "additionalProperties": {}, + "properties": { + "code": { + "type": "string" + }, + "detail": {}, + "effect": {}, + "fact_ids": { + "items": {}, + "type": "array" + }, + "fresh_until": { + "type": [ + "string", + "null" + ] + }, + "met": { + "anyOf": [ + { + "type": "boolean" + }, + { + "const": "unknown", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "true, false or \"unknown\"" + }, + "requirement": {}, + "source": { + "description": "Compact: the source name; full: the source object" + }, + "source_url": { + "type": [ + "string", + "null" + ] + }, + "verified_at": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "code" + ], + "type": "object" + }, + "type": "array" + }, + "receipt_id": { + "type": "string" + }, + "rules_url": { + "type": "string" + }, + "rules_version": { + "type": "string" + } + }, + "required": [ + "decision", + "activity", + "reasons", + "receipt_id" + ], + "type": "object" + }, + { + "type": "string" + } + ], + "description": "With an activity: the decision object; with no file matched: \"insufficient_data\"" + }, + "facts_total": { + "type": "number" + }, + "file": { + "additionalProperties": {}, + "description": "With an activity: the business the decision is about", + "properties": { + "facts_total": { + "type": "number" + }, + "file_checked_at": { + "type": [ + "string", + "null" + ] + }, + "full_file": { + "additionalProperties": {}, + "properties": { + "api": { + "type": "string" + }, + "detail_full": { + "type": "string" + }, + "page": { + "type": "string" + } + }, + "required": [ + "page", + "api" + ], + "type": "object" + }, + "id": { + "type": "string" + }, + "identifiers": { + "items": { + "additionalProperties": {}, + "properties": { + "type": { + "type": "string" + }, + "value": {} + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + "type": "array" + }, + "identifiers_total": { + "type": "number" + }, + "name": { + "type": "string" + }, + "owner_status": { + "description": "claimed | public_record", + "type": "string" + }, + "status": { + "additionalProperties": {}, + "properties": { + "flags": { + "description": "Compact: \"tone: label\" strings; full: objects", + "items": {}, + "type": "array" + }, + "rules": { + "type": "string" + }, + "status": { + "type": "string" + }, + "summary": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "status" + ], + "type": "object" + }, + "top_facts": { + "items": { + "additionalProperties": {}, + "properties": { + "label": { + "type": "string" + }, + "predicate": { + "type": "string" + }, + "source": { + "type": "string" + }, + "source_url": { + "type": [ + "string", + "null" + ] + }, + "value": {}, + "value_truncated": { + "const": true, + "type": "boolean" + }, + "verified_at": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "predicate", + "value" + ], + "type": "object" + }, + "type": "array" + }, + "url": { + "type": "string" + }, + "websites_verified": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "id", + "name", + "url", + "status" + ], + "type": "object" + }, + "file_checked_at": { + "type": [ + "string", + "null" + ] + }, + "full_file": { + "additionalProperties": {}, + "properties": { + "api": { + "type": "string" + }, + "detail_full": { + "type": "string" + }, + "page": { + "type": "string" + } + }, + "required": [ + "page", + "api" + ], + "type": "object" + }, + "id": { + "type": "string" + }, + "identifiers": { + "items": { + "additionalProperties": {}, + "properties": { + "type": { + "type": "string" + }, + "value": {} + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + "type": "array" + }, + "identifiers_total": { + "type": "number" + }, + "message": { + "type": "string" + }, + "name": { + "type": "string" + }, + "note": { + "description": "Terms of use for the facts", + "type": "string" + }, + "owner_status": { + "description": "claimed | public_record", + "type": "string" + }, + "query": { + "type": "string" + }, + "receipt": { + "anyOf": [ + { + "additionalProperties": {}, + "description": "Signed receipt reference; get_receipt returns the full signed statement", + "properties": { + "issued_at": { + "type": "string" + }, + "keys": { + "type": "string" + }, + "receipt_id": { + "type": "string" + }, + "signature": { + "additionalProperties": {}, + "properties": { + "alg": { + "type": "string" + }, + "kid": { + "type": "string" + } + }, + "required": [ + "alg", + "kid" + ], + "type": "object" + }, + "url": { + "type": "string" + }, + "verify_url": { + "type": "string" + } + }, + "required": [ + "receipt_id" + ], + "type": "object" + }, + { + "additionalProperties": {}, + "properties": {}, + "type": "object" + } + ] + }, + "resolved_from": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "chosen": { + "type": "string" + }, + "matched_on": {}, + "other_candidates": { + "items": { + "additionalProperties": {}, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + } + }, + "required": [ + "id", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "query": { + "type": "string" + } + }, + "required": [ + "query", + "chosen" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "result": { + "const": "no_file", + "type": "string" + }, + "status": { + "additionalProperties": {}, + "properties": { + "flags": { + "description": "Compact: \"tone: label\" strings; full: objects", + "items": {}, + "type": "array" + }, + "rules": { + "type": "string" + }, + "status": { + "type": "string" + }, + "summary": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "status" + ], + "type": "object" + }, + "top_facts": { + "items": { + "additionalProperties": {}, + "properties": { + "label": { + "type": "string" + }, + "predicate": { + "type": "string" + }, + "source": { + "type": "string" + }, + "source_url": { + "type": [ + "string", + "null" + ] + }, + "value": {}, + "value_truncated": { + "const": true, + "type": "boolean" + }, + "verified_at": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "predicate", + "value" + ], + "type": "object" + }, + "type": "array" + }, + "url": { + "type": "string" + }, + "websites_verified": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "type": "object" +}
2 tool updates
- Changed
qualify_counterparty1 field changed- changed
Input schema / properties / activity / enumPrevious value: -[ - "general_commerce", - "sell_prescription_drugs", - "manufacture_drugs", - "sell_medical_devices", - "haul_freight", - "broker_freight", - "sell_alcohol", - "produce_spirits", - "provide_investment_advice", - "accept_deposits", - "lend", - "bill_medicare_medicaid", - "healthcare_supplier", - "federal_contracting", - "charitable_solicitation", - "operate_psilocybin_healing_center" -]New value: +[ + "general_commerce", + "sell_prescription_drugs", + "manufacture_drugs", + "sell_medical_devices", + "haul_freight", + "broker_freight", + "sell_alcohol", + "produce_spirits", + "provide_investment_advice", + "accept_deposits", + "lend", + "bill_medicare_medicaid", + "healthcare_supplier", + "federal_contracting", + "charitable_solicitation", + "construction", + "operate_psilocybin_healing_center" +]
- Changed
verify_business1 field changed- changed
Input schema / properties / activity / enumPrevious value: -[ - "general_commerce", - "sell_prescription_drugs", - "manufacture_drugs", - "sell_medical_devices", - "haul_freight", - "broker_freight", - "sell_alcohol", - "produce_spirits", - "provide_investment_advice", - "accept_deposits", - "lend", - "bill_medicare_medicaid", - "healthcare_supplier", - "federal_contracting", - "charitable_solicitation", - "operate_psilocybin_healing_center" -]New value: +[ + "general_commerce", + "sell_prescription_drugs", + "manufacture_drugs", + "sell_medical_devices", + "haul_freight", + "broker_freight", + "sell_alcohol", + "produce_spirits", + "provide_investment_advice", + "accept_deposits", + "lend", + "bill_medicare_medicaid", + "healthcare_supplier", + "federal_contracting", + "charitable_solicitation", + "construction", + "operate_psilocybin_healing_center" +]
1 tool update
- Added
check_email
1 tool update
- Removed
check_email
1 tool update
- Added
check_email
2 tool updates
- Changed
qualify_counterparty7 fields changed- added
Input schema / properties / browser_timezoneAdded value: +{ + "description": "IANA time zone reported by the submitter's browser", + "maxLength": 60, + "type": "string" +} - added
Input schema / properties / ip_asnAdded value: +{ + "description": "ASN of the submitting network, to recognise hosting and VPN networks", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" +} - changed
Input schema / properties / ip_country / descriptionPrevious value: -"Country the submission came from, ISO alpha-2"New value: +"Country the submission came from, ISO alpha-2 (location consistency check)" - added
Input schema / properties / ip_regionAdded value: +{ + "description": "Region the submission came from (ISO 3166-2, e.g. US-CA or CA)", + "maxLength": 10, + "type": "string" +} - added
Input schema / properties / signalAdded value: +{ + "description": "Jid Signals token (the form's jid_signal field): Jid's own reading of the visitor's location; replaces the ip_* fields when it verifies", + "maxLength": 800, + "type": "string" +} - added
Input schema / properties / siteAdded value: +{ + "description": "The submitting website's domain (binds the signal token)", + "maxLength": 253, + "type": "string" +} - added
Input schema / properties / stated_countryAdded value: +{ + "description": "Country the submitter stated (same as country)", + "maxLength": 2, + "minLength": 2, + "type": "string" +}
- Changed
screen2 fields changed- added
Input schema / properties / signalAdded value: +{ + "description": "Jid Signals token (the form's jid_signal field): Jid's own reading of the visitor's location; replaces the ip_* fields when it verifies", + "maxLength": 800, + "type": "string" +} - added
Input schema / properties / siteAdded value: +{ + "description": "The submitting website's domain (binds the signal token)", + "maxLength": 253, + "type": "string" +}
1 tool update
- Changed
screen5 fields changed- added
Input schema / properties / browser_timezoneAdded value: +{ + "description": "IANA time zone reported by the browser", + "maxLength": 60, + "type": "string" +} - added
Input schema / properties / ip_asnAdded value: +{ + "description": "ASN of the request's network, to recognise hosting and VPN networks", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" +} - added
Input schema / properties / ip_countryAdded value: +{ + "description": "Country the request came from (ISO alpha-2), for the location consistency check", + "maxLength": 2, + "minLength": 2, + "type": "string" +} - added
Input schema / properties / ip_regionAdded value: +{ + "description": "Region of the request (ISO 3166-2, e.g. US-CA or CA)", + "maxLength": 10, + "type": "string" +} - added
Input schema / properties / stated_countryAdded value: +{ + "description": "Country the counterparty stated", + "maxLength": 2, + "minLength": 2, + "type": "string" +}
6 tool updates
- First observed
get_business_file - First observed
get_receipt - First observed
qualify_counterparty - First observed
screen - First observed
search_business - First observed
verify_business
Related MCP Connectors
Free agent identity and signed US supplier-payment decisions. Inspect first; verify portable proof.
Verify a company, figure or citation before you rely on it. Card or crypto; signed receipt.
Check before you pay. Prove to get paid. Signed answers on any agent, against your own bar.
Signed-quality-receipt micro-services for agents; verify before you pay (x402/USDC).
Related MCP Servers
- AlicenseBqualityCmaintenanceA local receipt and approval gate for AI agent sessions. The agent can act, but it cannot sign.434 npm3Apache 2.0
BizVerify MCP Serverofficial
AlicenseAqualityDmaintenanceEnables AI agents to verify and search business entities across US state and international company registries, providing real-time confirmation of legal existence, status, and filings.9MIT
emilia-mcp-serverofficial
AlicenseAqualityBmaintenanceThe accountability layer for AI agents — a named human's signed yes before an agent does anything irreversible (payment, record change, deploy), then an offline-verifiable Trust Receipt. Apache-2.0, formally verified.3612Apache 2.0
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.