jorkal-nft-mcp

Official

Overview Schema Source Related Servers Discussions Admin

wallet_activity

Retrieve recent NFT transaction history for a Solana wallet, including buys, sells, bids, and listings with prices and timestamps.

Instructions

Get recent NFT transaction history for a Solana wallet — buys, sells, bids, and listings with prices, collections, and timestamps.

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": {
      "address": "<address>"
    },
    "name": "wallet_activity"
  }
}

Input Schema

Name	Required	Description
`address`	Yes	Solana wallet address (base58)
`limit`	No	Number of activity events to return (1–50, default 20)
`offset`	No	Pagination offset (default 0)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0May 27, 2026

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so description bears full burden. It mentions transaction types and data fields but omits behavioral details like default ordering (presumably reverse chronological), pagination behavior, rate limits, authentication requirements, or what occurs for wallets with no activity.

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?

Single sentence efficiently conveys purpose and included data. Could be slightly improved with structured breakdown (e.g., bullet points for transaction types) but no wasted words.

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

Completeness2/5

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

Given 3 parameters and no output schema, description lacks critical context: data ordering, whether all transaction types are guaranteed to appear, timestamp format, and handling of edge cases. An agent would need to infer response structure from the description alone.

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% (address, limit, offset fully described). Description adds minimal value beyond schema, listing broad data categories but not linking them to parameters or providing extra constraints like default limit value (20) which is already in schema.

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?

Description clearly specifies the tool retrieves recent NFT transaction history for a Solana wallet, listing specific transaction types (buys, sells, bids, listings) and included data (prices, collections, timestamps). It distinguishes from siblings like wallet_nfts (owned NFTs) and nft_activity (likely per-NFT activity).

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

Usage Guidelines3/5

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

Implied usage for retrieving recent wallet transaction history, but no explicit guidance on when to use this vs. sibling tools like nft_activity, nor exclusions for cases like empty history or specific time ranges.

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

Deploy Server