Docker 컨테이너로 패키징된 다운로드 클라이언트용 MCP 서버입니다. servarr-mcp와 같은 미디어 관리 MCP의 동반 도구입니다.
각 클라이언트는 선택 사항입니다. 실제로 실행 중인 클라이언트만 구성하면 해당 도구만 등록됩니다.
도구 | 설명 |
| 속도 및 예상 완료 시간을 포함한 현재 다운로드 대기열 |
| 최근 기록 (최신순) |
| 구성된 카테고리 |
| SABnzbd 버전 정보 |
도구 | 설명 |
| 토렌트 목록 (선택적 상태 필터) |
| info-hash별 토렌트 세부 정보 |
| 토렌트 내 파일 |
| 전체 전송 통계 |
| 구성된 카테고리 |
| qBittorrent 애플리케이션 버전 |
Related MCP server: NZBGet MCP Server
각 클라이언트를 활성화하려면 전체 구성 블록이 필요합니다. 구성이 부분적일 경우 클라이언트는 자동으로 비활성화됩니다.
클라이언트 | 필수 환경 변수 | 기본 포트 |
SABnzbd |
| 8080 |
qBittorrent |
| 8080 |
API 키/자격 증명은 각 앱의 설정에서 찾을 수 있습니다:
SABnzbd: 설정 → 일반 → API 키
qBittorrent: 도구 → 옵션 → Web UI (기본 사용자 admin)
참고: SABnzbd와 qBittorrent 모두 기본 포트가 8080입니다. 동일한 호스트에서 둘 다 실행하는 경우, 각자의 구성에서 하나를 재매핑하십시오.
최소 하나의 클라이언트가 구성되어야 하며, 그렇지 않으면 서버가 오류와 함께 종료됩니다.
docker build -t downloader-mcp .
docker run -i --rm \
-e SABNZBD_URL=http://192.168.1.50:8080 -e SABNZBD_API_KEY=... \
-e QBITTORRENT_URL=http://192.168.1.50:8081 \
-e QBITTORRENT_USERNAME=admin -e QBITTORRENT_PASSWORD=... \
downloader-mcpclaude_desktop_config.json에 추가하십시오:
{
"mcpServers": {
"downloader": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "SABNZBD_URL", "-e", "SABNZBD_API_KEY",
"-e", "QBITTORRENT_URL",
"-e", "QBITTORRENT_USERNAME", "-e", "QBITTORRENT_PASSWORD",
"downloader-mcp"
],
"env": {
"SABNZBD_URL": "http://192.168.1.50:8080",
"SABNZBD_API_KEY": "...",
"QBITTORRENT_URL": "http://192.168.1.50:8081",
"QBITTORRENT_USERNAME": "admin",
"QBITTORRENT_PASSWORD": "..."
}
}
}
}실행하지 않는 클라이언트에 대한 -e/env 항목은 삭제하십시오.
npm install
cp .env.example .env # then edit
SABNZBD_URL=... SABNZBD_API_KEY=... npm run dev컨테이너는 루트가 아닌 사용자(mcp)로 실행됩니다.
자격 증명은 환경 변수를 통해 전달되며 이미지에 포함되지 않습니다.
.githooks/pre-commit은 gitleaks(비밀 정보) 및 PII 패턴 검사(사용자 홈 경로, 개인 도메인 이메일)를 실행합니다. 클론당 한 번 활성화하십시오: git config core.hooksPath .githooks.
List configured qBittorrent categories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states it lists categories, with no mention of side effects, authentication, edge cases (e.g., empty list), or whether it is read-only.
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 directly states the tool's purpose. No 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?
While the operation is simple, the description lacks any hint about the return format or structure. Without an output schema, this is a gap. The description could mention that it returns a list of category objects.
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 input schema has no parameters (100% coverage trivially), so baseline is 4. The description adds the purpose of listing categories, which is essential given the empty 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 the action 'List' and the resource 'configured qBittorrent categories', providing a specific verb+resource combination. It distinguishes the tool from siblings like qbittorrent_list_torrents and sabnzbd_categories.
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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or context for listing categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a single torrent by info-hash.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | The torrent info-hash |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Get details', implying a read operation. It does not explicitly state if it has side effects, requires authentication, or what errors may occur. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no redundancy, but could add more detail about what 'details' includes. Still efficient.
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?
Lacks output schema or description of return value, so agent doesn't know what to expect. For a simple retrieval, this is acceptable but not fully complete.
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 single parameter 'hash' is described in the schema as 'The torrent info-hash'. The description adds nothing beyond that. Since schema coverage is 100%, baseline 3 is appropriate.
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 tool retrieves details for a single torrent using the info-hash. The verb 'Get' and resource 'details for a single torrent' are specific, and it distinguishes from sibling tools like qbittorrent_list_torrents that list multiple torrents.
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 like qbittorrent_list_torrents or qbittorrent_torrent_files. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List torrents, optionally filtered by status (all, downloading, completed, paused, active, inactive, resumed).
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional status filter: all|downloading|completed|paused|active|inactive|resumed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states listing with filter; no disclosure of output format, pagination, authentication needs, or performance impact. Lacks behavioral context beyond schema.
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, front-loaded with verb and resource, no unnecessary words. Efficiently communicates core functionality.
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?
Minimally adequate for a simple list tool, but lacks any hint about return format (e.g., torrent names vs full metadata). No output schema to compensate.
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% for the single parameter; description restates filter values without adding new semantics (e.g., default behavior, result ordering). Baseline score appropriate.
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 'List torrents' with optional filter, distinguishing from siblings like qbittorrent_get_torrent (single torrent) and qbittorrent_torrent_files (files within a torrent).
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?
Implied usage by stating the action, but no explicit guidance on when to use this tool vs alternatives (e.g., qbittorrent_get_torrent for details). Lacks when-not-to-use or context for choosing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the files inside a torrent.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | The torrent info-hash |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose any behavioral traits (e.g., side effects, prerequisites, or return format). Assumes a simple query but lacks detail on behavior.
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 benefit from structured details (e.g., output expectations). No 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?
For a simple list tool with one parameter and no output schema, the description is minimally adequate. Lacks contextual details like auth requirements or constraints.
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% for the single parameter 'hash'. Description adds no additional meaning beyond what the schema already provides.
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?
Description clearly states the action (list) and the resource (files inside a torrent), effectively distinguishing from sibling tools like qbittorrent_get_torrent and qbittorrent_list_torrents.
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 (e.g., when to list files vs. get torrent info). Description merely states the function without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get global transfer statistics (current speeds, totals, connection state).
| 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 must carry the full burden. It states that the tool gets speeds, totals, and connection state, which implies a read-only operation. However, it does not disclose potential side effects, authentication needs, or rate limits. For a simple stat tool, this is adequate but minimal.
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 front-loaded with the main action and includes relevant examples, making it concise and efficient.
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, and no output schema, the description provides a reasonable overview of what the tool returns. It could be more specific about the data format, but it covers the key elements (speeds, totals, connection state).
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 input schema has no parameters, and schema description coverage is 100%. According to guidelines, a baseline of 4 is appropriate when there are no parameters, as the description does not need to add parameter information.
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 'Get global transfer statistics (current speeds, totals, connection state)' uses a specific verb and resource, and the examples clarify the scope. It effectively distinguishes the tool from siblings like qbittorrent_version or qbittorrent_list_torrents.
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 when global transfer statistics are needed, which is clear given the tool's name and the lack of parameters. It does not explicitly state when not to use it or mention alternatives, but the context from sibling tools makes this partly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get qBittorrent application version.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly implies a read-only operation with no side effects. Since no annotations are provided, the description carries the burden, and it adequately conveys the non-destructive nature of the tool.
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 conveys the essential information without 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?
For a simple version retrieval tool with no parameters or output schema, the description is sufficient. It tells the agent what to expect, though it does not specify the exact format of the version string.
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?
No parameters exist, so the schema provides all necessary information. The description adds nothing beyond the schema, but per guidelines, 0 parameters yields a baseline of 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 verb 'Get' and the resource 'qBittorrent application version'. It is specific and distinguishes from sibling tools like qbittorrent_categories or qbittorrent_list_torrents.
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. While the use case is obvious (retrieving version info), the description provides no context or exclusions, leaving the agent without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured SABnzbd categories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral traits are disclosed beyond the basic action. The description does not mention read-only nature, authentication requirements, or what constitutes a 'configured' category. Since no annotations are provided, the description carries the full burden but fails to add 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 sentence of five words, front-loading the key action and resource. Every word is essential, with no redundancy or filler.
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 low complexity (no parameters, no output schema), the description is mostly complete. It tells the agent what the tool does, though it could be improved by noting that the output is a list of category names or configurations.
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 zero parameters, so baseline is 4 per instructions. The description adds no parameter information, but the schema is empty and coverage is 100%, so no additional meaning is needed.
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 the specific verb 'List' and identifies the resource 'configured SABnzbd categories.' It clearly distinguishes itself from sibling tools like sabnzbd_history and sabnzbd_queue, which have different purposes.
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 does not explain the context or trade-offs, such as when to list categories versus other SABnzbd operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent SABnzbd download history (newest first).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Records to return (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks details on read-only nature, time range for 'recent', or mutation behavior. No annotations exist, so the description should compensate but does not.
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?
One concise sentence that directly conveys the purpose. No unnecessary words, though it could include more detail without losing conciseness.
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?
Adequate for a simple list tool with one parameter and no output schema. However, lacks behavioral details like time range or pagination beyond the limit.
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 single parameter 'limit' is fully described in the schema (100% coverage), so the description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate.
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 function: retrieving recent SABnzbd download history with newest first ordering. It distinguishes from siblings like sabnzbd_queue (current queue) and sabnzbd_categories.
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 such as sabnzbd_queue or sabnzbd_version. No mention of prerequisites or contextual usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current SABnzbd download queue (in-progress jobs, speeds, ETAs).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description must cover behavioral traits. It states the tool returns queue data (in-progress jobs, speeds, ETAs), which is read-only. No mention of authentication needs, rate limits, or side effects, but the operation is simple and safe.
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 sentence that efficiently front-loads the key information (verb, resource, and purpose). Every word earns its place with no redundancy.
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 mostly complete. It could mention that it retrieves the default server's queue, but the low complexity makes this acceptable.
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 input schema has zero parameters, so description coverage is 100% (vacuously). Per guidelines, 0 parameters merits a baseline of 4. The description adds no parameter-specific info 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 uses a specific verb 'Get' and resource 'current SABnzbd download queue', clearly distinguishing it from siblings like sabnzbd_history (completed downloads) and qbittorrent tools (different client).
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 (e.g., sabnzbd_history or qbittorrent_list_torrents). The description lacks context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SABnzbd version info.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It accurately describes a read-only operation with no side effects, rate limits, or other concerns. The behavior is trivial and well communicated.
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 straightforward sentence with no wasted words. The message is front-loaded and perfectly scoped.
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 zero parameters, no output schema, and a simple operation, the description is fully adequate. No additional information is required.
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?
No parameters exist, and schema coverage is 100%. The description adds no additional parameter info, but none is needed. Baseline score of 3 is appropriate.
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 SABnzbd version info,' using a specific verb and resource. It distinguishes from sibling tools like qbittorrent_version by the service prefix.
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 versus alternatives. However, the sibling tools are for different services (qbittorrent) or functions (history, queue), so the context is implicitly clear 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0qbittorrent_categoriesqbittorrent_get_torrentqbittorrent_list_torrentsqbittorrent_torrent_filesqbittorrent_transfer_infoqbittorrent_versionsabnzbd_categoriessabnzbd_historysabnzbd_queuesabnzbd_versionScored across 10 tools
Every tool is clearly distinguished by its client prefix (qbittorrent_ vs sabnzbd_) and specific action, with no overlap in functionality between tools.
All tools use a consistent snake_case client_verb_noun pattern, making it easy to predict tool names and purposes.
10 tools is well-scoped for a server supporting two download clients, covering essential query operations without unnecessary bloat.
While query operations are well-covered (list, get, categories, etc.), the server lacks mutation commands like add, remove, or pause torrents/jobs, which are expected for a downloader tool.
A registry of AI agent tools — MCP servers, APIs, CLIs, SDKs — kept current by automated ingestion.
Hosted MCP tools for FFmpeg-style video and audio processing through FFMPEG API.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
