What can you do with this server?

The yamtrack-mcp server allows LLMs to interact with a Yamtrack instance for comprehensive media tracking and management across multiple types (tv, movie, anime, manga, game, book, comic, boardgame) and providers (TMDB, MAL, IGDB, OpenLibrary, etc.). Discovery & Search * Search media by title and type across external providers * Get detailed metadata for a specific media item, including TV season info Tracking Management * List tracked media with filtering by status (Completed, In Progress, Planning, Paused, Dropped), title search, sorting, and pagination * View a dashboard (get_home) showing in-progress and planning items * Create entries from an external provider by ID, or manually with a custom title * Update entries (status, score, progress, notes) * Delete entries from your tracked list Progress & Scoring * Increment or decrement progress on a tracked item * Set score independently (0–10 scale) * Mark specific episodes as watched by season and episode number History, Stats & Sync * View change history for any tracked media item * Get aggregated user statistics, optionally filtered by date range * Re-sync metadata from the original provider to keep info up-to-date Account * Retrieve current authenticated user info * Authentication via static API token or username/password with auto-refresh; read-only tools (search, get details) work without authentication

Which integrations are available for this server?

Provides tools for searching and retrieving media metadata from IGDB, including details like titles, artwork, and descriptions, as well as tracking media progress and status through a Yamtrack instance.

How do I use yamtrack-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@yamtrack-mcp search for movie Inception" 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.

yamtrack-mcp

by URD0TH

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

yamtrack-mcp

Security Policy

Leer en español

A standalone Model Context Protocol server (stdio or http transport, TypeScript) that exposes the Yamtrack REST API as tools for LLMs (Claude Desktop, OpenCode, VS Code, Hermes, etc.).

It runs on any machine and talks to a Yamtrack instance over its public REST API. No Django code required.

Requirements

