Skip to main content
Glama
StampUI

@stampui/mcp

Official
by StampUI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

@stampui/mcp

npm CI license

MCP (Model Context Protocol) server for StampUI. Lets an AI coding agent browse the StampUI block registry and stamp blocks into a project as real .tsx source files, without leaving the editor: "add an FAQ section" becomes search, inspect, install.

Tools

Tool

What it does

list_blocks

List blocks, filter by category, tier (free/pro), or framework

search_blocks

Free-text search across slug, title, description, tags

get_block

Full manifest, install command, docs link, and source (free blocks) or an unlock note (pro blocks)

stamp_block

Write a block's files into the project at an absolute targetDir

The registry data and free block sources come from the MIT @stampui/blocks package; the manifest format is documented in the open block manifest spec.

Related MCP server: @kongyo2/npm-info-mcp-server

Setup

Claude Code

claude mcp add stampui -- npx -y @stampui/mcp

Claude Desktop

Add to claude_desktop_config.json (Settings > Developer > Edit Config):

{
  "mcpServers": {
    "stampui": {
      "command": "npx",
      "args": ["-y", "@stampui/mcp"]
    }
  }
}

Cursor and other MCP clients

Add the same entry to the client's MCP config (e.g. ~/.cursor/mcp.json):

{
  "mcpServers": {
    "stampui": {
      "command": "npx",
      "args": ["-y", "@stampui/mcp"]
    }
  }
}

Free vs pro

Everything needed for free blocks works offline and without an account: sources ship inside @stampui/blocks.

Pro blocks are part of the commercial StampUI catalog. Their source is not in this package or any public repo. With a license key, set it in the server's environment and pro sources are fetched from the licensed registry per request:

claude mcp add stampui --env STAMPUI_TOKEN=SU_LIVE_-XXXX -- npx -y @stampui/mcp

Without a token, pro blocks still appear in listings and get_block explains how to unlock them; the server never attempts to bypass licensing, and PRs adding such behavior will be closed.

Environment variables

Variable

Meaning

Default

STAMPUI_TOKEN

Commercial license key; only needed for pro blocks

unset

STAMPUI_REGISTRY_URL

Registry origin, useful for testing

https://stampui.com

Security notes

  • The server runs locally over stdio; it makes network requests only for pro block fetches, over HTTPS to the registry.

  • stamp_block writes files. It requires an absolute targetDir and refuses paths that resolve outside it. Review what your agent installs like any other code it writes; MCP clients ask for permission before tool calls by default, keep that on for stamp_block.

  • Your license key is read from the environment and sent only in the Authorization header to the registry. Never paste it into chat.

  • Report vulnerabilities per SECURITY.md.

Development

git clone https://github.com/StampUI/mcp
cd mcp
npm install
npm run build
# exercise it with the MCP inspector:
npx @modelcontextprotocol/inspector node dist/index.js

Links

License

MIT for this server. Free blocks it delivers are MIT via @stampui/blocks; pro blocks are covered by the StampUI commercial license.

Available Tools

4 tools
get_blockA

Get full details for one block: manifest, install command, dependencies, and the source code (free blocks) or how to unlock it (pro blocks).

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYes

TDQS

A3.6/5.0
Behavior3/5

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

Discloses behavioral trait: response differs for free vs pro blocks (source code vs unlock info). No annotations exist, so description carries full burden; however, it omits auth requirements, side effects, or performance implications.

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 packed with key information (manifest, install command, dependencies, conditional unlock). Front-loaded with main action. Efficient use of words.

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 one parameter and no output schema, the description adequately covers the response contents (manifest, install command, dependencies, conditional). However, it lacks details on error conditions or response structure.

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

Parameters2/5

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

Only parameter 'slug' has 0% schema description coverage, and the description does not explain what 'slug' means (e.g., block identifier). Description adds minimal value beyond the parameter name.

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 verb+resource 'Get full details for one block' and lists specific content items (manifest, install command, dependencies, source code/unlock). Distinguishes from sibling tools that list or search blocks.

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 context (when full details of a specific block are needed) but no explicit when-not-to-use or comparison to siblings. Sibling names are known from context signals but description does not guide selection.

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

list_blocksA

List StampUI blocks. Optionally filter by category, tier (free|pro) or framework. Returns slug, title, description, tier and tags for each.

