Stash MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.1
Disambiguation3/5
There 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness3/5
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.
Average 3.2/5 across 7 of 7 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness2/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose2/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![stash_mcp_server MCP server](https://glama.ai/mcp/servers/JakeBusler/stash_mcp_server/badges/card.svg)](https://glama.ai/mcp/servers/JakeBusler/stash_mcp_server)

Score Badge

Copy to your README.md:

[![stash_mcp_server MCP server](https://glama.ai/mcp/servers/JakeBusler/stash_mcp_server/badges/score.svg)](https://glama.ai/mcp/servers/JakeBusler/stash_mcp_server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/JakeBusler/stash_mcp_server'

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