Skip to main content
Glama
eamwhite1

AgentTrust

by eamwhite1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Audit Task

audit_task

Verify whether completed work meets a task specification using AI.

Instructions

Verify whether completed work meets a task specification using AI.

Call get_fees() first to get the current fee amount and accepted assets. Each fee_hash is single-use (anti-replay protection).

Response shape (always check criteria_failed before deciding how to proceed):

{
  "verdict":         "PASS" | "FAIL",
  "status":          "approved" | "rejected",
  "score":           0-100,
  "summary":         "one-sentence explanation",
  "details":         "full reasoning",
  "criteria_met":    ["criterion A passed", "criterion B passed"],
  "criteria_failed": ["criterion C not met — specific reason"],
  "model_used":      "gemini-2.5-flash"
}

On PASS: proceed to payment or accept the deliverable. On FAIL: read criteria_failed to understand exactly what was missing. Each entry is a specific, actionable failure — not a generic rejection. Use them to tell the worker precisely what to fix before resubmitting.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskYesThe task requirements or specification the worker must meet.
workYesThe work, output, or proof of completion to evaluate against the specification.
fee_hashYesTransaction hash of the fee payment. For XRP: 64-char hex of an XRPL Payment tx. For USDC on Base: 0x-prefixed 66-char EVM tx hash. Each hash is single-use.
task_categoryNoEvaluation rubric. One of: default, creative, code, data, data_analysis, bug_bounty, legal, supply_chain.default
require_consensusNoWhen True, two AI models must independently agree before returning PASS. Recommended for high-stakes tasks.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv3.1.0
    • addedInput schema / properties / fee_hash / title
      Added value: +"XRPL Payment Hash"
    • addedInput schema / properties / task / title
      Added value: +"Task Specification"
    • addedInput schema / properties / work / title
      Added value: +"Completed Work"
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnly=false, idempotent=false, openWorld=true, destructive=false) by disclosing the fee-gating prerequisite, the anti-replay single-use nature of fee_hash (consistent with non-idempotent), and the semantic contract of the verdict/status/criteria_failed fields. This is exactly the behavioral context an agent needs before invoking a paid, non-idempotent operation.

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 purpose and prerequisite before the response block, and the PASS/FAIL handling is actionable. The embedded JSON response shape is largely redundant with the existing output schema, which is the one inefficiency; the rest of the text earns its place.

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 paid, AI-driven, non-idempotent verification tool with a rich output schema, the description supplies everything an agent needs: prerequisite call, anti-replay constraint, and how to interpret PASS vs FAIL. Return values are already covered by the output schema, so no further explanation is required.

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 task, work, fee_hash, task_category, and require_consensus are all already documented in the schema. The description adds no further parameter meaning (it never mentions task_category rubrics or the require_consensus option), so the baseline 3 applies.

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+resource: 'Verify whether completed work meets a task specification using AI.' An agent can tell this is an evaluation/verification tool, distinct from job-listing or payment tools. However, it does not differentiate itself from the closely related sibling evaluate_escrow_work, which appears to serve a similar verification role.

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 an explicit prerequisite ('Call get_fees() first to get the current fee amount and accepted assets') and conditions the workflow on outcomes ('On PASS: proceed to payment...', 'On FAIL: read criteria_failed...'). It stops short of naming when to use this tool versus alternatives such as evaluate_escrow_work, so it lacks true alternative routing.

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

Deploy Server

Other Tools