Skip to main content
Glama
bolesk

crypto-transactions-mcp

by bolesk

log_transaction

Record crypto trades and swaps with a single log entry, supporting upsert for updates and optional fiat value for accurate P&L tracking.

Instructions

Registra un trade (BUY/SELL, incluso uno swap tra due crypto), upsert per id.

    Trade normale (es. BTC/USDT): symbol è la coppia BASE/QUOTE,
    side=BUY se acquisti il base, side=SELL se lo cedi; price è il
    prezzo unitario del base in quote.

    Swap crypto/crypto (es. scambio ETH -> BTC su un DEX o un exchange):
    si usa questo stesso tool, non ce n'è uno dedicato. Metti come base
    l'asset ceduto e come quote quello ricevuto, es. symbol="ETH/BTC",
    side="SELL", amount=1 (ETH ceduti), price=0.05 (BTC ricevuti per
    ETH). Attenzione: in questo caso price ti dice solo il cambio tra
    le due crypto, non il loro controvalore in una valuta fiat — senza
    quel dato non potrai più calcolare a posteriori né il P&L realizzato
    sull'asset ceduto né il cost-basis fiat del nuovo asset ricevuto.
    Per questo, quando disponibile, valorizza sempre fiat_value (il
    controvalore totale dello scambio, es. in EUR al momento
    dell'esecuzione) e fiat_currency: è fortemente consigliato per gli
    swap crypto/crypto, utile anche per i trade con quote fiat/stablecoin.

    Se `id` è omesso viene generata una nuova transazione con un id
    generato automaticamente. Se `id` corrisponde a una transazione già
    salvata, solo i campi passati vengono aggiornati (merge parziale);
    `value` viene ricalcolato come amount * price se non fornito
    esplicitamente e uno tra amount/price cambia. Per una nuova
    transazione sono richiesti tutti i campi obbligatori dello schema
    (exchange, symbol, side, timestamp, amount, price, fee_amount,
    fee_asset). `tx_hash` è opzionale, usalo per l'hash on-chain quando
    disponibile (tipico per gli swap su DEX).

    Per spostare lo stesso asset tra due exchange/wallet, senza
    scambiarlo con un altro asset, usa invece il tool log_transfer.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
sideNo
notesNo
priceNo
valueNo
amountNo
symbolNo
tx_hashNo
exchangeNo
fee_assetNo
timestampNo
fee_amountNo
fiat_valueNo
fiat_currencyNo
Behavior5/5

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

Discloses key behavioral traits: upsert behavior (merge partial update when id matches), auto-generation of id for new transactions, recalculation of value based on amount*price, required fields for new transactions, and the optional use of tx_hash. No annotations are provided, so the description fully compensates.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but well-structured with paragraphs separating normal trades, swaps, upsert behavior, and required fields. It is front-loaded with the main purpose. However, some content could be condensed, making it less concise than optimal.

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?

Given the complexity (14 parameters, upsert behavior, swap handling) and the absence of an output schema, the description covers most behavioral aspects thoroughly. It mentions sibling tools for disambiguation. It does not explain the return value of the tool, which is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description explains the meanings of several key parameters (side, symbol, price, amount, fiat_value, fiat_currency, id, tx_hash, value). It does not explicitly cover all 14 parameters (e.g., notes, timestamp, exchange, fee_amount, fee_asset are mentioned as required but not detailed). The coverage is extensive enough to guide an agent, though not exhaustive.

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?

The description clearly defines the tool as recording a trade (BUY/SELL, including swaps) and differentiates it from the sibling log_transfer tool, specifying which tool to use for asset transfers without exchange. The verb 'Registra' and the resource 'trade' are specific and unambiguous.

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?

Provides explicit guidance on when to use this tool vs the sibling log_transfer: 'Per spostare lo stesso asset tra due exchange/wallet, senza scambiarlo con un altro asset, usa invece il tool log_transfer.' Also explains how to handle crypto/crypto swaps, including the recommendation to provide fiat_value and fiat_currency for better P&L calculation.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bolesk/crypto-transactions-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server