Node.js 18+ (developed on v22/v26)
A reachable Yamtrack instance (e.g. http://localhost:8000 or your hosted URL)
An API token for that instance (from Account settings → Integrations)

Related MCP server: KappaML MCP Server

Install

Distributed via GitHub only — it is not published to npmjs.com, so npx yamtrack-mcp (the public unscoped name) will not work. Choose one of the two methods below.

1. Global install from release tarball (recommended)

Download the pre-built tarball from the latest release and install globally:

npm install -g https://github.com/URD0TH/yamtrack-mcp/releases/latest/download/urd0th-yamtrack-mcp-0.1.2.tgz

After this, the yamtrack-mcp command is available everywhere.

Or skip the install and run directly with npx:

npx github:URD0TH/yamtrack-mcp

Security note: pin an explicit version (change 0.1.2 to the tag you want) rather than relying on latest, so a compromised push can't be pulled automatically.

2. GitHub Packages (scoped registry — requires a token)

The Publish workflow pushes @urd0th/yamtrack-mcp to GitHub Packages on each v* tag. GitHub Packages requires authentication even for public packages, so consumers must configure the @urd0th scope and a GitHub token with read:packages before installing:

echo "@urd0th:registry=https://npm.pkg.github.com" >> ~/.npmrc
echo "//npm.pkg.github.com/:_authToken=<GITHUB_TOKEN>" >> ~/.npmrc
npm install -g @urd0th/yamtrack-mcp        # latest
npm install -g @urd0th/yamtrack-mcp@0.1.0  # specific version

Security note: pin an explicit version (@0.1.0) rather than @latest. Without the .npmrc entries above, npm install -g @urd0th/yamtrack-mcp returns 401.

Build from source

git clone https://github.com/URD0TH/yamtrack-mcp
cd yamtrack-mcp
npm install        # install dependencies
npm run build      # compile src/ -> dist/ (strict TypeScript)

Run

After installing globally (method 1 or 2):

yamtrack-mcp --transport http --port 8080                                # foreground (dev / testing)
yamtrack-mcp --transport http --port 8080 --base-url http://url:port/api # foreground, custom instance
yamtrack-mcp serve --port 9123                                              # daemonized via PM2 (production)
yamtrack-mcp serve --port 9123 --base-url http://url:port/api              # daemonized, custom instance
yamtrack-mcp --transport stdio                 # default, for local stdio clients
yamtrack-mcp serve:status                      # check server status
yamtrack-mcp serve:restart                     # restart
yamtrack-mcp serve:stop                        # stop
yamtrack-mcp serve:logs                        # log file paths
yamtrack-mcp --help                            # show all options

serve vs without serve: Without serve the process runs in the foreground — use it for development, testing, or with your own supervisor (systemd, Docker restart:). With serve the process daemonizes via PM2 with auto-restart and log management (no separate PM2 install required).

With npx (no install):

npx github:URD0TH/yamtrack-mcp --transport http

From source build (Build from source section):

node dist/index.js --transport http

Authentication

The server authenticates to Yamtrack with a single static account API key (from Account settings → Integrations), passed via --token <token> or the YAMTRACK_API_KEY env var. It never expires and is the only credential the server accepts.

Option	Env var	Description
`--transport <type>`	–	`stdio` (default) or `http`
`--base-url <url>`	`YAMTRACK_BASE_URL`	API base URL. Default `http://localhost:8000/api`
`--token <token>`	`YAMTRACK_API_KEY`	Static API key (http fallback when no header)
`--port <n>`	–	Port for `http` transport. Default `8080`
`--help`	–	Show usage

Read-only tools (search_media, get_details) work without authentication.

One token, two ways to pass it. There is a single credential — your Yamtrack account API key. "Bearer" is just how it's sent, not a different token.
stdio: set the raw key in YAMTRACK_API_KEY (or --token). Do not write Bearer — the server adds the Bearer prefix for you when it calls the REST API.
"env": { "YAMTRACK_API_KEY": "<token>" }
http: the client sends Authorization: Bearer <token> and the server forwards that same key. Here you do write Bearer.
"headers": { "Authorization": "Bearer <token>" }
The <token> value is identical in both cases.

HTTP transport

With --transport http the server listens on POST /mcp (StreamableHTTP, stateless). Each connection authenticates via the Authorization: Bearer <token> header it receives, falling back to --token / YAMTRACK_API_KEY when the header is absent. The token is then forwarded as a Bearer token to the Yamtrack REST API, exactly like the stdio transport.

Security note: the HTTP transport has no built-in TLS or rate limiting. Bind it to localhost and expose it only behind a reverse proxy with HTTPS/authentication — never directly to the internet.

Tools

All tools map 1:1 to the REST API documented in wiki/API.md.

Tool	REST endpoint
`search_media`	`GET /search/`
`get_details`	`GET /details/<source>/<type>/<id>/` (+ season)
`list_tracked_media`	`GET /media/<type>/`
`get_home`	`GET /home/`
`get_history`	`GET /history/<source>/<type>/<id>/`
`create_entry`	`POST /media/<type>/create/`
`manual_create`	`POST /media/manual/create/`
`update_entry`	`PATCH /media/<type>/<instance_id>/`
`update_progress`	`POST /media/<type>/<instance_id>/progress/`
`update_score`	`POST /media/<type>/<instance_id>/score/`
`delete_entry`	`DELETE /media/<type>/<instance_id>/delete/`
`sync_metadata`	`POST /sync/<source>/<type>/<id>/`
`create_episode`	`POST /episodes/`
`get_statistics`	`GET /statistics/`
`get_me`	`GET /auth/me/`

Enum values: media_type ∈ {tv, movie, anime, manga, game, book, comic, boardgame, season}, status ∈ {Completed, In progress, Planning, Paused, Dropped}, source ∈ {tmdb, mal, igdb, openlibrary, mangaupdates, comicvine, custom}.

Client configuration

If you installed globally (method 1), use "command": "yamtrack-mcp". If you prefer npx (no install), use "command": "npx" with "args": ["github:URD0TH/yamtrack-mcp"].

Claude Desktop (`claude_desktop_config.json`)

{
  "mcpServers": {
    "yamtrack": {
      "command": "yamtrack-mcp",
      "env": { "YAMTRACK_API_KEY": "<token>" }
    }
  }
}

OpenCode (`opencode.json`)

{
  "mcp": {
    "servers": {
      "yamtrack": {
        "type": "stdio",
        "command": "yamtrack-mcp",
        "env": { "YAMTRACK_API_KEY": "<token>" }
      }
    }
  }
}

VS Code (`.vscode/mcp.json`) / Hermes (`~/.hermes/config.yaml`)

Same command shape; pass the token via the YAMTRACK_API_KEY env var.

HTTP transport (any client that supports `url` + `headers`)

Start the server:

yamtrack-mcp serve --port 8080 --base-url http://url:port/api

Then configure the client:

{
  "mcpServers": {
    "yamtrack": {
      "url": "http://localhost:8080/mcp",
      "headers": { "Authorization": "Bearer <token>" }
    }
  }
}

See the wiki MCP for detailed configuration examples for each client.

Development

npm run verify   # typecheck (tsc) + lint/format (biome) + tests (vitest)
npm run typecheck
npm run lint     # biome check .
npm run format   # biome format --write .
npm run test     # vitest run
npm run dev      # build + run

Integration tests (tests/server.test.ts, tests/http.test.ts) drive every tool against an in-process mock REST API over InMemoryTransport and HTTP, covering auth (static token, per-request Bearer header, fallback token) and request/response shapes.

Resilience

For stdio, the MCP client respawns the process on exit. For HTTP, use the serve subcommand which runs under PM2 with auto-restart and log management (no separate PM2 install needed).

Alternatively, run yamtrack-mcp --transport http with your own supervisor (systemd, Docker restart:, etc.). A supervise.sh helper is also available in the repo.

Project structure

yamtrack-mcp/
├── src/
│   ├── index.ts     # Entry: transport selection (stdio/http), CLI args
│   ├── client.ts    # YamtrackClient: REST wrapper, Bearer auth
│   └── tools.ts     # Tool definitions mapped to REST endpoints (zod schemas)
├── tests/           # Integration tests with a mock REST API
├── biome.json       # Lint + format config
├── tsconfig*.json   # TypeScript (build + typecheck)
└── vitest.config.ts

FAQ

`npm install -g github:URD0TH/yamtrack-mcp` does not work

This command creates a symlink in the global node_modules pointing to a temporary npm directory that gets deleted after installation, leaving a broken binary. This is a known issue with npm install -g and git dependencies.

Use the release tarball (method 1) or GitHub Packages (method 2) instead.

License

Part of the Yamtrack project. See the main repository license.

Available Tools

15 tools

create_entryB

Start tracking media from an external provider by id.

ParametersJSON Schema

Name	Required	Description
`notes`	No
`score`	No
`source`	Yes	Provider source.
`status`	No
`media_id`	Yes	Provider media id.
`progress`	No
`media_type`	Yes	Type of media.

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It does not disclose side effects like whether duplicate IDs overwrite or cause errors, nor permissions or rate limits.

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?

Single sentence, front-loaded, no wasted words. Perfectly concise.

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 having 7 parameters and no output schema, the description provides minimal context. It does not clarify what 'start tracking' entails or what the response will be.

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 low (43%). The description adds no additional meaning beyond the schema; it does not explain parameter values or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'start tracking', the resource 'media', and the method 'from an external provider by id'. This distinguishes it from siblings like manual_create (manual entry) and create_episode (episode-specific).

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 explicit guidance on when to use versus alternatives. Does not compare to manual_create or search_media, nor mention prerequisites or exclusions.

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

create_episodeC

Mark an episode as watched.

ParametersJSON Schema

Name	Required	Description
`source`	Yes	Provider source.
`media_id`	Yes	Provider media id.
`season_number`	Yes	Season number.
`episode_number`	Yes	Episode number.

TDQS

C2.6/5.0

Behavior2/5

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

No annotations provided. The description does not disclose whether marking as watched is idempotent, what happens on repeat calls, or any side effects like updating progress. For a mutation tool, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise and front-loaded, but overly minimal. Could be improved without adding much length.

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 4 required parameters and no annotations or output schema, the description is incomplete. It lacks behavioral details, return value indication, and does not explain what 'mark as watched' entails (e.g., create vs update).

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?

Input schema covers all 4 parameters with descriptions, but the tool description adds no additional meaning or usage hints beyond the schema. Baseline 3 applies due to full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it 'marks an episode as watched,' but the tool name 'create_episode' implies creation. This mismatch creates ambiguity. It does not distinguish from sibling tools like update_progress, which may also handle watched status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool over alternatives (e.g., update_progress for changing progress, update_score for scores). No context about prerequisites or expected workflow.

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

delete_entryB

Delete a tracked media item.

ParametersJSON Schema

Name	Required	Description	Default
`media_type`	Yes	Type of media.
`instance_id`	Yes	Tracked item instance id.

TDQS

B3.4/5.0

Behavior2/5

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

The description adds minimal behavioral context beyond the name. No annotations are provided, so the description carries the full burden but only states the action without consequences, permissions, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with the key verb and resource. Every word contributes meaning, with no redundancy.

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 2-parameter delete tool with no output schema, the description adequately conveys the core function. Missing minor detail like success indication, but generally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description covers parameters fully, providing clear 'Type of media' and 'Tracked item instance id'. The tool description adds no extra meaning beyond the schema, so baseline score applies.

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 'Delete a tracked media item' clearly states the action (delete) and the resource (tracked media item). It distinguishes from siblings like create_entry and update_entry.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, such as irreversible nature or prerequisites. Only implied usage from the name.

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

get_detailsB

Get metadata for a media item from a provider.

ParametersJSON Schema

Name	Required	Description
`source`	Yes	Provider source.
`media_id`	Yes	Provider media id.
`media_type`	Yes	Type of media.
`season_number`	No	Season number (tv only).

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only says 'Get metadata' without indicating read-only nature, authentication needs, or error handling. The seasonal parameter usage is also not explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence and front-loaded, but it is too brief for the tool's complexity. It sacrifices completeness for conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is incomplete. It does not explain return format, conditional parameters (season_number for tv only), or behavior for unsupported media types.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema's parameter descriptions, only labeling the result as 'metadata'.

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 (Get metadata), the resource (media item), and the context (from a provider). It distinguishes from siblings like search_media (which searches) and create_entry (which creates).

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 on when to use or alternatives. Usage is implied by the required parameters (source, media_type, media_id), suggesting this is for fetching a specific item by ID, but the description does not articulate this context.

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

get_historyC

Change history for a tracked media item.

ParametersJSON Schema

Name	Required	Description
`source`	Yes	Provider source.
`media_id`	Yes	Provider media id.
`media_type`	Yes	Type of media.
`season_number`	No
`episode_number`	No

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not mention whether the operation is read-only, what happens if the media item is not found, or any rate 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?

The description is very concise at one sentence, but it lacks structure such as sections or examples. It could be longer to provide necessary details while remaining concise.

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 5 parameters (3 required), no output schema, and no annotations, the description is severely lacking. It does not explain the output format, pagination, or required parameters.

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 60%, so some parameters are documented in the schema, but the description adds no additional meaning beyond listing the output type. It does not explain parameter relationships or format constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool returns 'change history for a tracked media item', which indicates a read operation. However, it lacks a specific verb like 'retrieve' and does not distinguish itself from sibling tools like get_details or get_home.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. No exclusions or context are provided, leaving the agent to infer usage from the tool name alone.

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

get_homeC

Dashboard with in-progress and planning items.

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No	upcoming (default), recent, completion, episodes_left, title.

TDQS

C2.9/5.0

Behavior3/5

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

The description implies a read operation (dashboard), but does not confirm read-only nature, side effects, or authorization requirements. Without annotations, this is minimal but acceptable.

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?

Single sentence with no fluff, front-loading the purpose. Every word is necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should elaborate on what the dashboard contains. It fails to explain 'in-progress' and 'planning items', leaving the agent to infer the return structure.

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 100% for the single parameter, and the description adds no additional meaning beyond what the schema enumerates for 'sort'. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Dashboard with in-progress and planning items' clearly states it returns a dashboard view, but does not specify what items are included or how it differs from sibling tools like get_history or get_statistics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use get_home versus other tools; no mention of prerequisites or preferred contexts.

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

get_meA

Get the currently authenticated user.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided; the description is minimal and does not disclose any behavioral traits beyond the basic action.

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, perfectly concise.

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 tool with no parameters and no output schema, the description is functional but lacks detail on what the returned user object contains.

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?

With zero parameters, the schema coverage is 100%, and the description adds no parameter info, meeting the baseline for no 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 verb 'Get' and the resource 'currently authenticated user', distinguishing it from sibling tools like get_details or get_history.

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 on when to use this tool vs alternatives, but the purpose is straightforward and context is implied.

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

get_statisticsC

Aggregated statistics for the authenticated user.

ParametersJSON Schema

Name	Required	Description	Default
`end_date`	No	End date YYYY-MM-DD or 'all'.
`start_date`	No	Start date YYYY-MM-DD or 'all'.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, so the description must convey behavioral traits. It mentions 'for the authenticated user', implying authentication is required, but fails to disclose any side effects, data freshness, or aggregation logic.

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. While it earns its place by stating the core purpose, it could be more front-loaded with critical details without sacrificing brevity.

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 output schema and annotations, the description is incomplete. It does not explain what statistics are returned or how they are aggregated, leaving the agent without sufficient context to interpret results.

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 100% with explicit parameter descriptions. The description adds no additional meaning beyond the input schema, meeting the baseline.

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 'Aggregated statistics for the authenticated user' clearly identifies the tool as returning statistics for a specific user. However, it does not specify what type of statistics (e.g., activity, media counts), leaving room for confusion among sibling getter tools like 'get_history' or 'get_details'.

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 usage guidelines are provided. There is no advice on when to use this tool versus alternatives such as 'get_details' or 'get_history', nor any mention of prerequisites or context.

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

list_tracked_mediaB

List the authenticated user's tracked media.

ParametersJSON Schema

Name	Required	Description
`page`	No
`sort`	No	Sort field: score, title, progress, start_date, end_date, or any item field.
`search`	No	Case-insensitive title substring.
`status`	No	Filter by status (All by default).
`per_page`	No
`media_type`	Yes	Type of media.

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states 'List', implying read-only, but does not disclose pagination behavior, rate limits, or whether the output is limited. The schema shows pagination params but description omits this context.

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 with no wasted words. It is front-loaded with the core action and resource.

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 6 parameters, no output schema, and no annotations, the description is too sparse. It does not explain the return format, that pagination is available, or that filters (like 'status', 'search') are supported. More details are needed for a tool with this complexity.

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 67% (4 of 6 params have descriptions, but 'page' and 'per_page' lack descriptions). The tool description adds no extra meaning beyond what the schema provides; it does not compensate for missing schema descriptions.

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 'List the authenticated user's tracked media' is clear, specifying verb 'List', resource 'tracked media', and scope 'authenticated user'. This distinguishes it from siblings like 'search_media' or 'get_details'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, no prerequisites or exclusions mentioned. For example, it does not clarify that it lists the user's own tracked entries, not all available media.

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

manual_createC

Create a media entry manually (no external provider).

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Title of the media.
`status`	No
`progress`	No
`media_type`	Yes	Type of media.

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states 'create' and 'no external provider' but gives no information about side effects, permissions, or other behavioral traits like data persistence.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (one sentence) and front-loaded with the key distinction, but it lacks necessary detail for a tool with 4 parameters and no annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, limited parameter descriptions, and no annotations, the description is insufficient to fully understand the tool's functionality. It does not explain the effect of creating an entry or any constraints.

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 50%, but the description does not explain any parameter or add meaning beyond the schema. For example, it does not clarify the 'status' or 'progress' fields, which are not described in the schema.

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 action 'create' and the resource 'media entry', and distinguishes this tool from others by specifying 'manually (no external provider)'. However, it does not explicitly differentiate from the sibling 'create_entry', which might have a similar purpose.

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 explicit guidance on when to use this tool versus alternatives. The description implies usage when creating media without an external provider, but does not mention when not to use or list alternative tools.

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

search_mediaB

Search external providers for media by title.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number.
`query`	Yes	Search query.
`source`	No	Provider source (defaults to the media type's default).
`media_type`	Yes	Type of media to search for.

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the basic action without mentioning potential issues like network failures, rate limits, authentication, or what happens when no results are found.

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 sentence that directly states the purpose without extraneous detail. It is front-loaded and efficient, though it could benefit from a bit more context without becoming verbose.

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 4 parameters, no output schema, and no annotations, the description is too sparse. It fails to explain how the parameters interact (e.g., source vs. media_type defaults) or how pagination works, leaving the agent without sufficient context to use the tool effectively.

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 input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description does not add any additional meaning beyond what is already in the schema (e.g., clarifying 'query' further or explaining enum values).

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 specifies the action ('search'), the resource ('external providers for media'), and the filtering criterion ('by title'). This distinguishes it from sibling tools like create_entry or get_details.

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 get_details for local entries or other sibling tools. There is no mention of prerequisites or scenarios where this tool is appropriate.

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

sync_metadataC

Re-sync metadata for a media item from its provider.

ParametersJSON Schema

Name	Required	Description
`source`	Yes	Provider source.
`media_id`	Yes	Provider media id.
`media_type`	Yes	Type of media.

TDQS

C2.6/5.0

Behavior1/5

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

The description provides no behavioral details beyond the action itself. Without annotations, the agent is left guessing about side effects, idempotency, required permissions, or what data is overwritten.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but overly minimal. It lacks structure and fails to provide necessary context, making it less useful than it could be.

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 three required parameters, no output schema, and no annotations, the description is incomplete. It does not explain what happens after sync, error handling, or the result format.

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 100% with clear param descriptions. The tool description does not add extra meaning but does not need to, as the schema already explains each parameter.

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 verb 're-sync' indicates refreshing metadata, and the resource is clearly a media item from its provider. However, 're-sync' is somewhat vague and does not differentiate from sibling tools like update_entry, which also modifies entries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like update_entry or search_media. The description lacks context on prerequisites or use cases.

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

update_entryB

Update a tracked media item (status, score, progress, notes).

ParametersJSON Schema

Name	Required	Description
`notes`	No
`score`	No
`status`	No
`progress`	No
`media_type`	Yes	Type of media.
`instance_id`	Yes	Tracked item instance id.

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries full disclosure burden. It indicates mutation via 'update' but does not state whether this is destructive, requires specific permissions, or what happens to unspecified fields (e.g., are they cleared or left unchanged?). The description lacks sufficient behavioral context for safe invocation.

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 sentence that efficiently conveys the primary purpose and scope. It is front-loaded with the verb and resource, though it could benefit from structuring bullet points for clarity when listing fields.

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 6 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the return value, error behavior, or that media_type and instance_id are identifiers. Given the large set of sibling tools, more context (e.g., 'use this to update multiple fields at once') would improve 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 description coverage is only 33%, so the description should compensate. It lists updatable fields (status, score, progress, notes) but adds no semantic detail beyond their names. The schema already provides constraints and enums, so the description adds minimal value for parameter understanding.

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 verb 'update' and the resource 'tracked media item', listing specific updatable fields (status, score, progress, notes). This distinguishes it from sibling tools like 'create_entry' (create), 'delete_entry' (delete), and the more specific 'update_progress' and 'update_score'.

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 on when to use this tool vs alternatives. The listing of fields implies it is for updating multiple aspects at once, but it does not direct agents to use 'update_progress' or 'update_score' when only one field needs changing. This leaves usage context partially 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.

update_progressA

Increase or decrease progress on a tracked item.

ParametersJSON Schema

Name	Required	Description
`operation`	Yes	increase or decrease.
`media_type`	Yes	Type of media.
`instance_id`	Yes	Tracked item instance id.

TDQS

A3.6/5.0

Behavior3/5

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

No annotations exist, so the description carries full burden. It discloses the mutation (increase/decrease progress) but lacks details on side effects, idempotency, or constraints like maximum progress. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the action. However, it could be slightly more structured without losing brevity.

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 mutation tool with 3 parameters and no output schema, the description is adequate but lacks details on return behavior or error conditions. It is minimally sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond what the schema already provides for parameters; it merely restates the purpose.

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 (increase or decrease) and the resource (progress on a tracked item). It distinguishes itself from sibling tools like update_entry and update_score by focusing specifically on progress changes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for adjusting progress, but provides no explicit guidance on when to use this tool versus alternatives like update_entry or create_episode. No exclusion criteria or context is given.

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

update_scoreA

Update the score (0-10) of a tracked item.

ParametersJSON Schema

Name	Required	Description
`score`	Yes	Score from 0 to 10.
`media_type`	Yes	Type of media.
`instance_id`	Yes	Tracked item instance id.

TDQS

A3.5/5.0

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. It only repeats the score range already in the schema, with no mention of idempotency, side effects, or permissions.

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, clear sentence with no unnecessary words. Every part is essential.

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 update tool with no output schema and no annotations, the description is adequate but lacks prerequisites (e.g., the item must exist).

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 100%, so the baseline is 3. The description adds no extra meaning beyond the schema for any parameter.

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 ('Update') and the resource ('score of a tracked item') with the range 0-10, distinguishing it from siblings like update_entry.

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 when-to-use or when-not-to-use guidance is provided. The context implies it's for changing a score, but alternatives like update_entry are not discussed.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

15 tool updatesv0.1.0Jul 15, 2026
- First observedcreate_entry
- First observedcreate_episode
- First observeddelete_entry
- First observedget_details
- First observedget_history
- First observedget_home
- First observedget_me
- First observedget_statistics
- First observedlist_tracked_media
- First observedmanual_create
- First observedsearch_media
- First observedsync_metadata
- First observedupdate_entry
- First observedupdate_progress
- First observedupdate_score

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-07-15 06:00 across 15 tools

Disambiguation4/5

Most tools have distinct purposes, but update_entry overlaps with update_progress and update_score, which could cause confusion. However, descriptions likely clarify the differences.

Naming Consistency4/5

Tool names mostly follow a verb_noun snake_case pattern (e.g., create_entry, search_media), but 'get_me' deviates slightly and 'manual_create' is adjective_verb. Overall consistent.

Tool Count4/5

15 tools is on the higher end of well-scoped but still reasonable for a media tracking service. Some tools like update_progress and update_score could be merged into update_entry.

Completeness4/5

Covers core CRUD operations, search, metadata sync, history, statistics, and user info. Missing detailed episode retrieval and discovery features, but core workflow is complete.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Achriom AOAuth
com.achriom.mcp
The media memory layer for AI agents and their humans. Your AI client gets 29 tools to search your collection, add items, update ratings, preview music, and find patterns across everything you've read, watched, and listened to.
Knowledge & Memory Entertainment & Media Search
2
mcp-server AOAuth
com.httpstatus
AI-callable tools for API mocking, testing, monitoring, security, and automation.
API Testing Testing & QA Tools App Automation
92
Sugra API A
ai.sugra
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
Search Open Data Data Platforms
1122
Orbit A
ai.buildwithorbit
Turn any task into the right API calls: discover, evaluate, and integrate public APIs.
Developer Tools API Testing
21

Related MCP Servers

Yandex Tracker MCP Server
Project Management Workplace & Productivity
DChuhin
F
license
A
quality
D
maintenance
Exposes Yandex Tracker's REST API v3 as tools for LLM clients, enabling issue management and queue operations via natural language.
Updated 5 months ago (2026-04-05 18:53 UTC)
21
-
KappaML MCP Serverofficial
AI & Machine Learning Developer Tools Autonomous Agents
KappaML
F
license
Not graded
quality
D
maintenance
Exposes the KappaML API as tools for AI assistants, enabling user management, model operations, predictions, learning, forecasting, metrics, and checkpoint management.
Updated 7 months ago (2026-02-16 22:10 UTC)
1
-
Dynamic Jira Software Cloud
Project Management Developer Tools
ndigrazia
F
license
Not graded
quality
C
maintenance
Dynamically exposes over 100 Jira Software Cloud REST API operations as fully typed tools for LLMs to interact with, supporting SSE and Stdio transports.
Updated 19 days ago (2026-08-28 18:09 UTC)
-
TODO MCP Server
Project Management App Automation
shemix-netizen
F
license
Not graded
quality
D
maintenance
Exposes tools to create and list tasks by wrapping a REST API, enabling LLMs to manage a TODO list via natural language.
Updated 3 months ago (2026-06-25 22:47 UTC)
-

yamtrack-mcp

Requirements

Install

1. Global install from release tarball (recommended)

2. GitHub Packages (scoped registry — requires a token)

Build from source

Run

Authentication

HTTP transport

Tools

Client configuration

Claude Desktop (claude_desktop_config.json)

OpenCode (opencode.json)

VS Code (.vscode/mcp.json) / Hermes (~/.hermes/config.yaml)

HTTP transport (any client that supports url + headers)

Development

Resilience

Project structure

FAQ

npm install -g github:URD0TH/yamtrack-mcp does not work

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

KappaML MCP Serverofficial

Claude Desktop (`claude_desktop_config.json`)

OpenCode (`opencode.json`)

VS Code (`.vscode/mcp.json`) / Hermes (`~/.hermes/config.yaml`)

HTTP transport (any client that supports `url` + `headers`)

`npm install -g github:URD0TH/yamtrack-mcp` does not work