Mifori CertAgent

Submit Agent Audit Feedback & Telemetry

submit_agent_feedback

Idempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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}).

Output Schema

TableJSON Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

addedOutput schema / properties / reward_token

Added value: +{
+  "description": "Single-use credit token ('mfr_fbk_...') accepted as payment_proof in verify_agent_reputation.",
+  "type": "string"
+}

Changed3 schema fields changedOct 15, 2026

changedInput schema / properties / eval_id / description

Previous 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."

changedInput schema / properties / reported_issue / description

Previous 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')."

changedInput schema / properties / suggested_metric / description

Previous 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})."

First observedOct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Mifori CertAgent 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?