Skip to main content
Glama
wiktorekdev

nuvio-mcp

by wiktorekdev

Unlink a tracker

nuvio_unlink_tracker
Destructive

Unlink a tracker from a profile by removing stored tokens. The previous state is snapshotted for undo support.

Instructions

Remove stored tokens for a tracker on a profile. The previous state is snapshotted before the write; revert with nuvio_undo.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNoRequired for reversible destructive changes. Without it a preview is returned.
trackerYesTracker: mal | anilist | kitsu
profile_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true; the description goes beyond by specifying what is destroyed (stored tokens) and disclosing the safety mechanism — the previous state is snapshotted before the write and can be reverted via nuvio_undo. This adds decision-relevant context about reversibility that annotations do not carry.

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 tight sentences: the first states the core action, the second discloses the snapshot/undo safety behavior. No redundant phrasing or schema repetition; essential information is front-loaded.

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 destructive 3-param tool with no output schema, the description plus annotations cover what is removed, that it is destructive, that a preview is returned without confirm (via schema), and how to revert. The only gap is the undocumented profile_id parameter and no mention of what the preview/response looks like.

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 67% — confirm and tracker are described in the schema, so the description need not repeat them. However, the description adds no parameter-specific guidance and does not compensate for profile_id's missing schema description; 'on a profile' only weakly hints at profile_id's role. Baseline 3 is appropriate.

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?

States a specific action — 'Remove stored tokens for a tracker on a profile' — with a precise verb, resource (stored tokens), and scope (profile). This differentiates it from siblings like nuvio_link_tracker (the reverse operation) and nuvio_set_tracker_settings (configuration, not credentials).

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 makes the intent clear: remove stored tracker credentials from a profile, implying when to reach for it (when unlinking a tracker relation). It does not explicitly name the counterpart nuvio_link_tracker or state when not to use it, so clear context without explicit exclusions keeps it at a 4.

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

Deploy Server

Other Tools