MoviePilot MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clear, distinct purposes: search_media_or_person is by name, discover_* are by filters, and subscription tools are CRUD operations. There is slight overlap between search and discover (both find media), but descriptions adequately differentiate them. The subscription functions are unambiguous.
Naming Consistency4/5
Tool names consistently follow a verb_noun snake_case pattern (e.g., add_subscribe, get_media_details). The only minor deviation is 'list_subscribes' being plural while others use singular forms, but the overall pattern is predictable and readable.
Tool Count5/5
With 10 tools, the server is well-scoped for its purpose of media discovery and subscription management. Each tool serves a distinct function, and the count is within the ideal range, avoiding both bloat and sparsity.
Completeness4/5
The subscription lifecycle is fully covered with add, list, get, update, and delete. Media discovery and details are covered for movies/TV, and season episodes are available. A minor gap is the lack of detailed person information, since search_media_or_person can return people but there's no tool to fetch person-specific details.
Average 3.3/5 across 10 of 10 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
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

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 only mentions filter conditions and page number, and states a return list. It does not explain read-only safety, pagination behavior, rate limits, or error handling, which is a significant gap for a discovery tool.
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 very concise with a one-sentence summary followed by Args/Returns. There is no fluff, and the structure is clear, though it is almost too terse to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex discovery tool with a nested filters object containing five sub-parameters, no output schema, and no annotations. The description is severely incomplete, lacking filter semantics, pagination details, response structure, and differentiation from the sibling discover_tmdb_media tool. It does not adequately inform an agent for correct invocation.
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?
The description adds no meaning beyond the input schema. It simply restates 'filters' as '过滤条件' and 'page' as '页码', without explaining the nested object structure or available fields. The schema itself contains detailed descriptions, but the tool description contributes nothing.
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 explores Douban movies/TV shows based on filter conditions, which is a specific verb+resource combination. It does not explicitly distinguish from sibling tools like discover_tmdb_media, but the Douban scope and tool name provide differentiation.
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 such as search_media_or_person or discover_tmdb_media. There are no exclusions or contextual recommendations, leaving the agent to guess 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?
No annotations are provided, so the description carries the burden. It only states a return of '媒体详细信息' (media details) without disclosing any behavioral traits, such as how title/year are used, error handling, or required permissions. The lack of safety or side-effect information is notable.
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 concise and well-structured: a one-line summary, a bullet-like list of args, and a one-line return statement. It is easy to parse and does not contain unnecessary verbiage, though it could benefit from richer details without harming conciseness.
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?
With no output schema and no behavioral annotations, the description leaves the return format, potential errors, and the role of optional parameters (title, year) unexplained. For a tool with five parameters, this is insufficient context for an agent to reliably use it.
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 input schema has 0% description coverage, so the description must compensate. It lists parameter names with brief Chinese labels, but these largely mirror the schema (e.g., enums for id_type and media_type). No additional meaning is provided about parameter formats, relationships, or validation rules, leaving gaps for the agent.
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 retrieves media details ('获取媒体详细信息'), with a specific verb and resource. It differentiates from siblings like search_media_or_person and discover_* tools by focusing on detail lookup, though it doesn't explicitly name alternatives.
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 other related tools. It simply lists parameters and a return value, leaving the agent to infer that it is for fetching details by known IDs.
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?
No annotations are provided, so the description must carry the full burden. It only states '探索' and mentions returning a media list, but does not clarify read-only nature, pagination behavior, authentication requirements, or any side effects. This is minimal disclosure.
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 brief, front-loaded with a clear purpose sentence, and uses a clean Args/Returns structure. It contains no fluff, though it could still be informative within the same length.
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 (many filter options inside TMDBDiscover) and lack of output schema, the description is under-specified. It does not explain the structure of filters or the shape of the returned list, which is insufficient for correct invocation.
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?
The description lists only 'filters' and 'page' with generic Chinese labels, adding no meaning beyond the schema. With 0% schema description coverage and a complex TMDBDiscover object, the description fails to compensate, leaving the agent without explanation of filter semantics or page usage.
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 '探索TMDB电影/电视剧' with filter conditions, identifying a specific verb (explore), resource (TMDB movies/TV), and scope (based on filters). This distinguishes it from sibling tools like discover_douban_media and search_media_or_person.
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 explicit guidance is provided on when to use this tool versus alternatives. The description only implies use for filtered TMDB discovery but does not mention sibling tools or exclusions, leaving the agent without clear decision criteria.
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 states it returns a list of episode info but does not mention that it is a read-only operation, potential error conditions, pagination, or that data comes from TMDB (though source is mentioned in Args). This is minimal coverage for a tool with no annotation fallback.
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 extremely concise and well-structured, with a clear purpose line followed by Args and Returns sections. Every sentence serves a purpose with no wasted words, and the information is front-loaded.
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 simple retrieval tool with only 3 parameters and no output schema, the description provides the essential purpose, args, and return type. However, it lacks contextual details such as expected output structure, edge cases, or confirmation that only TMDB is supported. It is adequate but not rich.
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 schema description coverage is 0%, so the description must compensate. It provides inline comments for all three parameters: source_id is 'media ID (tmdbid)', season_number is 'season number', and source is 'data source (tmdb)'. This adds meaning beyond the schema, though it does not detail formats or constraints beyond what the schema already indicates.
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 '获取剧集的对应季的分集信息' (get episode info for the corresponding season of a series), which is a specific verb+resource. It distinguishes from siblings like get_media_details by focusing on season episodes. However, it does not explicitly differentiate from alternative tools that might provide similar 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?
No explicit guidance on when to use this tool vs alternatives. The purpose implies using it to fetch season episodes, but there is no mention of exclusions or comparison to sibling tools such as get_media_details or search_media_or_person. The agent must infer usage from the description alone.
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?
No annotations are provided, so the description carries the full burden. It discloses fuzzy search ('模糊搜索') and the return type ('媒体信息列表'), but leaves significant ambiguity: searching for 'person' still returns 'media info list', and there is no mention of read-only behavior, pagination, or error scenarios.
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 extremely concise, front-loaded with the purpose, and structured with Args and Returns sections. Every sentence adds value with no redundancy.
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?
Although the tool is simple with only two parameters and no output schema, the description is incomplete: it does not clarify the return structure for person searches (the tool name says 'media_or_person' but returns 'media info list'), and it lacks usage guidance or behavioral expectations beyond fuzzy search.
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 schema description coverage at 0%, the description compensates by explaining both parameters: type_name as '类型 (media/person)' and name as '名称 (模糊搜索)'. This adds meaning beyond the schema, particularly the 'fuzzy search' qualifier for name.
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 that it searches for media/actor information by name, which is a specific verb-resource pair. It does not explicitly differentiate from sibling tools like discover_douban_media or discover_tmdb_media, but the scope (media/person) is clear.
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 for name-based searches ('根据名称搜索'), but provides no explicit context about when to use this tool versus alternatives, nor does it mention any exclusions or conditions.
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 that an update occurs and returns the updated subscription, but it omits critical details such as whether the update is partial or full, what happens if the id does not exist, permission requirements, or any side effects. This is a mutation tool without adequate transparency.
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 concise and well-structured with summary, Args, and Returns sections. Every sentence provides necessary information, and the key point about requiring 'id' is front-loaded.
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?
The tool updates a complex object with many fields, but the description only covers the core requirement (id) and the return value. The schema is rich but lacks descriptions for most properties, so the description leaves significant gaps. It is minimally viable but not complete for such a complex mutation tool.
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 schema has one parameter (subscribe_data) with 0% description coverage, but the description adds meaning by explaining the object must contain 'id' and other fields to update, conveying partial-update semantics. It does not detail the many individual fields, leaving the agent to rely on property names in the schema, which is only partially self-explanatory.
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 'Update existing subscription' (更新现有订阅), a specific verb+resource that distinguishes it from siblings like add_subscribe, list_subscribes, get_subscribe, and delete_subscribe. It also emphasizes the required 'id' field, reinforcing the update intent.
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 for modifying an existing subscription and explicitly notes that 'id' must be included in the request body. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternative tools like add_subscribe for creation.
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 disclosure. It only states the listing action and return type, but does not mention whether it is read-only, whether pagination is involved, or any prerequisites. Minimal additional behavioral context beyond the obvious.
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 extremely concise, composed of two short statements that state the purpose and return value. Every word is useful, and there is no unnecessary verbosity.
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?
For a simple list operation with no inputs and no output schema, the description adequately covers the essential purpose and return type. It could benefit from explicit read-only or usage context, but given the low complexity, it is mostly complete.
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 tool has 0 parameters, so the baseline score is 4. The description does not need to explain parameters; the input schema is empty and fully covers this.
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 '列出用户所有媒体订阅' (List all media subscriptions of the user), using a specific verb and resource. It distinguishes itself from sibling tools such as get_subscribe (single subscription) and add/update/delete by explicitly indicating a full listing operation.
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 explicit guidance is provided for when to use this tool versus alternatives. Although sibling tools include get_subscribe, the description does not mention selection criteria or contrast with other subscription-related 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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the purpose and a data requirement but does not disclose side effects, return values, error handling, duplicate behavior, or permission requirements. This is minimal for a write 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 brief and front-loaded with the purpose, followed by the key requirement. However, the 'Args: subscribe_data: 订阅数据' line is redundant with the schema parameter name and adds no new information, slightly reducing conciseness.
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 tool accepts a complex Subscribe object with ~30 fields, has no output schema, and no annotations. The description omits return behavior, error conditions, and how the subscription will be processed, making it insufficient for an agent to fully understand the tool's behavior and consequences.
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 schema's top-level parameter 'subscribe_data' has no description (coverage 0%). The description adds a crucial validation rule—requiring at least one of tmdbid, doubanid, or bangumiid—which is not expressed in the schema. It does not explain the many nested fields, but they are present in the schema with some descriptions, so the added rule is significant.
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 '添加新的媒体订阅' (Add new media subscription), specifying the verb 'add' and resource 'subscription'. This distinguishes it from sibling tools like list_subscribes, get_subscribe, update_subscribe, and delete_subscribe, as it uniquely indicates creation.
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 provides a clear prerequisite: subscription data must contain at least one of tmdbid, doubanid, or bangumiid. This gives context for when to use the tool, though it does not explicitly mention alternatives or when not to use it (e.g., for updates).
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. It discloses deletion behavior, supported ID types, and the conditional season parameter, but lacks details on return format, error handling, or side effects beyond a generic 'result information' note.
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 succinct and organized, front-loaded with the purpose, followed by a clear list of args and returns. Every sentence adds value, with no superfluous content.
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?
While parameter explanations are thorough, the return value description is vague ('result information') and there's no mention of potential errors or prerequisites. For a delete tool without annotations or output schema, this is a notable gap.
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 fully explains all three parameters, including enum values, examples, and the conditional behavior of season, compensating for the 0% schema description coverage. It adds meaning beyond the schema's title and enum definitions.
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 deletes a subscription and supports deletion by subscription ID or media ID (tmdb/douban). This distinguishes it from sibling tools like add_subscribe, update_subscribe, and get_subscribe, with a specific verb and resource.
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 for deleting subscriptions but provides no explicit guidance on when to use this tool versus alternatives like update_subscribe. It does give specific guidance on when the season parameter is applicable, which is a partial usage guideline.
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 of disclosure. It discloses the return value (subscription details or None if not found) and the conditional behavior of the season parameter. It does not explicitly state read-only nature, potential side effects, or authentication requirements, but for a retrieval operation this is acceptable.
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 concise and well-structured, with distinct Args and Returns sections. Every sentence adds value without redundancy, making it easy for an agent to parse and extract key information.
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?
For a straightforward get tool, the description covers: purpose, query modes, parameter semantics, and return behavior including the None case. It does not mention explicit integration with sibling tools or provide examples, but the tool's simplicity means the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section thoroughly explains all three parameters, including the enum values for id_type, the meaning of id_value, and the conditional relevance of season. Since the input schema has no property descriptions (0% coverage), this fully compensates for the schema's lack of semantic detail.
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 '获取订阅信息' (get subscription information) and specifies querying by subscribe ID or media ID (tmdb/douban), indicating a concrete resource and action. However, it does not explicitly distinguish this from sibling tools like get_media_details, though the subject (subscriptions) is distinct.
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 the tool is for retrieving subscription records and provides parameter-level guidance (e.g., season is only valid for tmdb/douban). It does not explicitly mention when to use this tool versus alternatives such as list_subscribes or get_media_details, so the usage context is inferred rather than stated.
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:

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

Score Badge

Copy to your README.md:

[![MoviePilot-MCP MCP server](https://glama.ai/mcp/servers/Pollo3470/MoviePilot-MCP/badges/score.svg)](https://glama.ai/mcp/servers/Pollo3470/MoviePilot-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/Pollo3470/MoviePilot-MCP'

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