LCSH MCP Server
LCSH MCP サーバー
シンプルな API インターフェースを通じて Library of Congress Subject Headings (LCSH) へのアクセスを提供する Model Context Protocol (MCP) サーバー。
概要
このMCPサーバーは、ClaudeのようなAIアシスタントが、公開されているsuggest2 APIを使用して、米国議会図書館件名標目表(LCSH)を検索することを可能にします。LCSHデータのクエリと、APIからの様々なレスポンス形式を処理するための、簡潔なインターフェースを提供します。
Related MCP server: MeSH MCP
インストール
オプション 1: PyPI からインストールする (推奨)
LCSH MCP サーバーをインストールする最も簡単な方法は、PyPI から直接インストールすることです。
pip install lcsh-mcp-serverオプション2: ソースからインストールする
ソースからインストールしたい場合:
git clone https://github.com/kltng/lcsh-mcp-server.git
cd lcsh-mcp-server
pip install -e .Claude Desktop の設定
Claude Desktop をまだインストールしていない場合は、 https://claude.ai/desktopからインストールしてください。
上記のインストール方法のいずれかを使用して、 LCSH MCP サーバーをインストールします。
Claude Desktop を開き、[設定] に移動します。
左下のプロフィール写真をクリックします
メニューから「設定」を選択します
MCP サーバーを構成します。
設定パネルで「MCPサーバー」をクリックします。
「サーバーを追加」をクリックします
以下の詳細を入力してください。
名前:
LCSH Searchコマンド:
lcsh-mcp-server
「保存」をクリック
サーバーを有効にする:
LCSH検索サーバーの横にあるスイッチを切り替えて有効にします
クロードはLCSHの検索機能にアクセスできるようになります
クロードとLCSH MCPサーバーの使用
Claude Desktopでサーバーをセットアップして有効化したら、ClaudeにLibrary of Congress Subject Headingsの検索を依頼できます。以下にプロンプトの例を示します。
「議会図書館の件名表で『人工知能』を検索できますか?」
「LCSHで『気候変動』を調べて、正式な件名を教えてください。」
「「量子コンピューティング」に関連する LCSH 用語は何ですか?」
Claude は MCP サーバーを使用して LCSH データベースを照会し、結果を返します。
特徴
MCPツール統合: AIアシスタントが使用できる
search_lcshツールを公開しますリソースエンドポイント:
lcsh://search/{query}でリソースエンドポイントを提供します。堅牢なエラー処理: APIエラー、接続の問題、予期しない応答形式を適切に処理します。
複数の応答形式: LCSH API からの辞書 (ヒット) とリスト応答形式の両方をサポートします。
トラブルシューティング
MCP サーバーで問題が発生した場合:
サーバーステータスの確認: Claude Desktopで、[設定] > [MCPサーバー]に移動し、サーバーが有効になっていて実行されているかどうかを確認します。
サーバーの再起動: サーバーの電源をオフにしてから再度オンにします
コンソール出力を確認する: サーバーを手動で実行している場合は、コンソール出力にエラーメッセージがないか確認してください。
ネットワーク接続の確認: LCSH API にアクセスするために、コンピュータがアクティブなインターネット接続を持っていることを確認してください。
ライセンス
このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細については LICENSE ファイルを参照してください。
開発者向け
サーバー実装、API リファレンス、テスト情報に関する詳細なドキュメントについては、 references.mdファイルを参照してください。
Available Tools
1 toolsearch_lcshC
Search Library of Congress Subject Headings (LCSH) using the public suggest2 API. Returns a dictionary with the top results.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the API source ('public suggest2 API') and return type ('dictionary with the top results'), but lacks details on error handling, rate limits, authentication needs, or what 'top results' entails (e.g., ranking criteria, number of results). This leaves behavioral gaps for a search tool.
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 concise with two sentences, front-loading the main action and resource. It avoids unnecessary words, though it could be slightly more structured (e.g., separating API details from return values). Every sentence contributes meaning, making it efficient.
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 the tool's complexity (a search operation with no annotations, 0% schema coverage, and no output schema), the description is incomplete. It omits parameter details, behavioral traits like error handling, and specifics on the return value (e.g., dictionary structure). This is inadequate for effective tool use.
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 0%, so the description must compensate. It does not mention the 'query' parameter at all, failing to explain its purpose, format, or constraints. The description adds no semantic value beyond what the bare schema provides, leaving the parameter undocumented.
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 clearly states the action ('Search Library of Congress Subject Headings') and the resource (LCSH), with the specific verb 'search' and target 'LCSH'. It distinguishes itself by mentioning the 'public suggest2 API', though there are no sibling tools for comparison. The purpose is specific and unambiguous.
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 no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. It mentions the 'public suggest2 API', but does not explain its context or limitations. With no sibling tools, this is less critical, but still lacks usage context.
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 tool update
v1.0.0- First observed
search_lcsh
TDQS
Scored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'search_lcsh' has a clearly defined and distinct purpose.
The naming follows a consistent verb_noun pattern with 'search_lcsh'. With only one tool, there is no inconsistency to evaluate, and the pattern is clear and appropriate.
A single tool is too few for a server focused on LCSH, as it lacks basic operations like browsing, filtering, or retrieving detailed subject information. This minimal set limits functionality and agent workflows.
The server is severely incomplete for LCSH operations; it only offers search without supporting actions like get_subject_details, list_subjects_by_category, or related term lookups. This creates significant gaps for agent tasks.
Maintenance
Related MCP Connectors
Curated knowledge API for AI agents - skill packs, semantic search, validated patterns.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Search US grants + federal contracts (Grants.gov + SAM.gov) from any LLM.
Academic literature search, retrieval, and private library management on top of OpenAlex.
Related MCP Servers
- AlicenseAqualityDmaintenanceExposes CDISC standards data including SDTM, ADaM, CDASH, and Controlled Terminology as tools for AI assistants via the CDISC Library API. It enables users to search standards, retrieve domain variables, and access codelist definitions to facilitate clinical research data management.12MIT
- AlicenseAqualityDmaintenanceConnects Claude to the U.S. National Library of Medicine MeSH APIs to search and retrieve medical authority data, descriptors, and qualifiers. It enables library and metadata staff to perform subject analysis and confirm terminology within an AI-assisted cataloging workflow.41GPL 3.0
- FlicenseAqualityDmaintenanceConnects AI assistants to the Open Library API for searching books and authors, retrieving metadata, and comparing works.12-
- AlicenseNot gradedqualityCmaintenanceProvides access to the Library of Congress (loc.gov) data, enabling AI agents to search and retrieve information from the world's largest library.3 npmMIT