mcp-inscription
Enables interaction with Bitcoin's Ordinals Inscriptions, allowing retrieval and display of content from blockchain transactions including text, images, and JSON formats.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mcp-inscriptionshow me inscription content from transaction abc123def456"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP-Inscription Server
Overview
A Model Context Protocol (MCP) server that enables AI models to interact with Ordinals Inscriptions, allowing them to display content from a transaction.
Related MCP server: MCP Bitcoin CLI
๐ฎ Demo
Goose Demo Video |
๐ผ Table of Contents
๐ง Features
Ordinal Detection: Automatically detect and parse Bitcoin transaction into ordinals, supporting text-based, images, json and more inscriptions formats.
๐ฆ Goose Integration
Goose is an open-source AI agent framework by Block that supports extensions via the Model Context Protocol. You can integrate the MCP-Inscription server as a Goose extension to allow Goose to interact with Ordinals Inscriptions. Goose supports two modes of integration for MCP servers: running the server as a local process (STDIO) or connecting to it as a remote service via Server-Sent Events (SSE). Below are instructions for both methods:
Using STDIO (Local Extension)
This method runs the MCP-Inscription server locally as a subprocess of Goose, communicating through standard input/output.
Clone and Build the MCP-Inscription Repository (if you haven't already):
git clone https://github.com/Laz1mov/mcp-inscription cd mcp-inscription npm install npm run buildNote the full absolute path to the repository, as you'll need it in the next step.
Add a new extension in Goose: Open Goose's configuration interface. You can do this via the command line by running
goose configure, or in the Goose Desktop app by going to Settings > Extensions. From the menu, choose "Add Extension." (Using Extensions | goose)Choose the extension type โ Command-Line Extension: When prompted for the type of extension, select Command-Line Extension (in the CLI menu or UI) so that Goose knows it should launch a local command (Using Extensions | goose) (as opposed to a built-in or remote extension).
Enter the extension details: Provide a name and command for the MCP-Inscription server:
ID:
mcp-inscriptionName: You can call it "mcp-inscription", or any identifier (this will be how you refer to the extension).
Command: Specify the full path to the built CLI script. For example:
node /absolute/path/to/mcp-inscription/build/cli.jsReplace
/absolute/path/to/mcp-inscriptionwith the actual path to where you cloned the repository.You typically do not need to add any arguments beyond the script path (unless your server requires special flags).
Finalize and enable: Complete the extension addition. Goose will add this new extension to its configuration (usually
~/.config/goose/config.yaml). Ensure the extension is enabled (if using the CLI wizard, it should be enabled by default once added; in the Goose Desktop app, you can check the Extensions list and toggle it on if it isn't already (Using Extensions | goose) (Using Extensions | goose)).Start a Goose session with the new extension: You can now use the extension in Goose. If you're running Goose via CLI, start a session that includes the extension by running:
goose session --with-extension "mcp-inscription"
replacing "ordinals" with whatever name you gave the extension (Using Extensions | goose). (This ensures the session loads the extension. Alternatively, if the extension is enabled globally, Goose Desktop or CLI will automatically have it available in all sessions.)
Using SSE (Remote Extension)
This method connects Goose to an already-running MCP server via an HTTP SSE stream. Use this if you want to run the MCP-Inscription server as a standalone service (possibly on another machine or just independently of Goose).
Launch the MCP server as a standalone service: Run the MCP-Inscription server in SSE mode to listen for connections:
# Navigate to your mcp-inscription directory cd /path/to/mcp-inscription # If you havent built it yet npm install npm run build # Run in SSE mode on port 3000 (default) SERVER_MODE=sse node build/cli.js # Alternatively, specify a different port SERVER_MODE=sse PORT=9000 node build/cli.jsThis will start the server in SSE mode, making it available at
http://localhost:3000(or your specified port).Add a new extension in Goose (Remote): As before, run
goose configureor use the Goose UI to Add Extension (Using Extensions | goose). This time, choose Remote Extension when asked for the type of extension (Using Extensions | goose). This tells Goose that it will connect to an external server via SSE.Enter the remote extension details: Give the extension a name (e.g., "ordinals") and provide the server's URL. For the URL, enter the base address where the MCP server is running. For instance, if your server is listening on port 9000 on your local machine, you might enter
http://localhost:9000. Goose will attempt to connect to the MCP server's SSE endpoint at that address. (Goose uses the standard MCP SSE path, which by convention is under the/mcp/sseroute on the server, you usually just need to supply the host and port, and Goose handles the rest.)Enable the extension: After adding the remote extension, ensure it's enabled in Goose's settings (just like in the STDIO case). Only one of the STDIO or SSE extension (with the same tools) needs to be enabled โ if you accidentally enable both a local and remote version of the same server, you may want to disable one to avoid confusion.
Using the MCP-Inscription extension in Goose: Once the extension is set up (via either method above) and enabled, you can interact with Goose and query ord data through it. In a new Goose chat or session, simply ask questions as you normally would. Goose will recognize when to use the MCP-Inscription tools to fulfill your request. For example:
"Show me Ordinals: 0169d12c4edf2026a67e219c10207438a080eb82d8f21860f6784dd66f281389?"
When you ask these questions, Goose will invoke the MCP-Inscription server's tools and return the answer (e.g., the latest Bitcoin block information). You should see Goose responding with up-to-date information pulled from the Bitcoin blockchain via the MCP-Inscription server.
If Goose does not seem to use the extension (for instance, if it responds that it cannot find the information), make sure the extension is enabled and that the server is running (in SSE mode for remote). You can also run Goose's CLI with verbose logging to see if it attempted to call the extension. Generally, if configured correctly, Goose will automatically discover the MCP-Inscription server's capabilities and use them when relevant.
Further Resources: For more details on Goose extensions and the MCP, refer to the official Goose documentation (Using Extensions | goose). The docs include a list of built-in and community extensions and explain how MCP servers integrate into Goose. You can also find a directory of available MCP servers and additional configuration tips in the Goose docs and the Model Context Protocol documentation. This can help if you want to explore more extensions or develop your own.
๐ Claude Desktop Integration
To use the MCP-Inscription server with Claude Desktop (Anthropic's desktop app for Claude), follow these steps:
Download and Install Claude Desktop: Visit the official Claude Desktop downloads page and get the app for your operating system (macOS or Windows) (Installing Claude for Desktop | Anthropic Help Center). Install the app and ensure you're using the latest version (you can check for updates in the app menu).
Clone and Build the MCP-Inscription Repository:
git clone https://github.com/Laz1mov/mcp-inscription cd mcp-inscription npm install npm run buildConfigure Claude Desktop to use the MCP-Inscription Server: Open the Claude Desktop configuration file (it's created when you first edit settings in Claude Desktop):
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
Add an entry for the MCP-Inscription server in this JSON config under the"mcpServers"section. For example:
{ "mcpServers": { "mcp-inscription": { "command": "node", "args": ["/absolute/path/to/mcp-inscription/build/cli.js"] } } }In the snippet above,
"mcp-inscription"is an identifier for the server (you can name it whatever you want). Replace/absolute/path/to/mcp-inscriptionwith the actual full path to where you cloned the repository.Restart Claude Desktop: Save the
claude_desktop_config.jsonfile and then close and reopen Claude Desktop. On the next launch, Claude will automatically start the MCP-Inscription server as configured. If Claude Desktop was running, you need to restart it for the changes to take effect.
Testing the Claude Desktop Integration
Once Claude Desktop is restarted, you can test whether the MCP-Inscription server is working correctly:
Verify the response: Claude should return a detailed answer (e.g. the inscription itself or runes info) without errors. If you get an error message or no useful response, the MCP server might not be connected properly.
Check Claude's logs (if needed): Claude Desktop provides log files that can help debug MCP integrations. If the tool isn't responding, check the log files in:
macOS:
~/Library/Logs/Claude/Windows:
%APPDATA%\Claude\logs\
Look formcp.logfor general MCP connection messages, and a file namedmcp-server-mcp-inscription.log(or with whatever name you used) for the MCP server's output/errors. These logs will show if the server started up or if there were any errors (such as a wrong path or exceptions in the server). If you see errors, fix the configuration or environment as needed, then restart Claude Desktop and test again.
Installing via Smithery
To install Inscription Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @Laz1mov/mcp-inscription --client claude๐ Project Structure
mcp-inscription/
โโโ src/
โ โโโ ordinals_client.ts # Bitcoin ordinals and runestone utility functions
โ โโโ servers/
โ โ โโโ index.ts # Server exports and factory functions
โ โ โโโ sse.ts # Server implementation using SSE transport
โ โ โโโ stdio.ts # Server implementation using STDIO transport
โ โ โโโ base.ts # Base server implementation with shared functionality
โ โโโ index.ts # Main entry point
โ โโโ cli.ts # CLI launcher
โ โโโ mcp_inscription_types.ts # Shared types and schemas for the MCP-Inscription server
โ โโโ utils/
โ โโโ logger.ts # Logger setup
โ โโโ cache.ts # Caching implementation
โ โโโ error_handlers.ts # Error handling utilities
โ โโโ json_utils.ts # JSON processing utilities
โ โโโ img_utils.ts # Image processing and conversion utilities
โ โโโ version.ts # Version information
โโโ .env.example # Example environment configuration file
โโโ package.json
โโโ tsconfig.json
โโโ README.md๐ฆ Available Tools
show_ordinals
Description:
Decodes Ordinal inscription data from a transaction's witness data.
Input Schema:
{
"txid": "string"
}Example Input:
{
"txid": "0169d12c4edf2026a67e219c10207438a080eb82d8f21860f6784dd66f281389"
}Output:
Returns the decoded inscription content, which may be text, JSON, HTML, or other formats.
๐จ Error Handling
The server employs custom error types to handle Bitcoin operations and blockchain queries. Detailed error messages are logged using Pino and included in client responses for easier debugging.
๐ค Contributing
Contributions and feature requests are welcome! Feel free to submit pull requests or open issues on GitHub.
๐ License
This project is licensed under the MIT License.
Available Tools
1 toolshow_ordinalsB
๐น Bitcoin Ordinals Expert Assistant
๐ MANDATORY TWO-RESPONSE PROCESS FOR IMAGES
I strictly follow a two-step structured workflow for processing Bitcoin Ordinal inscriptions. STRICT ADHERENCE IS REQUIRED.
๐ Required Tools & Workflow
๐ Tools Used:
1๏ธโฃ show_ordinals (MANDATORY FIRST STEP)
Fetches inscription data.
If the inscription is an image, it MUST:
Save it locally and return the
local_file_path.(Code currently does NOT return a separate displayable source, only the local path)
2๏ธโฃ image_processor / vision (OCR & Visual Analysis ONLY)
MUST be used for extracting textual/visual data from the image.
Takes
local_file_pathas input.
๐ MANDATORY TWO-STEP RESPONSE WORKFLOW (FOR IMAGES)
๐ RESPONSE 1: Display Attempt + Technical Details (NON-TERMINAL)
โ Execute show_ordinals FIRST.
โ Return an <img> tag using the local_file_path provided by show_ordinals as the src attribute.
โ Follow with detailed technical metadata.
โ STOP HERE. NO ANALYSIS YET.
โ RESPONSE FORMAT (STRICTLY ENFORCED):
<!-- Attempting display using local path. Note: May not render in standard browsers due to security restrictions. -->
<img src="[local_file_path from show_ordinals]" alt="Ordinal Image Inscription" style="max-width: 100%; height: auto;" />
### ๐ Technical Details
* **MIME Type:** [MIME type]
* **Size:** [Size]
* **Transaction ID:** [Tx ID]
* **Status:** [Status]
* **Inscription Input:** [Input]
* **Local Path (for analysis):** `[local_file_path from show_ordinals]`
* [Other available details]๐น End FIRST response here. No OCR, No AI-generated descriptions. This response is intended to be NON-TERMINAL to allow for Step 2.
๐ RESPONSE 2: OCR & Content Analysis (Using Designated Tools ONLY)
โ AFTER Response 1, consult available tools.
โ Execute image_processor OR vision using the local_file_path from Response 1.
โ Strictly use ONLY tool-generated analysis.
โ If BOTH tools fail, state failure explicitly.
โ Return a new markdown response with the extracted data.
โ RESPONSE FORMAT (STRICTLY ENFORCED):
### ๐ Detailed Image Analysis (Result from '[Executed Tool Name]')
[Extracted OCR text, visual description, or failure message from the tool ONLY]โ No hallucinations. No AI-generated assumptions.
๐ FALLBACK MECHANISM (IF OCR TOOLS FAIL)
If BOTH
image_processorANDvisionfail, use a verified fallback OCR tool (if available).If no fallback exists, explicitly state failure instead of hallucinating content.
๐ฏ Summary: Strict 2-Response Workflow
โ
Step 1: Execute show_ordinals โ Attempt Image Display (using local path) + Metadata. (Response intended as Non-Terminal)
โ
Step 2: Execute image_processor / vision โ Analysis Description. (Separate Response)
๐ก This ensures clarity, prevents AI hallucinations, and provides structured responses. ๐
| Name | Required | Description | Default |
|---|---|---|---|
| txid | Yes | The unique 64-character hexadecimal identifier of the Bitcoin transaction to inspect for Ordinals. Example: 'f1d2d3...a8b9c0'. | |
| inscription_index | No | Optional. The specific index (starting from 0) of the inscription to retrieve within the transaction, if there are multiple. | |
| content_type_filter | No | Optional. Filter inscriptions by content type, e.g., 'image/png', 'text/plain', 'application/json'. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does disclose important behavioral traits: it fetches inscription data, saves images locally, returns a local_file_path, and is part of a mandatory two-response workflow. It explains that code 'currently does NOT return a separate displayable source, only the local path' which is valuable behavioral context. However, it doesn't mention error conditions, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely verbose (over 800 words) and poorly structured for a tool definition. It's front-loaded with workflow instructions rather than tool purpose. Most content is about the mandatory two-response process, fallback mechanisms, and response formats rather than concisely describing the tool itself. Every sentence does not earn its place in a tool description context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 100% schema coverage but no annotations and no output schema, the description provides extensive workflow context but lacks critical tool-specific information. It doesn't explain what the tool returns (beyond mentioning local_file_path for images), error conditions, or performance characteristics. The workflow instructions are comprehensive but don't compensate for missing tool behavior documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. It mentions the tool fetches inscription data but doesn't explain how parameters affect this process. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fetches inscription data' which is a vague purpose statement. While it mentions Bitcoin Ordinals context, it doesn't specify what data is fetched (metadata, content, both) or how it differs from other potential tools. The description is primarily workflow instructions rather than a clear tool purpose definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit, detailed guidance on when to use this tool: 'MANDATORY FIRST STEP' for processing Bitcoin Ordinal inscriptions, specifically for images where it must save locally and return the local_file_path. It clearly states this is step 1 of a two-step workflow and specifies when to use sibling tools (image_processor/vision) in step 2.
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. Dates show when Glama detected each change.
1 tool update
- First observed
show_ordinals
TDQS
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool 'show_ordinals' has a singular, clear purpose of fetching Bitcoin Ordinal inscription data, so agents cannot misselect among multiple options.
The single tool name 'show_ordinals' follows a clear verb_noun pattern (show + ordinals), which is consistent and predictable. Since there is only one tool, there is no inconsistency to evaluate, and the naming convention is straightforward.
The server has only one tool, which is too few for its stated purpose of being a 'Bitcoin Ordinals Expert Assistant' with a mandatory two-step workflow involving multiple tools. The description references other tools like 'image_processor' and 'vision' that are not provided, creating a significant mismatch between the expected scope and the actual tool surface.
The tool set is severely incomplete. The server description mandates a two-response process using multiple tools (e.g., 'show_ordinals', 'image_processor', 'vision'), but only 'show_ordinals' is available. This leaves obvious gaps that will cause agent failures, as critical analysis steps cannot be performed without the missing tools.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Bitcoin and YouTube video intelligence for AI agents. Pay-per-call via x402 USDC on Base.
Bitcoin wallet intelligence for AI agents: trust, labels, tx verify, fees, and timestamps.
Provide AI agents and automation tools with contextual access to blockchain data including balanceโฆ
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analyโฆ
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables interaction with the Stacks blockchain through Claude Desktop. Manage wallets, trade tokens on DEXs, stack STX for Bitcoin rewards, and track portfolioโall through natural conversation.306MIT
- AlicenseBqualityDmaintenanceEnables interaction with Bitcoin's blockchain through Claude to embed and read data using OP_RETURN, create timestamps, deploy BRC-20 tokens, and store documents up to 100KB on-chain.162MIT

MIDL MCP Serverofficial
FlicenseAqualityDmaintenanceEnables AI assistants to interact with the MIDL blockchain, supporting smart contract deployment, balance queries, asset bridging, Bitcoin Rune management, and more through natural language.291-- AlicenseCqualityDmaintenanceEnables AI applications to interact with the Bitcoin Network, manage wallets, check balances, convert prices, and send transactions.4616MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Laz1mov/mcp-inscription'
If you have feedback or need assistance with the MCP directory API, please join our Discord server