Allows AI assistants to interact with MyAnimeList user accounts for list management, progress tracking, and personalized anime recommendations.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MAL User MCP Server I just finished watching Death Note, mark it completed with score 9"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables AI assistants to interact with MyAnimeList user accounts for list management, progress tracking, and personalized anime recommendations.
OAuth 2.0 with PKCE for secure MyAnimeList authentication
Automatic token refresh and management
Multi-user support with secure token storage
View Lists: Get user's anime lists (watching, completed, on-hold, dropped, plan-to-watch)
Update Progress: Mark episodes watched, update scores, change status
Bulk Operations: Update multiple anime at once with natural language
Smart Updates: "I watched episodes 1-5 of Attack on Titan, score it 8/10"
User statistics and viewing patterns
Genre and studio preferences analysis
Personalized recommendations based on watch history
Compare preferences with other users
Natural language anime list updates
Context-aware recommendations during conversations
Automatic status tracking based on discussion
Preference analysis for better suggestions
Related MCP server: mal-mcp
This project consists of two separate servers that work together:
build/server.js)Purpose: Provides MCP tools for AI assistants to interact with MAL API
Usage: Runs in background, connects to Claude Code or other MCP clients
Authentication: Reads stored tokens from tokens.json
auth-server.js)Purpose: Web interface for easy MyAnimeList OAuth authentication
Usage: Visit http://localhost:3006 to login and manage tokens
Output: Saves authentication tokens to tokens.json for MCP server use
Start Auth Server: node auth-server.js → Visit localhost:3006 → Login with MAL
Use MCP Server: Add to Claude Code → Use tools like mal_get_user_list
Tokens Shared: Both servers use the same tokens.json file
For best results, use alongside the anime-search-mcp server to:
Search and discover anime with detailed information
Get MyAnimeList anime IDs needed for list management
Access comprehensive anime metadata before adding to your list
Node.js 18+
TypeScript
A MyAnimeList account
Registered MAL API application
Clone and setup:
git clone <repository>
cd mal-user-mcp
npm installConfigure environment:
cp .env.example .env
# Edit .env with your MAL API credentialsBuild the project:
npm run build# Start the authentication server
node auth-server.js
# Visit http://localhost:3006 in your browser
# Click "Login with MyAnimeList"
# Complete OAuth flow
# Tokens are saved to tokens.json# The MCP server is now ready to use with stored tokens
# Add to your MCP client configuration (see below)Add to your MCP client configuration:
{
"mcpServers": {
"mal-user": {
"command": "node",
"args": ["/path/to/mal-user-mcp/build/server.js"],
"env": {
"MAL_CLIENT_ID": "your_client_id",
"MAL_CLIENT_SECRET": "your_client_secret"
}
}
}
}Test all tools before integrating with Claude Code:
# Start the MCP Inspector
npx @modelcontextprotocol/inspector node build/server.js
# Visit the provided URL (e.g., http://localhost:6274/?MCP_PROXY_AUTH_TOKEN=...)
# Test tools in this order:
# 1. mal_get_auth_status - Check if authenticated
# 2. mal_authenticate - Get authentication instructions
# 3. Complete authentication at http://localhost:3006
# 4. mal_get_user_info - Test API connection
# 5. mal_get_user_list - View your anime list# Test OAuth flow independently
node test-oauth.js
# Or run the full auth server
node auth-server.js
# Visit http://localhost:3006# Check authentication status (gets login instructions if needed)
"Check my MAL authentication status"
# After authentication through web interface:
"I just finished watching Death Note, mark it completed with score 9"
# Bulk updates
"I watched these anime: Attack on Titan (completed, 8/10), Naruto (episode 50, still watching)"
# Get your stats
"Show me my anime statistics and what genres I prefer"
# View your list
"Show me what anime I'm currently watching"mal_authenticate - Start OAuth flow and store credentials
mal_get_auth_status - Check authentication status
mal_revoke_auth - Remove stored credentials
mal_get_anime_list - Retrieve user's anime list with filters
mal_add_anime - Add anime to list with status/score
mal_update_anime - Update anime progress, status, or score
mal_remove_anime - Remove anime from list
mal_bulk_update - Update multiple anime at once
mal_get_user_stats - Get user statistics and preferences
mal_get_user_info - Get basic user profile information
mal_search_user_list - Search within user's anime list
mal_analyze_preferences - Analyze genre/studio preferences
mal_get_watching_history - Get recently updated entries
mal_compare_with_user - Compare lists with another user
# Required: MyAnimeList API credentials
MAL_CLIENT_ID=your_mal_client_id
MAL_CLIENT_SECRET=your_mal_client_secret
# Optional: Customize OAuth callback
MAL_REDIRECT_URI=http://localhost:8080/callback
MAL_CALLBACK_PORT=8080
# Optional: Token storage location
TOKEN_STORAGE_PATH=./tokens.json
# Optional: API settings
MAL_API_BASE_URL=https://api.myanimelist.net/v2
MAL_RATE_LIMIT_DELAY=1000Go to MyAnimeList API
Create a new application
Set redirect URI to http://localhost:8080/callback
Copy Client ID and Client Secret to your .env file
The MCP server handles OAuth authentication automatically:
First Use: Call mal_authenticate to start OAuth flow
Browser Opens: Complete authentication in browser
Tokens Stored: Access/refresh tokens saved securely
Auto-Refresh: Tokens refreshed automatically when needed
The server automatically handles MyAnimeList API rate limits:
Maximum 3 requests per second
Automatic retry with exponential backoff
Graceful error handling for rate limit exceeded
OAuth 2.0 with PKCE prevents authorization code interception
Tokens stored locally and encrypted
No sensitive data logged or transmitted
Automatic token cleanup on revocation
# Install dependencies
npm install
# Development mode with auto-reload
npm run dev
# Build for production
npm run build
# Run tests
npm test
# Type checking
npm run type-checksrc/
├── server.ts # Main MCP server
├── auth/
│ ├── oauth.ts # OAuth 2.0 flow handler
│ └── token-store.ts # Secure token storage
├── api/
│ ├── mal-client.ts # MyAnimeList API client
│ └── endpoints.ts # API endpoint definitions
├── tools/
│ ├── auth-tools.ts # Authentication MCP tools
│ ├── list-tools.ts # List management MCP tools
│ └── stats-tools.ts # Statistics MCP tools
└── types/
└── mal-types.ts # TypeScript type definitionsProblem: "Connection Error" in MCP Inspector
Solution: Make sure only the MCP server (build/server.js) is running, not the auth server
Explanation: MCP Inspector connects to the MCP server, not the auth server
Problem: "Not authenticated" errors
Solution:
Start auth server: node auth-server.js
Visit http://localhost:3006 and login
Verify tokens.json file exists
Restart MCP client to pick up new tokens
Problem: Port conflicts
Auth server: Uses port 3006 (configurable via MAL_CALLBACK_PORT)
MCP Inspector: Uses ports 6274/6277 (managed automatically)
Solution: Make sure ports are available or change in .env
Ensure MAL API credentials are correct in .env
Check redirect URI is http://localhost:3006/callback in MAL app settings
Verify auth server is accessible at http://localhost:3006
Check tokens.json exists and contains valid tokens
Verify internet connectivity to MyAnimeList API
Tokens auto-refresh, but may need re-authentication if refresh token expires
Server automatically handles MAL's 3 requests/second limit
If persistent issues, avoid concurrent MCP tool calls
Fork the repository
Create feature branch (git checkout -b feature/amazing-feature)
Commit changes (git commit -m 'Add amazing feature')
Push to branch (git push origin feature/amazing-feature)
Open Pull Request
MIT License - see LICENSE file for details
Report bugs via GitHub Issues
Feature requests welcome
Documentation improvements appreciated
Note: This MCP server requires a MyAnimeList account and API application. Ensure you comply with MyAnimeList's API terms of service.
Get instructions for authenticating with MyAnimeList using the web interface
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the tool 'Get instructions', which implies a read-only, non-destructive operation. However, it does not explicitly disclose that it makes no changes, requires no credentials, or what side effects (if any) exist. The behavioral transparency is adequate for a simple instruction tool but lacks explicit safety or idempotency details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous words. Every word adds value: 'Get instructions' specifies the action, 'for authenticating with MyAnimeList' specifies the resource, and 'using the web interface' adds context. It is front-loaded and perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is largely complete. It covers the core purpose. However, it could be slightly more complete by hinting at what the instructions look like (e.g., URL, steps) or how they relate to other tools like 'mal_get_auth_status'. Still, for a zero-param tool, it is sufficiently informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (no params to cover). According to guidelines, 0 parameters sets a baseline of 4, and the description adds no additional parameter information, which is appropriate since none is needed. The description's focus on 'instructions' implies no input requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 instructions for authenticating with MyAnimeList using the web interface'. It uses a specific verb ('Get') and resource ('instructions for authenticating'), and it distinguishes itself from sibling tools like 'mal_get_auth_status' (which checks status) and 'mal_revoke_auth' (which revokes) by focusing on providing instructions rather than performing authentication actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical usage scenarios, or when not to use it. For example, it does not indicate that this should be used before other MAL tools or that it is a first step for authentication. The context signals show no explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bulk add multiple anime to your list by their IDs
| Name | Required | Description | Default |
|---|---|---|---|
| score | No | Optional score to set (0-10) | |
| status | No | Status to add anime with | plan_to_watch |
| dry_run | No | If true, shows what would be added without making changes | |
| anime_ids | Yes | Array of MyAnimeList anime IDs to add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks behavioral details such as authentication requirements, rate limits, or side effects beyond the action itself. The dry_run parameter is not highlighted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at one sentence. Every word serves a purpose, but could be slightly expanded for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing information about return values, authentication prerequisites, and error handling. Given 4 parameters and no output schema, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-described in the schema. The description adds no extra meaning beyond what the schema provides, hence baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (bulk add), resource (multiple anime), and method (by IDs). Distinguishes from siblings like mal_bulk_delete_anime and mal_bulk_update_anime.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Does not mention prerequisites like authentication or when to prefer this over single-add operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bulk delete anime from your list (by status or specific IDs)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of entries to process (only for status-based deletion) | |
| status | No | Status to filter and delete (required if delete_by=status) | |
| dry_run | No | If true, shows what would be deleted without making changes | |
| anime_ids | No | Array of anime IDs to delete (required if delete_by=ids) | |
| delete_by | Yes | Delete by status filter or specific anime IDs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Bulk delete' but does not mention that it is destructive, whether operations are reversible, or what happens with partial failures. The dry_run parameter is missing from the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively communicates the core functionality. It is front-loaded and avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite schema coverage, the description omits key contextual details such as return values, error handling, and the behavior of dry_run and limit. Given no output schema, more guidance is needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions in the schema. The description adds no additional meaning beyond what the schema already provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Bulk delete anime from your list' and specifies two deletion modes: 'by status or specific IDs'. This distinguishes it from sibling tools like mal_remove_anime (single delete) and mal_bulk_add_anime.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the two deletion methods but does not explicitly state when to use this tool over alternatives like mal_remove_anime. No prerequisites, exclusions, or context about authentication are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bulk update anime status for multiple anime (useful for changing watching→dropped/on_hold)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of entries to process | |
| dry_run | No | If true, shows what would be updated without making changes | |
| to_status | Yes | New status to change to | |
| from_status | Yes | Current status to filter and update from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only mentions the transformation and the dry_run parameter. It fails to disclose important behavioral traits such as authentication requirements, whether the operation is reversible, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core purpose with no redundant words. It is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a bulk operation with 4 parameters and no output schema, the description is too brief. It omits critical context such as return format, behavior when limit is reached, atomicity, and error scenarios. The example is helpful but insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds a usage example but does not clarify the implicit selection logic (e.g., that it updates all anime matching from_status). Baseline 3 is appropriate as the description provides marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool performs bulk anime status updates, with a concrete example ('changing watching→dropped/on_hold'). It is clearly distinguished from siblings like mal_update_anime (single update) and mal_bulk_delete_anime.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for use (bulk status changes) and includes a practical example. However, it does not explicitly state when not to use this tool or mention alternatives (e.g., mal_update_anime for single entries).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show current OAuth configuration for debugging
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It implies a read-only operation with 'show', but does not mention prerequisites (e.g., required authentication), side effects, or return details. This is adequate for a debug tool but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no unnecessary words. It is front-loaded and efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and zero parameters, the description minimally describes the tool. It does not detail the output format or what the configuration contains, which could be helpful for a debug tool. However, it is arguably sufficient for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. The description adds no parameter info, which is acceptable since there are none. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows current OAuth configuration for debugging. It uses a specific verb ('show') and resource ('OAuth configuration'), and distinguishes itself from sibling tools like mal_authenticate and mal_get_auth_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings such as mal_get_auth_status. There are no explicit when-to-use or when-not-to-use instructions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check current authentication status and get login instructions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the tool checks status and provides login instructions. With no annotations, the description adequately conveys the read-only, non-destructive nature, but does not disclose details like response format or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous information. It is optimally concise for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description is complete enough for a simple check tool. It covers the essential functionality, though additional detail about the response could enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema description coverage is 100% by default. The description adds value by explaining the purpose of the tool, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking authentication status and providing login instructions. It is a specific verb-resource pair, but does not explicitly distinguish from sibling tools like mal_authenticate or mal_revoke_auth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description lacks context such as prerequisites, when the tool is needed, or scenarios to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get basic user information and statistics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose what data constitutes 'basic user information' or 'statistics', nor does it mention authentication requirements or side effects. With no annotations, the description fails to provide sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It is front-loaded and efficient, though it could include slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description is minimal. It does not specify what information is returned, leaving the agent to guess. More detail on the response structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema coverage is 100%. The description does not need to elaborate on parameters. It appropriately indicates the tool requires no input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves basic user information and statistics, with a specific verb and resource. It is straightforward but does not differentiate from sibling tools like mal_get_auth_status or mal_get_user_list, though the lack of parameters suggests it returns info about the authenticated user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 mal_get_auth_status for authentication status or mal_get_user_list for user lists. The intended 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.
Get user's anime list with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of entries to retrieve (max 1000) | |
| offset | No | Offset for pagination | |
| status | No | Filter by list status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Get user's anime list' without disclosing behavioral traits such as authentication needs, rate limiting, pagination behavior, or effects. The description carries full burden but adds minimal transparency beyond the function name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately short, though it could include more context about the return value without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotation, the description fails to explain what the returned list contains (e.g., titles, scores), that authentication is required, or that the list is for the authenticated user. The tool's behavior is under-specified for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents the parameters. The description adds no new semantic information beyond 'with optional filters', providing no extra meaning over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get user's anime list with optional filters', which is a specific verb and resource. It distinguishes from sibling tools like mal_get_user_info (user profile) and mal_get_auth_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving an anime list, but does not provide explicit context about authentication requirements, when to use vs. alternatives, or limitations. The sibling list provides some implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove anime from user's list
| Name | Required | Description | Default |
|---|---|---|---|
| anime_id | Yes | MyAnimeList anime ID to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states the action but does not disclose authentication requirements, reversibility, or behavior when anime is not in list. For a destructive operation, more disclosure is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but could be slightly expanded to include usage context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and no description of return values or error handling. For a simple delete, mention of success/failure confirmation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (anime_id) with schema description coverage 100%. The description 'MyAnimeList anime ID to remove' is adequate but adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove anime from user's list' clearly states the action (remove) and the resource (anime) and scope (from user's list). It distinguishes from bulk deletion and update siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like mal_bulk_delete_anime. Does not state prerequisites (e.g., authentication, anime must exist in list).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revoke stored authentication tokens
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks details on side effects (e.g., invalidation of sessions, need for re-authentication). For a destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-formed sentence with no unnecessary words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, param-less tool, the description is minimally viable. However, it lacks details about return values or confirmation, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the description does not need to add parameter details. It provides context by specifying 'stored authentication tokens', adding meaning to the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Revoke' and the resource 'stored authentication tokens', making the action unambiguous. It effectively distinguishes from siblings like mal_authenticate (create) and mal_get_auth_status (check status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context as a counterpart to authentication, but does not explicitly specify when to use versus alternatives. However, the tool's simplicity (no parameters) makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update anime in user's list (status, score, episodes watched)
| Name | Required | Description | Default |
|---|---|---|---|
| score | No | Score from 0-10 (0 removes score) | |
| status | No | New status for the anime | |
| anime_id | Yes | MyAnimeList anime ID | |
| is_rewatching | No | Whether currently rewatching | |
| num_watched_episodes | No | Number of episodes watched |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only states the verb 'Update' without disclosing behavioral traits such as authentication requirements (presumably needed), side effects, or whether the user's list must exist. This leaves significant gaps in understanding the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient and front-loaded. However, it sacrifices some completeness for brevity, earning a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should provide more context about prerequisites (e.g., authentication, existing entry) and return behavior. It currently lacks this, making it incomplete for a mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The tool description restates some fields (status, score, episodes watched) but adds no new semantic information beyond what the schema already provides. Baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('anime in user's list'), and explicitly mentions the fields that can be updated (status, score, episodes watched). This clearly distinguishes it from sibling tools like mal_remove_anime (delete) and mal_get_user_list (read).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating individual anime entries, but provides no explicit guidance on when to use this tool versus alternatives like mal_bulk_update_anime for batch updates or mal_remove_anime for deletion. No when-not-to-use or prerequisite context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0mal_authenticatemal_bulk_add_animemal_bulk_delete_animemal_bulk_update_animemal_debug_configmal_get_auth_statusmal_get_user_infomal_get_user_listmal_remove_animemal_revoke_authmal_update_animeScored across 11 tools
Each tool has a distinct purpose: authentication, user info, list retrieval, and CRUD operations on anime list entries are clearly separated. Bulk operations are distinct from single ones, and authentication tools cover different steps.
All tools follow the 'mal_verb_noun' pattern consistently. Verbs are descriptive and consistent (e.g., get_, update_, remove_, bulk_*). No mixing of styles.
11 tools is well-scoped for a MyAnimeList user list management server. Covers authentication, CRUD, bulk operations, and debugging without excess.
The set covers most lifecycle operations for anime list entries, but lacks a single-add tool (only bulk add). Also missing update for user profile, but that's minor. Agents can work around using bulk_add with a single ID.
Access and interact with anime and manga data seamlessly. Retrieve detailed information about your…
AniList MCP — wraps AniList GraphQL API (free, no auth)
Accurate anime-song (anison) database for AI-built playlists — export to Spotify/Apple/YT Music
Media memory for AI agents and their humans: books, movies, music, shows, anime, podcasts, games.