KushBitx AgentProof

KushBitx Preflight

kushbitx_preflight

Read-onlyIdempotent

One check before money moves on Base. Simulates the unsigned transaction, decodes approvals and transfers, screens the token and the recipient or spender, and applies a protected SpendGuard policy when given. Returns ALLOW, REVIEW or BLOCK with sourced findings. Fail-closed: no ALLOW unless every check ran. Does not detect prompt injection; Protected SpendGuard can cap what an agent pays, but does not detect it either. Paid tool: 0.005 USDC per call on Base via x402 (exact scheme). An unpaid call returns the payment requirement and charges nothing. Sign only if verdict is ALLOW, before expiresAt, and the transaction you sign is exactly the one you sent (same transactionDigest, chainId 8453). In code: canSign(report, transaction) from @kushbitx/sdk.

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": {
      "chainId": "<chainId>",
      "to": "<to>"
    },
    "name": "kushbitx_preflight"
  }
}

Input Schema

Name	Required	Description
`to`	Yes	Transaction destination (contract or wallet).
`data`	No	Unsigned calldata.
`from`	No	Wallet that will sign. Required in practice: without it the verdict is REVIEW (sender_unknown), because the transaction cannot be simulated from the signing wallet.
`value`	No	Native ETH value in wei.
`amount`	No	Amount in token units, for the record.
`intent`	No	What the agent means to do.
`policy`	No	Protected SpendGuard policy (send the agent key as Authorization: Bearer). Base USDC transfers only.
`chainId`	Yes	Base mainnet.
`minAmountOut`	No	Swap: smallest acceptable output, in token units (for example 25.5).
`tokenAddress`	No	Token to screen, when it is not the transaction destination (for example the token being bought).
`expectedTokenOut`	No	Swap: token the swap must deliver; 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE for native ETH. For buy_token, tokenAddress is used when this is absent.
`expectedRecipient`	No	Swap: who must receive the output (default: from). ETH or ERC-20 transfer: who must be paid; a different recipient is BLOCK (EXPECTED_RECIPIENT_MISMATCH).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

changedInput schema / properties / expectedRecipient / description

Previous value: -"Swap: who must receive the output. Default: from."New value: +"Swap: who must receive the output (default: from). ETH or ERC-20 transfer: who must be paid; a different recipient is BLOCK (EXPECTED_RECIPIENT_MISMATCH)."

Changed4 schema fields changedOct 31, 2026

addedInput schema / properties / expectedRecipient

Added value: +{
+  "description": "Swap: who must receive the output. Default: from.",
+  "pattern": "^0x[a-fA-F0-9]{40}$",
+  "type": "string"
+}

addedInput schema / properties / expectedTokenOut

Added value: +{
+  "description": "Swap: token the swap must deliver; 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE for native ETH. For buy_token, tokenAddress is used when this is absent.",
+  "pattern": "^0x[a-fA-F0-9]{40}$",
+  "type": "string"
+}

changedInput schema / properties / from / description

Previous value: -"Wallet that will sign; used for simulation."New value: +"Wallet that will sign. Required in practice: without it the verdict is REVIEW (sender_unknown), because the transaction cannot be simulated from the signing wallet."

addedInput schema / properties / minAmountOut

Added value: +{
+  "description": "Swap: smallest acceptable output, in token units (for example 25.5).",
+  "pattern": "^[0-9]+(\\.[0-9]{1,36})?$",
+  "type": "string"
+}

AddedOct 30, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well past the annotations: fail-closed semantics ('no ALLOW unless every check ran'), an explicit limitation ('does not detect prompt injection'), a priced-call model (0.005 USDC via x402, unpaid calls return the payment requirement and charge nothing), verdict expiry via expiresAt, and a staleness guard requiring the same transactionDigest and chainId 8453. It even names a helper (canSign) for programmatic verification. Nothing here contradicts readOnlyHint=true, since it only simulates.

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 one-line summary, then behavior, limits, pricing, and the signing rule in a logical order. Dense but nearly every clause carries information; the prompt-injection sentence is slightly redundant in restating the limitation for SpendGuard, but that repetition is defensible as a safety caveat.

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 12-parameter, nested-object tool with no output schema, the description still supplies the return vocabulary and finding provenance, the payment behavior, the fail-closed rule, and the conditions under which a signature is safe. An agent has enough to call it correctly and to interpret the result without an output schema.

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 coverage is 100%, so every parameter including the nested policy object already carries its own description. The description adds only light framing ('policy when given', chainId 8453, the digest-match rule) and repeats field semantics the schema already covers. 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.

Purpose5/5

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

States a specific verb chain (simulates, decodes, screens, applies policy) against a specific resource (an unsigned transaction on Base) and names the exact output vocabulary (ALLOW / REVIEW / BLOCK). An agent can tell this is the pre-signing screening gate rather than a signer or a token lookup.

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?

Clearly frames when to use it: 'One check before money moves' and 'Sign only if verdict is ALLOW, before expiresAt'. It also implies a relationship to a SpendGuard policy step ('applies a protected SpendGuard policy when given'). It never explicitly routes to a sibling such as quick_check or spendguard_evaluate, so sibling differentiation 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.

All KushBitx AgentProof tools Inspect

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

Need Help?