Evidence infrastructure for agents: source-backed company verification and beta import assessment.
Scored across 7 tools
The three active tools (factrail_assess, factrail_verify, factrail_capabilities) have distinct purposes: import assessment vs. company verification vs. capability discovery. However, the three deprecated tools (analyze_company, assess_import, verify_french_company) are explicit aliases of factrail_verify and factrail_assess respectively, creating intentional overlap that could confuse agents without careful reading.
The active tools follow a 'factrail_' prefix with mixed verb/noun structure (factrail_assess, factrail_verify, factrail_capabilities, factrail_get_receipt), which is fairly consistent. But the deprecated tools use entirely different conventions (analyze_company, assess_import, verify_french_company) with no prefix, breaking the pattern.
Seven tools is a reasonable number for the scope, but three of them are deprecated compatibility shims, leaving only four unique operations. This makes the effective tool surface feel thin and cluttered with legacy aliases.
The active tools cover capability discovery, company verification, import assessment, and result auditing, which is a coherent core. However, the deprecated tools expose unavailable data (financial/credit) or partial results, and there is no clear CRUD or lifecycle management beyond verify/assess/get_receipt.
Deprecated: use factrail_verify instead. Use only when an older integration still calls this experimental tool; financial and credit data sources are unavailable and returned fields are null.
| Name | Required | Description | Default |
|---|---|---|---|
| siren | No | Optional SIREN (9-digit) or SIRET (14-digit) identifier. | |
| company_name | No | Optional caller-provided display name; it is echoed without verification. | |
| country_code | No | ISO 3166-1 alpha-2 country code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds critical non-obvious behavior: this is deprecated, financial/credit sources are unavailable, and returned fields are null. That directly prevents an agent from trusting garbage output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, and the deprecation notice is front-loaded before any other content. Every clause earns its place: replacement tool, usage condition, and the null-field warning.
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 deprecated tool with no output schema and all-optional params, the description supplies exactly what's needed: don't use it, here's the replacement, and the output is empty anyway. Nothing an agent requires to call or avoid it 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% with three optional, self-documented parameters, so the baseline is 3. The description adds no parameter-level meaning (e.g., which identifier wins if both siren and company_name are given), leaving the schema to carry it.
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 operation (company analysis), its deprecated status, and the exact sibling to use instead (factrail_verify). An agent can distinguish it from factrail_verify and verify_french_company purely from the text, with no schema inspection needed.
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?
Explicit when-to-use and when-not-to-use: only call it when a legacy integration still invokes the experimental path, and use factrail_verify otherwise. Both the condition and the alternative are stated without inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deprecated: use factrail_assess instead. Use when an older integration still expects the legacy beta EU import assessment format; coverage may be partial or provisional and this is not a binding customs result.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optional model identifier. | |
| product | Yes | Short product description (e.g. '750ml insulated stainless steel drinking bottle'). | |
| currency | Yes | ISO 4217 currency code (e.g. 'EUR'). | |
| incoterm | No | Optional Incoterm (e.g. 'FCA', 'CIF', 'DDP'). | |
| material | No | Optional primary material (e.g. 'stainless steel'). | |
| quantity | Yes | Number of units. | |
| weight_kg | No | Optional gross weight per unit in kg. | |
| dimensions | No | Optional product dimensions (e.g. '25x8x8 cm'). | |
| goods_value | Yes | Total goods value in the given currency. | |
| freight_cost | No | Optional total freight cost in the given currency. | |
| manufacturer | No | Optional manufacturer name. | |
| known_hs_code | No | Optional known HS code (6-10 digits). If supplied, validated and enriched. | |
| shipping_mode | No | Optional shipping mode (e.g. 'sea', 'air', 'road'). | |
| insurance_cost | No | Optional total insurance cost in the given currency. | |
| origin_country | Yes | ISO 3166-1 alpha-2 origin country code (e.g. 'CN'). | |
| origin_location | No | Optional origin city/port/location. | |
| destination_country | Yes | ISO 3166-1 alpha-2 EU destination country code (e.g. 'FR'). V0 supports EU member states only. | |
| destination_location | No | Optional destination city/port/location. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely non-obvious behavioral caveats: coverage may be partial or provisional and the output is not a binding customs result, which tells the agent how much to trust the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short clauses, deprecation notice front-loaded ahead of the residual use case, with no filler. Every sentence (replacement target, legacy condition, trust caveat) 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?
For a deprecated 6-required-parameter tool with no output schema, the description gives the essential routing, the fallback condition, and the trust caveat. It could note that EU destinations are the supported scope (which only appears in the schema), but nothing critical for correct invocation 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% across all 18 parameters, so every field (including optional ones like incoterm, known_hs_code, shipping_mode) is already documented in the schema. The description adds no parameter-level guidance, 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 identifies the tool as the legacy beta 'EU import assessment' and leads with its deprecated status, so an agent immediately understands what it is and that it is superseded. It stops short of a crisp verb+resource statement of what the assessment computes, but the identity and scope are unambiguous.
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 names the replacement explicitly ('use factrail_assess instead') and states the one condition under which this tool is still correct: an older integration expecting the legacy beta format. Both the when-not (new work) and the when (legacy caller) are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need a source-backed assessment of importing a product into the EU (tariff classification, duties, and related evidence). Returns an EvidenceEnvelope; import assessment is Beta and results expose source coverage and support levels.
| Name | Required | Description | Default |
|---|---|---|---|
| parameters | Yes | Required + optional inputs for assess_import. | |
| assessment_type | Yes | Currently only import is supported. |
| Name | Required | Description |
|---|---|---|
| facts | Yes | |
| status | Yes | |
| subject | Yes | |
| coverage | Yes | |
| evidence | Yes | |
| conflicts | Yes | |
| freshness | Yes | |
| receipt_id | No | |
| generated_at | Yes | |
| schema_version | No | |
| state_fingerprint | No |
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 context beyond that: it returns an EvidenceEnvelope, is Beta, and results expose source coverage and support levels — useful for interpreting reliability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the usage trigger and then the return/Beta caveat. Efficient and no wasted phrasing, though it is fairly terse for a tool with a large nested parameter object.
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?
An output schema exists, so return-value details need not be in the description. It mentions the EvidenceEnvelope type and Beta status, and the schema fully covers the 2-param nested input. The only real gap is disambiguation from the assess_import sibling.
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 schema already documents every parameter (product, origin/destination country, currency, HS code, TARIC date, etc.). The description adds no additional input semantics or formats, 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 gives a specific verb (assess) and resource (importing a product into the EU), plus concrete scope: tariff classification, duties, and related evidence. It is clear on its own, but it never differentiates from the sibling tool named assess_import, which sounds nearly identical.
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?
"Use when you need a source-backed assessment of importing a product into the EU" gives a positive trigger condition. However, there are no when-not conditions and no routing away from the very similar sibling assess_import, so the agent gets only implied guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need to discover what FACTRAIL can verify or assess before calling another tool. Returns available capabilities, inputs, fields, sources, versions, and limitations; call first to inspect current coverage and source state.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | No | ||
| capability | No |
| Name | Required | Description |
|---|---|---|
| capabilities | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuine context beyond that: it is a pre-flight introspection call whose output reflects current coverage and source state, which tells the agent the result can change over time and should precede other calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tightly front-loaded with the usage trigger and then the return shape. No filler, though the second sentence's list is slightly dense and could be trimmed without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, zero-required-parameter discovery tool with an output schema and rich annotations, the description covers trigger, ordering, and return scope adequately. The only real gap is the undocumented input parameters, which it assumes the agent will read from the schema.
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 0% and the description never mentions the `operation` or `capability` parameters or what they constrain. The enum values ('verify'/'assess', 'company_fr'/'import') are partly self-describing and both params are optional, which limits the damage, but the description does not compensate for the missing documentation.
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 — discovering what FACTRAIL can verify/assess — and enumerates the shape of the return (capabilities, inputs, fields, sources, versions, limitations). It is clearly distinguishable from the action-oriented siblings (factrail_verify, factrail_assess, analyze_company) as the introspection entry point.
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?
"Use when you need to discover ... before calling another tool" plus "call first to inspect current coverage" gives explicit ordering guidance and a clear trigger condition. It lacks an explicit when-not-to-use clause, but the discovery framing makes the alternative (just call the verify/assess tool directly) obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need to re-fetch or audit a previously returned FACTRAIL result by its receipt ID. Recomputes the stored EvidenceEnvelope's content hash and rejects altered content; this checks integrity, not truth.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | Yes | A FACTRAIL evidence observation ID. |
| Name | Required | Description |
|---|---|---|
| facts | Yes | |
| status | Yes | |
| subject | Yes | |
| coverage | Yes | |
| evidence | Yes | |
| conflicts | Yes | |
| freshness | Yes | |
| receipt_id | No | |
| generated_at | Yes | |
| schema_version | No | |
| state_fingerprint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior, so the lower bar applies; the description still adds substantive context by disclosing that the content hash is recomputed and altered content is rejected. What remains unspecified is the failure surface (e.g., behavior on an unknown receipt ID) and the shape of the returned envelope, though the output schema covers the latter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the usage trigger and followed by the one behavioral caveat that matters. No filler, no restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, idempotent read tool with an output schema, the description covers when to use it, what it does mechanically, and its key limitation (integrity, not truth). Return-value explanation is correctly left to the output schema.
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 receipt_id parameter already documents its role and pattern (^fr_[0-9a-f]{64}$). The description only restates that lookup happens 'by its receipt ID' and adds no format or source 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?
Names a specific verb pair (re-fetch/audit) and a precise resource (a previously returned FACTRAIL result identified by receipt ID). The clause 'this checks integrity, not truth' cleanly separates it from the verification-oriented siblings (factrail_verify, factrail_assess) without the schema being opened.
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?
'Use when you need to re-fetch or audit a previously returned FACTRAIL result by its receipt ID' gives an explicit trigger condition — you must already hold a receipt from an earlier call. The integrity-vs-truth note functions as a partial exclusion, but no alternative tool is named outright for the truth-checking case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need verified, source-backed facts about a French company from its SIREN or SIRET. Returns Evidence with provenance, freshness, coverage, conflicts, and a reusable receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Optional company fields to resolve; omit for the default set. | |
| identifier | Yes | A 9-digit SIREN or 14-digit SIRET. | |
| subject_type | Yes | Currently only French companies are supported. |
| Name | Required | Description |
|---|---|---|
| facts | Yes | |
| status | Yes | |
| subject | Yes | |
| coverage | Yes | |
| evidence | Yes | |
| conflicts | Yes | |
| freshness | Yes | |
| receipt_id | No | |
| generated_at | Yes | |
| schema_version | No | |
| state_fingerprint | No |
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 fully covered. The description adds that results carry provenance, freshness, coverage and conflicts, which is genuine behavioral context, but with an output schema present most of the return-value detail is already available elsewhere.
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 tight sentences, with the usage trigger front-loaded before the return description. No filler, though "reusable receipt" is slightly vague and could carry its weight better with a concrete note on reuse.
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 rich annotations, a full-coverage schema and an output schema, the description only needed to convey purpose and the evidence-oriented nature of the response, which it does. The one real hole is routing between it and its overlapping siblings, which the description never resolves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and all three parameters are documented (identifier pattern, subject_type enum, fields list), so the schema carries the semantics. The description only echoes the SIREN/SIRET idea and adds no detail on the fields array or default field set, 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?
Names a specific verb (verify) and resource (French company) plus the accepted keys (SIREN/SIRET), so the agent knows exactly what it does. However, it does not differentiate itself from the near-identical sibling verify_french_company, nor from analyze_company, so it falls short of the 5 bar for sibling differentiation.
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?
"Use when you need verified, source-backed facts" gives a usable trigger condition, which is more than nothing. But it names no exclusions and no alternatives, which matters a lot here because verify_french_company appears to be a directly overlapping sibling — the definition leaves the agent to guess which to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deprecated: use factrail_verify instead. Use when an older integration still expects the legacy flat French company lookup by SIREN/SIRET; kept callable for compatibility only.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | A 9-digit SIREN or 14-digit SIRET. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the deprecation lifecycle context and compatibility-only constraint, which is meaningful beyond the annotations, though it does not add rate-limit or auth details.
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, both earning their place, with the deprecation warning and replacement tool front-loaded before the compatibility condition. There is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only compatibility tool with no output schema, the description covers lifecycle status, intended use, and the alternative tool. Annotations supply the safety profile, so 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single `identifier` parameter is already fully documented as a 9-digit SIREN or 14-digit SIRET. The description mentions SIREN/SIRET but adds no format or syntax detail beyond the schema, matching the baseline 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (lookup) and resource (legacy flat French company by SIREN/SIRET), and explicitly names the sibling `factrail_verify` as the preferred alternative. An agent can distinguish this deprecated compatibility shim from the modern verification tool without opening either 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?
It gives explicit when-to-use guidance: only when an older integration still expects the legacy flat lookup, and it names `factrail_verify` as the replacement. It also states it is kept callable for compatibility only, which tells the agent not to select it for new work.
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.
analyze_company1 field changedInput schema / properties / company_name / descriptionPrevious value: -"Company legal name for lookup."New value: +"Optional caller-provided display name; it is echoed without verification."factrail_assess4 fields changedInput schema / properties / parameters / properties / assessment_dateAdded value: +{
+ "anyOf": [
+ {
+ "format": "date",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional TARIC effective/simulation date; availability depends on the installed snapshot.",
+ "title": "Assessment Date"
+}Output schema / $defs / Fact / properties / support_levelAdded value: +{
+ "$ref": "#/$defs/SupportLevel",
+ "default": "supported"
+}Output schema / $defs / SupportLevelAdded value: +{
+ "description": "How strongly a fact is supported, independent of numeric confidence.",
+ "enum": [
+ "authoritative",
+ "supported",
+ "derived_supported",
+ "derived_provisional",
+ "curated",
+ "caller_input"
+ ],
+ "title": "SupportLevel",
+ "type": "string"
+}Output schema / properties / schema_version / defaultPrevious value: -"1.1"New value: +"1.2"factrail_capabilitiesfactrail_get_receipt3 fields changedOutput schema / $defs / Fact / properties / support_levelAdded value: +{
+ "$ref": "#/$defs/SupportLevel",
+ "default": "supported"
+}Output schema / $defs / SupportLevelAdded value: +{
+ "description": "How strongly a fact is supported, independent of numeric confidence.",
+ "enum": [
+ "authoritative",
+ "supported",
+ "derived_supported",
+ "derived_provisional",
+ "curated",
+ "caller_input"
+ ],
+ "title": "SupportLevel",
+ "type": "string"
+}Output schema / properties / schema_version / defaultPrevious value: -"1.1"New value: +"1.2"factrail_verify3 fields changedOutput schema / $defs / Fact / properties / support_levelAdded value: +{
+ "$ref": "#/$defs/SupportLevel",
+ "default": "supported"
+}Output schema / $defs / SupportLevelAdded value: +{
+ "description": "How strongly a fact is supported, independent of numeric confidence.",
+ "enum": [
+ "authoritative",
+ "supported",
+ "derived_supported",
+ "derived_provisional",
+ "curated",
+ "caller_input"
+ ],
+ "title": "SupportLevel",
+ "type": "string"
+}Output schema / properties / schema_version / defaultPrevious value: -"1.1"New value: +"1.2"analyze_companyfactrail_assessfactrail_get_receiptfactrail_verifyassess_importverify_french_companySource-traced evidence research for AI agents. We organise the evidence; you decide.
Machine-native utility network: verified evidence services for autonomous agents.
Verify a source or provider before an AI agent trusts it. Evidence only; unknown stays unknown.
Evidence-backed x402 web verification for AI agents, with auditable decisions for every condition.
Add one secure layer between your agents and this server.
