Skip to main content
Glama
Sign In

Magneta Contract Risk

by io.github.Bosacks
OverviewDiscussionsAdmin

Contract risk summary

contract_risk_summary
Read-onlyIdempotent

Analyze a deployed smart contract and return a deterministic risk report: 0-100 score with level (low/medium/high/critical), proxy/upgradeability, owner and pause state, risky selectors found in the bytecode (mint, blacklist, fee/tax setters, pause, upgrade), SELFDESTRUCT/DELEGATECALL opcodes, source verification (Blockscout, Sourcify) and aderyn static-analysis findings. Use it before trading, bridging, approving or integrating a token or protocol contract; Use contract_quick_flags first for a free bytecode-only preview when you are not sure the full report is worth paying for. Use supported_chains first if you are unsure the chain id is covered, and scoring_rubric to interpret the score. Paid: $0.01 in USDC on Base per call via x402. The first call answers with an x402 payment challenge; an x402-enabled client pays automatically and the same call then returns the report. Read-only, no side effects. Error cases (unsupported chain, invalid address, address is not a contract, upstream data source failure or timeout) return an isError result with an error message and are not charged; identical requests within 10 minutes return the cached report.

Input Schema

NameRequiredDescriptionDefault
addressYesContract address, 0x followed by 40 hex characters (an EOA is rejected without charge)
chainIdYesEVM chain id, one of: 1, 10, 56, 100, 130, 137, 146, 480, 5000, 8453, 42161, 42220, 43114, 59144, 81457, 84532, 421614, 534352, 11155111, 11155420

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / address / description
      Previous value: -"Contract address (0x...)"New value: +"Contract address, 0x followed by 40 hex characters (an EOA is rejected without charge)"
    • changedInput schema / properties / chainId / description
      Previous value: -"EVM chain id"New value: +"EVM chain id, one of: 1, 10, 56, 100, 130, 137, 146, 480, 5000, 8453, 42161, 42220, 43114, 59144, 81457, 84532, 421614, 534352, 11155111, 11155420"
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the read-only/idempotent profile, and the description goes far beyond them with pricing ($0.01 USDC on Base via x402), the payment-challenge flow, a 10-minute cache on identical requests, and an explicit no-charge policy for error cases. This is exactly the extra context annotations cannot express.

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-loads the report contents before usage and payment mechanics, and every sentence carries information. It is dense and runs long, but the length is justified by the payment flow and error/caching details rather than padding.

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?

With no output schema, the description fully specifies return shape, payment handshake, caching, and error behavior for a complex paid analysis tool. An agent has everything needed to decide and invoke correctly.

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 address format and the full chainId enumeration are already documented in the schema. The description adds no syntax or format detail beyond it, so the baseline 3 applies.

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 (analyze) and resource (deployed smart contract) and enumerates exactly what the report contains: score/level, proxy state, owner/pause, risky selectors, opcodes, verification sources, and static analysis. It explicitly distinguishes itself from siblings contract_quick_flags, scoring_rubric, and supported_chains.

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

Usage Guidelines5/5

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

Gives concrete when-to-use triggers (before trading, bridging, approving, integrating) and names two alternatives with the exact conditions that select them: contract_quick_flags for a free preview, supported_chains if the chain is uncertain, scoring_rubric to interpret the score.

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

All Magneta Contract Risk toolsInspect
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