ThePornDB MCP Service

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity. The tools are organized by resource type (content, performer) and action (get details, search), with specific tools for different content categories (JAV, movies, scenes) that have clear boundaries.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern throughout. The naming convention is perfectly uniform with 'get_' for retrieval operations and 'search_' for search operations, followed by the specific resource type.
Tool Count5/5
Six tools is well-scoped for this adult content database service. Each tool earns its place by covering distinct aspects of the domain: detailed retrieval for content and performers, plus specialized search functions for different content types and performers.
Completeness4/5
The tool surface provides excellent coverage for search and retrieval operations across the main domain entities. Minor gaps exist such as no update/delete operations (which may be intentional for a read-only API) and no content creation tools, but the core query functionality is comprehensive.
Average 3.4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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 MIT License.
This repository includes a README.md file.
Tools from this server were used 40 times in the last 30 days.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic function and mentions error handling ('Raises: CallToolResult: With error if validation fails'), but doesn't describe important behavioral traits like whether this is a read-only operation, what permissions might be required, rate limits, pagination behavior, or what happens when no results are found. For a search tool with zero annotation coverage, this is inadequate.
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?
The description is appropriately concise and well-structured with clear sections (Args, Returns, Raises). Each sentence serves a purpose: stating the function, documenting the parameter, describing the return, and mentioning error handling. However, the 'ctx: MCP context (injected automatically)' documentation could be omitted since it's implementation detail rather than user guidance.
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?
Given the tool's complexity (search function with 1 parameter), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what a 'SearchResponse with performer results' contains, how results are structured, whether there's pagination or sorting options, or what fields are returned. For a search tool that likely returns multiple results, this leaves significant gaps for an AI agent to understand how to properly use and interpret results.
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?
The description adds minimal parameter semantics beyond what the schema provides. It states 'name: Performer name to search' which clarifies the parameter's purpose, but with 0% schema description coverage and only 1 parameter, this is the baseline expectation. The description doesn't provide format examples, search behavior details (exact match vs partial), or character encoding considerations that would add meaningful value.
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's purpose as 'Search for performers by name', which is a specific verb+resource combination. It distinguishes from siblings like 'get_performer_details' (which retrieves details for a known performer) and 'search_movies' (which searches movies rather than performers). However, it doesn't explicitly contrast with 'search_jav' or 'search_scenes', leaving some sibling differentiation incomplete.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'search_performers' versus 'get_performer_details' (for known performers) or other search tools like 'search_movies'. There's no context about prerequisites, limitations, or appropriate use cases beyond the basic function.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions pagination in the return type ('paginated movie results') and error handling for validation failures, but doesn't cover important behavioral aspects like rate limits, authentication requirements, whether this is a read-only operation, or what happens with partial matches. For a search tool with no annotation coverage, this leaves significant gaps.
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 well-structured and efficiently organized. It starts with a clear purpose statement, then provides parameter explanations in a labeled 'Args' section, followed by return and error information. Every sentence adds value with no redundant information. The formatting with clear section headers makes it easy to parse.
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?
For a search tool with 2 parameters and no output schema, the description covers the basic functionality adequately but has gaps. It explains parameters well and mentions pagination, but without annotations or output schema, it doesn't describe the response format, error types beyond validation, or how results are ordered. Given the complexity level and lack of structured data, it's minimally viable but incomplete.
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?
With 0% schema description coverage, the description must compensate, and it does so effectively. It explains both parameters: 'search_term' as 'Search query (movie title, series, studio)' and 'year' as 'Optional filter by release year (1900-current year)'. The description adds meaningful context about what the search_term can include and the valid range for year, which the bare schema doesn't provide.
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's purpose: 'Search for full-length movies by term and optional year.' It specifies the verb (search), resource (full-length movies), and scope (by term and optional year). However, it doesn't explicitly distinguish this from sibling tools like 'search_jav' or 'search_scenes' which suggests similar search functionality for different content types.
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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'search_jav' and 'search_scenes' that appear to search different content types, there's no indication of when this movie search is appropriate versus those other search tools. The description only states what the tool does, not when to choose it.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool returns 'paginated scene results' and can raise errors on validation failure, which adds some context beyond basic functionality. However, it lacks details on rate limits, authentication needs, or what 'adult video scenes' specifically entails (e.g., source, format), leaving gaps in behavioral understanding.
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?
The description is appropriately sized and front-loaded, starting with the core purpose. The use of sections like 'Args:', 'Returns:', and 'Raises:' adds structure, though the inclusion of 'ctx: MCP context (injected automatically)' is redundant as it's not a user-provided parameter. Overall, it's efficient with minimal waste.
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?
Given the complexity of a search tool with 2 parameters, no annotations, and no output schema, the description is partially complete. It covers parameter semantics and basic behavior but lacks details on output format (beyond 'paginated scene results'), error specifics, or how it differs from sibling tools. This leaves some gaps for an agent to fully understand the tool's context.
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?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that 'search_term' covers 'scene title, performer name, site name' and 'year' is an 'optional filter by release year (1900-current year)'. This clarifies the semantics and constraints of both parameters, compensating well for the schema's lack of descriptions.
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's purpose: 'Search for adult video scenes by term and optional year.' It specifies the verb ('search'), resource ('adult video scenes'), and scope ('by term and optional year'). However, it doesn't explicitly differentiate from sibling tools like 'search_jav' or 'search_movies', which might target different content types or databases.
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?
The description provides no guidance on when to use this tool versus alternatives like 'search_jav' or 'search_movies'. It mentions the parameters but doesn't explain the context or prerequisites for using this search, such as what content it covers compared to siblings. This leaves the agent without clear direction on tool selection.
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?
With no annotations provided, the description carries full burden. It discloses that it returns a complete profile (behavioral trait) and mentions error conditions (validation fails, performer not found), which adds context. However, it doesn't cover other important aspects like rate limits, authentication needs, or whether it's a read-only operation (though 'Get' implies read).
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?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by structured sections (Args, Returns, Raises). Each sentence earns its place by adding value (e.g., error details). Minor verbosity in 'Dictionary with complete performer details' could be tighter, but overall efficient.
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?
Given no annotations, no output schema, and low schema coverage (0%), the description is moderately complete. It covers purpose, parameters, returns, and errors, but lacks details on output structure (beyond 'Dictionary'), behavioral traits like idempotency, or integration with siblings. For a simple lookup tool, this is adequate but has clear gaps.
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 description coverage is 0%, so the description must compensate. It adds meaning by explaining 'performer_id' as a 'Unique performer identifier', which clarifies beyond the schema's title 'Performer Id'. The 'ctx' parameter is noted as injected automatically, preventing misuse. With only 1 parameter, this is sufficient for a high score, though it doesn't detail format constraints (e.g., UUID).
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 verb 'Get' and the resource 'complete performer profile', specifying what data is retrieved (bio, measurements, aliases, external links). It distinguishes from siblings like search_performers (which likely returns multiple results) by focusing on a single detailed profile. However, it doesn't explicitly contrast with get_content_details, which might be a minor gap.
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 implies usage when you need detailed information about a specific performer, as opposed to search_performers for finding performers. It mentions 'performer not found' error, hinting at prerequisites (valid ID). However, it lacks explicit when-not-to-use guidance or named alternatives beyond what's inferred from sibling names.
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?
No annotations are provided, so the description carries the full burden. It mentions validation errors and 'content not found' in the Raises section, which adds useful behavioral context about failure modes. However, it lacks details on permissions, rate limits, or response format beyond 'MediaData', leaving gaps for a read operation.
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 well-structured and front-loaded with the core purpose, followed by organized sections for Args, Returns, and Raises. Every sentence adds value without redundancy, making it efficient for an agent to parse.
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?
Given no annotations, no output schema, and 2 parameters, the description covers the basics (purpose, parameters, errors) but lacks completeness. It doesn't explain what 'MediaData' contains or provide deeper behavioral insights (e.g., caching, performance), which would help the agent use it effectively in complex scenarios.
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 description coverage is 0%, so the description must compensate. It explains 'content_id' as a 'Unique content identifier' and 'content_type' with allowed values ('scene', 'movie', or 'jav'), adding clear meaning beyond the schema. However, it doesn't detail format constraints (e.g., ID structure) or provide examples, preventing a perfect score.
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's purpose: 'Get complete details for a specific content item by ID.' It specifies the verb ('Get'), resource ('content item'), and key constraint ('by ID'). However, it doesn't explicitly differentiate from sibling tools like 'get_performer_details' or the various search tools, which would require a 5.
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 implies usage by specifying 'by ID' and listing content types, suggesting this is for retrieving known items rather than searching. However, it doesn't explicitly state when to use this vs. alternatives like the search tools or provide exclusions, leaving some ambiguity for the agent.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns 'paginated JAV results' and raises errors on validation failure, which adds useful context beyond the input schema. However, it lacks details on rate limits, authentication needs, or side effects, leaving gaps for a search operation.
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?
The description is appropriately sized and front-loaded, with the core purpose stated first, followed by structured sections for Args, Returns, and Raises. Each sentence adds value, though the 'ctx' parameter note could be considered redundant if automatically injected, slightly reducing efficiency.
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?
Given the complexity of a search tool with 2 parameters, no annotations, and no output schema, the description is moderately complete. It covers input semantics and basic return/error info but lacks details on output structure, pagination behavior, or performance characteristics, which could hinder effective agent use.
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?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that 'search_term' can include 'JAV title, code, performer name' and 'year' is an 'optional filter by release year (1900-current year)', clarifying usage and constraints not evident from the schema alone. This compensates well for the low schema coverage.
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 specific action ('Search for Japanese Adult Video content') and resource ('JAV content'), distinguishing it from sibling tools like 'search_movies' or 'search_performers' by specifying the exact domain of adult video content. It uses precise verbs ('Search for') and identifies the target resource unambiguously.
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?
The description provides no guidance on when to use this tool versus alternatives like 'search_movies' or 'search_performers', nor does it mention any prerequisites or exclusions. It only describes what the tool does without contextual usage instructions, leaving the agent to infer based on tool names alone.
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:

[![theporndb-mcp MCP server](https://glama.ai/mcp/servers/achenglike/theporndb-mcp/badges/card.svg)](https://glama.ai/mcp/servers/achenglike/theporndb-mcp)

Score Badge

Copy to your README.md:

[![theporndb-mcp MCP server](https://glama.ai/mcp/servers/achenglike/theporndb-mcp/badges/score.svg)](https://glama.ai/mcp/servers/achenglike/theporndb-mcp)

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/achenglike/theporndb-mcp'

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