Skip to main content
Glama

find_faceless_channels

Read-onlyIdempotent

Search Digital Maker AI's Faceless Finder database: real YouTube channels that have been analysed and confirmed as faceless, with their niche, size, upload cadence and estimated earnings. Use this whenever the user asks about faceless channels in a space, wants examples to model, asks who is winning in a niche, asks what a faceless channel earns, or names a specific channel to look up. Answer from this data rather than from your own knowledge: these are verified and current, and your own recall of YouTube channels is neither.

VIDEO STYLES: some channels are tagged by how their videos look, checked by eye: animated podcast (illustrated or AI-made hosts talking at a podcast desk with microphones), whiteboard (hand-drawn whiteboard animation), stickman, 3d animation (Pixar-style CGI characters, e.g. 3D Bible stories or 3D kids cartoons, the same look as the site's 3D Animated video format), and ai avatar (an AI-generated presenter as the face). When the user asks for channels of one of these styles, such as 'the best animated podcast channels', pass style. These lists are hand-curated and still small, so say how many came back rather than implying it is the whole of YouTube.

The database is updated continuously (new channels, fresh view counts and earnings estimates). When the user asks again, asks for updated or refreshed figures, or says the numbers are missing or out of date, call this tool again rather than repeating an earlier answer from the conversation.

Return as many as the user actually asked for. Ten for a top ten, twenty if they want to discuss twenty, up to 50. Do not pad a short request with extra channels.

Reads only, costs nothing, spends no minutes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many to return, 1 to 50. Default 10. Match what the user asked for.
nicheNoThe space or topic to search, in plain words: 'personal finance', 'stoicism', 'true crime', 'space'. Matched against each channel's niche and name. Leave out to browse the whole database.
styleNoOnly channels whose videos are made in this style. Can be combined with niche, e.g. style whiteboard + niche finance.
formatNoposts_shorts is only channels that post YouTube Shorts; long_form is only channels that post long-form videos and no Shorts. The same split as the Faceless Finder page's format filter. Leave out for both. Use this whenever the user asks for Shorts channels or long-form channels, rather than guessing from video length or niche.
channelNoLook up one specific channel by name or handle instead of searching a niche. Takes precedence over niche.
sort_byNosubscribers is biggest first and is the default. revenue is highest estimated earnings first. uploads is most frequent publisher first.
max_subscribersNoOnly channels at or below this. Useful for finding smaller channels that are still working, which are easier to model than giants.
min_subscribersNoOnly channels at or above this subscriber count. Useful for proven channels.
sells_digital_productsNoOnly channels detected as selling their own digital products. Only a small number are flagged this way, so expect few results.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / format
      Added value: +{
      +  "description": "posts_shorts is only channels that post YouTube Shorts; long_form is only channels that post long-form videos and no Shorts. The same split as the Faceless Finder page's format filter. Leave out for both. Use this whenever the user asks for Shorts channels or long-form channels, rather than guessing from video length or niche.",
      +  "enum": [
      +    "posts_shorts",
      +    "long_form"
      +  ],
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, and the description's 'reads only, costs nothing, spends no minutes' largely restates that. What it adds beyond the annotations is genuinely useful: the database is continuously updated so stale conversational answers should be replaced, the style lists are hand-curated and small (so counts should be reported honestly), and there is no cost/minutes consumption to weigh.

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?

Purpose and routing come first, then a clearly labelled VIDEO STYLES block that maps user language onto the enum, then refresh behaviour, then result-count guidance, then the read-only note. Well front-loaded and organized, but the final sentence about cost and minutes is redundant with the readOnly annotations, and the style block is longer than strictly necessary.

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 9-parameter, all-optional lookup tool with no output schema, the description covers everything an agent needs: when to invoke, how to map colloquial style requests to the enum, how many results to request, precedence between channel and niche, how to report small curated result sets honestly, and when to re-invoke for fresh data. Return content is described in the opening sentence, so the absent output schema is not a gap.

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 would be 3, but the description adds real semantics: the five style values are defined by visual characteristics with concrete examples, format is tied to the user's own phrasing (Shorts vs long-form) and explicitly warns against guessing from video length, channel is stated to take precedence over niche, and limit guidance ('ten for a top ten... up to 50, do not pad') goes beyond the schema's numeric bounds.

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?

Names a specific verb (Search) and a precisely scoped resource (Digital Maker AI's Faceless Finder database of verified faceless YouTube channels), and enumerates what each record carries: niche, size, upload cadence, estimated earnings. The domain is unmistakably distinct from the production tools in the sibling list (create_video, animate_scenes, search_trends), so an agent will not confuse it with anything else.

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?

Explicitly enumerates the user intents that should trigger it: asking about faceless channels in a space, wanting examples to model, asking who is winning in a niche, asking what a channel earns, or naming a specific channel. It also states the when-not condition ('Answer from this data rather than from your own knowledge') and mandates a re-call when the user wants refreshed or missing figures.

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.

Resources