mcp-inscription
MCP-Inscriptionサーバー
概要
AI モデルが Ordinals Inscription と対話し、トランザクションのコンテンツを表示できるようにする Model Context Protocol (MCP) サーバー。
Related MCP server: MCP Bitcoin CLI
🎮 デモ
Gooseデモビデオ |
💼 目次
🔧 機能
序数検出: Bitcoin トランザクションを自動的に検出し、序数に解析します。テキストベース、画像、JSON、その他の表記形式をサポートします。
🦆 Goose 統合
Gooseは、Block社によるオープンソースのAIエージェントフレームワークで、モデルコンテキストプロトコル(Model Context Protocol)を介した拡張機能をサポートしています。MCP-InscriptionサーバーをGoose拡張機能として統合することで、GooseがOrdinals Inscriptionと連携できるようになります。Gooseは、MCPサーバーとの統合に2つのモードをサポートしています。サーバーをローカルプロセス(STDIO)として実行するか、Server-Sent Events(SSE)を介してリモートサービスとして接続するかです。以下に、両方の方法の手順を示します。
STDIO (ローカル拡張) の使用
このメソッドは、MCP-Inscription サーバーを Goose のサブプロセスとしてローカルで実行し、標準入出力を介して通信します。
MCP-Inscription リポジトリをクローンしてビルドします (まだ行っていない場合)。
git clone https://github.com/Laz1mov/mcp-inscription cd mcp-inscription npm install npm run build次のステップで必要になるので、リポジトリへの完全な絶対パスをメモしておいてください。
Gooseで新しい拡張機能を追加するには、 Gooseの設定インターフェースを開きます。コマンドラインから
goose configureを実行するか、Gooseデスクトップアプリから設定 > 拡張機能にアクセスして**拡張機能を追加できます。メニューから「拡張機能を追加」**を選択します。( 拡張機能の使用 | goose )**拡張機能の種類を選択します - コマンドライン拡張機能:**拡張機能の種類を尋ねられたら、コマンドライン拡張機能(CLI メニューまたは UI) を選択して、Goose がローカル コマンド ( 拡張機能の使用 | goose ) (組み込み拡張機能またはリモート拡張機能ではなく) を起動する必要があることを認識できるようにします。
拡張機能の詳細を入力します。MCP -Inscription サーバーの名前とコマンドを入力します。
ID :
mcp-inscription名前: 「mcp-inscription」または任意の識別子で呼ぶことができます (これが拡張機能の参照方法になります)。
**コマンド:**ビルドされたCLIスクリプトへのフルパスを指定します。例:
node /absolute/path/to/mcp-inscription/build/cli.js/absolute/path/to/mcp-inscriptionリポジトリのクローンを作成した実際のパスに置き換えます。通常、スクリプト パス以外に引数を追加する必要はありません (サーバーで特別なフラグが必要な場合を除く)。
最終処理と有効化:拡張機能の追加を完了します。Goose はこの新しい拡張機能を自身の設定(通常は
~/.config/goose/config.yaml)に追加します。拡張機能が有効になっていることを確認してください(CLI ウィザードを使用している場合は、追加後すぐにデフォルトで有効になります。Goose デスクトップアプリでは、拡張機能リストを確認し、まだ有効になっていない場合は有効にすることができます ( 拡張機能の使用 | goose ) ( 拡張機能の使用 | goose ))。**新しい拡張機能を使ってGooseセッションを開始します。**これで、Gooseで拡張機能を使用できるようになりました。CLI経由でGooseを実行している場合は、次のコマンドを実行して、拡張機能を含むセッションを開始します。
goose session --with-extension "mcp-inscription"
「序数」を拡張機能に付けた名前( 拡張機能の使用 | goose )に置き換えます。(これにより、セッションで拡張機能が確実に読み込まれます。また、拡張機能がグローバルに有効になっている場合は、Goose Desktop または CLI によってすべてのセッションで拡張機能が自動的に使用できるようになります。)
SSE (リモート拡張) の使用
このメソッドは、HTTP SSEストリームを介してGooseを既に実行中のMCPサーバーに接続します。MCP-Inscriptionサーバーをスタンドアロンサービスとして(別のマシン上、あるいはGooseとは独立して)実行する場合、このメソッドを使用します。
MCP サーバーをスタンドアロン サービスとして起動します。MCP -Inscription サーバーを SSE モードで実行して接続をリッスンします。
# 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これにより、サーバーが SSE モードで起動し、
http://localhost:3000(または指定したポート) で利用できるようになります。Goose(リモート)で新しい拡張機能を追加します。これまでと同様に、
goose configure実行するか、Goose UI を使用して拡張機能を追加します(拡張機能の使用 | goose )。今回は、拡張機能の種類を尋ねられたら**「リモート拡張機能」**を選択します( 拡張機能の使用 | goose )。これにより、Goose は SSE 経由で外部サーバーに接続します。リモート拡張機能の詳細を入力します。拡張機能に名前(例:"ordinals")を付け、サーバーのURLを指定します。URLには、MCPサーバーが稼働しているベースアドレスを入力します。例えば、サーバーがローカルマシンのポート9000でリッスンしている場合は、
http://localhost:9000と入力します。Gooseは、そのアドレスにあるMCPサーバーのSSEエンドポイントへの接続を試みます。(Gooseは標準のMCP SSEパスを使用します。これは慣例的にサーバーの/mcp/sseルートの下にあります。通常はホストとポート番号を指定するだけで、残りの処理はGooseが処理します。)**拡張機能の有効化:**リモート拡張機能を追加したら、Gooseの設定で有効化されていることを確認してください(STDIOの場合と同様)。STDIOまたはSSE拡張機能(同じツールを使用)のいずれか一方のみを有効化すれば十分です。誤って同じサーバーのローカルバージョンとリモートバージョンの両方を有効化してしまった場合は、混乱を避けるためにどちらか一方を無効化することをお勧めします。
**Goose で MCP-Inscription 拡張機能を使用する:**拡張機能を(上記のいずれかの方法で)セットアップして有効化すると、Goose を操作し、ord データを照会できるようになります。Goose の新しいチャットまたはセッションで、通常どおりに質問してください。Goose は、リクエストを満たすために MCP-Inscription ツールを使用するタイミングを認識します。例:
「序数を表示してください: 0169d12c4edf2026a67e219c10207438a080eb82d8f21860f6784dd66f281389?」
これらの質問をすると、GooseはMCP-Inscriptionサーバーのツールを起動し、回答(例:最新のビットコインブロック情報)を返します。GooseがMCP-Inscriptionサーバー経由でビットコインブロックチェーンから取得した最新情報を返すのが確認できるはずです。
Goose が拡張機能を使用していないように見える場合(例えば、情報が見つからないという応答を返す場合)、拡張機能が有効になっていること、およびサーバーが稼働していることを確認してください(リモートの場合は SSE モードで実行)。また、Goose の CLI を詳細ログ付きで実行し、拡張機能の呼び出しを試行したかどうかを確認することもできます。通常、正しく設定されていれば、Goose は MCP-Inscription サーバーの機能を自動検出し、必要に応じて使用します。
その他のリソース: Goose拡張機能とMCPの詳細については、Gooseの公式ドキュメント( 拡張機能の使用 | goose )を参照してください。このドキュメントには、組み込み拡張機能とコミュニティ拡張機能のリストが含まれており、MCPサーバーをGooseに統合する方法が説明されています。また、Gooseドキュメントとモデルコンテキストプロトコルのドキュメントには、利用可能なMCPサーバーのディレクトリと追加の設定ヒントが記載されています。これらのドキュメントは、他の拡張機能を調べたり、独自の拡張機能を開発したりする場合に役立ちます。
🔑 クロード デスクトップ統合
Claude Desktop (Claude 用の Anthropic のデスクトップ アプリ) で MCP-Inscription サーバーを使用するには、次の手順に従います。
Claude Desktopのダウンロードとインストール: Claude Desktopの公式ダウンロードページにアクセスし、お使いのオペレーティングシステム(macOSまたはWindows)用のアプリを入手してください( Claude for Desktopのインストール | Anthropicヘルプセンター)。アプリをインストールし、最新バージョンを使用していることを確認してください(アプリメニューでアップデートを確認できます)。
MCP-Inscription リポジトリのクローンとビルド:
git clone https://github.com/Laz1mov/mcp-inscription cd mcp-inscription npm install npm run buildMCP-Inscription Server を使用するように Claude Desktop を構成します。Claude Desktop 構成ファイルを開きます (Claude Desktop で最初に設定を編集したときに作成されます)。
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
このJSON設定の"mcpServers"セクションに、MCP-Inscriptionサーバーのエントリを追加します。例:
{ "mcpServers": { "mcp-inscription": { "command": "node", "args": ["/absolute/path/to/mcp-inscription/build/cli.js"] } } }上記のスニペットで、
"mcp-inscription"はサーバーの識別子です(任意の名前を付けることができます)。//absolute/path/to/mcp-inscriptionリポジトリをクローンした場所への実際のフルパスに置き換えてください。Claude Desktopを再起動します。claude_desktop_config.jsonファイルを保存し、 Claude Desktopを閉じて再度開きます。次回起動時に、Claudeは設定に従ってMCP-Inscriptionサーバー
claude_desktop_config.json自動的に起動します。Claude Desktopが起動していた場合は、変更を有効にするために再起動する必要があります。
Claudeデスクトップ統合のテスト
Claude Desktop を再起動すると、MCP-Inscription サーバーが正しく動作しているかどうかをテストできます。
応答を確認してください。Claudeは詳細な回答(例えば、刻印自体やルーン情報など)をエラーなく返すはずです。エラーメッセージが表示されたり、有効な応答がない場合は、MCP サーバーに正しく接続されていない可能性があります。
Claude のログを確認する(必要な場合): Claude Desktop は、MCP 統合のデバッグに役立つログファイルを提供します。ツールが応答しない場合は、以下のログファイルを確認してください。
macOS:
~/Library/Logs/Claude/Windows:
%APPDATA%\Claude\logs\
一般的なMCP接続メッセージについてはmcp.logを、MCPサーバーの出力/エラーについてはmcp-server-mcp-inscription.log(または任意の名前)というファイルを参照してください。これらのログには、サーバーが起動したかどうか、またはエラー(パスの誤りやサーバー内の例外など)が発生したかどうかが表示されます。エラーが発生した場合は、必要に応じて設定または環境を修正し、Claude Desktopを再起動して再度テストしてください。
📂 プロジェクト構造
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📦 利用可能なツール
序数を表示
説明:
トランザクションの証人データから序数表記データをデコードします。
入力スキーマ:
{
"txid": "string"
}入力例:
{
"txid": "0169d12c4edf2026a67e219c10207438a080eb82d8f21860f6784dd66f281389"
}出力:
デコードされた碑文コンテンツを返します。テキスト、JSON、HTML、その他の形式である可能性があります。
🚨 エラー処理
サーバーは、ビットコイン操作とブロックチェーンクエリを処理するためにカスタムエラータイプを採用しています。詳細なエラーメッセージはPinoを使用して記録され、クライアントのレスポンスに含まれるため、デバッグが容易になります。
🤝 貢献する
貢献や機能リクエストは大歓迎です! お気軽に GitHub でプルリクエストを送信したり、問題を報告してください。
📝 ライセンス
このプロジェクトはMIT ライセンスに基づいてライセンスされています。
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