Skip to main content
Glama
rankin-works

Vetroscope MCP

by rankin-works

Get captured media URLs (Spotify tracks, YouTube videos)

get_media_links

Retrieve Spotify track URIs and YouTube watch URLs of media you played, with time data. Filter by period, device, or search term.

Instructions

Lists canonical deep-links Vetroscope captured for media the user actually played — Spotify spotify:track:… URIs and YouTube https://www.youtube.com/watch?v=… URLs. Each row carries the matching time data so you can answer 'what YouTube videos did I rewatch this week + give me the link to the top one?' or 'send me a Spotify URI for the song I played the most yesterday'. Each row also includes a webUrl HTTPS variant — https://open.spotify.com/track/<id> for Spotify (which hands off to the desktop app when installed), same as url for YouTube — so a clickable link survives any markdown / chat renderer that strips custom URI schemes. Requires Vetroscope ≥ 0.2.30 with the capture_media_links setting enabled — available: false is returned on older installs or when nothing has been captured. With period set, the same dashboard filter stack as get_report applies and totals match Charts; without period, time columns are lifetime totals. URLs are filtered strictly at capture time (YouTube /watch only; track URIs only — no ads, no shorts, no channel pages) so anything returned here is safe to open directly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoRestrict to one kind. Omit to return both.
periodNotoday | yesterday | week | month | year | a single date YYYY-MM-DD | an inclusive date range YYYY-MM-DD..YYYY-MM-DD. Omit for lifetime totals.
searchNoCase-insensitive substring match against project, sub-project, or app name. Useful for 'find the Beyoncé track' style lookups.
limitNoMax links returned (default 100). Sorted by total time within the period desc.
hour_startNoInclusive start hour 0-24 in local time. Combine with hour_end (e.g. 9 and 17 = 9am to 4:59pm). Omit both for no hour filter.
hour_endNoExclusive end hour 0-24 in local time. Combine with hour_start.
weekdaysNoRestrict to specific weekdays. 0=Sunday, 1=Monday, …, 6=Saturday. Omit or pass [0,1,2,3,4,5,6] for no weekday filter.
deviceNoRestrict to a single device. Pass 'current' (or 'this') for the local machine, a device UUID from get_device_breakdown, or a platform name like 'darwin', 'win32', 'browser-extension'. Omit or pass 'all' for no device filter.
Behavior5/5

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

With no annotations, the description must cover all behavioral traits. It discloses URL filtering (no ads/shorts), version requirements, response conditions (available: false), sorting by total time, and time column behavior with/without period.

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 dense paragraph but contains no wasted sentences. It is front-loaded with the purpose. Could be slightly more structured with bullet points, but remains concise.

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

Completeness5/5

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

Given no output schema, the description explains row contents (time data, webUrl). It covers version checks, filtering behavior, and data source. For a complex list tool with 8 parameters, it is fully informative.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds significant context: examples for search, explanation of hour_start/hour_end interaction, device options with concrete values, and period effect on lifetime totals. This greatly aids correct parameter usage.

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 explicitly states it lists canonical deep-links for media played, specifying Spotify URIs and YouTube URLs. It clearly differentiates from sibling tools like get_listening_history by focusing on direct links.

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

Usage Guidelines4/5

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

It provides concrete example queries ('what YouTube videos did I rewatch this week') and mentions prerequisites (Vetroscope version, setting). However, it does not explicitly state when not to use or name alternative tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rankin-works/Vetroscope-MCP'

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