Deterministic pre-execution audit for trading agents. PASS/WAIT/FAIL, reproducible verdict_hash.
Scored across 4 tools
The four tools split cleanly along two axes: read-only history lookups (query_agent_trust vs query_pol_certificates) and pre-execution audits (verify_perp_trade vs verify_pm_trade). Descriptions include explicit negative routing rules ('DO NOT use for on-chain trust scores — use query_agent_trust', 'use verify_pm_trade' for prediction markets), leaving no realistic misselection path.
All names follow a strict verb_noun pattern (query_*/verify_*), and the pairing is parallel: query_agent_trust/query_pol_certificates and verify_perp_trade/verify_pm_trade. The only nit is the 'perp' vs 'pm' abbreviation asymmetry, which is readable and domain-standard.
Four tools is on the lean side, but each maps to a genuinely distinct capability (trust lookup, certificate retrieval, perp/spot audit, prediction-market audit) with no filler. Slightly thin if a caller wants richer subgraph access, but nothing feels unearned.
The read side (scores, certificates, verdict history) and the write side (deterministic theses audits for two asset classes) are both covered, with clear outcomes PASS/WAIT/FAIL and reproducible hashes. Minor gaps: no way to enumerate agents or certificates by owner/project, and no reporting or dispute path if a verdict is contested.
Query an agent's DJZS trust score, aggregated on-chain (Base mainnet) from its audit history and indexed via the DJZS subgraph. USE BEFORE delegating work, releasing escrow, or executing agent transactions. Returns scored_audits, pass/fail counts, the raw fail rate, and a Wilson 95% lower bound on it, plus latest verdict/risk and DJZS-S01/DJZS-X01 flag counts. WAIT verdicts are abstentions: they are excluded from BOTH the numerator and the denominator of the fail rate and are reported separately as wait_count. Below 10 scored audits the tool returns INSUFFICIENT_HISTORY and NO rate - a 0-of-0 record is not evidence of reliability and must not compare as better than a 3-of-50. This tool returns evidence, not a decision: it applies no threshold and emits no HALT. Interpreting the bound against your own risk tolerance is the caller's job.
| Name | Required | Description | Default |
|---|---|---|---|
| agentAddress | Yes | Agent wallet address (0x-prefixed) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and succeeds: it discloses the return payload (scored_audits, pass/fail counts, fail rate, Wilson lower bound, verdicts, flag counts), the special WAIT abstention handling, the INSUFFICIENT_HISTORY behavior below 10 audits, and the important fact that it emits evidence rather than a HALT decision.
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?
Dense but front-loaded, leading with what it is before the usage directive and the return/edge-case details. Every sentence adds real information, though it is longer than strictly necessary for a one-parameter read tool.
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?
No output schema exists, so the description must explain the return shape and edge cases – and it does so thoroughly, including the abstention semantics and the insufficient-history boundary. Nothing needed to call or interpret the result 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 coverage is 100% and the single agentAddress parameter is fully documented with a 0x pattern in the schema, so the description adds no parameter-level meaning. Baseline 3 applies when the schema does the heavy lifting.
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?
Names a specific verb (query) and resource (an agent's DJZS trust score), plus its data provenance (on-chain Base mainnet, DJZS subgraph). It is clearly distinguishable from siblings like verify_perp_trade or query_pol_certificates without opening a 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 triggering conditions: 'USE BEFORE delegating work, releasing escrow, or executing agent transactions.' It does not name alternatives or state when the sibling tools should be preferred instead, so it stops short of a full routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query immutable ProofOfLogic certificates stored on Irys Datachain by DJZS Protocol. USE THIS TOOL when you need to verify audit history for an agent or project before delegating work, check FAIL verdicts, or retrieve certificates by Irys tx ID. DO NOT use for on-chain trust scores — use query_agent_trust for those.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Filter by tier | |
| limit | No | Number of results | |
| to_ms | No | Window end (epoch ms). Defaults to now + 1h. | |
| from_ms | No | Window start (epoch ms). Default path auto-narrows (14d then 3d) to stay under the mainnet index timeout; pass an explicit value to reach older certificates (used as-is). | |
| verdict | No | Filter by verdict | |
| targetSystem | No | Project name or wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states certificates are 'immutable' but does not clarify read-only nature, side effects, or performance constraints. The schema mentions index timeouts for from_ms but this is not in the description.
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?
The description is two efficient sentences. The first sentence states the core action, the second provides usage guidelines. Every word adds value, and the structure is front-loaded with the most critical 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?
Given 6 parameters, no output schema, and no annotations, the description covers high-level purpose and usage but lacks details about return values, pagination, or the complex from_ms behavior. It is minimally complete for an agent familiar with the domain but could be improved.
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%, so baseline is 3. The description adds no extra meaning beyond the schema; it only restates the general purpose. The from_ms auto-narrowing behavior described in the schema is not mentioned in the description.
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?
The description clearly states the tool queries immutable ProofOfLogic certificates on Irys Datachain. It explicitly distinguishes from sibling tool query_agent_trust by indicating use cases for audit history and FAIL verdicts, and what not to use it for.
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?
The description provides explicit when-to-use instructions (verify audit history, check FAIL verdicts, retrieve by Irys tx ID) and when-not-to-use (on-chain trust scores), with a named alternative (query_agent_trust). This leaves no ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deterministic pre-execution audit of a perpetual or spot TRADE thesis (direction, size, leverage, entry, stop, target, venue, and the REASON), run before capital is committed. USE THIS TOOL before opening, sizing, or increasing any perpetual or spot position. Returns PASS / WAIT / FAIL with a reproducible verdict hash. A position stated with no thesis FAILS (DJZS-S01); an unbounded position FAILS (DJZS-X01); an unresolvable stop or thesis WAITs. Prediction-market bets are refused here (use verify_pm_trade) and are not charged. Price 2.00 USDC per audit on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | Free-text perpetual or spot trade thesis to audit: direction, size, leverage, entry, stop, target, venue, and the REASON | |
| bracket | No | Optional exact bracket (side, entry, stop, target, taker_fee_bps, optional hit_rate_pct / funding_rate_8h / sigma_annual). Returns the break-even hit rate in the non-scoring mechanics block; never enters the verdict or its hash | |
| agent_address | No | Optional agent wallet (0x). If set, this audit updates that agent's on-chain DJZS trust score | |
| target_system | No | Optional agent/project identifier. Written to the certificate ONLY with a matching target_system_subject + target_system_signature; unsigned values are DISCARDED, not stored | |
| target_system_subject | No | Address that signed the target_system claim. Must be the address that recovers from target_system_signature | |
| target_system_signature | No | EIP-191 personal_sign over "DJZS-TSC-1 target-system claim\nsubject: <lowercased subject>\ntarget_system: <value>" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only a title annotation, the description carries the burden and does well: it discloses the three possible verdicts (PASS/WAIT/FAIL), a reproducible verdict hash, the specific fail/wait rules (DJZS-S01, DJZS-X01, unresolvable stop), and the 2.00 USDC Base charge. It does not cover latency, idempotency, or what happens if payment fails, which keeps it short of a 5.
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?
The trigger ('USE THIS TOOL before...') is front-loaded right after the one-line purpose, followed by outcomes, failure rules, the sibling exclusion, and price. Every sentence carries distinct information with no repetition of the title or schema.
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?
There is no output schema, yet the description names the return shape (PASS/WAIT/FAIL plus verdict hash) and the failure semantics, and it covers the cost and the excluded asset class. For a nested-schema audit tool this is sufficient for an agent to call it correctly.
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%, so the schema already documents intent, bracket sub-fields, agent_address, and the target-system signing trio in detail. The description adds no per-parameter meaning beyond restating the thesis fields, so the baseline 3 is the right call.
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 ('Deterministic pre-execution audit of a perpetual or spot TRADE thesis') and enumerates the audited dimensions (direction, size, leverage, entry, stop, target, venue, reason). It explicitly carves out prediction-market bets and routes them to the sibling verify_pm_trade, so an agent can separate it from that tool without opening either 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?
'USE THIS TOOL before opening, sizing, or increasing any perpetual or spot position' gives an explicit trigger condition, and the sentence about prediction-market bets being refused here with a pointer to verify_pm_trade gives the exclusion plus the alternative. Nothing about when to select this tool is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deterministic pre-execution audit of a prediction-market trade thesis, run before capital is committed. USE THIS TOOL before opening, sizing, or increasing any prediction-market position, and whenever a user or an upstream agent asks whether a thesis is sound, carries a falsification condition, or has a sourced probability basis. Audits against the calibrated DJZS-M taxonomy (M01 narrative/resolution gap, M02 falsification absent, M03 probability unsourced, M04 consensus-as-edge advisory) and returns PASS->PROCEED, WAIT->HALT, or FAIL with the flagged defects and a reproducible verdict_hash. DO NOT use to retrieve past verdicts or certificates - use query_pol_certificates for those. DO NOT use for an agent's historical trust score - use query_agent_trust for that. DO NOT use for spot, perpetuals, or equities: out-of-scope submissions are refused WITHOUT CHARGE. Audit before act. Paid tool: 2 USDC per audit via x402 on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | Free-text prediction-market trade thesis to audit | |
| agent_address | No | Optional agent wallet (0x). If set, this audit updates that agent's on-chain DJZS trust score | |
| target_system | No | Optional agent/project identifier. Written to the certificate ONLY with a matching target_system_subject + target_system_signature; unsigned values are DISCARDED, not stored | |
| target_system_subject | No | Address that signed the target_system claim. Must be the address that recovers from target_system_signature | |
| target_system_signature | No | EIP-191 personal_sign over "DJZS-TSC-1 target-system claim\nsubject: <lowercased subject>\ntarget_system: <value>" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only a title annotation, the description carries the full burden and does so richly: deterministic audit, mapping of PASS/WAIT/FAIL to PROCEED/HALT, side effect of updating an on-chain trust score, reproducibility via verdict_hash, and a pricing/charge policy (2 USDC via x402, out-of-scope refused without charge). These are exactly the traits annotations do not provide.
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 purpose before the usage directives, and every clause carries information (alternatives, scope exclusions, price, outcomes). It is dense and slightly long with repeated DO NOT framing and the 'Audit before act' tagline, but nothing is filler.
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?
Despite having no output schema, the description explains the return contract (verdict, flagged defects, verdict_hash) and the failure modes, and it covers cost, scope, and side effects. An agent has everything needed to decide and call correctly.
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%, so the schema already documents all five parameters including the signature format and the conditional storage rule for target_system. The description adds no parameter-level syntax or format detail, 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 specific verb (verify/audit), a specific resource (prediction-market trade thesis), and its timing constraint (pre-execution, before capital is committed). It also names the taxonomy used and the three verdict outcomes, so an agent can distinguish it from siblings without opening a 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?
Explicit 'USE THIS TOOL before opening, sizing, or increasing any position' plus three named alternatives with their own triggers (query_pol_certificates for past verdicts, query_agent_trust for trust scores) and an explicit out-of-scope exclusion (spot/perp/equities). This is the full when/when-not/alternatives pattern.
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.
verify_perp_trade1 field changedInput schema / properties / bracketAdded value: +{
+ "description": "Optional exact bracket (side, entry, stop, target, taker_fee_bps, optional hit_rate_pct / funding_rate_8h / sigma_annual). Returns the break-even hit rate in the non-scoring mechanics block; never enters the verdict or its hash",
+ "properties": {
+ "entry": {
+ "exclusiveMinimum": 0,
+ "type": "number"
+ },
+ "funding_rate_8h": {
+ "description": "Funding rate per 8 hours as a fraction (0.0001 = 0.01%); longs pay a positive rate. Counted only with sigma_annual",
+ "maximum": 0.05,
+ "minimum": -0.05,
+ "type": "number"
+ },
+ "hit_rate_pct": {
+ "description": "The thesis's stated probability, in percent, that the target prints before the stop",
+ "maximum": 99,
+ "minimum": 1,
+ "type": "number"
+ },
+ "side": {
+ "enum": [
+ "long",
+ "short"
+ ],
+ "type": "string"
+ },
+ "sigma_annual": {
+ "description": "Annualized volatility as a fraction (0.45 = 45%); sets the expected hold, and so the funding paid",
+ "exclusiveMinimum": 0,
+ "maximum": 10,
+ "type": "number"
+ },
+ "stop": {
+ "exclusiveMinimum": 0,
+ "type": "number"
+ },
+ "taker_fee_bps": {
+ "description": "The venue's taker fee in basis points, charged on entry and on exit",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ },
+ "target": {
+ "exclusiveMinimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "side",
+ "entry",
+ "stop",
+ "target",
+ "taker_fee_bps"
+ ],
+ "type": "object"
+}verify_perp_trade3 fields changedInput schema / properties / target_system / descriptionPrevious value: -"Optional agent/project identifier; becomes the Target-System tag on the anchored PoL certificate"New value: +"Optional agent/project identifier. Written to the certificate ONLY with a matching target_system_subject + target_system_signature; unsigned values are DISCARDED, not stored"Input schema / properties / target_system_signatureAdded value: +{
+ "description": "EIP-191 personal_sign over \"DJZS-TSC-1 target-system claim\\nsubject: <lowercased subject>\\ntarget_system: <value>\"",
+ "pattern": "^0x[0-9a-fA-F]{130}$",
+ "type": "string"
+}Input schema / properties / target_system_subjectAdded value: +{
+ "description": "Address that signed the target_system claim. Must be the address that recovers from target_system_signature",
+ "pattern": "^0x[0-9a-fA-F]{40}$",
+ "type": "string"
+}verify_pm_trade3 fields changedInput schema / properties / target_system / descriptionPrevious value: -"Optional agent/project identifier; becomes the Target-System tag on the anchored PoL certificate"New value: +"Optional agent/project identifier. Written to the certificate ONLY with a matching target_system_subject + target_system_signature; unsigned values are DISCARDED, not stored"Input schema / properties / target_system_signatureAdded value: +{
+ "description": "EIP-191 personal_sign over \"DJZS-TSC-1 target-system claim\\nsubject: <lowercased subject>\\ntarget_system: <value>\"",
+ "pattern": "^0x[0-9a-fA-F]{130}$",
+ "type": "string"
+}Input schema / properties / target_system_subjectAdded value: +{
+ "description": "Address that signed the target_system claim. Must be the address that recovers from target_system_signature",
+ "pattern": "^0x[0-9a-fA-F]{40}$",
+ "type": "string"
+}verify_perp_tradequery_agent_trustquery_pol_certificatesverify_pm_tradePre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Deterministic decision layer for autonomous agents: reproducible PROCEED/REVIEW/SKIP verdicts.
Deterministic pre-trade risk checks for AI agents on Robinhood Chain. Returns allow/warn/deny.
Deterministic decision guardrail for AI agents and bots. Verifies pre-trade economics (long-only).
Add one secure layer between your agents and this server.
