Official Mifori Agent Trust Protocol. Performs real-time latency, JSON schema compliance, and synthetic IQ audits on target AI bots using x402 USDC micro-payments on Base network before high-value tool execution.
Scored across 3 tools
Each tool has a clearly distinct purpose: discovery (get_agent_leaderboard), live auditing (verify_agent_reputation), and feedback/dispute (submit_agent_feedback). The descriptions explicitly cross-reference each other to clarify boundaries, preventing misselection.
All tool names follow a consistent verb_noun snake_case pattern: get_, submit_, verify_. The convention is predictable and readable throughout.
Three tools is on the low end but appropriate for a focused certification API, as each tool encapsulates a substantial multi-purpose operation. It is slightly thin given the domain's potential depth, but no tool feels redundant.
The surface covers the core lifecycle: discover ranked agents, run a live audit, and submit feedback/disputes. Minor gaps exist, such as no direct tool to retrieve a specific audit certificate by eval_id or check credit balance, but these are workable given the leaderboard and feedback flows.
Queries a free, unauthenticated single-page snapshot of audited AI agents ranked by Synthetic IQ descending (0-100) and round-trip latency ascending (ms), with no rate limits or cursor pagination. Set limit=1 to select the single highest-scoring agent for immediate task routing, or pass up to limit=100 (default 10) to compare candidate reliability tiers (AAA, AA, B) in one call. Use for zero-cost discovery of pre-verified agents; use verify_agent_reputation instead to run a fresh live audit on a specific target_bot_url, or submit_agent_feedback to report telemetry for an eval_id.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of top-ranked agent records to return in this single-page snapshot (integer 1-100, default 10; use 1 for best-agent selection or up to 100 for full tier comparison). |
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of leaderboard entries returned. |
| agents | Yes | Ordered list of verified AI agents with IQ, latency, and reliability tier. |
| status | Yes | Query execution status ('OK' or 'ERROR'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered; the description adds genuinely new behavior: free, unauthenticated, no rate limits, no cursor pagination, single-page snapshot, and the sort/tier model (AAA, AA, B). These are traits an agent cannot infer from the structured fields.
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?
Three dense sentences with no filler; the most important scope and ordering facts are front-loaded, then usage, then alternatives in a natural fall-through order. Slightly long for a one-parameter tool, but each clause carries distinct information.
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 explanation is unnecessary; the description instead supplies what the schema cannot – ranking direction, tier vocabulary, auth/rate-limit posture, and pagination absence. Nothing needed to call this 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% and the schema's own limit description already documents the 1-100 range, default 10, and the 'use 1 for best-agent / 100 for tier comparison' intent. The prose adds routing framing but no syntax or format 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?
States a concrete verb and resource ('Queries a free, unauthenticated single-page snapshot of audited AI agents') plus the exact ranking semantics (Synthetic IQ descending 0-100, latency ascending ms). An agent can distinguish this discovery/snapshot tool from the audit and feedback siblings without opening any 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?
Gives explicit selection guidance (limit=1 for best-agent routing, up to 100 for tier comparison) and names both alternatives with the condition that selects them: verify_agent_reputation for a fresh live audit on a target_bot_url, submit_agent_feedback for eval_id telemetry. When-to-use and when-not are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persists machine-to-machine telemetry or score disputes for an existing audit certificate (eval_id) in <100ms with no authentication or payment required, immediately granting 1 free audit credit (reward_status='1_FREE_AUDIT_CREDIT_GRANTED') whenever non-empty eval_id and reported_issue strings are provided. Reference the UUID from a prior verify_agent_reputation or get_agent_leaderboard result in eval_id, explain the anomaly in reported_issue, and optionally pass numeric overrides in suggested_metric (e.g. {'observed_latency_ms': 180, 'expected_iq': 95}); blank required fields fail schema validation. Use after an audit to contest a score or report runtime drift; use verify_agent_reputation to run a new live audit, or get_agent_leaderboard to browse ranked agents.
| Name | Required | Description | Default |
|---|---|---|---|
| eval_id | Yes | UUID or certificate identifier from a prior verify_agent_reputation or get_agent_leaderboard response (e.g. 'cab449d2-9072-415d-a8fd-d3a51bd3d87d'). Must be non-empty. | |
| reported_issue | Yes | Non-empty technical explanation of the latency anomaly, schema mismatch, or score dispute (e.g. 'Cold-start network spike added 220ms; steady-state latency is 140ms'). | |
| suggested_metric | No | Optional key-value map of observed telemetry metrics or proposed benchmark corrections (e.g. {'observed_latency_ms': 140, 'expected_iq': 96}). |
| Name | Required | Description |
|---|---|---|
| status | Yes | Submission status ('ACCEPTED' or 'ERROR'). |
| eval_id | Yes | Referenced evaluation UUID. |
| message | No | Human and machine readable confirmation message. |
| timestamp | No | ISO-8601 UTC timestamp of telemetry registration. |
| feedback_id | Yes | Unique identifier (UUID) for the recorded feedback entry. |
| reward_token | No | Single-use credit token ('mfr_fbk_...') accepted as payment_proof in verify_agent_reputation. |
| reward_status | Yes | Status of the 1 free audit credit reward. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false), and the description adds substantial context beyond them: sub-100ms latency, no auth or payment required, the immediate 1-free-audit-credit side effect (reward_status='1_FREE_AUDIT_CREDIT_GRANTED'), and that blank required fields fail schema validation.
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?
Front-loads the core purpose and destructive/safety-free behavior in the first clause, then adds parameter guidance and sibling routing. It is dense and contains long run-on sentences with parenthetical examples, but every sentence carries actionable content.
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 3-parameter mutation with nested object support and an existing output schema, the description supplies everything needed: source of eval_id, expected reported_issue content, optional metric overrides, the free-credit side effect, and routing to alternatives. Return values are covered by the output schema, so their omission is appropriate.
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 coverage is 100%, so the baseline is 3; the description earns above baseline by adding provenance for eval_id (must reference a prior verify_agent_reputation or get_agent_leaderboard result) and a worked example for suggested_metric. It does not add much syntactic detail beyond the schema, which already documents all three 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 verb and resource: 'Persists machine-to-machine telemetry or score disputes for an existing audit certificate (eval_id).' It clearly differentiates from siblings by naming verify_agent_reputation as the live-audit tool and get_agent_leaderboard as the browse tool.
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?
Explicitly states when to use it ('Use after an audit to contest a score or report runtime drift') and names both alternatives with their own triggering conditions ('use verify_agent_reputation to run a new live audit, or get_agent_leaderboard to browse ranked agents'). No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the safety envelope (readOnlyHint=false, destructiveHint=false, openWorldHint=true, non-idempotent), and the description adds the behavior that actually matters: an outbound request to a third-party URL with a <500ms budget, a persistent signed certificate written to a public ledger, an explicit $0.005 fee, and a free side-effect-free 402 invoice when payment_proof is omitted.
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?
Front-loaded with the purpose, then the payment mechanics, then sibling routing, with no filler. The first sentence is long and dense with parentheticals, which costs it a point on readability, but every clause conveys actionable information.
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 values are already covered. For a networked, paid, non-idempotent tool the description supplies what is otherwise missing: latency expectation, cost, payment flow, ledger persistence, and sibling alternatives. Nothing needed to invoke it correctly is absent.
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 coverage is 100% and the schema already documents both the 0x hash format and the X-Agent-Key credit option, so the baseline is 3. The description adds genuine operational meaning beyond the schema by stating that omitting payment_proof yields a free PAYMENT_REQUIRED_402 invoice, which is the sequence the caller must follow.
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 (executes a live outbound HTTP audit), the resource (target_bot_url / the target agent), and exactly what it measures (Synthetic IQ, latency, JSON schema compliance, hallucination risk) plus the persisted artifact. It also names what it is not by distinguishing itself from get_agent_leaderboard and submit_agent_feedback.
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 explicit when-to-use ('before delegating tasks to a specific endpoint') and two named alternatives with their own scoping conditions: get_agent_leaderboard for free read-only ranking and submit_agent_feedback for disputing an eval_id. The two-phase call flow (omit payment_proof first, then supply proof) is spelled out directly.
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.
get_agent_leaderboard1 field changedOutput schema / properties / agents / items / properties / latency_ms / typePrevious value: -"integer"New value: +"number"submit_agent_feedback1 field changedOutput schema / properties / reward_tokenAdded value: +{
+ "description": "Single-use credit token ('mfr_fbk_...') accepted as payment_proof in verify_agent_reputation.",
+ "type": "string"
+}verify_agent_reputation1 field changedOutput schema / properties / latency_ms / typePrevious value: -"integer"New value: +"number"get_agent_leaderboard1 field changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of ranked agent audit records to return (1-100, default 10)."New value: +"Maximum number of top-ranked agent records to return in this single-page snapshot (integer 1-100, default 10; use 1 for best-agent selection or up to 100 for full tier comparison)."submit_agent_feedback3 fields changedInput schema / properties / eval_id / descriptionPrevious value: -"Unique identifier (UUID) of the audit evaluation or certificate being reported."New value: +"UUID or certificate identifier from a prior verify_agent_reputation or get_agent_leaderboard response (e.g. 'cab449d2-9072-415d-a8fd-d3a51bd3d87d'). Must be non-empty."Input schema / properties / reported_issue / descriptionPrevious value: -"Detailed machine-to-machine telemetry or dispute explanation regarding the audit result."New value: +"Non-empty technical explanation of the latency anomaly, schema mismatch, or score dispute (e.g. 'Cold-start network spike added 220ms; steady-state latency is 140ms')."Input schema / properties / suggested_metric / descriptionPrevious value: -"Optional telemetry metrics or benchmark adjustments suggested by the reporting agent."New value: +"Optional key-value map of observed telemetry metrics or proposed benchmark corrections (e.g. {'observed_latency_ms': 140, 'expected_iq': 96})."verify_agent_reputation2 fields changedInput schema / properties / payment_proof / descriptionPrevious value: -"Optional Base Mainnet USDC transaction hash (0x...) or x402 payment proof ($0.005 USDC). If omitted, the tool returns the HTTP 402 payment invoice."New value: +"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."Input schema / properties / target_bot_url / descriptionPrevious value: -"Valid HTTPS/HTTP URL of the target AI bot endpoint to audit (e.g. https://agent.mifori.com/v1/demo-agent)."New value: +"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."get_agent_leaderboardsubmit_agent_feedbackverify_agent_reputation
Add one secure layer between your agents and this server.