Deterministic pre-execution audit for trading agents. PASS/WAIT/FAIL, reproducible verdict_hash.
Scored across 4 tools
The four tools split cleanly into two query tools (on-chain trust scores vs. Irys certificates) and two verify tools (perpetuals/spot vs. prediction markets). Descriptions explicitly cross-reference each other to steer selection, e.g. 'Prediction-market bets are refused here (use verify_pm_trade)' and 'DO NOT use for on-chain trust scores — use query_agent_trust.' Boundaries are unmistakable.
All names follow a consistent snake_case verb_noun pattern: query_agent_trust, query_pol_certificates, verify_perp_trade, verify_pm_trade. The two verb families (query_/verify_) align logically with the two tool types, and abbreviations (pol, pm, perp) are used consistently.
Four tools is well within the ideal range and none overlap. Each earns its place: two distinct data-retrieval surfaces plus two market-specific audit surfaces.
The audit/verify lifecycle is well covered for both perps/spot and prediction markets, with both on-chain scores and immutable certificates retrievable. There is no obvious way to list or browse past verdicts beyond certificate lookup by tx ID, a minor gap an agent can work around.
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 | |
| 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?
Annotations carry only a title, so the description bears the full burden and delivers: deterministic/reproducible verdict hash, the three outcome states (PASS/WAIT/FAIL), concrete failure codes (DJZS-S01, DJZS-X01), refund/charge behavior for refusals, and the 2.00 USDC price on Base. Only the on-chain trust-score side effect of agent_address is left to the schema, which is a minor residual.
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?
Five tight sentences with the purpose front-loaded, then usage, then return semantics, then refusal routing, then price. No filler, and each sentence carries information an agent needs before calling.
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?
With no output schema, the description correctly explains the return contract (PASS/WAIT/FAIL plus verdict hash) and the cost/refusal model. It is slightly short on the optional three-parameter signed target_system certificate flow, which is the most intricate part of the schema and gets no mention in the description.
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 signed target_system claim flow and the agent_address trust-score effect. The description repeats the intent components but adds no syntax, format, or edge-case guidance 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 specific verb (deterministic pre-execution audit) on a specific resource (perpetual/spot trade thesis) and enumerates the thesis components it consumes. It explicitly names the sibling it is not (prediction-market bets go to verify_pm_trade), so an agent can distinguish it 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 an imperative when-to-use rule ('USE THIS TOOL before opening, sizing, or increasing any perpetual or spot position'), an explicit exclusion (prediction-market bets are refused here), and names the alternative tool for that case. Both the trigger and the boundary are stated, not implied.
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_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 AI code review, with an audit record. Governance inside the agent loop.
Deterministic pre-trade risk checks for autonomous AI trading agents.
Add one secure layer between your agents and this server.
