mcp-stashbox
Related Servers
Alternatives to mcp-stashbox
No user-submitted related servers found.
Related Servers
- AlicenseCqualityBmaintenanceAn MCP server for querying and analyzing a Stash instance with advanced filters, caching, and personalized recommendations.716Apache 2.0
- AlicenseBqualityDmaintenanceMCP server for Stash that provides tools, resources, and prompts to query, analyze, and manage a Stash instance, with advanced filtering, caching, and personalized recommendations.7Apache 2.0
- AlicenseAqualityBmaintenanceThis MCP server provides tools to search for songs, artists, and random records from the Bide & Musique catalogue. It offers read-only access to tens of thousands of French songs with no authentication needed.5240 npmMIT
- AlicenseNot gradedqualityCmaintenanceA comprehensive MCP server for querying the MusicBrainz database, providing tools to search for artists, releases, recordings, and browse music metadata.4MIT
- AlicenseBqualityDmaintenanceAn MCP server for obtaining the README content, metadata and search function of CPAN packages.31Apache 2.0
- FlicenseNot gradedqualityCmaintenanceA remote MCP server for the Arxpot processing core, enabling music search, metadata retrieval, and download management with remote storage delivery.-
TDQS
Scored across 10 tools
The set is neatly partitioned by verb (search_* vs get_*) and by entity type (scenes, performers, studios, tags), so selection is almost always obvious. The only soft edge is find_by_fingerprint, which reaches records that are then rendered like scene cards, making it slightly confusable with get_scene at the point of consumption; get_sources is clearly separate as install metadata.
Names are uniformly snake_case and verb-led, with a clean search_<entity> / get_<entity> symmetry across the four entity types. find_by_fingerprint and get_sources break the verb_noun shape slightly (prepositional compound, and a non-entity noun), which is a minor deviation rather than an inconsistency.
Ten tools is well within the ideal range and every tool earns its place: four entity searches, four entity reads, one hash lookup, and one configuration/health inspection. Nothing looks redundant or bolted on for a read-only cross-catalogue facade.
The read lifecycle is covered end to end for all four entity types: discover via search, resolve via get with cross-catalogue merge, plus fingerprint-based file identification and catalogue introspection. The main gap is the absence of an unfiltered browse/list operation — if a caller has no query terms or typed filters, there is no way to page through a catalogue's contents, and there are no tools for traversing relations (e.g. scenes by performer) beyond whatever filters the search schemas accept.