Search YouTube by keyword (yt-dlp, no login). Returns up to limit hits: url/title/uploader/durationSec/uploadDate(often null)/thumbnail/views. YouTube only — use framefetch_extract on a hit's url for transcript/frames/etc. Billed ~$0.002/call (metadata-tier), regardless of limit.
| Name | Required | Description | Default |
|---|---|---|---|
| cache | No | false = fresh, billed search. | |
| limit | No | Default 10. | |
| query | Yes | 2-200 chars. | |
| platform | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only signal readOnlyHint and openWorldHint. The description goes further by disclosing 'yt-dlp, no login', billing cost '~$0.002/call', result field list, and the caveat that uploadDate is often null. It does not contradict annotations and adds meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, front-loaded with the primary purpose, then implementation details, billing, and a pointer to the next step. No fluff; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, what it returns, cost, login requirements, and the alternative tool. It lacks an explicit note about error cases or empty results, but it is complete enough for a simple search tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the description adds meaning by clarifying that `limit` controls the number of returned hits, listing the fields returned, and restricting platform to YouTube. It does not repeat schema text and gives context for `limit` and platform beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair: 'Search YouTube by keyword'. It clearly identifies what the tool does and differentiates from the sibling 'framefetch_extract' by stating 'use framefetch_extract on a hit's url for transcript/frames/etc.' It also pins scope with 'YouTube only'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context: 'Search YouTube by keyword' and an explicit alternative: 'use framefetch_extract on a hit's url...'. It also gives an exclusion: 'YouTube only'. This is strong guidance for tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool maps to a clearly distinct function: balance checking, single-URL extraction, platform capability lookup, and YouTube search. The descriptions explicitly separate them, especially framing framefetch_account as read-only and framefetch_extract as the only paid operation. There is no real risk of selecting the wrong tool for a task.
All tools share the framefetch_ prefix and use consistent lowercase snake_case, giving the set a coherent namespace. However, the suffixes mix nouns like account and platform_capabilities with verbs like extract and search, so the naming is not as uniform as a strict verb_noun convention.
Four tools is well-scoped for a social-video extraction API: account, capabilities, search, and extraction each earn their place without overlap. The set is neither too thin nor bloated for its apparent purpose.
The tool surface covers the core workflow: check platform support, search for a video, extract desired data, and monitor account balance. There are no obvious dead ends or missing operations for the stated video-extraction domain.