Mifori CertAgent Trust Oracle

Verify Agent Reputation (x402 Audit)

verify_agent_reputation

Executes a live <500ms outbound HTTP audit against target_bot_url to measure Synthetic IQ (0-100), round-trip latency, JSON schema compliance, and hallucination risk, persisting a signed certificate (eval_id) to the public ledger. Call with target_bot_url alone (omitting payment_proof) for a free, side-effect-free PAYMENT_REQUIRED_402 invoice, then supply a 0x Base Mainnet USDC transaction hash ($0.005) or X-Agent-Key credit in payment_proof to run the live probe. Use before delegating tasks to a specific endpoint; use get_agent_leaderboard instead for free read-only ranking lookups, or submit_agent_feedback to dispute an existing eval_id.

Input Schema

TableJSON Schema

Name	Required	Description
`agent_id`	No	Optional semantic agent identifier or DID (e.g. 'did:mifori:my-agent' or 'agent://router') to associate with the signed audit certificate in the public ledger.
`payment_proof`	No	Optional 66-character Base Mainnet USDC transaction hash ('0x...') for the $0.005 x402 audit fee or an X-Agent-Key credit token. Omit on initial call to receive the free HTTP 402 payment invoice.
`target_bot_url`	Yes	Publicly reachable HTTPS/HTTP endpoint URL of the AI agent to audit (e.g. 'https://agent.mifori.com/v1/demo-agent'). Must accept JSON POST probes.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Error code or payment requirement description if audit was not completed.
`status`	Yes	Execution status ('VERIFIED', 'PAYMENT_REQUIRED_402', or 'ERROR').
`eval_id`	No	Unique identifier (UUID) of the audit evaluation.
`agent_id`	No	Optional semantic identifier or DID associated with the audited agent.
`latency_ms`	No	Measured round-trip execution latency in milliseconds.
`synthetic_iq`	No	Computed Synthetic IQ score between 0 and 100.
`target_bot_url`	Yes	Audited target agent URL.
`reliability_tier`	No	Assigned Mifori trust tier based on IQ and latency.
`certagent_signature`	No	Cryptographic HMAC-SHA256 signature of the audit certificate.
`json_schema_compliant`	No	Whether the target agent returned a valid JSON contract.
`hallucination_detected`	No	Whether logical hallucination or invalid output was detected.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 16, 2026

addedInput schema / properties / agent_id

Added value: +{
+  "description": "Optional semantic agent identifier or DID (e.g. 'did:mifori:my-agent' or 'agent://router') to associate with the signed audit certificate in the public ledger.",
+  "maxLength": 128,
+  "type": "string"
+}

addedOutput schema / properties / agent_id

Added value: +{
+  "description": "Optional semantic identifier or DID associated with the audited agent.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

First observedOct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false, openWorldHint=true, non-idempotent and non-destructive, but the description goes beyond them: it discloses the outbound network call, the sub-500ms latency budget, the $0.005 USDC cost with accepted payment forms, the free side-effect-free invoice path, and public-ledger persistence. That is real behavioral context an agent needs before invoking a paid, state-mutating audit.

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?

Information is front-loaded: purpose and measured outputs first, then the payment flow, then tool-selection guidance. It is dense and the second sentence is long, but every clause carries distinct information, so nothing reads as filler.

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?

An output schema exists, so return values need not be re-explained. Given the tool's complexity, the description covers prerequisites (reachable JSON POST endpoint), cost and auth mechanics, ledger side effects, and sibling alternatives — everything needed to call it correctly.

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 both the payment_proof workflow ('omit on initial call to receive the free HTTP 402 payment invoice') and the POST-probe requirement for target_bot_url are already documented in the schema; the description largely restates them. The optional agent_id parameter is not mentioned at all, so the description adds little beyond structured data. Baseline 3 applies.

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 ('Executes a live <500ms outbound HTTP audit against target_bot_url') plus the concrete outputs it measures (Synthetic IQ, latency, schema compliance, hallucination risk) and the side effect of persisting a signed certificate. It also names the two siblings it is not, so an agent can distinguish it without opening other schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use it ('before delegating tasks to a specific endpoint') and names alternatives with their selecting conditions: get_agent_leaderboard for free read-only ranking and submit_agent_feedback to dispute an eval_id. It additionally documents the two-step invocation flow (free 402 invoice, then paid probe), leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Mifori CertAgent Trust Oracle tools Inspect

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.

Resources

Need Help?