Skip to main content
Glama
Laz1mov
by Laz1mov

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.

  1. 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 build

    Note the full absolute path to the repository, as you'll need it in the next step.

  2. 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)

  3. 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).

  4. Enter the extension details: Provide a name and command for the MCP-Inscription server:

    • ID: mcp-inscription

    • Name: 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.js

      Replace /absolute/path/to/mcp-inscription with 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).

  5. 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)).

  6. 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).

  1. 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.js

    This will start the server in SSE mode, making it available at http://localhost:3000 (or your specified port).

  2. Add a new extension in Goose (Remote): As before, run goose configure or 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.

  3. 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/sse route on the server, you usually just need to supply the host and port, and Goose handles the rest.)

  4. 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:

  1. 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).

  2. Clone and Build the MCP-Inscription Repository:

    git clone https://github.com/Laz1mov/mcp-inscription
    cd mcp-inscription
    npm install
    npm run build
  3. Configure 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.json

    • Windows: %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-inscription with the actual full path to where you cloned the repository.

  4. Restart Claude Desktop: Save the claude_desktop_config.json file 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 for mcp.log for general MCP connection messages, and a file named mcp-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 tool
show_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_path as 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_processor AND vision fail, 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. ๐Ÿš€

ParametersJSON Schema
NameRequiredDescriptionDefault
txidYesThe unique 64-character hexadecimal identifier of the Bitcoin transaction to inspect for Ordinals. Example: 'f1d2d3...a8b9c0'.
inscription_indexNoOptional. The specific index (starting from 0) of the inscription to retrieve within the transaction, if there are multiple.
content_type_filterNoOptional. Filter inscriptions by content type, e.g., 'image/png', 'text/plain', 'application/json'.

TDQS

B3.2/5.0
Behavior4/5

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.

Conciseness1/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose2/5

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.

Usage Guidelines5/5

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. 1 tool update
    • First observedshow_ordinals

TDQS

B3.2/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness1/5

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

ActivityInactive
ResponsivenessNo issues

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

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables 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.
    30
    6
    MIT
  • A
    license
    C
    quality
    D
    maintenance
    Enables AI applications to interact with the Bitcoin Network, manage wallets, check balances, convert prices, and send transactions.
    4
    61
    6
    MIT

Latest Blog Posts

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