get_item_details

Rich, curated metadata for a registry item — marketing opening paragraph, 6 hand-picked related siblings, 6 FAQ questions. For blocks, this unlocks content the lite get_item intentionally omits.

get_item_details is the companion to the lite get_item. Same resolver, but augmented with curated block metadata that the core registry parser skips to keep get_item cheap.

The split is deliberate: agents browsing 10 candidates should use get_item (small payload, fast). Agents committed to one block should escalate to get_item_details to unlock the hand-curated content.

When to use

  • After narrowing candidates — the agent has picked a block and wants to explain it in depth or suggest alternatives.
  • To answer FAQ-style prompts ("how do I customize X?") without hallucinating.
  • To show the user a block's @related siblings as "you might also like…" options.

If you only need dependencies / premium status / file paths, stay on get_item — it's cheaper by several hundred tokens.

How it works

  1. Resolve the item via getRegistryItem(name) — same universal resolver as get_item.
  2. If the item is a block (its files[0].path starts with blocks/), resolve the absolute source path (packages/<files[0].path>) and call the JSDoc parser in lib/mcp/jsdoc-parser.ts.
  3. The parser:
    • Reads the file (per-process cache keyed by path + mtime — subsequent calls touch memory only).
    • Isolates the leading JSDoc block.
    • Extracts @opening (plain text until the next @tag), @related (JSON array), @questions (JSON array), @lastModified (date string).
    • Concurrent calls for the same file share one in-flight readFile — no stampede.
  4. Returns a lite item (same shape as get_item) plus a details object with the extracted fields.

For non-block surfaces (ai, components, hooks, etc.) the tool returns an empty details: {} — those surfaces don't curate the same JSDoc schema. Agents should fall back to get_item_source if they need rich info on non-blocks.

Arguments

NameTypeRequired
namestring

Response

{
  "$schema": "https://ui.shadcn.com/schema/registry-item.json",
  "name": "pricing-grouped-comparison-table",
  "type": "registry:block",
  "title": "React Pricing Grouped Comparison Table Block",
  "description": "A grouped feature comparison table pricing section …",
  "premium": true,
  "dependencies": ["motion", "lucide-react"],
  "registryDependencies": ["table"],
  "files": [
    { "path": "blocks/pricing/pricing-grouped-comparison-table.tsx", "type": "registry:block", "target": "…" }
  ],
  "details": {
    "opening": "Compare dense feature matrices across plans with this grouped comparison table pricing section for React and Next.js. Features a shadcn Table with four plan columns, feature categories rendered as section header rows dividing the table into logical groups (Rate Limits, Authentication, Infrastructure, Support) …",
    "lastModified": "2026-04-07",
    "related": [
      { "href": "/blocks/pricing-comparison-table", "title": "Comparison Table Pricing", "description": "Feature matrix comparison table" },
      { "href": "/blocks/pricing-three-columns", "title": "Three Column Pricing", "description": "Classic three-tier pricing cards" },
      { "href": "/blocks/pricing-accordion-plans", "title": "Accordion Plans Pricing", "description": "Expandable accordion plan rows" },
      { "href": "/blocks/pricing-dark-highlight", "title": "Dark Highlight Pricing", "description": "Dark card highlight treatment" },
      { "href": "/blocks/pricing-enterprise-contact", "title": "Enterprise Contact Pricing", "description": "Enterprise tier with contact sales" },
      { "href": "/blocks/pricing-feature-matrix", "title": "Feature Matrix Pricing", "description": "Detailed feature matrix layout" }
    ],
    "questions": [
      { "id": "q1", "title": "How do I customize the API plans, feature rows, and quantities?", "answer": "Edit the PLANS array for column headers …" },
      { "id": "q2", "title": "How do I connect plan CTAs to Stripe or a billing backend?", "answer": "Add an onClick handler to each ShadcnioButton …" }
    ]
  }
}

Example prompts

use shadcnio and give me the curated details for pricing-grouped-comparison-table — including the related blocks and FAQs
use shadcnio to tell me the three best alternatives to hero-announcement based on its @related list
use shadcnio get_item_details for pricing-split-highlight and answer my follow-up from its FAQ

Manual invocation

curl -s -X POST "https://www.shadcn.io/api/mcp?token=YOUR_TOKEN" \
  -H "content-type: application/json" -H "accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_item_details","arguments":{"name":"pricing-grouped-comparison-table"}}}' \
  | sed -n 's/^data: //p' | jq '.result.content[0].text | fromjson | .details'

Tips + gotchas

  • Block-only richness. The @opening / @related / @questions schema is enforced only for blocks by bun run validate. Other surfaces return an empty details — that's expected, not a bug.
  • related links are flat URLs. Every href is /blocks/{slug} (no category segment). Feed the slug directly into any other MCP tool.
  • Per-file cache with mtime-invalidation. Editing a block's JSDoc in dev flushes the cache automatically on the next call — no restart needed.
  • No second registry roundtrip. The tool reads the source file directly rather than calling getRegistryItem twice — it's ~1 file read on a cache miss.
  • Pair with get_preview_url. When showing the user the 6 related siblings, also emit get_preview_url calls for 2-3 of them so they can eyeball alternatives.

Was this page helpful?

Sign in to leave feedback.