web3-agent

deep_semantic_audit

Read-only

Audit proposal claims against target contract bytecode and calldata using LLM evaluation and risk scoring to approve, flag for review, or reject transactions.

Instructions

Stage 2 Paid ($0.05 USDC via x402 on Base Mainnet) hybrid audit combining Stage 1 on-chain gatekeeping with Stage 2 Gemini LLM evaluation to verify proposal_description claims against target_address bytecode and calldata under policy_prompt. Non-idempotent due to LLM evaluation and single-use EIP-3009 x402_payment_header nonce; omitting x402_payment_header safely returns an HTTP 402 payment challenge without charging. Breaching risk_threshold (0.0-10.0) escalates decision to REJECT. Returns JSON with status, decision (APPROVE, MANUAL_REVIEW, REJECT), risk_score, reasoning, and flagged_issues.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "target_address": "<target_address>",
      "proposal_description": "<proposal_description>"
    },
    "name": "deep_semantic_audit"
  }
}

Input Schema

Name	Required	Description	Default
`calldata`	No	Transaction hex calldata or function selector being executed	0x
`chain_id`	No	EVM Chain ID (default: 8453 for Base Mainnet)
`policy_prompt`	No	Security policy or governance criteria to audit against	Audit contract and proposal for unauthorized privilege escalation, proxy upgrades, honeypot traps, or treasury drainage.
`risk_threshold`	No	Risk score threshold (0.0 to 10.0) above which the audit triggers rejection or alert
`target_address`	Yes	Hex EVM address of smart contract under evaluation
`x402_payment_header`	No	Optional Base64-encoded EIP-3009 transferWithAuthorization payment header satisfying $0.05 USDC requirement
`proposal_description`	Yes	Natural language claim or governance proposal description explaining the intent of the transaction

Output Schema

Name	Required	Description	Default
`tool`	Yes
`stage`	Yes
`status`	Yes
`decision`	No
`reasoning`	No
`risk_score`	No
`llm_invoked`	No
`status_code`	No
`flagged_issues`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.1Nov 11, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "decision": {
+      "type": "string"
+    },
+    "flagged_issues": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "llm_invoked": {
+      "type": "boolean"
+    },
+    "reasoning": {
+      "type": "string"
+    },
+    "risk_score": {
+      "type": "number"
+    },
+    "stage": {
+      "type": "integer"
+    },
+    "status": {
+      "enum": [
+        "completed",
+        "payment_required"
+      ],
+      "type": "string"
+    },
+    "status_code": {
+      "type": "integer"
+    },
+    "tool": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "tool",
+    "stage",
+    "status"
+  ],
+  "type": "object"
+}

First observedv0.1.0Nov 11, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=false, destructiveHint=false, but the description adds substantial context beyond them: the $0.05 USDC x402 cost on Base Mainnet, the reason for non-idempotency (LLM evaluation plus single-use EIP-3009 nonce), and the escalation behavior of risk_threshold. It also states the safe no-charge 402 path, which is exactly the kind of behavior an agent needs before paying.

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-loaded with the core action and scope, then payment behavior, then escalation semantics and return shape. Sentences are dense but each carries distinct information; the enumerated return fields are slightly redundant given the output schema.

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, non-idempotent, open-world tool, the description covers cost, payment mechanism, idempotency risk, threshold behavior, and decision outcomes. With an output schema present, the brief return-value mention is enough, and nothing critical to correct invocation is missing.

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 the baseline is 3. The description adds only marginal meaning beyond the schema — clarifying that breaching risk_threshold escalates to REJECT and that policy_prompt is the audit criteria set — while calldata, chain_id, target_address, and x402_payment_header are already fully documented in the schema.

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?

Names a specific verb+resource: verifies proposal_description claims against target_address bytecode and calldata under policy_prompt using a two-stage (on-chain gatekeeping + Gemini LLM) audit. The 'Stage 2 Paid' framing hints at a cheaper Stage 1 counterpart, but no sibling (check_token_honeypot, scan_contract_selectors, scan_dao_proposals) is named to route the agent explicitly.

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

Usage Guidelines3/5

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

Operational guidance is present: omitting x402_payment_header safely yields an HTTP 402 challenge without charging, which tells an agent how to invoke it safely. However, there is no when-to-use/when-not guidance relative to the deterministic sibling scanners, leaving the choice between a paid LLM audit and cheaper scans implicit.

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

Deploy Server