Source-attributed person, company, contact and entity enrichment with explicit limitations and signed evidence.
Scored across 12 tools
The five *_evidence enrichment tools (agent, company, contact, entity, person) plus social_source_evidence are differentiated by entity type, but entity_enrichment_evidence is generic enough to overlap with the specific ones, and phion_execute as a 'universal execution gateway' that executes 'one selected PHION service' directly conflicts with the individual callable services, leaving unclear when to use the gateway vs the named tool. inspect_agent also overlaps conceptually with agent_reputation_evidence.
There is a recognizable <domain>_evidence suffix pattern for six tools, but it coexists with bare verbs (preflight, verify), verb_noun (inspect_agent, try_service), a namespaced verb (phion_execute), and a _free suffix (schema_normalize_free). Conventions are mixed but still readable and inferrable.
Twelve tools is well within a healthy scoped range for a multi-domain enrichment plus payment-verification service. Each tool maps to a distinct capability (per-entity enrichment, agent inspection, execution, preflight, normalization, verification, preview).
The surface covers enrichment across person/company/contact/entity/agent/social domains and includes the full payment lifecycle helpers (preflight, schema_normalize_free, try_service, verify, phion_execute). Minor gaps exist, such as no explicit batch or list/status operation, but core workflows appear closed.
Evidence-bounded agent reputation assessment with confidence, coverage, provenance limitations and a signed receipt; 0.005 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| signals | No | ||
| subject | Yes | ||
| evidence | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Company enrichment with free input preflight, provider attribution and signed evidence; 0.005 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| lid | No | ||
| name | No | ||
| No | |||
| input | No | ||
| phone | No | ||
| query | No | ||
| entity | No | ||
| pdl_id | No | ||
| person | No | ||
| region | No | ||
| school | No | ||
| ticker | No | ||
| company | No | Company name or nested input object | |
| contact | No | ||
| country | No | ||
| profile | No | ||
| subject | No | ||
| website | No | ||
| locality | No | ||
| location | No | ||
| last_name | No | ||
| birth_date | No | ||
| email_hash | No | ||
| first_name | No | ||
| identifier | No | Email, profile URL, phone, company domain, ticker or name; interpreted by service | |
| postal_code | No | ||
| street_address | No | ||
| minimum_likelihood | No |
Business-contact enrichment with free input preflight, identity limitations and signed receipt; 0.007 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| lid | No | ||
| name | No | ||
| No | |||
| input | No | ||
| phone | No | ||
| query | No | ||
| entity | No | ||
| pdl_id | No | ||
| person | No | ||
| region | No | ||
| school | No | ||
| ticker | No | ||
| company | No | Company name or nested input object | |
| contact | No | ||
| country | No | ||
| profile | No | ||
| subject | No | ||
| website | No | ||
| locality | No | ||
| location | No | ||
| last_name | No | ||
| birth_date | No | ||
| email_hash | No | ||
| first_name | No | ||
| identifier | No | Email, profile URL, phone, company domain, ticker or name; interpreted by service | |
| postal_code | No | ||
| street_address | No | ||
| minimum_likelihood | No |
Source-bounded entity field coverage with explicit missing facts; 0.008 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| subject | No | ||
| source_urls | Yes | ||
| expected_fields | No |
Pre-payment agent inspection across x402, A2A, ERC-8004, OpenAPI and MCP; failed inspections are not charged; 0.009 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Person enrichment with free input preflight, provider attribution, likelihood, limitations and signed receipt; 0.006 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| lid | No | ||
| name | No | ||
| No | |||
| input | No | ||
| phone | No | ||
| query | No | ||
| entity | No | ||
| pdl_id | No | ||
| person | No | ||
| region | No | ||
| school | No | ||
| ticker | No | ||
| company | No | Company name or nested input object | |
| contact | No | ||
| country | No | ||
| profile | No | ||
| subject | No | ||
| website | No | ||
| locality | No | ||
| location | No | ||
| last_name | No | ||
| birth_date | No | ||
| email_hash | No | ||
| first_name | No | ||
| identifier | No | Email, profile URL, phone, company domain, ticker or name; interpreted by service | |
| postal_code | No | ||
| street_address | No | ||
| minimum_likelihood | No |
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.
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.
agent_reputation_evidence1 field changedInput schema / examplesAdded value: +[
+ {
+ "evidence": [],
+ "signals": {
+ "endpoint_reachable": true,
+ "identity_registered": true,
+ "successful_settlements": 4
+ },
+ "subject": {
+ "erc8004_agent_id": 86081,
+ "wallet": "0x..."
+ }
+ }
+]company_enrichment_evidence1 field changedInput schema / examplesAdded value: +[
+ {
+ "website": "example.com"
+ }
+]contact_enrichment_evidence1 field changedInput schema / examplesAdded value: +[
+ {
+ "company": "Example",
+ "minimum_likelihood": 6,
+ "name": "Ada Lovelace"
+ }
+]entity_enrichment_evidence1 field changedInput schema / examplesAdded value: +[
+ {
+ "expected_fields": [
+ "name",
+ "domain"
+ ],
+ "source_urls": [
+ "https://example.com"
+ ],
+ "subject": {
+ "name": "Example"
+ }
+ }
+]inspect_agent1 field changedInput schema / examplesAdded value: +[
+ {
+ "url": "https://agent.example/.well-known/agent.json"
+ }
+]person_enrichment_evidence1 field changedInput schema / examplesAdded value: +[
+ {
+ "email": "ada@example.com",
+ "minimum_likelihood": 6
+ }
+]social_source_evidence1 field changedInput schema / examplesAdded value: +[
+ {
+ "query": "announcement",
+ "source_urls": [
+ "https://example.com"
+ ]
+ }
+]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.
social_source_evidenceInspect
Attributable public social-source observations with identity limitations; 0.006 USDC.