Aspen Catalog MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ASPEN_API_KEY1 | No | First part of the API token pair if using token-based authentication. | |
| ASPEN_API_KEY2 | No | Second part of the API token pair if using token-based authentication. | |
| ASPEN_BASE_URL | No | Your library's Aspen catalog URL (e.g. https://catalog.faylib.org) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_catalogC | Search the library catalog for books, DVDs, audiobooks, and other materials. Returns titles, authors, formats, and availability links. |
| check_availabilityA | Check if a specific book or title is available at the library. Useful for filtering book recommendations to only those the library carries. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: check_availability verifies if a specific book/title is available, while search_catalog performs broader searches across materials. There is no overlap in functionality, making it easy for an agent to choose the right tool based on the task.
Both tools follow a consistent verb_noun pattern (check_availability and search_catalog) with clear, descriptive names. The naming style is uniform throughout, using snake_case and action-oriented verbs that accurately reflect each tool's purpose.
With only 2 tools, the server feels under-scoped for a library catalog system. While the tools cover basic search and availability checks, typical catalog operations like borrowing, reserving, or managing user accounts are missing, making the set too thin for comprehensive library interactions.
The tool surface is significantly incomplete for a library catalog domain. It lacks essential operations such as borrowing/returning items, placing holds, managing user profiles, or accessing detailed item metadata. This creates dead ends for agents trying to perform common library tasks beyond basic searching.