DevX Agent Hub

Solidity smart-contract pre-audit (automated)

smart_contract_pre_audit

Read-onlyIdempotent

Automated Solidity smart-contract pre-audit / security scan: send source (one file or a multi-file project) or a verified contract address + chain (Sourcify, proxies followed) and get a severity-ranked report: reentrancy, access control, unchecked calls, tx.origin, delegatecall, selfdestruct, integer issues, approvals, oracle and signature flaws, plus owner rug powers (mint, pause, blacklist, fees, withdraw) and honeypot patterns. Triage before a human audit, not a replacement. $99 USDC on Base via x402; invalid input and failed runs are not charged. Most x402 clients cap one payment at $0.10 by default; raise the cap for this tool. Price: $99 per run. First call returns the x402 PaymentRequired (no charge); retry with payment in _meta["x402/payment"].

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "smart_contract_pre_audit"
  }
}

Input Schema

Name	Required	Description
`chain`	No	Chain for address mode (default base), e.g. base, ethereum, arbitrum, optimism, polygon, bsc, or a numeric chain id
`source`	No	Solidity source of one (flattened) file. Use this OR sources OR address.
`address`	No	Verified (Sourcify) contract address
`sources`	No	Multi-file project {"contracts/Vault.sol": "..."} (max 60 files, 250 KB total)
`requestKey`	No	Optional idempotency key: same payer + requestKey + input returns the stored result without a second charge (7 days).
`x402_payment`	No	Optional. Base64 x402 v2 PaymentPayload, for clients that cannot set params._meta["x402/payment"]. Omit on the first call to get the exact price.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 25, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Goes well beyond readOnlyHint/idempotentHint: discloses the $99 USDC-on-Base price, the double-charge protection (invalid input and failed runs are not charged), the 7-day stored-result idempotency window keyed on payer + requestKey, the client-side $0.10 payment cap pitfall, and that address mode only works for Sourcify-verified contracts with proxies followed. That is exactly the operational context annotations cannot carry.

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 capability and report contents before the payment mechanics, which is the right order. It wastes some space repeating the price twice ('$99 USDC on Base via x402' and 'Price: $99 per run') in one dense block.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does the work of describing the return value by enumerating the severity-ranked report categories and rug/honeypot detection. It doesn't describe the report's structure or size, and says nothing about latency or rate limits for what is implicitly a long-running scan.

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 parameter meaning is already documented in structured fields. The description reinforces the source/sources/address mutual exclusivity and adds that address mode needs a Sourcify-verified contract with proxies followed, but adds no format details for chain, requestKey, or the limit caps already 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?

States a specific verb+resource (automated Solidity smart-contract pre-audit / security scan) and enumerates exactly what the report covers, so an agent can tell it apart from token-level siblings like token_safety_check or erc20_token_quick_scan. It never explicitly names a sibling, in particular smart_contract_pre_audit_demo, so full differentiation is left to inference.

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?

Clear about the three input modes ('Use this OR sources OR address', with address requiring chain) and explicitly frames the tool as 'Triage before a human audit, not a replacement,' which is real when-not guidance. It also spells out the x402 call flow (first call returns PaymentRequired, retry with payment) and the idempotency path. It stops short of routing to alternative sibling tools for cheaper/quick scans.

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

All DevX Agent Hub 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?