jdownloader-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation or stage (linkgrabber vs downloads vs global controller). The only adjacent tools, force_start and control_downloads, have clearly different scopes (specific items vs global state).
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (add_links, list_downloads, set_priority). Minor deviations: status, wait_for, remove, and reset are shorter but still intuitive; no mixing of styles.
Tool Count4/5
At 17 tools, the set is on the heavier side but each tool covers a meaningful function in the download lifecycle. The count is reasonable for a full-featured download manager.
Completeness5/5
The toolkit covers the full workflow: adding, collecting, moving, controlling, prioritizing, configuring directories/extraction, and removing/resetting. The raw_action fallback ensures no endpoint is unreachable, making the surface effectively complete.
Average 3.6/5 across 17 of 17 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 23 commits in the last 12 weeks
- Last stable release on August 4, 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.
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, the description carries the full burden of behavioral disclosure. It states the mutation action ('set') and scope ('for the given download-queue packages') but omits details like whether existing directories are overwritten, permission requirements, side effects, or result confirmation.
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 a single, clear sentence that front-loads the core action and object. Every word contributes meaning, with no filler or 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?
Given the lack of annotations, no output schema, and the presence of many sibling tools with overlapping concepts, the description is not complete. It lacks usage context, behavioral caveats, and return expectations, leaving an agent under-informed for reliable invocation.
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%, so the description must compensate. It vaguely maps 'directory' to the target directory and 'package_ids' to 'download-queue packages', but offers no format, constraints, or behavior beyond the parameter names. This is insufficient for full understanding of parameter semantics.
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 identifies the action ('set') and resource ('download directory') for specific entities ('given download-queue packages'). It distinguishes from siblings like get_directories (retrieval) and set_extraction (different resource), though it does not 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 alternatives. There is no mention of prerequisites, when not to use it, or how it fits into a workflow. The context of setting a directory is only implicitly understood from the name and description.
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 must bear the full burden of behavioral disclosure. It only states the two actions but does not explain side effects, reversibility, requirements, or what happens when parameters are null. This is insufficient for a configuration 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 a single concise sentence that front-loads the main actions. It avoids unnecessary words, though the phrase 'and/or' is slightly awkward. It earns its place but is terse.
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 lack of annotations and output schema, the description should explain what the tool does beyond the bare action. It does not mention return values, behavior of null inputs, or any downstream effects. For a simple tool this is minimal but still leaves the agent with limited context for correct invocation.
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%, so the description must compensate. It hints at parameter roles by mentioning 'Toggle' (implying 'enabled') and 'set a custom extract path' (implying 'custom_path'), but it does not describe the parameters explicitly or explain their interaction or defaults beyond what the schema already titles.
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 identifies the tool's dual function: toggling the extraction extension and setting a custom extract path. It uses specific verbs ('Toggle', 'set') and a specific resource ('extraction extension', 'custom extract path'), distinguishing it from generic sibling tools like set_enabled and set_download_dir.
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. It does not mention prerequisites, exclusions, or contrast with sibling tools such as set_enabled for toggling or set_download_dir for path settings. The usage context is entirely absent.
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 burden of behavioral disclosure. It states the action ('promote') but does not disclose whether items are removed from the linkgrabber, what happens for invalid IDs, or what the return value is. The 'resolved' precondition is helpful but incomplete.
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 a single, front-loaded sentence with no fluff. It is concise and readable, though slightly undersized given the tool's behavioral complexity.
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 annotations, no output schema, and only 0% parameter coverage, this description leaves major gaps: return values, side effects, selection behavior, and error handling are all omitted. It is not complete enough for reliable tool 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?
Schema description coverage is 0% and the description provides no parameter-level semantics. link_ids and package_ids are not explained—neither their relationship nor whether one is required over the other. The parameter names are somewhat self-explanatory, but the description adds no meaning beyond the schema.
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 uses a specific verb ('Promote') with a clear resource ('resolved linkgrabber items') and destination ('download queue'). It clearly distinguishes from siblings like add_links, list_linkgrabber, and control_downloads.
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 word 'resolved' implies a precondition for use, but no explicit alternatives or when-not-to-use scenarios are given. It provides some implied usage context but lacks explicit guidance compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description discloses an important side effect: from_disk=True deletes files from disk. It also notes this applies only to downloads, which is a useful scope restriction. Missing details include whether removal is permanent, what happens to associated metadata, or required permissions, but the key destructive behavior is surfaced.
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: two short sentences, front-loaded with the primary purpose and one crucial qualifier. Every word contributes value with no redundancy or fluff.
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 four optional parameters, no annotations, and no output schema, the description is markedly incomplete. It fails to explain how to specify what to remove (link_ids vs package_ids), what stage options exist, or what the tool returns. An agent would struggle to construct a correct invocation beyond guessing from param names.
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%, so the description must explain parameters. Only from_disk is partially explained (its effect on files), while stage, link_ids, and package_ids are left completely undefined. The description does not clarify the distinction between link_ids and package_ids or valid values for stage.
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 primary action ('Remove items from a list') and the from_disk qualifier, which distinguishes it from sibling tools like add_links and move_to_downloads. However, 'list' is generic and does not specify whether it targets linkgrabber or downloads, leaving some ambiguity.
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 reset or move_to_downloads. It only mentions a constraint (from_disk applies 'downloads only') but does not explain selection criteria or exclusions. This is insufficient for an agent to decide between 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, the description carries the full burden for behavioral disclosure. It states the toggle action but does not explain scoping behavior (e.g., whether link_ids/package_ids act as filters or targets), the effect on running downloads, or whether changes are reversible. This 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to defining the action and scope, achieving maximum brevity while remaining clear.
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 has 4 parameters, no output schema, and no annotations, yet the description is extremely thin. It fails to clarify the role of the selection parameters (link_ids, package_ids), the default behavior when they are null, or the practical difference between 'enabled' and related sibling actions. This is inadequate for safe and correct invocation.
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%, so the description must compensate. It only adds meaning for the 'stage' parameter by listing valid values, but it does not explain 'enabled', 'link_ids', or 'package_ids' beyond their names and schemas. Given 4 parameters and minimal param-level guidance, this is a significant gap.
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 identifies the action ('Enable/disable') and the resource ('items in the given stage'), and explicitly enumerates valid stage values (linkgrabber | downloads). This distinguishes it from sibling tools like set_priority or control_downloads, making the primary function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to toggle item enabled-state within a specific stage, and the stage list provides some context. However, it does not explicitly state when to prefer this tool over alternatives, nor does it mention prerequisites or exclusions, leaving the guidance only implicit.
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, the description carries full responsibility for disclosing behavior. It mentions setting priority but does not explain effects like what happens when both link_ids and package_ids are provided, whether priority is overwritten or appended, or any side effects. It also does not describe return values or error conditions.
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 a single sentence with no filler. It front-loads the core action and includes the key scoping information (stage). Every word earns its place, and it is easy to scan.
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?
Despite the tool having 4 parameters and no annotations/output schema, the description only covers the basic purpose and stage values. It lacks detail on parameter interactions, priority value enumeration, prerequisites, and behavioral outcomes. This is insufficient for an agent to confidently invoke the tool with correct parameter combinations.
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%, so the description must compensate. It provides useful context for the `stage` parameter (allowed values: linkgrabber|downloads) and mentions priority range (HIGHEST..LOWEST), but it does not explain the relationship between `link_ids` and `package_ids` (e.g., are they alternatives or combinable), nor the exact set of valid priority values. The term 'items' is vague and does not clearly map to the schema's parameters.
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 action ('Set priority'), the resource ('items'), and the scope ('in the given stage (linkgrabber | downloads)'). This distinguishes it from sibling tools like set_enabled or set_extraction, which target different attributes.
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 used to set priority on items in either the linkgrabber or downloads stage, but does not explicitly mention when to use it over alternatives or any exclusion criteria. No alternative tools are named, so guidance is only implied.
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?
There are no annotations, and the description provides minimal behavioral context. It does not mention that this is a write operation, what happens to the added container (e.g., goes to linkgrabber), or any side effects. The word 'Add' implies mutation, but no further transparency is offered.
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 a single concise sentence that front-loads the action and resource. It avoids redundancy and includes only essential information, making it easy to scan and understand.
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?
With only two parameters, no output schema, and no annotations, the description is relatively complete for a simple tool. Yet it lacks context about what 'content' means, whether the container is added to a specific list, and what the expected outcome is. This leaves the agent uncertain about the exact invocation semantics.
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 coverage is 0%, so the description must clarify parameters. It does add value by enumerating allowed container_type values (DLC | RSDF | CCF), which the schema does not provide as enums. However, 'content' is left vague—only described as 'by its content' without explaining what format or source is expected. Partial compensation for schema gap.
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 a specific action ('Add') applied to a specific resource ('link container'), and lists the valid container types (DLC | RSDF | CCF). It distinguishes itself from the sibling 'add_links' by targeting container files rather than plain links.
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: use this when you have a container file to add. However, it does not explicitly contrast with alternatives like 'add_links' or state when not to use it. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of transparency. It discloses that autostart moves links to the download queue once resolved and mentions the priority range, but it omits important behaviors such as resolution side effects (network requests), error handling, and package handling.
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, consisting of two sentences that are appropriately front-loaded with the primary action. It adds relevant detail (autostart behavior and priority range) without wasted words.
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?
For a tool with 7 parameters, no annotations, and no output schema, a two-sentence description is inadequate. It lacks return value information, side effects, and parameter details, leaving much to be inferred by the agent.
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 description explains the autostart parameter (moves to download queue) and the priority range (HIGHEST..LOWEST), but it leaves urls, package, extract_password, download_password, and destination_folder unexplained. With 0% schema coverage, this is insufficient for a tool with seven parameters.
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 action ('Add URLs') and the target ('linkgrabber'), distinguishing it from sibling tools like add_container and move_to_downloads. It also provides brief notes on autostart and priority, reinforcing the tool's specific role.
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?
No explicit guidance is given on when to use this tool over alternatives like add_container or force_start. The description implies usage by stating the tool adds URLs to the linkgrabber, but it does not mention when not to use it or provide alternative tool references.
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, the description carries the burden of behavioral disclosure. It communicates that the tool retrieves directory/settings information, which implies a read-only operation, but it does not describe behavior when package_ids is null, return format, or error cases. Some useful context is added via 'extension enabled' and 'custom extract path'.
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 a single concise fragment that wastes no words and front-loads the key content. Every element ('per-package save paths', 'default download folder', 'extraction settings') carries meaningful information.
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 getter with one optional parameter and no output schema, the description gives a reasonable overview of the response categories. However, it lacks details about how results are structured, the effect of omitting package_ids, and whether the response is grouped per package. This leaves some gaps for an agent to handle correctly.
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 optional parameter with no description, and schema coverage is 0%. The description adds partial meaning by tying 'per-package save paths' to package_ids, but it does not clarify how package_ids affects the default folder/extraction settings or what null means. This partially compensates for the missing schema 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 lists the specific information returned (per-package save paths, default download folder, extraction settings) and the tool name 'get_directories' reinforces the retrieval purpose. It is specific and distinguishable from sibling setters, though it lacks an explicit verb.
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?
Usage is implied by the tool being a getter: an agent would use it to inspect current save paths and extraction settings, as opposed to set_download_dir or set_extraction. However, there is no explicit when-to-use guidance or mention of alternatives.
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, the description bears the full burden of disclosing behavior. It does not explain what each action does (e.g., does 'stop' cancel downloads or just pause them?), whether changes are reversible, or any side effects. This is a significant gap for a control 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 extremely concise, front-loading the purpose ('Global queue control') and then listing the action values. Every word earns its place, with no unnecessary fluff or repetition.
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 the tool is simple with one parameter, the description still fails to convey important context like the effect of each action, any prerequisites, or what the tool returns. The absence of an output schema makes this more critical, but the description remains minimally adequate for a basic control action.
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 provides no description or enum for the 'action' parameter, but the description lists the allowed values: start, stop, pause, resume. This adds critical semantic information beyond the schema, though it does not elaborate on the meaning of each value.
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 as 'Global queue control' and lists the supported actions (start, stop, pause, resume). This distinguishes it from sibling tools like force_start or set_enabled, which likely operate on individual items rather than the entire queue.
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 action list implies usage (e.g., use 'pause' to pause the queue), but the description does not explicitly explain when to use this tool versus alternatives like force_start, nor does it exclude cases where another tool would be more appropriate. The guidance is 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It conveys that the tool resets download state and causes re-download, but does not detail side effects like whether existing files are deleted, if downloads are immediately stopped, or if the operation is reversible. The main behavior is stated, but additional nuance is missing.
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 a single, focused sentence with no unnecessary words. It is appropriately sized and front-loaded, delivering the core function efficiently.
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 has 2 optional parameters, no output schema, and no annotations, the description leaves critical ambiguities unaddressed, such as the default behavior when no parameters are provided, the relationship between link_ids and package_ids, and the exact effects of the reset operation. The description is too minimal to be considered complete for this tool.
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 two parameters (link_ids and package_ids) with no descriptions, and the tool description does not explain them. The parameter names hint at their purpose, but the description does not clarify how they interact, whether both can be used together, or what happens when they are null (e.g., does it reset all items?). Schema coverage is 0%, so the description should compensate but does not.
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 resets download-queue items, specifying the action (reset), the resource (download-queue items), and the intended outcome (re-download from scratch). This distinguishes it from siblings like 'remove' or 'force_start'.
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 explicitly indicates when to use the tool: when download-queue items need to be re-downloaded from scratch. It provides clear context but does not mention exclusions or alternatives, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates what the tool returns but does not explicitly state that it is read-only or has no side effects. For a status tool, this is straightforward, but the description does not add behavioral context beyond the basic result.
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 a single, well-structured sentence that immediately conveys the essence of the tool. Every word earns its place, and there is no redundancy or filler.
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?
Given the tool's simplicity (no parameters, no output schema), the description provides a clear overview of the return value: overall state and aggregate speed. It could be slightly more detailed about the format or structure of the state, but for a basic status tool, it is sufficient.
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 zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it does not detract from them.
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 resource (download-controller) and what it provides (state and aggregate speed in bytes/s). It is not a tautology and is distinct from sibling tools that perform actions like add_links or control_downloads, though it lacks an explicit verb like 'get' or 'retrieve'.
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?
Usage is implied by the name 'status' and the description, but there is no explicit guidance on when to use this tool versus alternatives. Since there is no sibling status tool, the intended use is fairly evident, but no exclusions or conditions are provided.
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, the description carries the full burden. It does disclose the key behavioral trait: bypassing queue/connection limits and starting downloads immediately. Yet it omits side effects (e.g., impact on existing downloads, reversibility) and prerequisites, which a mutation tool should clarify. It adds some value over the name but is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. It efficiently conveys the core action and qualifier, earning a top score for conciseness and clear structure.
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 is relatively simple, but with no output schema and no annotations, the description should ideally clarify return behavior, expected outcomes, or error conditions. It explains the action but leaves gaps around parameter usage and side effects, making it minimally adequate for context completeness.
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 coverage is 0%—the description never mentions link_ids or package_ids. While the schema names are clear, the description does not explain that users can pass either or both, nor what happens if both are null. Given low schema coverage, the description should compensate but doesn't, providing minimal semantic value.
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 action ('Force... to download now') and resource ('given items'), with a specific qualifier ('bypassing queue/connection limits') that distinguishes it from sibling tools like control_downloads or move_to_downloads. This meets the 'specific verb+resource, distinguishes from siblings' criterion.
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 phrase 'bypassing queue/connection limits' clearly implies this tool is for forcing downloads immediately, overriding normal limits—a context distinct from siblings. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of the 'explicit when/when-not/alternatives' standard for a 5.
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, the description carries the full burden of behavioral disclosure. It explains the path format and that params is a positional argument list, but it does not mention return values, side effects (e.g., destructive actions), error handling, or authentication requirements, which are critical for a raw passthrough tool. The 'call any endpoint' phrasing hints at broad behavior but lacks explicit safety or response info.
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 one concise, front-loaded sentence that efficiently states purpose, gives examples, and explains the key parameter. Every phrase earns its place, with no redundant or filler 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?
Given no output schema and no annotations, the description provides a reasonable but incomplete picture. It covers purpose and parameter semantics but omits return values and side-effect warnings, which are especially important for an arbitrary endpoint caller. The tool's simplicity and clear role prevent a lower score, but the lack of behavioral details 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?
Schema description coverage is 0%, so the description compensates by explaining that params is the positional argument list and giving an example path format. It does not explain http_action, but the name and default ('POST') make it self-evident. This adds meaning beyond the bare schema.
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 identifies the tool as a generic caller for any JD API endpoint not covered by dedicated wrappers, with concrete examples (premium accounts, captcha, reconnect, speed-limit). It distinguishes itself from sibling tools by explicitly positioning itself as the 'not wrapped above' fallback, making its purpose unmistakable.
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?
It states when to use: for endpoints not wrapped by other tools, and gives examples that imply alternatives (the specialized sibling tools). While it doesn't explicitly say 'use other tools for wrapped endpoints', the phrase 'not wrapped above' plus the examples provide clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 the bounded nature (cap 120s), the possible return values, and the retry instruction. It is a read/poll operation and the side-effect-free nature is implied by 'poll' and 'returns', but it could be more explicit about not mutating state.
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 sentences, front-loaded with the core action ('Bounded poll'), and every clause adds useful information—no filler. The return statuses and re-call guidance are packed efficiently.
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 two-parameter tool with no output schema, the description covers the essential behavior: what it polls, the timeout cap, the possible return statuses, and the retry instruction. It misses precise parameter semantics but is otherwise complete enough for an agent to select and invoke correctly.
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%. The description mentions 'one download package' (mapping to package_id) and a 120s cap (relating to timeout_s), but it does not directly explain the timeout_s parameter, its units, or how it relates to the cap. It doesn't sufficiently compensate for the lack of parameter descriptions in the schema.
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 action: 'Bounded poll of one download package' with a specific resource (download package) and a cap of 120s. It also lists the distinct return statuses, which differentiates it from sibling tools like status or list_downloads.
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?
It provides explicit usage guidance by saying 're-call on still_running', indicating a polling loop with retry behavior. It implies its use for waiting on a package rather than a one-shot check, but it doesn't explicitly name alternatives like 'status' or say when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses output fields and a key behavioral trait (poll-friendly), which strongly implies a read-only, lightweight operation. It doesn't mention auth or rate limits, but for a simple list tool these are less critical.
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?
Two sentences, front-loaded with the action and resource, followed by a valuable usage hint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-param tool with no output schema, the description provides sufficient detail: it names the main return fields and gives a clear use case. The tool is simple, and the description covers all essential aspects.
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 zero parameters, and the description correctly doesn't discuss any. Baseline for 0 params is 4; no further elaboration needed.
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 download-queue packages' with a specific verb and resource. It distinguishes from the sibling 'list_linkgrabber' by focusing on the download queue and enumerating exact fields (progress_pct, speed, ETA, status, saveTo).
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 phrase 'The workhorse for polling' gives clear usage context, implying frequent/repeated calls for progress monitoring. However, it does not explicitly mention when to prefer this over alternatives like 'status' or 'wait_for', though the name and field list imply its niche.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the exact output content (status, collecting state, and UUIDs), which is valuable behavioral detail. The verb 'list' implicitly indicates a read-only operation, though explicit safety notes are absent.
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 sentences with no redundancy. It front-loads the action and resource, and every word adds value—first the primary function, then the critical UUID usage note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter-less list tool with no output schema, the description covers all essential aspects: what is listed, status details, the collecting state, and the presence of UUIDs for actions. It is sufficiently complete for an agent to use the tool correctly.
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 zero parameters, so the description appropriately does not discuss them. The baseline for 0 parameters is 4, and the description adds no confusion by mentioning parameters that do not exist.
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 lists linkgrabber packages and links with online/offline status and whether JD is still collecting. It distinguishes itself from sibling list_downloads by explicitly naming 'linkgrabber' and provides actionable output details (UUIDs).
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 implies usage context: it is for inspecting linkgrabber items and the UUIDs are meant for subsequent actions. It does not explicitly name alternatives or exclusions, but the context is clear enough for an AI agent to know when to invoke it.
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:

[![jdownloader-mcp MCP server](https://glama.ai/mcp/servers/swe-sanad/jdownloader-mcp/badges/card.svg)](https://glama.ai/mcp/servers/swe-sanad/jdownloader-mcp)

Score Badge

Copy to your README.md:

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

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