Skip to main content
Glama
Sign In

Mifori CertAgent

by com.mifori.agent
OverviewDiscussionsAdmin

Submit Telemetry or Request Free Sandbox Audit Credit

submit_agent_feedback
Idempotent

Persists machine-to-machine telemetry, score disputes, or initial sandbox credit requests in <100ms with no authentication or payment required, immediately granting 1 free single-use audit credit token ('mfr_fbk_...'). First-time evaluators without a prior audit or dispute can pass eval_id='sandbox' (or 'onboarding') and describe their intended evaluation in reported_issue to receive a legitimate free reward_token for verify_agent_reputation without fabricating a complaint.

Input Schema

NameRequiredDescriptionDefault
eval_idYesPass 'sandbox' (or 'onboarding') to request a free initial evaluation credit token, or pass the UUID of an existing certificate from verify_agent_reputation / get_agent_leaderboard to report runtime telemetry. Must be non-empty.
reported_issueYesNon-empty description of your evaluation use case (when eval_id='sandbox') or technical telemetry/anomaly observation for an existing eval_id.
suggested_metricNoOptional key-value map of observed telemetry metrics or benchmark metadata (e.g. {'observed_latency_ms': 140, 'expected_iq': 96}).

Output Schema

NameRequiredDescriptionDefault
statusYesSubmission status ('ACCEPTED' or 'ERROR').
eval_idYesReferenced evaluation UUID or 'sandbox'.
messageNoHuman and machine readable confirmation message.
timestampNoISO-8601 UTC timestamp of telemetry registration.
feedback_idYesUnique identifier (UUID) for the recorded telemetry entry.
reward_tokenNoSingle-use credit token ('mfr_fbk_...') accepted as payment_proof in verify_agent_reputation.
reward_statusYesStatus of the 1 free audit credit reward.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / eval_id / description
      Previous value: -"UUID or certificate identifier from a prior verify_agent_reputation, get_agent_certificate, or get_agent_leaderboard response (e.g. 'cab449d2-9072-415d-a8fd-d3a51bd3d87d'). Must be non-empty."New value: +"Pass 'sandbox' (or 'onboarding') to request a free initial evaluation credit token, or pass the UUID of an existing certificate from verify_agent_reputation / get_agent_leaderboard to report runtime telemetry. Must be non-empty."
    • changedInput schema / properties / reported_issue / description
      Previous 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')."New value: +"Non-empty description of your evaluation use case (when eval_id='sandbox') or technical telemetry/anomaly observation for an existing eval_id."
    • changedInput schema / properties / suggested_metric / description
      Previous value: -"Optional key-value map of observed telemetry metrics or proposed benchmark corrections (e.g. {'observed_latency_ms': 140, 'expected_iq': 96})."New value: +"Optional key-value map of observed telemetry metrics or benchmark metadata (e.g. {'observed_latency_ms': 140, 'expected_iq': 96})."
    • changedOutput schema / description
      Previous value: -"Confirmation receipt and reward credit status for submitted telemetry."New value: +"Confirmation receipt and single-use reward_token for verify_agent_reputation."
    • changedOutput schema / properties / eval_id / description
      Previous value: -"Referenced evaluation UUID."New value: +"Referenced evaluation UUID or 'sandbox'."
    • changedOutput schema / properties / feedback_id / description
      Previous value: -"Unique identifier (UUID) for the recorded feedback entry."New value: +"Unique identifier (UUID) for the recorded telemetry entry."
  2. Changed1 schema field changed
    • changedInput schema / properties / eval_id / description
      Previous 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."New value: +"UUID or certificate identifier from a prior verify_agent_reputation, get_agent_certificate, or get_agent_leaderboard response (e.g. 'cab449d2-9072-415d-a8fd-d3a51bd3d87d'). Must be non-empty."
  3. Changed1 schema field changed
    • addedOutput schema / properties / reward_token
      Added value: +{
+  "description": "Single-use credit token ('mfr_fbk_...') accepted as payment_proof in verify_agent_reputation.",
+  "type": "string"
+}
  4. Changed3 schema fields changed
    • 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})."
  5. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-schema context: sub-100ms persistence, no authentication or payment required, and that a single-use reward token is returned for verify_agent_reputation. It does not, however, address the idempotency hint's implications (e.g. whether repeat calls re-issue tokens).

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?

Two front-loaded sentences that lead with the action, the performance/auth characteristics, and the reward, then cover the sandbox usage pattern. Dense but every clause carries operational information; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values needn't be explained, and the description supplies the auth, latency, and token-grant behavior an agent needs before calling. The only mild gap is the unaddressed idempotentHint interaction with the single-use token claim.

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 goes beyond the schema by explaining the intent behind eval_id='sandbox'/'onboarding' and tying reported_issue to the described use case, which helps the agent pick the right argument values rather than just their types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and set of resources: persisting telemetry, score disputes, and sandbox credit requests, plus the concrete side effect (granting a 'mfr_fbk_...' token). It references verify_agent_reputation as the consumer of the token but never explicitly contrasts itself with the read-only siblings, so it stops short of full sibling differentiation.

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

Usage Guidelines4/5

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

Gives a clear condition for the sandbox path: 'First-time evaluators without a prior audit or dispute can pass eval_id=sandbox', and frames the alternative as fabricating a complaint. It covers the two main modes (telemetry reporting vs. initial credit request), though it doesn't state when *not* to call it or how it relates to get_agent_certificate/get_agent_leaderboard.

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

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