Hook Detector

make_thumbnails

Make 2 to 12 thumbnails (default 4): 3 different concepts first, then images (Nano Banana 2.1, 1K or 4K), every printed word read back and checked letter by letter, a face only from your photos or your channel's own thumbnails. Answers at once with call_id and status pending; read it with get_thumbnails until done. 4 credits a delivered 1K image, 12 a 4K one, charged only for what is delivered. Same as POST /v1/thumbnails.

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": {
      "title": "<title>"
    },
    "name": "make_thumbnails"
  }
}

Input Schema

Name	Required	Description
`mode`	No
`size`	No
`count`	No
`faces`	No
`title`	Yes
`topic`	No
`words`	No
`run_id`	No
`sketch`	No
`api_key`	No
`channel`	No
`concept`	No
`reference`	No
`background`	No
`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

A3.7/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 a lot: asynchronous create returning a call_id, credit pricing (4 per delivered 1K, 12 per 4K, charged only on delivery), and content rules (three concepts first, faces only from supplied photos or the channel's own thumbnails, text read back letter by letter). Auth requirements and rate limits are unstated, keeping it short of a 5.

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 core action is front-loaded, but the paragraph is a dense run-on mixing pricing, quality guarantees, and endpoint aliasing into one block. It spends words on promotional detail ('checked letter by letter') while leaving ten parameters unaddressed, so the sizing is misallocated rather than simply too long.

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

Completeness2/5

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

For a 15-parameter generation tool with 7% schema coverage, the description leaves most inputs unexplained, including content-shaping fields like topic, words, concept, sketch, and reference. The async return contract is covered and an output schema exists, but the input surface is largely undocumented.

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

Parameters2/5

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

Schema description coverage is only 7% across 15 parameters, so the description must compensate and largely does not. It clarifies count (2–12, default 4), size (1K/4K), faces sourcing, and hints at mode via '3 different concepts first', but title, topic, words, concept, sketch, reference, background, channel, run_id, and api_key are left completely undefined.

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 plus concrete scope ('Make 2 to 12 thumbnails (default 4)'), names the backing endpoint (POST /v1/thumbnails), and points at get_thumbnails for the read path. An agent knows exactly what this does and how it differs from the sibling that fetches results.

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?

It states the follow-up flow explicitly — the call returns call_id/status pending and 'read it with get_thumbnails until done' — which is the key routing decision. It does not, however, distinguish this from recreate_thumbnail, edit_thumbnail, or search_thumbnails, so the agent gets context but no exclusions.

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?