jorkal-nft-mcp

Official

by jorkal-crypto

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.2.0
Disambiguation5/5
Each tool has a clear, distinct purpose. The six nft_ tools cover different aspects of collection data (activity, floor, listings, stats, individual token), and the three wallet_ tools cover wallet transaction history, holdings, and portfolio valuation, with no overlap.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with a clear domain prefix (nft_ or wallet_) followed by a descriptive noun. This provides predictability and makes it easy for an agent to understand the tool's scope.
Tool Count5/5
With 8 tools, the count is well-scoped for a focused NFT server. Each tool provides essential functionality without unnecessary bloat, covering both collection-level and wallet-level operations.
Completeness4/5
The tool set covers core use cases: collection exploration (activity, floor, listings, stats, token details) and wallet management (activity, holdings, portfolio value). Missing a generalized search tool, but the surface is complete for typical NFT interactions.
Average 3.8/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on June 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals that the tool returns floor price in SOL and lamports, average 24h price, and total volume, which is helpful. However, it does not mention potential error states, rate limits, authentication needs, or whether the data is real-time, leaving gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two clear sentences. The first states the primary action and scope, and the second lists the return fields. There is no extraneous information, and the key details are front-loaded.
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?
The description is adequate for a simple data-retrieval tool with one parameter. It explains what is returned, but it lacks context about when to use this tool over siblings, any prerequisites, or edge cases. Given the tool's simplicity, the information is sufficient but not comprehensive.
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?
The input schema covers the single parameter 'symbol' with a description that includes examples. The tool description does not add further semantic meaning beyond the schema. Since schema description coverage is 100%, the baseline score is 3, and no additional param context is provided.
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 specifies the tool's function: getting floor price and listing count for a Magic Eden Solana NFT collection. It uses a specific verb ('Get') and resource ('NFT collection'), and the output details (floor price in SOL/lamports, average 24h price, total volume) distinguish it from sibling tools like nft_stats or nft_listings.
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?
The description implies usage when a user needs floor price and listing count data, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., nft_listings for individual listings, nft_stats for broader stats). No exclusions or caveats are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It indicates a read operation retrieving 'recent' activity but does not define how recent, whether results are cached, pagination behavior, or rate limits. While not misleading, it omits helpful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 20-word sentence that packs all essential information: resource, action, scope, and data included. No unnecessary words or repetition. Perfectly concise.
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?
For a simple tool with 2 parameters and no output schema, the description provides sufficient context about the resource and output. It lacks details on ordering or time range, but given the straightforward nature, it is largely complete.
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?
Schema coverage is 100% with both parameters described. The description adds meaning by explaining the output includes bids, listings, sales with prices, buyers, sellers, and timestamps, which is not in the schema. This helps the agent understand what the response will contain.
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 states the tool retrieves recent activity for a Magic Eden Solana NFT collection, explicitly listing event types (bids, listings, sales) and included data (prices, buyers, sellers, timestamps). This distinguishes it from siblings like nft_listings or nft_stats, which focus on different aspects.
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 lacks any guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or scenarios where other tools (e.g., nft_floor for floor price, wallet_activity for wallet-specific data) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses key behaviors: returns active listings only, sorted by price ascending, up to 20. However, it lacks details on data freshness, error handling, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, no redundant information. Every sentence adds value.
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?
Tool is simple with no output schema. Description covers input parameters and output characteristics (sorted, up to 20 listings). Missing details on listing fields but sufficient for basic usage.
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 has 100% description coverage for both parameters. Description adds minor context (e.g., examples for symbol, 'up to 20' for limit) but largely overlaps with schema. Baseline score of 3 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?
Description clearly states the verb 'Get' and the resource 'cheapest active NFT listings for a Magic Eden Solana collection', including the source and ordering. This distinguishes it from siblings like nft_floor (floor price) and nft_activity (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?
Description implies usage for retrieving cheapest listings but does not explicitly state when to use this tool versus alternatives like nft_floor or nft_stats. No when-not-to-use or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read operation and lists returned fields, which is adequate for basic understanding. However, it does not disclose behavior on invalid symbols, potential errors, or rate limits, limiting richness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys the tool's purpose and output. Every word earns its place with no redundancy or filler.
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 tool's simplicity (one parameter, no output schema), the description covers the purpose and returned stats. It is slightly lacking in error handling or behavior notes, but overall complete for a basic stats tool.
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% as the only parameter 'symbol' is already well-described in the schema with the collection symbol example. The tool description merely repeats the context (Magic Eden NFT collection) without adding new meaning beyond the 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?
The description clearly states it gets 'full collection stats' for a Magic Eden Solana NFT collection and lists specific data points (floor, volume, 24h avg, holders, supply). This differentiates it from siblings like nft_floor (which likely returns only floor price) and nft_token (individual token data).
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?
The description implies usage for collection-level aggregated stats but does not provide explicit guidance on when to choose this tool over alternatives like nft_floor or nft_activity. No when-not or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses what the tool returns (mint addresses, names, etc.), but does not state the read-only nature, potential errors, authentication needs, or pagination behavior (limit/offset hinted via schema). Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no fluff, conveying purpose and output efficiently. Well structured and front-loaded.
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 no output schema, the description adequately covers return values. It explains all parameters via schema. Missing usage context and pagination hints, but overall complete for a simple data retrieval tool.
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 baseline is 3. The description adds no new parameter insights beyond the schema; it only summarizes the output type. No added value for parameter semantics.
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 states the action (Get NFTs), the resource (owned by a Solana wallet address), and the output (mint addresses, names, collections, listing status). It distinguishes from siblings like nft_token (individual NFT) and nft_listings (listings) by focusing on ownership.
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?
The description indicates when to use the tool (to get NFTs owned by a wallet), but provides no guidance on when not to use it or alternatives among siblings. No explicit usage guidelines beyond the core purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description covers return fields but does not disclose any behavioral traits such as error handling, authentication needs, or potential side effects. For a read-only tool, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence effectively communicates purpose and output fields. No unnecessary words or fluff.
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 simple tool (1 param, no output schema), description adequately covers purpose and return fields. Lacks mention of scenario where NFT not found or required permissions, but these are minor gaps.
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?
Parameter 'mint' is described in schema as 'Solana token mint address (base58)'. Tool description repeats that it is 'by its mint address'. No additional meaning beyond schema, so baseline 3.
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?
Clearly describes the verb 'Get detailed information', resource 'single Solana NFT', and scope 'by its mint address'. The description lists specific data fields (name, owner, collection, etc.), making it distinct from sibling tools like nft_activity or nft_floor.
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?
Implies use for retrieving full details of a specific NFT. Does not explicitly state when not to use or compare to siblings, but the listed fields make its purpose clear relative to the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full transparency. It discloses the use of 'current floor prices' and output in SOL, but does not mention limitations (e.g., floor prices may not reflect actual market value) or potential side effects. The transparency is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only two sentences, achieves front-loading of purpose and output, and contains no wasted words. Every sentence adds value.
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 tool's simplicity (one input, no output schema), the description covers the main aspects: what it does, input, and output format (breakdown by collection and grand total in SOL). It lacks explicit mention of the output structure, but the context is mostly complete.
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?
The input schema provides 100% coverage for the single parameter 'address' with description 'Solana wallet address (base58)'. The description does not add additional meaning beyond confirming it's a Solana wallet. Baseline score of 3 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?
The description clearly states the tool's purpose: 'Estimate the total NFT portfolio value for a Solana wallet using current floor prices.' It specifies the resource ('total NFT portfolio value') and action ('estimate') and distinguishes from siblings like nft_floor (specific collection floor) and wallet_nfts (list NFTs).
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?
The description implies usage for portfolio valuation but does not explicitly state when to use or not use it compared to alternatives. It provides clear context but lacks exclusions or alternative tool references, resulting in slightly incomplete guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![jorkal-nft-mcp MCP server](https://glama.ai/mcp/servers/jorkal-crypto/jorkal-nft-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jorkal-crypto/jorkal-nft-mcp)

Score Badge

Copy to your README.md:

[![jorkal-nft-mcp MCP server](https://glama.ai/mcp/servers/jorkal-crypto/jorkal-nft-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jorkal-crypto/jorkal-nft-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/jorkal-crypto/jorkal-nft-mcp'

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