Skip to main content
Glama
Sign In
oceanalt-aml-mcp

oceanalt-aml-mcp

by OceanAlt666
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Decode a transaction and compare with declared intent (free)

check_calldata_intent
Read-onlyIdempotent

Decode EVM calldata and Solana transactions, compare them with the intended payment, and flag mismatches or undecodable data as unsafe to sign.

Instructions

Anti blind-signing. EVM: decodes what calldata will actually do (ERC-20 transfer/approve/permit, setApprovalForAll, ownership transfer, native transfer). Solana: decodes a whole base64 transaction (SPL Token / Token-2022 Transfer, TransferChecked, Approve, SetAuthority, CloseAccount, Burn; System Transfer / Assign; ATA creation). Compares it with the payment the agent believes it is making. decision match = does what you declared; mismatch = different recipient/amount/asset, or an approval / authority change instead of a payment — do not sign; unknown = could not decode (including address-lookup-table accounts), which is NOT the same as safe. Free, no API key.

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": "check_calldata_intent"
  }
}

Input Schema

NameRequiredDescriptionDefault
dataNoEVM only: 0x-prefixed hex calldata.
valueNoEVM only: native value in wei.
intentNo
networkNo'solana' to decode a Solana transaction; EVM chain name or CAIP-2 id otherwise.
contractNoEVM only: the transaction's `to` (token contract, or the recipient for native transfers).
transactionNoSolana only: base64-serialized transaction or message.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only cover readOnly/idempotent/openWorld; the description adds substantial context beyond them: that it is free with no API key, what it decodes per chain, the meaning of each decision outcome, and a genuine caveat that address-lookup-table accounts yield 'unknown' rather than a safe verdict. With no output schema, this return-value disclosure is exactly what the description should 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 anti-blind-signing purpose, then structured by chain with parenthetical enumerations. It is dense but nearly every clause carries information a caller needs; the decoded-operation lists are the only slightly padded part.

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 heavy lifting on return semantics and unknown-handling, and it labels chain-specific parameters. It stops short of stating which parameter combinations are required (0 are marked required) or what happens on undecodable/malformed input beyond the lookup-table case.

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 83%, so the schema already documents parallel EVM-only vs Solana-only fields, the base-units convention for amount, and network semantics. The description echoes the chain split ('EVM: ...', 'Solana: ...') but adds no format or validation detail beyond what the schema provides. Baseline 3 for high coverage is appropriate.

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?

Opens with a precise framing ('Anti blind-signing') then states the exact verb and resource: decode calldata / a base64 Solana transaction and compare against declared intent. It enumerates the specific decoded operations (ERC-20 transfer/approve/permit, setApprovalForAll, SPL TransferChecked, SetAuthority, etc.), which clearly separates it from siblings like verify_payment_requirements or payment_decision.

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?

Gives a clear decision rule tied to the tool's use: match = proceed, mismatch = 'do not sign', unknown = not the same as safe. This tells an agent how to act on the result. It does not, however, explicitly contrast when to reach for this versus siblings such as verify_payment_requirements or payment_decision.

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

Deploy Server

Other Tools