Skip to main content
Glama
smeet666

mcp-stashbox

Search performers

search_performers
Read-only

Search performers across all configured stash-box catalogues using text queries or structured filters, with paginated results from each catalogue.

Instructions

Search performers across every configured stash-box catalogue. Two exclusive paths: 'query' runs each catalogue's own text index, which reads the words as a union, and the typed arguments narrow as an intersection. Writing both is refused. The answer says per catalogue which of three it met: a failure, a catalogue nobody asked, and an emptiness it established. Counts are never added across them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
pageNoWhich page of its own order every catalogue asked is read at, counted from 1. A search written with words alone reads the first rows each text index answers with, since those routes take no page.
sortNo
aliasNoNo catalogue's faceted route applies it, though every faceted input declares it: a request carrying it answers as wide as one carrying none, so it is never sent and the answer names it as a narrowing nobody received.
limitNoHow many rows one page of one catalogue carries. An answer holding several carries up to this many from each: their pages are their own and nothing here interleaves them into one.
queryNoWords for the catalogue's own text index, which reads them as a union. It is exclusive with the typed arguments, which narrow as an intersection.
genderNo
countryNo
sourcesNo
directionNo
ethnicityNo
studio_idNo
birth_yearNo
disambiguationNo
performed_withNo
career_end_yearNoNo catalogue's faceted route applies it, though every faceted input declares it: a request carrying it answers as wide as one carrying none, so it is never sent and the answer names it as a narrowing nobody received.
career_start_yearNoNo catalogue's faceted route applies it, though every faceted input declares it: a request carrying it answers as wide as one carrying none, so it is never sent and the answer names it as a narrowing nobody received.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesYes
cachedNoReplayed from this client's store.
windowNoThe page and the row limit this answer was read at, absent where no catalogue answered.
resultsYes
orderingYesHow the rows were laid out, which a reader needs before reading the first.
per_sourceYes
result_countYesHow many rows this page carries.
Install Server

TDQS

A4.2/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations (readOnlyHint: true, openWorldHint: true) already establish safety and open-world semantics. The description goes well beyond, revealing exclusive paths, the refusal when both are written, per-catalogue response states ('a failure, a catalogue nobody asked, and an emptiness it established'), non-summation across catalogues, and the behavior of no-op parameters like alias.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Remarkably compact for a description covering such conceptual terrain, front-loading purpose and then detailing behavior efficiently. The unusual phrasing 'a catalogue nobody asked, and an emptiness it established' is striking but slightly confusing without clearer syntax, and the description remains dense yet occasionally opaque, costing it a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 17 parameters, multi-catalogue fan-out, and exclusive query modes, the description captures the critical behaviors—union vs intersection semantics, exclusivity rules, per-catalogue response consistency—that an agent must understand to invoke it correctly. The output schema correctly handles return-value details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 35%, so the description carries a heavy burden. It delivers an excellent conceptual framework explaining 'query' (union) vs typed args (intersection) and exclusivity, but with 10 of 17 parameters undocumented and uncovered by the main description, it cannot fully compensate. The framework elegantly covers the crucial conceptual model without resolving all gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

'Search performers across every configured stash-box catalogue' precisely states verb, resource, and the distinguishing scope of multi-catalogue search. It clearly differentiates from sibling search tools by stressing 'across every configured stash-box catalogue,' something search_scenes, search_studios, and search_tags would not do.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong internal guidance on when to use the 'query' path vs typed arguments (union vs intersection, mutually exclusive). It implicitly communicates when to use the tool but never explicitly names alternatives or states conditions for choosing it over get_performer or sibling search tools, leaving the exclusion logic unexplained.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Other Tools

Latest Blog Posts

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/smeet666/mcp-stashbox'

If you have feedback or need assistance with the MCP directory API, please join our Discord server