Skip to main content
Glama

Get new videos from monitors

get_new_videos
Read-onlyIdempotent

Read the new videos the account's monitors have found, newest first: titles, links and publish times, with their transcripts for monitors that deliver them. Leave monitor_id out for every monitor. To ask again later, pass this answer's lastEventId as since and only videos found after it come back. Monitors find videos when they check, on their own schedule (check_monitor_now checks at once). Found videos are kept for 30 days. Free.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_new_videos"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoChecks to read, newest first (1-50, default 10). One check can report several videos.
sinceNoAn event id (mev_…): the last_event_id of an earlier answer. Only what was found after it counts as new.
cursorNonextCursor from the previous answer, for older finds.
monitor_idNoThe monitor's id (mon_…), from list_monitors or create_monitor. Leave out for every monitor.
timestampsNoInclude each transcript's timestamped segments (default false: the text only, which is smaller).

Output Schema

NameRequiredDescriptionDefault
countNoVideos returned.
videosNoThe videos found, newest event first.
monitorsNoMonitors covered.
nextCursorNoPass as cursor for older finds; null when there are none.
lastEventIdNoPass as since next time to see only later finds.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: freshness is asynchronous ('monitors find videos when they check, on their own schedule'), found videos expire after 30 days, and the call is free. Those are exactly the operational facts an agent cannot infer from the schema.

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?

Front-loaded with what comes back, followed by scoping, polling, and cost caveats — every sentence carries information. The mid-paragraph sentence about passing lastEventId is a touch dense, but nothing is filler.

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

Completeness5/5

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

For a 5-param read tool with a full schema and an output schema, this covers the remaining unknowns: staleness, retention window, cost, and pagination. An agent could call it and correctly re-poll it without further documentation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description still adds cross-field meaning the schema cannot: it links the response's lastEventId to the 'since' parameter and states the default scope when monitor_id is omitted, turning two isolated params into a polling contract.

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?

Specific verb+resource ('Read the new videos the account's monitors have found') plus the exact payload returned (titles, links, publish times, transcripts). It is clearly distinct from list_channel_videos, search_videos, and get_transcript, which cover other discovery paths and raw transcript retrieval.

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

Usage Guidelines5/5

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

Gives explicit operating instructions: omit monitor_id to cover every monitor, feed lastEventId back as 'since' to poll for subsequent finds, and use check_monitor_now when you want an immediate check instead of waiting for the monitor's own schedule. That is when-to-use, how-to-repeat, and the named alternative in one place.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.