Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

opensea_profile_items

Retrieve NFTs held by a wallet, including collection, rarity rank, and best standing listing. Use a wallet address, ENS name, or OpenSea username to get paginated results.

Instructions

List the NFTs a wallet holds. Returns a cursor-paginated page of the NFTs held by a wallet, with each item's collection, rarity rank, and best standing listing. Accepts a wallet address, ENS name, or OpenSea username; a non-address identifier costs one extra resolution lookup.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoItems per page, 1-100
cursorNoOpaque pagination cursor from a previous next_page_cursor
identifierYesWallet address, ENS name, or OpenSea username
sort_directionNoSort direction by received date

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.16.2

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations provided, the description bears the full behavioral disclosure burden. It adds useful details: the tool returns a 'cursor-paginated page' and that a non-address identifier 'costs one extra resolution lookup'. However, it leaves other aspects unattested: no statement about read‑vs‑write nature (it is a listing so presumably read-only), no error handling for unknown/invalid identifiers, no rate‑limit or authentication notes, and no mention of what happens when no NFTs are held.

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?

The description is three sentences and every sentence adds value: the first states the core action, the second reports what a page contains, the third explains input formats and a cost prefix. It is front-loaded with the primary verb ('List'), and there is no fluff. Minor point: the phrase 'auto holds' appears twice in a consistent way, but this is not redundant: the second use clarifies the subject of the returns.

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

Completeness3/5

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

Given the lack of output schema and annotations, the description covers return content by listing item fields, and covers input format and a latency consideration. But it omits several details an agent might need for correct use: how to obtain the next page (the cursor field is only mentioned implicitly in the schema as 'from a previous next_page_cursor'), what the sorting direction parameter allows, and how errors or empty results are reported. It is adequate but not thorough.

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 100%, so the description does not need to repeat parameter definitions; the baseline is 3. The description adds a small extra semantic for the identifier parameter by noting the resolution lookup cost, but it provides no additional meaning for limit, cursor, or sort_direction, and it does not clarify the allowed values for sort_direction (which the schema also leaves open). Thus the description gives modest added value beyond the structured 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?

The description opens with 'List the NFTs a wallet holds', which names the specific resource (wallet-held NFTs) and verb (list). It also clarifies the returned per-item data (collection, rarity rank, best standing listing), and it sets the tool apart from related OpenSea siblings like opensea_collection_items, though it does not explicitly name any sibling or state what the tool is not.

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

Usage Guidelines2/5

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

The description gives no direct guidance on when to select this tool over alternatives such as opensea_collection_items, opensea_profile, or opensea_item. It does state the accepted identifier formats and mentions the cost of non-address identifiers, but this is not a comparison with other tools or an exclusion – it only explains input behavior. There is no 'if you need X, use this, else use Y' guidance.

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