This server lets AI assistants search the Digital Guitar Archive and retrieve bibliographic records and source-library information.
Search records using full-text queries or filters for title, author, publisher, and source library (RISM sigla), with a configurable result limit.
Retrieve full bibliographic details for a specific record by its numeric ID.
List all source libraries, including their RISM sigla, record counts, and location information.
Connect to the live Digital Guitar Archive API, with configurable API URL and request timeout.
Click on "Deploy 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., "@Digital Guitar Archive MCP Server Search for 19th-century guitar sheet music by Mauro Giuliani"
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.
This MCP (Model Context Protocol) server provides AI assistants with tools to search, browse, and retrieve records from the Digital Guitar Archive.
The server is pre-configured to connect to the Digital Guitar Archive API at https://digitalguitararchive.com/archive/api.
search_guitar_archive — Search for records with full-text search, field-specific filters, and pagination
browse_by_source — Browse records from a specific source library (RISM sigla) with pagination
get_record_details — Get full bibliographic details for a specific record by ID
list_sources — List all source libraries (RISM sigla) with record counts and location info
list_collections — List known collections by Local ID with human-readable collection names (some collections are private holdings or journals, not RISM library sigla)
research_library_collection — Guided workflow to research guitar repertoire from a specific library or collection
archive://record/{id} — Direct access to a single archive record by ID
Related MCP server: heritage-research-mcp
Environment Variable | Description | Default |
| Base URL of the Digital Guitar Archive API |
|
| Timeout for API requests in milliseconds |
|
Node.js 18+ (with native fetch support)
npm
cd mcp
npm install
npm run buildClaude Desktop launches the MCP server automatically. Add the following to your configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"guitar-archive": {
"command": "node",
"args": ["/path/to/mcp/dist/mcp-server.js"]
}
}
}Replace /path/to/mcp/ with the absolute path to your mcp folder.
{
"mcpServers": {
"guitar-archive": {
"command": "node",
"args": ["/path/to/mcp/dist/mcp-server.js"],
"env": {
"REQUEST_TIMEOUT_MS": "30000"
}
}
}
}After updating the configuration, restart Claude Desktop for the changes to take effect.
To test the server manually:
npx ts-node src/mcp-server.tsNote: When running with stdio transport, the server communicates via stdin/stdout and won't produce visible output. The server acts as a proxy to the live production API.
The Source field is a RISM library sigla, but not every collection lives in a library — some are private holdings or journals. The Local ID field carries the actual collection identifier, resolved to a readable name via list_collections and shown as Collection in get_record_details (and appended to the source in search/browse results when present).
Search and browse tools support pagination via limit (max 100) and offset (0-based). The result summary indicates the range of records returned out of the total matching set.
ISC
Get full details for a specific record by its ID
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | Yes | The ID of the record to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves details but does not specify whether it's a read-only operation, potential error conditions (e.g., invalid ID), rate limits, or authentication needs. This leaves significant gaps in understanding the tool's behavior.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It does not explain what 'full details' entail, potential return formats, or error handling, which are crucial for a tool that retrieves data. The simplicity of the tool (one parameter) mitigates this slightly, but key behavioral aspects are missing.
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?
The schema description coverage is 100%, with the parameter 'record_id' fully documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., format examples or constraints), so it meets the baseline score for high schema coverage without extra value.
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 verb ('Get') and resource ('full details for a specific record'), making the purpose unambiguous. However, it does not explicitly differentiate this tool from its siblings (list_sources, search_guitar_archive), which might involve similar data retrieval but for different resources or scopes.
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. It lacks context about prerequisites (e.g., needing a valid record ID), exclusions, or comparisons to sibling tools, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all source libraries (RISM sigla) in the archive with record counts and location info
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what data is returned without disclosing behavioral traits like pagination, rate limits, authentication needs, or whether the list is static or dynamic. It mentions 'all' sources but doesn't clarify if this includes archived or inactive ones.
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 a single, well-structured sentence that efficiently conveys the tool's purpose and output details without any redundant or unnecessary information. It is front-loaded and appropriately sized for a simple tool.
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?
For a tool with 0 parameters, no annotations, and no output schema, the description adequately explains what the tool does but lacks completeness regarding behavioral context (e.g., response format, error handling). It covers the basics but leaves gaps that could hinder effective use by an AI agent.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, focusing on the tool's purpose instead, which meets the baseline for this scenario.
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 ('Get a list') and resource ('all source libraries (RISM sigla) in the archive'), specifying what information is included ('record counts and location info'). It distinguishes itself from siblings by focusing on listing sources rather than getting details or searching, though it doesn't explicitly name alternatives.
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 implies usage for retrieving a comprehensive list of sources with metadata, but provides no explicit guidance on when to use this tool versus alternatives like 'search_guitar_archive' for filtered queries. It lacks any mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Digital Guitar Archive for records. Supports full-text search and field-specific filters.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Full text search across all fields | |
| title | No | Search by title only | |
| author | No | Search by author only | |
| source | No | Filter by source/library (RISM sigla, e.g. US:Wc) | |
| publisher | No | Search by publisher | |
| limit | No | Max results to return (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions search capabilities but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or what the return format looks like (e.g., pagination, error handling). For a search tool with zero annotation coverage, this is a significant gap.
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 a single, efficient sentence that front-loads the core purpose ('Search the Digital Guitar Archive for records') and adds a useful detail ('Supports full-text search and field-specific filters') without any wasted words. It's appropriately sized for the tool's complexity.
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 moderate complexity (6 parameters, no output schema, no annotations), the description is incomplete. It lacks information on behavioral traits, output format, and usage guidelines relative to siblings. While the schema covers parameters well, the description doesn't compensate for missing annotations or output details, making it inadequate for full agent understanding.
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%, meaning all parameters are documented in the schema itself. The description adds minimal value by mentioning 'full-text search and field-specific filters,' which aligns with parameters like 'q' and others but doesn't provide additional syntax, format details, or usage examples beyond what the schema already covers.
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') and resource ('Digital Guitar Archive for records'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_record_details' or 'list_sources' beyond implying it's a search function rather than a detail retrieval or listing tool.
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 mentions 'Supports full-text search and field-specific filters,' which implies usage context but doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_record_details' or 'list_sources.' No exclusions or prerequisites are stated, leaving the agent to infer appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_record_detailslist_sourcessearch_guitar_archiveScored across 3 tools
Each tool has a clearly distinct purpose with no overlap: get_record_details retrieves a specific record, list_sources provides metadata about source libraries, and search_guitar_archive performs queries across the archive. The descriptions clearly differentiate between individual record access, source cataloging, and search functionality.
All three tools follow a consistent verb_noun pattern with snake_case naming: get_record_details, list_sources, and search_guitar_archive. The naming is predictable and follows the same structural convention throughout the tool set.
With only 3 tools, the server feels somewhat thin for an archive management domain. While the tools cover basic access patterns (get, list, search), typical archive operations like creating, updating, or deleting records are missing, suggesting the surface may be incomplete rather than optimally scoped.
For a digital archive server, there are significant gaps in CRUD/lifecycle coverage. The tools only provide read-only operations (get, list, search) with no ability to create, update, or delete records. This will cause agent failures when trying to perform basic archive management tasks beyond querying existing data.
A read-only verified record of agent-operable GTM tools: search, fetch, compare, track changes.
Search ATProto writing, annotations, identity, agents, and forum posts. 12 read-only tools.
Find AI design tools, compare catalog records, and inspect stored evidence and limitations.
Search and read the aicoolies catalog of AI and developer tools via a remote MCP knowledge graph.