MyShows MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting different resources or actions, but there is some potential confusion between get_viewed_episodes (retrieves viewed episodes for a specific TV show) and watched_movies (retrieves watched movies list) as both involve 'watched' content with overlapping terminology. The descriptions help clarify the distinction, but the naming could cause initial ambiguity.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern (e.g., check_episode, get_calendar_episodes, search_shows) with clear action-object relationships. There is one minor deviation with get_myshows_profile_shows_list, which includes 'myshows' redundantly, but overall the pattern is predictable and readable.
Tool Count5/5
With 10 tools, the count is well-scoped for a media tracking server covering TV shows and movies. Each tool serves a specific function in the domain, such as searching, retrieving details, managing watch status, and getting recommendations, without feeling bloated or insufficient.
Completeness4/5
The toolset provides good coverage for core MyShows operations, including CRUD-like actions for episodes and movies (check/uncheck, set status), retrieval of shows, episodes, recommendations, and search. A minor gap is the lack of tools for managing TV show watch status at a higher level (e.g., marking entire seasons as watched), but agents can work around this using existing tools.
Average 3.1/5 across 10 of 10 tools scored. Lowest: 2.4/5.
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
- Last stable release on January 7, 2026
- 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.
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.
This repository includes a glama.json configuration file.
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?
No annotations are provided, so the description carries full burden. It only states the tool retrieves recommendations and returns a dictionary, but doesn't disclose behavioral traits like authentication requirements, rate limits, pagination, freshness of data, or whether it's a read-only operation. This is inadequate for a tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two brief sentences, though the colon before 'return' is a minor formatting issue. It's front-loaded with the core purpose, but could be more structured by explicitly separating purpose from return value.
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 no annotations, 0% schema coverage, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain the parameter, return format beyond 'dictionary', or how this tool differs from others, making it insufficient for an agent to use effectively without additional 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%, with one undocumented parameter 'self'. The description provides no information about this parameter's purpose, format, or semantics (e.g., whether it's a user ID, authentication token, or something else). 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'retrieves recommendations from MyShows', which is a clear verb+resource combination. However, it doesn't distinguish this from sibling tools like 'search_shows' or 'get_myshows_profile_shows_list', leaving ambiguity about what specific type of recommendations are provided (personalized vs general, TV vs movies).
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. With siblings like 'search_shows', 'get_calendar_episodes', and 'get_myshows_profile_shows_list', the description doesn't indicate whether this is for personalized recommendations, trending content, or another context, leaving the agent to guess.
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 ('page number to retrieve') and return format ('dictionary containing the search results'), but lacks critical details like rate limits, authentication needs, error handling, or whether results are cached. For a search tool with zero annotation coverage, this is insufficient.
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 in the first sentence. The parameter and return explanations are concise, though the use of Python-style ':param' and ':return' markers is slightly verbose. Overall, it avoids unnecessary fluff and communicates key points efficiently.
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 tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and parameters but lacks depth in behavioral traits, usage context, and output details. Without annotations or output schema, more elaboration on results structure or error cases would improve completeness.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaning for all three parameters: 'query' as a search string, 'year' as an optional filter, and 'page' for pagination with a default. However, it doesn't explain parameter constraints (e.g., query length, year range, page limits) or interactions (e.g., how year affects results), leaving gaps in understanding.
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: 'Searches for TV shows/movies on MyShows by a query and optional year.' It specifies the verb ('Searches'), resource ('TV shows/movies'), and platform ('MyShows'). However, it doesn't explicitly differentiate from sibling tools like 'get_movie_show_by_id' or 'get_myshows_recomendations', which prevents a perfect score.
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 sibling tools like 'get_movie_show_by_id' for specific IDs or 'get_myshows_recomendations' for recommendations, nor does it specify use cases like fuzzy matching versus exact lookups. This lack of context leaves the agent without clear selection 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a retrieval operation, implying read-only behavior, but doesn't mention authentication requirements, rate limits, pagination details beyond the 'page' parameter, or what happens on errors. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 with two sentences: one stating the purpose and another explaining the parameter and return value. It's front-loaded with the main function, though the parameter explanation could be integrated more smoothly rather than using Python-style docstring syntax.
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 no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain the return structure beyond 'a dictionary containing the list', missing details like keys, data types, or error handling. For a retrieval tool with siblings, more context is needed to ensure correct usage.
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 meaning for the single parameter 'page' by explaining it's for pagination with a default value, which is useful since schema description coverage is 0%. However, it doesn't clarify the pagination model (e.g., page size, total pages) or format, leaving some ambiguity. With one parameter and low schema coverage, this provides basic but incomplete compensation.
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 ('Retrieves') and resource ('list of watched movies from MyShows'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_viewed_episodes' or 'get_myshows_profile_shows_list', which might also retrieve user-specific content.
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 siblings like 'get_viewed_episodes' and 'get_myshows_profile_shows_list', there's no indication of how this tool differs in scope or context, leaving the agent to guess 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool retrieves/fetches data, implying a read-only operation, but doesn't specify authentication needs, rate limits, error handling, or data freshness. The mention of 'next episodes scheduled to air' hints at future-oriented data, but behavioral traits like pagination or response format are not described.
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 reasonably concise with three sentences, but has some redundancy: 'Retrieves the calendar episodes' and 'This method fetches the next episodes' convey similar information. The return statement adds value by specifying output format. However, it could be more front-loaded by merging the first two sentences for better flow.
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 tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does and the return format, but lacks behavioral context like authentication or error handling. For a read operation with no complex inputs, this is acceptable but leaves gaps an agent might need to infer.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. This meets the baseline for tools with no parameters.
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: retrieving calendar episodes from MyShows with information about next episodes. It specifies the resource (calendar episodes from MyShows) and action (retrieves/fetches next episodes scheduled to air). However, it doesn't explicitly differentiate from sibling tools like 'get_viewed_episodes' or 'check_episode' which might also involve episode 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for use, or comparison to sibling tools like 'get_myshows_profile_shows_list' or 'search_shows' that might retrieve similar data. The agent must infer usage from the purpose 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the return type ('A dictionary containing the list of tv shows'), which is helpful, but fails to mention critical aspects like whether authentication is required, rate limits, pagination behavior, or error conditions. For a read operation with zero annotation coverage, this leaves important behavioral traits unspecified.
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 two concise sentences that efficiently state the purpose and return value. It is front-loaded with the core functionality and avoids unnecessary elaboration. However, the colon before ':return:' is slightly awkward, and it could be structured more cleanly (e.g., 'Returns: A dictionary...'), but this is a minor issue.
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 tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose and return type, but lacks context about authentication, error handling, or sibling differentiation, which would be valuable for an agent. Without annotations or output schema, the description should do more to compensate, but it meets the bare minimum for a basic retrieval tool.
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 with 100% schema description coverage, so the schema fully documents the absence of inputs. The description adds no parameter information, which is appropriate here. Baseline for 0 parameters is 4, as the description need not compensate for any gaps, and it correctly avoids redundant details about inputs.
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 ('Retrieves') and resource ('list of tv shows from the MyShows profile'), making the purpose unambiguous. It distinguishes from siblings like 'search_shows' (searching) or 'get_calendar_episodes' (calendar-focused), though it doesn't explicitly name alternatives. The description avoids tautology by specifying what is retrieved beyond just the tool name.
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 'get_myshows_recomendations' or 'get_viewed_episodes'. It lacks context about prerequisites (e.g., authentication needs) or typical use cases, leaving the agent to infer usage based on the purpose alone. This is a significant gap for a tool with multiple siblings.
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 'retrieves' viewed episodes, implying a read-only operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or whether it returns all episodes or paginated results. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 front-loaded with the core purpose in the first sentence, followed by parameter and return details. It's efficient with no wasted words, though the use of ':param' and ':return' markers is slightly informal for MCP standards but doesn't hinder clarity.
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 tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the purpose and parameter semantics but lacks behavioral details like response format (beyond 'dictionary'), error cases, or integration with sibling tools. Without annotations or output schema, more context would improve completeness.
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 meaningful context for the single parameter 'myshows_item_id', specifying it's 'The ID of the TV show to retrieve episodes for.' This clarifies the parameter's purpose beyond the schema's type (integer). With 0% schema description coverage and only one parameter, this compensation is effective, though it doesn't detail format constraints (e.g., valid ID ranges).
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 ('Retrieves') and resource ('viewed episodes of a TV show'), specifying it's for episodes that have been viewed. It distinguishes from siblings like 'get_calendar_episodes' (calendar-based) or 'search_shows' (searching), but doesn't explicitly contrast with 'check_episode' or 'uncheck_episode' which might involve viewing status.
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 on when to use this tool versus alternatives is provided. It doesn't mention when to choose this over 'check_episode' (which might mark episodes as viewed) or 'get_myshows_profile_shows_list' (which could list shows with viewing data), leaving usage context implied rather than explicit.
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 of behavioral disclosure. It states the tool 'Sets' a status, implying a mutation operation, but doesn't describe side effects (e.g., if it updates a database, requires authentication, or has rate limits), error handling, or what the return dictionary contains, which is insufficient for a mutation 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 appropriately sized and front-loaded with the core purpose in the first sentence. The parameter explanations are necessary but could be slightly more streamlined; overall, it avoids unnecessary verbosity and maintains a clear structure.
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 complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permissions, side effects), return value specifics, and usage context, making it inadequate for safe and effective tool invocation by an agent.
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 description adds significant meaning beyond the input schema, which has 0% description coverage. It explains the purpose of both parameters: 'movie_id' identifies the movie, and 'status' includes detailed enum-like values with explanations ('watching', 'cancelled', etc.), fully compensating for the schema's lack of 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 clearly states the verb ('Sets') and resource ('watch status of a movie by its ID'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'watched_movies' or 'uncheck_episode', which might have overlapping functionality for tracking viewing status.
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 prerequisites (e.g., needing a valid movie ID), exclusions, or how it relates to sibling tools like 'watched_movies', leaving the agent to infer usage context.
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 full burden. It states this is a retrieval operation but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or whether it's idempotent. The return format is mentioned but lacks detail on structure or potential null responses.
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 with three sentences. The first states the purpose, the second explains the parameter, and the third describes the return. No wasted words, though the colon-prefixed format is slightly unconventional.
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 1 parameter and no output schema, the description is minimally adequate. It covers purpose, parameter meaning, and return type, but lacks behavioral context (auth, errors, etc.) and doesn't fully address sibling differentiation given the server's multiple show-related tools.
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%, but the description compensates by explaining the single parameter: 'The MyShows ID of the show or movie to retrieve.' This adds meaning beyond the schema's type declaration, though it doesn't specify format constraints or example values.
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: 'Retrieves a show or movie by its MyShows ID.' This is a specific verb ('Retrieves') and resource ('show or movie'), though it doesn't explicitly differentiate from siblings like 'search_shows' or 'get_myshows_profile_shows_list' beyond the ID-based lookup.
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 have a specific MyShows ID, but doesn't explicitly state when to use this versus alternatives like 'search_shows' (for name-based queries) or 'get_myshows_profile_shows_list' (for user-specific lists). No exclusions or prerequisites are mentioned.
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 batch operation support, which adds some context, but fails to address critical aspects like permissions needed, whether the action is reversible, or any rate limits. This leaves significant gaps for a mutation tool.
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 front-loaded and concise, consisting of two sentences that efficiently convey the core functionality and batch support without any wasted words. Every sentence earns its place.
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 as a mutation operation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, error handling, and return values, making it inadequate for safe and effective use by an AI agent.
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 meaningful semantics beyond the input schema by explaining that 'episode_id' can be a single integer or a list of integers for batch operations, which clarifies the 'anyOf' structure in the schema. With 0% schema description coverage and 1 parameter, this compensates well, though it could specify format or constraints.
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 purpose with a specific verb ('unmarks') and resource ('a specific episode as watched'), and distinguishes it from sibling tools like 'check_episode' by indicating an opposite action. It is precise and avoids tautology.
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, such as 'check_episode' or 'set_movie_watch_status', nor does it mention any prerequisites or exclusions. Usage is implied but not explicitly stated.
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 full burden but only states the action ('marks as watched') without disclosing behavioral traits like authentication needs, side effects (e.g., updates to user profiles), rate limits, or error handling. It mentions batch support, which adds some context, but overall leaves critical mutation behavior underspecified.
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 two concise sentences with zero waste: the first states the core purpose, and the second adds crucial batch operation detail. It's appropriately sized and front-loaded, with every sentence earning its place.
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 mutation nature (implied by 'marks'), no annotations, no output schema, and 0% schema coverage, the description is incomplete. It lacks details on permissions, response format, error cases, or how it differs from similar tools like 'set_movie_watch_status', making it inadequate for safe and effective 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?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'episode_id' can be a single integer or a list of integers for batch operations, adding meaningful semantics beyond the schema's structural definition. However, it doesn't explain ID formats or constraints, leaving some gaps.
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 ('Marks... as watched') and resource ('a specific episode by its ID'), distinguishing it from siblings like 'uncheck_episode' (which presumably unmarks) and 'get_viewed_episodes' (which retrieves). It goes beyond tautology by specifying the operation's scope.
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 marking episodes as watched, with no explicit guidance on when to use it versus alternatives like 'set_movie_watch_status' or 'watched_movies'. It mentions batch operations, which provides some context but lacks clear when/when-not directives or prerequisite information.
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:

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

Score Badge

Copy to your README.md:

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

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