TranscriptFetch

Create a monitor

create_monitor

Watch a YouTube channel or a TikTok or Instagram profile for new videos. The monitor checks on a schedule, every interval_minutes, and the new videos each check finds are read with get_new_videos (and posted to webhook_url when one is set). A monitor costs credits for as long as it exists: creating it reads the channel once for 1 credit, and every scheduled check costs 1 credit whether or not it finds anything (over a 30-day month, daily checks come to about 30 credits and hourly checks to about 720). With transcripts: true, each new video's caption transcript costs 1 credit more, and AI Fallback Transcription of one without captions 1 credit per started 5 minutes of audio. Limits: 5 monitors checked at most daily on the free plan; 100 monitors checked as often as every 15 minutes on any paid plan. Tell the user what it will cost and get their go-ahead before calling this. Channels and profiles only: a playlist or a search cannot be watched.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "channel": "<channel>"
    },
    "name": "create_monitor"
  }
}

Input Schema

Name	Required	Description
`tab`	No	YouTube only. videos (default), shorts (a creator who posts only Shorts), or live. Fixed once created.
`name`	No	A name for the monitor.
`channel`	Yes	What to watch: a YouTube channel (@handle, UC… id or URL), or a TikTok or Instagram profile URL.
`platform`	No	Optional: read from channel. When sent, it must match.
`transcripts`	No	Also fetch each new video's transcript (default false). Costs 1 credit per caption transcript; AI transcription when there are none is billed by length.
`webhook_url`	No	Optional https URL that receives each find as a signed POST. When set, the answer carries the signing secret, shown only this once.
`interval_minutes`	No	Minutes between checks. Defaults to daily on the free plan, hourly on a paid plan. Each check costs 1 credit.

Output Schema

Name	Required	Description
`balance`	No	Remaining credit balance after this call, when known.
`monitor`	No	A monitor. The webhook signing secret is never shown here.
`creditsSpent`	No	Credits charged for this call (0 on failure or for admins).
`baselineCount`	No	Videos already on the channel, recorded as seen: only later ones are reported.
`creditsNotice`	No	Credits words for the user, with the link that acts on them: why the call was refused for credits, or a note once the balance runs low. Pass it on to the user.
`webhookSecret`	No	The webhook signing secret. Present only with webhook_url, and only in this answer.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well past the annotations by disclosing the ongoing credit model (1 credit to create, 1 per scheduled check regardless of findings, monthly projections), per-transcript pricing including AI fallback billed per 5 minutes, and plan-based monitor limits. It also warns that webhook_url's signing secret is returned only once, which is exactly the kind of irreversible side effect an agent must know before calling.

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 purpose, then workflow, then cost, then limits — a sensible order. The parenthetical monthly cost math is slightly verbose but justified since the agent must quote cost to the user before calling.

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 7-parameter, non-idempotent, open-world creation tool with an output schema, the description covers cost, quotas, consent requirement, resource restrictions, and one-time secret handling. Return values are correctly left to the output schema.

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, but the description adds real meaning: interval_minutes drives recurring cost, transcripts adds per-video charges, and tab is fixed once created. channel's accepted forms are covered by the schema; webhook_url behavior is the main value-add.

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?

Opens with a specific verb and resource: watch a YouTube channel or TikTok/Instagram profile for new videos. It also bounds the resource type explicitly ("Channels and profiles only: a playlist or a search cannot be watched"), which separates it cleanly from search_channels and list_channel_playlists.

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?

States the workflow it belongs to (scheduled checks feed get_new_videos and webhook_url), the prerequisite that the user must be told the cost and consent first, and an explicit exclusion for playlists/searches. An agent knows both when to call it and when not to.

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

All TranscriptFetch tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.