Skip to main content
Glama
elibonk

MyDramaList MCP

by elibonk

mdl_titles_get_progress

Read-onlyIdempotent

Fetch the configured account's watch progress for a MyDramaList title by title ID. Requires host-configured MyDramaList authentication.

Instructions

Titles: get progress. Requires host-configured MyDramaList authentication.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
title_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds the authentication requirement, which is genuine extra context, but discloses nothing about what 'progress' data is returned or any rate/scope limits.

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?

Very short and front-loaded, with no filler, which is good. But the brevity comes at the cost of under-specification — the second sentence carries only an auth note, leaving the core concept of 'progress' unexplained.

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?

There is no output schema, so the description carries the burden of explaining what the tool returns — yet 'progress' is never defined. Combined with 0% schema coverage on the only parameter, an agent lacks enough to call this confidently.

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% for the single required title_id parameter, so the description must compensate and does not. It never mentions the parameter, its accepted integer-or-string form, or the positive-integer/pattern constraints the schema imposes.

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?

States a verb (get) and resource (progress) tied to 'Titles', so the domain is identifiable. However, 'progress' is left ambiguous — it never clarifies whether this is a user's watch progress, a release/airing progress, or completion status, and no sibling is named for 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?

The only guidance is an authentication prerequisite ('Requires host-configured MyDramaList authentication'), which is a precondition rather than usage guidance. There is no statement of when to call this versus related siblings like mdl_titles_get_title or mdl_watchlist_get_last_activities.

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

Deploy Server

Other Tools