Hook Detector

write_ideas

Write ideas for new videos: each a title, a thumbnail concept (one visible action) and the words to print, built on one to three real outliers (based_on, each with its video_id, title, multiple, find_id and bend niche when it came from another niche). constraints are rules every idea keeps (said in fits). band (10x, 5x, 2x) is the median multiple of the finds behind the idea, never a predicted view count. label: written by Hook Detector. 1 credit, refunded when the writing fails; fewer than 5 outliers known is 422 too_few_outliers and costs nothing. Same as POST /v1/ideas; remix_find makes one find yours.

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

Input Schema

Name	Required	Description
`count`	No	3 to 12 ideas (default 6)
`topic`	No	the subject, 3 to 300 characters (the outliers come from the shared index); send this or run_id
`run_id`	No	a finished Packaging or Long form run of yours: its finds, direct and bent, are the sources
`api_key`	No
`constraints`	No	rules every idea keeps, up to 200 characters ("low budget")
`content_type`	No	for a topic: long (default) or short
`idempotency_key`	No	1 to 255 visible ASCII characters; the same key and request within 24 hours answer the saved remix and charge nothing; the same key with another request is 422 idempotency_key_reused

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 26, 2026

TDQS

B3.4/5.0

Behavior4/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 well: it discloses that calls cost 1 credit, are refunded when writing fails, and return a 422 too_few_outliers (at no cost) when fewer than 5 outliers are known. It also explains the 'band' semantics and the 'label' origin, though it does not cover authentication or broader operational limits.

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?

The description is compact and mostly relevant, but it is a dense run-on paragraph with unexplained jargon like 'said in fits' and 'bend niche'. The purpose and cost details are front-loaded, yet the lack of structure makes it harder to scan than it should be.

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 complex generation tool with an output schema, the description covers the essential behavioral context: credits, refunds, failure codes, constraints, and the meaning of key output fields. It leaves some gaps around authentication and the exact topic-versus-run_id requirement, but those are documented in the input schema.

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 description coverage is high at 86%, so the baseline is 3. The description adds some meaning for constraints ('rules every idea keeps') and implies topic/run_id sourcing via outliers, but it spends much of its text on output concepts like based_on and band rather than adding parameter-specific guidance beyond the schema.

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?

The description states a specific verb and resource: 'Write ideas for new videos', and then describes the idea shape (title, thumbnail concept, words to print) and the outlier basis. It does not explicitly distinguish itself from the sibling write_titles, and the jargon ('fits', 'bend niche') makes the purpose less immediately clear, but the core operation is identifiable.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance or comparison against alternatives such as write_titles or find_packaging. The mention that 'remix_find makes one find yours' explains a related tool but does not tell the agent when write_ideas is the right choice versus another generation tool.

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?