Evidence-bounded RWA due diligence, compliance, sanctions, reserves, corporate actions and transaction assurance.
Scored across 11 tools
The rwa_* tools mostly target distinct concerns (due diligence, compliance, corporate actions, NAV, sanctions, transaction assurance), and the free meta-tools are clearly separate. However, rwa_compliance and rwa_transaction_assurance both cover transfer restrictions, and phion_execute as a universal gateway overlaps conceptually with the individual paid services, creating some selection ambiguity.
Naming mixes three conventions: prefixed snake_case domain tools (rwa_*), a prefixed gateway (phion_execute), and bare verbs/nouns (preflight, verify, try_service, schema_normalize_free). The rwa_* group is internally consistent, but the overall set is mixed and several names are noun phrases rather than verb_noun.
Eleven tools sits comfortably in the well-scoped 3-15 range. Each tool covers a specific service or meta-capability, and none feels like filler.
The surface covers the core RWA lifecycle: due diligence, compliance, corporate actions, NAV/reserve, sanctions, and transaction assurance, plus free preflight, normalization, preview, and receipt verification. Gaps are minor, e.g. no explicit service catalog listing aside from try_service and no batch/history access.
Universal PHION execution gateway: enforce a budget and persistent idempotency, execute one selected PHION service, evaluate acceptance criteria, and return a signed completion envelope. No gateway surcharge; the selected service price applies.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| dry_run | No | ||
| objective | Yes | ||
| target_service | Yes | ||
| idempotency_key | Yes | ||
| max_budget_atomic | Yes | ||
| acceptance_criteria | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is partly covered. The description nonetheless adds real substance: budget enforcement, persistent idempotency, acceptance-criteria evaluation, a signed completion envelope, and the pricing note ('no gateway surcharge'). It stops short of describing failure/retry behavior or the dry-run semantics.
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, front-loaded with the gateway purpose and flow, with a pricing clause that earns its place. Dense but not padded; density does cost some readability for a 7-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter, nested-object, no-output-schema mutation tool, the description leaves meaningful gaps: dry-run behavior, input shape, atomic budget units, acceptance-criteria pointer syntax, and what happens when criteria fail are all unaddressed. Both schema and description are thin on parameters.
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%, so the description carries the burden, and it only partially compensates. It conceptually covers budget (max_budget_atomic), idempotency (idempotency_key), acceptance criteria, and target_service, but says nothing about the 'atomic' unit format, the JSON-pointer syntax for acceptance criteria, the objective field, or what dry_run does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('execute one selected PHION service') and frames the tool as a 'Universal PHION execution gateway' that also budgets, idempotency-checks, evaluates acceptance criteria, and returns a signed envelope. That is far more informative than restating the name, but it never explicitly contrasts itself with siblings like phion_preflight or verify, so an agent must infer the boundary.
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?
'Execute one selected PHION service' implies this is the terminal step after discovery/selection, but no condition is given for choosing this over phion_preflight or verify, and no prerequisites or exclusions are stated. Usage is deducible from context rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free URL safety and reachability check.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, and it discloses almost nothing beyond 'free' — no auth requirements, no explanation of what makes a URL unsafe, no behavior on failure, and no rate limits. Calling something a safety check without saying what it inspects or returns leaves real ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler; the core action leads. It is efficient, though the terseness edges toward under-specification rather than tightness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description still omits what a 'safety' verdict consists of and what the caller gets back, which is the main thing an agent needs to decide whether to gate a downstream action on the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required url parameter, and the description only says a URL is checked. It does not clarify expected form (absolute? scheme? relative paths rejected?), which matters because the schema only declares format: uri with no prose.
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 concrete verb-plus-resource framing: it checks a URL for safety and reachability. That is enough for an agent to know what it does, but it never distinguishes itself from the sibling payment_preflight, which sounds nearly identical in kind.
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?
There is no statement of when to call this versus payment_preflight, verify, or the other siblings, and no prerequisites (e.g., authenticate first, call before payment). The agent is left to infer the workflow position of a 'preflight' entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fail-closed issuer, contract, jurisdiction, custody and documentation coverage with independently fetched evidence; 0.019 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| source_urls | No | ||
| declared_facts | No |
Fail-closed RWA transfer decision requiring explicit jurisdiction, KYC, allowlist, limit and transfer-window checks; 0.012 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| policy | Yes | ||
| source_urls | No |
Detect and sign material RWA changes in NAV, income, maturity, redemption or freeze state; 0.012 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| source_urls | No | ||
| current_state | Yes | ||
| previous_state | Yes |
Evidence-based literal subject screening against observed official US/EU sanctions sources; 0.015 USDC. Not legal clearance or wallet attribution.
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | ||
| source_urls | No | ||
| jurisdictions | Yes |
Verify an RWA asset, payment, delivery and transfer restrictions; 0.020 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| policy | Yes | ||
| source_urls | No | ||
| transaction | Yes |
Free, rate-limited payload validation and safe key normalization before payment. Payment-critical values are never changed.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | ||
| target_service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose genuine behavior beyond the schema: free tier, rate limiting, non-mutation of payment-critical values. But it omits error/invalid-payload behavior, what the rate limit actually is, and whether normalization mutates or returns a new payload.
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 key guarantee front-loaded after the purpose clause; no filler. Slightly dense with unattributed modifiers ('Free, rate-limited') but appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations, with a nested free-form payload object and an undocumented required target_service string. An agent cannot reliably construct a valid invocation from this description alone; payload shape, service identifiers, and failure behavior are all 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 0%: the nested 'payload' object has no field documentation, and 'target_service' is never mentioned in the description at all, so its expected values are entirely unknown. The description adds some intent ('payment-critical values are never changed') but does not compensate for the uncovered, required parameters.
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 action pair (validation and safe key normalization) on a specific resource (payload) with scope (before payment). The adjectival 'Free, rate-limited' implicitly distinguishes it from the sibling schema_normalize, but the distinction is left for the agent to infer rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear timing context ('before payment'), which implies when to reach for it, but never names the alternative schema_normalize or states when to use the paid variant instead. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free representative preview, exact price and upgrade instructions for any PHION paid service; no wallet required.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does disclose two important traits: cost is zero ('Free') and no wallet/auth is needed. It stops short of other operational facts an agent needs — whether the preview is truncated/representative-only, rate limits, and whether calling it commits to anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence that front-loads the key benefit ('Free representative preview') before the outputs and the 'no wallet required' constraint. Nothing is wasted, though the clause stacking makes it slightly harder to parse at a glance.
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 tool with a 120+ value enum, no output schema, and no annotations, the description is adequate on the basics (free, no wallet, returns price and upgrade path) but does not explain what the 'representative preview' actually contains or how it relates to the real paid response, which matters given the huge service surface.
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%, so the description must compensate. 'For any PHION paid service' does convey that the single parameter selects a service, which is useful, but it adds no format, naming, or constraint detail beyond the 120+ value enum, and gives no hint about the enum itself.
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 action ('free representative preview') plus a concrete scope ('any PHION paid service') and the extra outputs (exact price, upgrade instructions). It is clearly distinguishable from a generic execute tool, but it never names or contrasts any of the many related siblings such as phion_get_service, phion_preflight, or phion_discover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'No wallet required' implies the usage context (pre-payment evaluation, cold-start without credentials), so the when-to-use is inferable. However, it never states when NOT to use it (e.g. when a paid call is actually intended) nor points at the alternative tool to use in that case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free verification of a PHION signed receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | ||
| receipt | Yes | ||
| sources | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds only 'Free', which is a useful pricing trait not covered by annotations, but it omits what verification actually checks, what an invalid receipt produces, and any return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and free of filler. However, its extreme brevity borders on under-specification for a tool with three parameters and no schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 0% schema description coverage, the description should explain return semantics and parameter roles. It does not, leaving an agent unclear about what verification produces and how to use the optional parameters.
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 only hints at the required 'receipt' parameter via the phrase 'signed receipt'. It says nothing about the optional 'content' or 'sources' parameters, so it does not compensate for the undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('verification') and resource ('PHION signed receipt'), and adds the pricing trait 'Free'. It does not explicitly differentiate itself from siblings such as phion_preflight or phion_resolve, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, prerequisites, or alternatives. An agent must infer usage entirely from the tool name and title, with no exclusions or context about when this is preferable to sibling tools.
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.
rwa_asset_due_diligence1 field changedInput schema / examplesAdded value: +[
+ {
+ "asset": {
+ "contract": "0x...",
+ "custodian": "Example Custodian",
+ "documentation": "https://issuer.example/disclosures",
+ "issuer": "Issuer",
+ "jurisdiction": "US",
+ "name": "Tokenized Treasury",
+ "network": "eip155:8453"
+ },
+ "source_urls": [
+ "https://issuer.example/disclosures"
+ ]
+ }
+]rwa_compliance1 field changedInput schema / examplesAdded value: +[
+ {
+ "asset": {
+ "contract": "0x..."
+ },
+ "policy": {
+ "allowlisted": true,
+ "jurisdiction_allowed": true,
+ "kyc_satisfied": true,
+ "transfer_window_open": true,
+ "within_limits": true
+ },
+ "source_urls": [
+ "https://issuer.example/transfer-policy"
+ ]
+ }
+]rwa_corporate_actions1 field changedInput schema / examplesAdded value: +[
+ {
+ "asset": {
+ "contract": "0x..."
+ },
+ "current_state": {
+ "frozen": false,
+ "nav": "1.01"
+ },
+ "previous_state": {
+ "frozen": false,
+ "nav": "1.00"
+ },
+ "source_urls": [
+ "https://issuer.example/notices"
+ ]
+ }
+]rwa_nav_reserve1 field changedInput schema / examplesAdded value: +[
+ {
+ "asset": {
+ "contract": "0x..."
+ },
+ "declared_facts": {
+ "nav": "1.00",
+ "reserve_ratio": 1
+ },
+ "source_urls": [
+ "https://issuer.example/nav",
+ "https://oracle.example/reserves"
+ ]
+ }
+]rwa_sanctions_screening_evidence1 field changedInput schema / examplesAdded value: +[
+ {
+ "jurisdictions": [
+ "US",
+ "EU"
+ ],
+ "subject": {
+ "identifiers": [
+ "registration-id"
+ ],
+ "name": "Example Entity"
+ }
+ }
+]rwa_transaction_assurance1 field changedInput schema / examplesAdded value: +[
+ {
+ "asset": {
+ "contract": "0x...",
+ "network": "eip155:8453"
+ },
+ "policy": {
+ "recipient_eligible": true
+ },
+ "transaction": {
+ "amount": "1000000",
+ "recipient": "0x...",
+ "tx_hash": "0x..."
+ }
+ }
+]try_service1 field changedInput schema / properties / service / enumPrevious value: -[
- "attest",
- "payment-firewall",
- "web-evidence",
- "mandate-reserve",
- "agent-inspection",
- "commerce-journey",
- "transaction-assurance",
- "transaction-recovery",
- "rwa-asset-due-diligence",
- "rwa-compliance",
- "rwa-nav-reserve",
- "rwa-transaction-assurance",
- "rwa-corporate-actions",
- "schema-normalize",
- "sanctions-screening-evidence",
- "agent-reputation-evidence",
- "counterparty-risk-preflight",
- "tool-output-firewall",
- "delegation-scope-guard",
- "memory-write-guard",
- "mcp-manifest-firewall",
- "tool-call-policy-guard",
- "data-egress-preflight",
- "agent-budget-guard",
- "idempotency-replay-guard",
- "human-approval-policy",
- "secret-redaction-preflight",
- "oauth-token-audience-guard",
- "redirect-callback-validator",
- "tool-capability-drift-monitor",
- "mcp-server-identity-evidence",
- "agent-task-handoff-receipt",
- "context-provenance-labeler",
- "signed-result-comparator",
- "service-sla-attestation",
- "payment-route-selector",
- "x402-quote-comparator",
- "payment-receipt-reconciler",
- "duplicate-charge-detector",
- "subscription-spend-guard",
- "webhook-verifier",
- "delivery-evidence",
- "inter-agent-policy-evaluator",
- "concurrency-guard",
- "resource-cycle-guard",
- "abandoned-tool-detector",
- "manifest-version-diff",
- "dependency-provenance-assessment",
- "conflict-resolution",
- "data-freshness-certificate",
- "domain-ownership-evidence",
- "purpose-bound-consent",
- "retention-deletion-receipt",
- "interrupted-task-recovery",
- "portable-observability-audit",
- "index-feed",
- "verified-web-extract",
- "entity-enrichment-evidence",
- "social-source-evidence",
- "market-data-snapshot",
- "onchain-evidence",
- "verified-news-monitor",
- "multi-source-fact-bundle",
- "document-to-verified-json",
- "source-backed-search",
- "live-data-freshness",
- "person-enrichment-evidence",
- "company-enrichment-evidence",
- "contact-enrichment-evidence",
- "mcp-2026-compatibility-gateway",
- "durable-agent-task",
- "task-checkpoint-evidence",
- "task-cancel-assurance",
- "agent-approval-relay",
- "capability-negotiation-preflight",
- "mcp-catalog-cache-guard",
- "oauth-issuer-binding-evidence",
- "mcp-a2a-task-bridge",
- "quote-freshness-guard",
- "delegated-credential-guard",
- "agent-session-continuity",
- "task-lease-guard",
- "tool-result-schema-validator",
- "agent-memory-provenance",
- "payment-delivery-atomicity",
- "service-failover-selector",
- "agent-rate-limit-negotiator",
- "execution-cost-estimator",
- "cross-agent-receipt-bundle",
- "capability-verification",
- "capability-benchmark",
- "sybil-reputation-guard",
- "agent-behavior-fingerprint",
- "trust-anomaly-detector",
- "economic-loop-detector",
- "provider-quality-predictor",
- "transaction-risk-score",
- "payment-optimizer",
- "x402-v2-router",
- "erc8004-identity-evidence",
- "erc8004-reputation-intelligence",
- "delegated-spend-policy",
- "ap2-mandate-bridge",
- "a2a-transaction-bridge",
- "mcp-transaction-gateway",
- "proof-of-service",
- "automated-dispute-bundle",
- "transaction-recovery-v2",
- "reputation-update-receipt",
- "agent-economic-graph",
- "market-demand-predictor",
- "service-gap-detector",
- "price-discovery-engine",
- "sla-risk-predictor",
- "dynamic-service-pricing",
- "autonomous-procurement",
- "multi-agent-escrow",
- "cross-protocol-receipt",
- "phion-inference",
- "phion-search",
- "phion-enrich",
- "phion-intelligence"
-]New value: +[
+ "attest",
+ "payment-firewall",
+ "web-evidence",
+ "mandate-reserve",
+ "agent-inspection",
+ "commerce-journey",
+ "transaction-assurance",
+ "transaction-recovery",
+ "rwa-asset-due-diligence",
+ "rwa-compliance",
+ "rwa-nav-reserve",
+ "rwa-transaction-assurance",
+ "rwa-corporate-actions",
+ "schema-normalize",
+ "sanctions-screening-evidence",
+ "agent-reputation-evidence",
+ "counterparty-risk-preflight",
+ "tool-output-firewall",
+ "delegation-scope-guard",
+ "memory-write-guard",
+ "mcp-manifest-firewall",
+ "tool-call-policy-guard",
+ "data-egress-preflight",
+ "agent-budget-guard",
+ "idempotency-replay-guard",
+ "human-approval-policy",
+ "secret-redaction-preflight",
+ "oauth-token-audience-guard",
+ "redirect-callback-validator",
+ "tool-capability-drift-monitor",
+ "mcp-server-identity-evidence",
+ "agent-task-handoff-receipt",
+ "context-provenance-labeler",
+ "signed-result-comparator",
+ "service-sla-attestation",
+ "payment-route-selector",
+ "x402-quote-comparator",
+ "payment-receipt-reconciler",
+ "duplicate-charge-detector",
+ "subscription-spend-guard",
+ "webhook-verifier",
+ "delivery-evidence",
+ "inter-agent-policy-evaluator",
+ "concurrency-guard",
+ "resource-cycle-guard",
+ "abandoned-tool-detector",
+ "manifest-version-diff",
+ "dependency-provenance-assessment",
+ "conflict-resolution",
+ "data-freshness-certificate",
+ "domain-ownership-evidence",
+ "purpose-bound-consent",
+ "retention-deletion-receipt",
+ "interrupted-task-recovery",
+ "portable-observability-audit",
+ "index-feed",
+ "verified-web-extract",
+ "entity-enrichment-evidence",
+ "social-source-evidence",
+ "market-data-snapshot",
+ "onchain-evidence",
+ "verified-news-monitor",
+ "multi-source-fact-bundle",
+ "document-to-verified-json",
+ "source-backed-search",
+ "live-data-freshness",
+ "person-enrichment-evidence",
+ "company-enrichment-evidence",
+ "contact-enrichment-evidence",
+ "mcp-2026-compatibility-gateway",
+ "durable-agent-task",
+ "task-checkpoint-evidence",
+ "task-cancel-assurance",
+ "agent-approval-relay",
+ "capability-negotiation-preflight",
+ "mcp-catalog-cache-guard",
+ "oauth-issuer-binding-evidence",
+ "mcp-a2a-task-bridge",
+ "quote-freshness-guard",
+ "delegated-credential-guard",
+ "agent-session-continuity",
+ "task-lease-guard",
+ "tool-result-schema-validator",
+ "agent-memory-provenance",
+ "payment-delivery-atomicity",
+ "service-failover-selector",
+ "agent-rate-limit-negotiator",
+ "execution-cost-estimator",
+ "cross-agent-receipt-bundle",
+ "capability-verification",
+ "capability-benchmark",
+ "sybil-reputation-guard",
+ "agent-behavior-fingerprint",
+ "trust-anomaly-detector",
+ "economic-loop-detector",
+ "provider-quality-predictor",
+ "transaction-risk-score",
+ "payment-optimizer",
+ "x402-v2-router",
+ "erc8004-identity-evidence",
+ "erc8004-reputation-intelligence",
+ "delegated-spend-policy",
+ "ap2-mandate-bridge",
+ "a2a-transaction-bridge",
+ "mcp-transaction-gateway",
+ "proof-of-service",
+ "automated-dispute-bundle",
+ "transaction-recovery-v2",
+ "reputation-update-receipt",
+ "agent-economic-graph",
+ "market-demand-predictor",
+ "service-gap-detector",
+ "price-discovery-engine",
+ "sla-risk-predictor",
+ "dynamic-service-pricing",
+ "autonomous-procurement",
+ "multi-agent-escrow",
+ "cross-protocol-receipt",
+ "phion-inference",
+ "phion-search",
+ "phion-enrich-basic",
+ "phion-enrich",
+ "phion-intelligence"
+]
Add one secure layer between your agents and this server.