ParametersJSON Schema
NameRequiredDescriptionDefault
tierNo
categoryNoe.g. UI, Dashboard, Auth, AI, Finance
frameworkNoe.g. nextjs, react, vite

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It states the tool lists blocks and returns specific fields, which is minimally transparent. However, it omits details like pagination, ordering, or rate limits, which are common for listing endpoints.

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, well-structured sentence that conveys all essential information without extraneous words. It is appropriately front-loaded with the primary action and resource.

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

Completeness5/5

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

Given the tool's simplicity (3 optional params, no output schema), the description covers the key aspects: what it does, filters, and return fields. It is complete enough for an agent to understand and invoke the tool correctly.

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 description mentions the three filter parameters (category, tier, framework) and their optionality, but largely mirrors the schema's own descriptions. It adds some value by grouping them and indicating the enum for tier, but no additional semantics beyond that.

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 clearly states the action ('List') and the resource ('StampUI blocks'), making the purpose evident. It includes filtering options and return fields, but does not explicitly differentiate from sibling tools like get_block or search_blocks.

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 listing blocks with optional filters, but provides no guidance on when to use this tool versus alternatives (e.g., search_blocks for advanced search, get_block for a single block). No exclusions or context are mentioned.

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

search_blocksA

Search StampUI blocks by free text across slug, title, description and tags. Use this to find a block for a need, e.g. 'billing', 'data table', 'login'.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes

TDQS

A4/5.0
Behavior3/5

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

Describes search fields (slug, title, description, tags) but omits details like case sensitivity, result ordering, pagination, or read-only nature. With no annotations, more behavioral disclosure would be beneficial.

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: first defines action, second gives usage guidance. No filler, front-loaded. 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?

For a simple search tool with one parameter and no output schema, the description covers the main functionality and provides examples. Could mention potential return format or pagination but not essential for basic use.

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 0%, but description adds context: 'query' is free text searched across fields. No syntax, length limits, or format details given, but the meaning is adequately conveyed for a single string parameter.

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?

Clear verb 'search' with specific resource 'StampUI blocks' and scope 'by free text across slug, title, description and tags'. Distinguishes from siblings like get_block (fetch by ID) and list_blocks (list all) by implying filtering. Examples reinforce purpose.

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?

Explicitly advises when to use: 'to find a block for a need' with concrete examples. Lacks explicit when-not-to-use or comparison to siblings, but context is directional enough for an agent.

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

stamp_blockA

Write a block's source files into the user's project. Provide the slug and a target directory (absolute, e.g. the repo root). Free blocks work offline; pro blocks need STAMPUI_TOKEN.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYes
targetDirYesAbsolute path of the project root to write files into.

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided. The description mentions the token requirement for pro blocks and that target directory should be absolute, but it does not disclose potential side effects like file overwriting, or error handling.

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?

Three sentences, no wasted words. The first sentence states the primary action, with supporting details following. Efficient 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?

For a simple 2-parameter tool without output schema, the description covers the main action, parameter guidance, and a conditional requirement. Missing details on return behavior or error handling, but adequate for the complexity.

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 50%: targetDir has a description, slug does not. The description adds context by mentioning 'slug' but does not define it. It compensates slightly with the offline/pro block distinction, but the slug parameter remains under-described.

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 writes block source files into the user's project. It distinguishes from siblings: get_block, list_blocks, search_blocks are read/search tools, while stamp_block is a write operation.

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 specifies inputs (slug and target directory) and provides a condition: free blocks work offline, pro blocks need STAMPUI_TOKEN. It gives clear context but does not explicitly state when not to use or alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.1.0
    • First observedget_block
    • First observedlist_blocks
    • First observedsearch_blocks
    • First observedstamp_block
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a distinct purpose: get_block retrieves details of one block, list_blocks lists multiple blocks, search_blocks searches by text, and stamp_block writes files. No overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case: get_block, list_blocks, search_blocks, stamp_block. Perfectly predictable.

Tool Count5/5

Four tools is an appropriate size for a block management server, covering core operations without being too few or too many.

Completeness4/5

The server covers the main use cases: retrieving, listing, searching, and installing blocks. Minor missing operations like removing or updating installed blocks are not critical for this domain.

Maintenance

ActivityStale
ResponsivenessResponsive

Resources

Related MCP Connectors

Related MCP Servers