Skip to main content
Glama
smeet666

mcp-stashbox

Read one performer

get_performer
Read-onlyIdempotent

Retrieve a performer's catalogued record by identifier, with scene counts and selected sections. Clarifies coverage gaps and identifier redirects.

Instructions

Read one catalogued performer by its identifier. 'scene_count' counts what that catalogue has indexed: a settled record naming a career spanning decades can report none, and that states the catalogue's coverage, never a career. An identifier folded into another answers as a marker naming its successor.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesIdentifier as returned by another tool, such as stashdb:<uuid>.
sectionsNoWhich blocks to load. Defaults to basic.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
nameNo
urlsNo
notesYes
genderNo
imagesNo
scenesNo
sourceYes
statusYes'established' is a record the catalogue holds. 'merged' and 'deleted' are markers: the identifier resolves, and what comes back describes the record rather than the thing it once named.
aliasesNoStage names and variant spellings alike.
countryNo
createdNo
studiosNo
updatedNo
appearanceNo
birth_dateNo
death_dateNo
merged_idsNo
source_urlYes
former_nameNoPresent on a marker: the name the record carried.
merged_intoNoPresent on a marker: the identifier that continues this record.
scene_countNoScenes this catalogue has indexed crediting this performer. A settled record naming a career spanning decades can report zero, which measures coverage and states nothing about a person's work. Null on a marker, since the count belongs to the record that continues it.
retrieved_atYesWhen this record came off the catalogue, ISO 8601.
scenes_totalNoWhat the catalogue holds behind the one page this section shows.
disambiguationNoFree text telling two people apart. It reads and never parses.
career_end_yearNo
career_start_yearNo
scene_count_meansNo
scenes_unavailableNoWhy the section is missing, when it was asked for and could not be read. Its absence then says nothing about what the catalogue holds.
Behavior5/5

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

Beyond the safe readOnly and idempotent annotations, the description discloses non-obvious behaviors about scene_count semantics and identifier folding. It explains that scene_count reflects catalogue coverage rather than career activity, and that merged identifiers return markers for successors—valuable context for interpreting responses.

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 three sentences with no wasted words. The first sentence front-loads the core purpose, and the subsequent sentences add essential nuance about data interpretation. Every sentence earns its place.

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 simple read operation, the presence of an output schema, and the clear annotations, the description covers all necessary context. It addresses the two potentially confusing aspects (scene_count and identifier merging) without redundantly repeating schema details.

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?

Schema coverage is 100%, providing a solid baseline. The description adds extra meaning by explaining the subtle behavior of the 'id' parameter (folded identifiers act as markers), which is not present in the schema's basic description. This enhances parameter understanding.

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 uses a specific verb ('Read') and resource ('performer') with a clear mechanism ('by its identifier'), which clearly distinguishes it from sibling tools like search_performers and get_scene. The title 'Read one performer' reinforces the single-resource read operation.

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 clearly implies this tool is for fetching a known performer by identifier, as opposed to searching. It gives clear context for when to use it but does not explicitly name alternatives or provide exclusions, so it falls just short of full marks.

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

Install Server

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