Hook Detector

list_finds

The index: every video your long and packaging runs found, across all runs, one entry a video on each tab (its newest read, with the keep or reject made on the video). Each is a full find object: the title and thumbnail_url as YouTube shows them, views, channel_median_views, outlier (views over the channel's usual) and outlier_score (0 to 100 on one fixed scale, so entries from different runs rank together), plus the analysis its run wrote. q (at most 120 characters) looks in the title, the channel, the hook as it was said, and what the thumbnail prints and shows, so a package can be found by its thumbnail ("red arrow", "before and after"). Returns {"finds", "count", "total" (every match, on any page), "next_cursor"}; pass next_cursor as cursor for the next page. Use it to search what you already paid for before starting a new run. Same as GET /v1/finds. Free. Errors: 422 for a kind, sort, tier, min_score, device or q that is not allowed. The bounds min_multiple to language (T3-FL) narrow the index on the server, as on GET /v1/finds; an entry that does not carry a bounded field is left out.

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": "list_finds"
  }
}

Input Schema

Name	Required	Description	Default
`q`	No	words a title, channel, hook or thumbnail must hold
`kind`	No	only "long" or only "packaging"; leave out for both
`sort`	No	"score" (default: the highest outlier score first), "outlier" (views over the channel's usual), "views" or "newest"	score
`tier`	No	only "breakout" (10 times the channel's usual or more), "strong" (5 to 10) or "outlier" (under 5)
`limit`	No	page size, 1 to 100
`cursor`	No
`device`	No	only entries filed under this device: a hook_type, a title_device or one of the thumbnail_devices
`api_key`	No
`language`	No
`max_views`	No
`min_score`	No	only entries with an outlier_score of at least this, 0 to 100
`min_views`	No
`max_comments`	No
`max_multiple`	No
`min_comments`	No
`min_multiple`	No
`max_duration_s`	No
`min_duration_s`	No
`max_channel_median`	No
`min_channel_median`	No
`posted_within_days`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedOct 26, 2026

addedInput schema / properties / language

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Language"
+}

addedInput schema / properties / max_channel_median

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Max Channel Median"
+}

addedInput schema / properties / max_comments

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Max Comments"
+}

addedInput schema / properties / max_duration_s

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Max Duration S"
+}

addedInput schema / properties / max_multiple

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Max Multiple"
+}

addedInput schema / properties / max_views

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Max Views"
+}

addedInput schema / properties / min_channel_median

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Min Channel Median"
+}

addedInput schema / properties / min_comments

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Min Comments"
+}

addedInput schema / properties / min_duration_s

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Min Duration S"
+}

addedInput schema / properties / min_multiple

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Min Multiple"
+}

addedInput schema / properties / min_views

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Min Views"
+}

addedInput schema / properties / posted_within_days

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Posted Within Days"
+}

AddedOct 7, 2026

TDQS

A4/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does it well: it declares the tool is free, enumerates 422 error cases by parameter name, discloses that bounds are applied server-side and that entries lacking a bounded field are excluded, and explains pagination via next_cursor. These are non-obvious behaviors an agent could not get 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and the content is dense, but sentences sprawl with stacked parentheticals and the phrase 'min_multiple to language (T3-FL)' is cryptic rather than helpful. Some clause-level editing would preserve the information with less drag.

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

Completeness4/5

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

For a 21-parameter paginated list tool, the description covers cost, error surface, pagination, filter semantics and the shape of results (though an output schema exists, so that is bonus). The main residual gap is per-filter meaning for the roughly two-thirds of parameters with no schema description.

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

Parameters3/5

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

Schema coverage is only 33% across 21 parameters, so the description needs to compensate. It adds real meaning for q (searchable fields, 120-char cap) and for the numeric bounds collectively (server-side narrowing, exclusion semantics), but leaves min_views, max_comments, min_duration_s, posted_within_days, language, cursor and others unexplained. Partial compensation only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a concrete framing ('the index: every video your long and packaging runs found, across all runs, one entry a video on each tab') that tells an agent exactly what resource is returned and at what grain. It is clearly a list/read of finds, distinguishable in spirit from get_find and list_kept_finds, though those siblings are never named.

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?

'Use it to search what you already paid for before starting a new run' gives an explicit trigger condition for calling this tool. It stops short of naming alternatives (search_index, list_kept_finds, get_find) or stating when not to use it, so routing between sibling read tools is still partly inferred.

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

All Hook Detector 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.

Resources

Need Help?