Click on "Install 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., "@Stash MCP Server Recommend me some scenes based on my preferences and recent watches."
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.
An MCP (Model Context Protocol) server that provides a concise set of tools to query and analyze an Stash instance with composable, high‑precision filters, optimized caching for faster queries, automated intelligence for performer/scene analysis, and personalized recommendations based on usage and preferences.
Prompt | Description | Parameters |
analyze-performer | Complete performer analysis with insights |
|
library-insights | Strategic insights for the entire library | — |
recommend-scenes | Personalized scene recommendations |
|
discover-performers | Performer discovery by criteria |
|
Resource | Description | URI |
All performers | List of all favorite performers with basic info |
|
Performers Information | Detailed information about a specific performer |
|
Performers by Country | List of performers filtered by country |
|
Performers by Ethnicity | List of performers filtered by ethnicity |
|
Performers Statistics | Statistical summary of all performers |
|
Resource | Description | URI |
All studios | List of all favorite studios with basic info |
|
Studio Information | Detailed information about a specific studio |
|
Studios Statistics | Statistical summary of all studios |
|
Resource | Description | URI |
All tags | List of all favorite tags with basic info |
|
Tag Information | Detailed information about a specific tag |
|
Tags Statistics | Statistical summary of all tags |
|
Tool | Description | Parameters |
advanced_performer_analysis | Deep analysis with progress and logging |
|
batch_performer_insights | Aggregated insights from multiple performers |
|
health_check | Basic connectivity/cache status | — |
get_performer_info | Detailed performer information |
|
get_all_performers | List performers with advanced filtering |
|
get_all_scenes_from_performer | Scenes for a performer |
|
get_all_scenes | List all scenes with optional filters | advanced filters (see "Advanced Filters" section) |
get_all_performersThis tool now supports advanced filtering by multiple physical and demographic criteria:
favorites_only: bool = True - Limit to favorite performers
country: str - Filter by country
ethnicity: str - Filter by ethnicity
eye_color: str - Filter by eye color
hair_color: str - Filter by hair color
measurements: str - Filter by body measurements
piercings: str - Filter by piercings
tattoos: str - Filter by tattoos
height_cm: int - Filter by height in centimeters
weight: int - Filter by weight
Each filter supports modifiers for different comparison types:
EQUALS (default) - Exact match
NOT_EQUALS - Not equal
GREATER_THAN - Greater than (numeric only)
LESS_THAN - Less than (numeric only)
BETWEEN - Between two values (numeric only, requires _value2)
NOT_BETWEEN - Not between two values (numeric only, requires _value2)
For BETWEEN and NOT_BETWEEN filters:
height_cm_value2: int - Second value for height range
weight_value2: int - Second value for weight range
The server provides dedicated resources to access performers information in multiple formats:
stash://performer/all - Lists all favorite performers with basic information
Returns: Name, country, ethnicity, height, weight, and associated tags
Use case: Get a quick overview of all favorite performers
stash://performer/{name} - Detailed information for a specific performer
Parameters: {name} - Exact performer name
Returns: Complete profile including demographics, physical characteristics, bio, and tags
Use case: Get comprehensive information about a specific performer
stash://performer/country/{country} - Filter performers by country
Parameters: {country} - Country name or code (e.g., "USA", "ES")
Returns: List of performers from the specified country with ethnicity
Use case: Discover performers from a specific country
stash://performer/ethnicity/{ethnicity} - Filter performers by ethnicity
Parameters: {ethnicity} - Ethnicity name (e.g., "Caucasian", "Asian")
Returns: List of performers with the specified ethnicity and their countries
Use case: Find performers matching specific ethnic characteristics
stash://performer/stats - Statistical summary of the performer database
Returns:
Total number of favorite performers
Geographic distribution (countries and counts)
Ethnic distribution
Physical statistics (average height and weight ranges)
Use case: Analyze the composition and diversity of your performer collection
The server supports flexible configuration through environment variables:
Variable | Default | Description |
|
| Stash server endpoint |
| — | Required API key (mandatory) |
|
| Initial connection retries |
|
| Delay between retries (seconds) |
|
| Filter resources by favorites only |
|
| Log level: DEBUG, INFO, WARNING, ERROR |
Copy the example environment file:
cp .env.example .envEdit .env with your settings:
STASH_ENDPOINT=http://localhost:9999
STASH_API_KEY=YOUR_API_KEYRelated MCP server: codeweaver-mcp
Clone the repository and install with uv:
git clone https://github.com/donlothario/stash_mcp_server.git
cd stash_mcp_server
cp .env.example .env
# Edit .env file with your Stash settings
uv syncOr install directly from the repository:
uv add git+https://github.com/donlothario/stash_mcp_server.gitInstall the package in mode:
git clone https://github.com/donlothario/stash_mcp_server.git
cd stash_mcp_server
cp .env.example .env
# Edit .env file with your Stash settings
python3 -m pip install .Or install directly from the repository:
python3 -m pip install git+https://github.com/donlothario/stash_mcp_server.gitBuild the image:
docker build -t stash_mcp_server:latest .Pull the latest image from the Docker registry:
docker pull ghcr.io/donlothario/stash_mcp_server:latestuv run stash_mcp_serverpython3 -m stash_mcp_serverAdd this configuration to your application's settings (mcp.json):
"stash mcp server": {
"type": "stdio",
"command": "uv",
"args": [
"run",
"--directory",
"/path/to/stash_mcp_server",
"stash_mcp_server"
],
"env": {
"STASH_ENDPOINT": "http://localhost:9999",
"STASH_API_KEY": "YOUR_API_KEY",
}
}"stash mcp server": {
"type": "stdio",
"command": "python3",
"args": [
"-m",
"stash_mcp_server"
],
"env": {
"STASH_ENDPOINT": "http://localhost:9999",
"STASH_API_KEY": "YOUR_API_KEY",
}
}"stash mcp server": {
"type": "stdio",
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--env-file",
"${workspaceFolder}/.env",
"ghcr.io/donlothario/stash_mcp_server"
]
}Connection to Stash is performed with configurable retries.
If the API key is missing, the server generates an error and does not start.
GraphQL fragments used by queries are centralized in the code (FRAGMENTS).
Improved cache architecture: Cache functions are separated from MCP decorators to avoid conflicts with Pydantic schema generation.
Advanced filtering: Robust filter system with modifiers and range handling for complex queries.
Enhanced logging: Detailed information about active filters and query results for better debugging.
Advanced performer analysis with progress reporting and contextual logging
| Name | Required | Description | Default |
|---|---|---|---|
| performer_name | Yes | ||
| include_similar | No | ||
| deep_scene_analysis | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the description does not need to repeat that. It adds 'progress reporting and contextual logging', which hints at potential long-running behavior or internal logging, but these are vague. No contradiction with annotations, but the added context is minimal.
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 sentence but is under-specified. It is short but not effectively concise because it omits critical information; the sentence does not earn its place by conveying substantive meaning.
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?
The description is incomplete for a tool with 3 parameters and an output schema. While the output schema covers return values, the description fails to define what 'advanced analysis' actually does, when to use it, or how parameters affect the result. Minimal context is provided beyond annotations.
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%, and the description mentions none of the parameters. It neither explains performer_name nor the boolean flags (include_similar, deep_scene_analysis), leaving the agent without any semantic guidance for invocation.
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 basically restates the tool name ('Advanced performer analysis') and adds a vague phrase ('with progress reporting and contextual logging') that does not explain what analysis is performed or how it differs from sibling tools like get_performer_info or batch_performer_insights. The verb is missing, leaving the tool's specific action unclear.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or exclusions, making it impossible for an agent to decide between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates insights for multiple performers with detailed progress
| Name | Required | Description | Default |
|---|---|---|---|
| max_performers | No | ||
| performer_names | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and openWorldHint=false covers safety. The description adds 'detailed progress' which hints at a long-running operation, but this is not elaborated. No mention of rate limits, resource usage, or what happens on partial failures.
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 sentence, which is concise, but it is under-specified rather than effectively concise. It lacks any structuring of information beyond a generic statement, and the phrase 'detailed progress' adds ambiguity.
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?
An output schema exists, so return values are documented. However, for a batch operation with multiple performers, the description does not explain how to specify them, performance implications of max_performers, or failure behavior. Given the complexity, the description is too sparse to be complete.
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% for both parameters. The description provides no information about what 'performer_names' or 'max_performers' mean or how they affect the output. Since coverage is low, the description should compensate, but it does not.
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 uses a specific verb 'Generates' and identifies the resource 'insights for multiple performers', which clearly distinguishes it from single-performer tools like get_performer_info. However, 'insights' and 'detailed progress' are somewhat vague, lacking specifics about what kind of insights are produced.
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 tool name and description imply batch use for multiple performers, but no explicit guidance is given about when to choose this over alternatives like advanced_performer_analysis or get_performer_info. There are no exclusions or stated conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a list of performers with advanced filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| weight | No | ||
| country | No | ||
| tattoos | No | ||
| ethnicity | No | ||
| eye_color | No | ||
| height_cm | No | ||
| piercings | No | ||
| hair_color | No | ||
| measurements | No | ||
| weight_value2 | No | ||
| favorites_only | No | ||
| weight_modifier | No | EQUALS | |
| country_modifier | No | EQUALS | |
| height_cm_value2 | No | ||
| ethnicity_modifier | No | EQUALS | |
| eye_color_modifier | No | EQUALS | |
| height_cm_modifier | No | EQUALS | |
| hair_color_modifier | No | EQUALS | |
| measurements_modifier | No | EQUALS |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation declares readOnlyHint=true, so the safety profile is covered. The description does not contradict this and adds that the tool has 'advanced filtering options,' but it does not disclose any additional behavioral traits such as pagination, default limits, or ordering. Since annotations already cover the read-only nature, a 3 is appropriate.
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, front-loaded sentence that is concise and to the point. Every word is necessary, and it is not bloated.
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?
Despite having an output schema, the tool has 19 parameters with no descriptions in the schema. The description does not explain how to effectively use the filtering options, the meaning of modifiers, or the relationship between value and value2 fields. The tool is complex, and the description is too sparse to provide complete guidance.
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. However, it only mentions 'advanced filtering options' without explaining any of the 19 parameters, their modifiers, or how value2 fields work for ranges. This leaves the agent to infer all parameter semantics from names and defaults, which is insufficient.
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 tool returns a list of performers and mentions advanced filtering options. The resource (performers) and verb (return/list) are specific, and the name 'get_all_performers' reinforces the action. This distinguishes it from siblings like get_performer_info (single performer) and get_all_scenes (scenes).
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 the tool is for listing performers with filters, which is clear context. However, it does not explicitly mention alternatives or exclusions, such as using get_performer_info for a single performer. It provides a clear usage context without exclusions, earning a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all scenes from Stash with advanced filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| max_rating | No | ||
| min_rating | No | ||
| exclude_tags | No | ||
| include_tags | No | ||
| organized_only | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds that filtering options exist but does not disclose specifics like the default for organized_only or how include_tags/exclude_tags interact. No contradiction with annotations, and some value is added, but behavioral detail is limited.
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, front-loaded sentence that states the purpose without wasted words. It is highly concise and appropriately structured for a simple list-returning 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?
An output schema exists, so return values are covered elsewhere. However, with five filtering parameters and related sibling tools, the description would benefit from at least noting what the filters do and when to use this tool versus get_all_scenes_from_performer. It is minimally complete but lacks contextual depth.
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%, and the description does not explain any of the five parameters. While parameter names like max_rating and exclude_tags are somewhat self-explanatory, the description adds no meaning beyond the raw schema, and the phrase 'advanced filtering options' does not clarify semantics.
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 tool returns all scenes from Stash, with 'advanced filtering options' indicating additional scoping. It distinguishes itself from the sibling get_all_scenes_from_performer by noting it returns ALL scenes rather than a subset, though it does not explicitly name that alternative.
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?
There is no guidance on when to use this tool versus alternatives such as get_all_scenes_from_performer. The description does not specify preferred contexts, exclusions, or prerequisites, leaving the agent to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all scenes for a given performer
| Name | Required | Description | Default |
|---|---|---|---|
| organized_only | No | ||
| performer_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'all scenes' but the input schema includes organized_only with a default of true, meaning the default behavior excludes unorganized scenes. The description does not disclose this filter, which is misleading about the result set. The readOnlyHint annotation covers safety, but the behavioral nuance is missing.
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 concise sentence that conveys the core purpose without any filler. It is appropriately size 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?
Although the tool has a readOnlyHint and an output schema, the description fails to mention the organized_only default filter, which is essential to understanding what 'all scenes' means. This is a notable gap, but other contextual signals (sibling tools, output schema) help fill in some context.
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%, and the description does not explain the organized_only parameter at all. It only implies performer_name via 'given performer'. The default behavior of organized_only, which significantly changes results, is left entirely to the schema.
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 ('Return') and the resource ('all scenes for a given performer'). It is unambiguous and distinguishes this tool from siblings like get_all_scenes, which has no performer filter.
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 phrase 'for a given performer' provides clear context for when to use this tool. However, it does not explicitly mention alternatives or when-not-to-use, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return detailed information for a single performer
| Name | Required | Description | Default |
|---|---|---|---|
| performer_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description aligns with this by using 'Return.' No additional behavioral context is provided, such as behavior for missing performers or exact-match requirements, which would add value beyond the annotations. A score of 3 is appropriate given the annotation coverage.
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, front-loaded sentence with no unnecessary words. It is appropriately sized for a simple read-only lookup tool, 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 tool's low complexity (one parameter, read-only annotation, and an output schema), the description sufficiently conveys the core purpose. The output schema likely covers return details, so the lack of return description is acceptable. However, edge-case behavior like missing performers is not mentioned, which slightly reduces completeness.
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 has 0% description coverage for the single parameter performer_name, and the description does not explicitly explain it. The phrase 'for a single performer' implies the name identifies the performer, but no format, ambiguity, or case-sensitivity information is given. The description fails to compensate for the lack of schema documentation.
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 states 'Return detailed information for a single performer,' which specifies a clear verb and resource, and distinguishes from siblings like get_all_performers and get_all_scenes_from_performer. However, 'detailed information' is somewhat vague, so it does not fully capture the scope of the returned data.
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?
There is no guidance on when to use this tool versus alternatives such as advanced_performer_analysis or batch_performer_insights. The description does not mention any exclusions or conditions for use, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return basic health/connectivity information for the MCP server
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds minimal context (server-wide scope), but doesn't disclose response details; however, the output schema likely covers those. This is adequate but not exceptional given the existing annotations.
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, concise sentence that immediately delivers the purpose. No wasted words or unnecessary elaboration.
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 has no parameters and includes an output schema, the description is complete. It fully conveys the purpose and scope of the operation without needing extra guidance.
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?
There are zero parameters, and the input schema is empty. The baseline for 0 parameters is 4, as there is nothing to explain. The description adds no parameter-specific detail, but none is needed.
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 tool's function: returning basic health/connectivity information for the MCP server. This specific verb-resource pairing makes it easy to distinguish from sibling tools, which all focus on performer data.
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 a clear use case: checking server health/connectivity. While it doesn't explicitly mention alternatives or when not to use it, the sibling tools are entirely unrelated, so there is little risk of confusing this with another tool.
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. Dates show when Glama detected each change.
v0.3.1advanced_performer_analysisbatch_performer_insightsget_all_performersget_all_scenesget_all_scenes_from_performerget_performer_infohealth_checkThere is some overlap between get_all_scenes and get_all_scenes_from_performer, as the former likely supports filtering by performer. The two analysis/insight tools also have similar purposes, which could cause selection confusion.
Tool names largely follow a consistent get_ prefix pattern for retrieval operations, but health_check and the analysis tools (advanced_performer_analysis, batch_performer_insights) deviate from this convention. Overall, naming remains predictable and readable.
With 7 tools, the server is well-scoped for its domain. Each tool serves a distinct function, and the count is appropriate for a focused MCP server without being excessive or too sparse.
The server covers performer retrieval and analysis well, but scene support is incomplete: there is no get_single_scene equivalent to get_performer_info. Missing CRUD operations or other resource types like tags or studios also create notable gaps for a comprehensive Stash interface.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A MCP server built for developers enabling Git based project management with project and personal…
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JakeBusler/stash_mcp_server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
