Crawlora MCP

webtoon_search

Read-only

Search WEBTOON's public catalogue by keyword and return the matching series grouped into the site's own ORIGINALS and CANVAS sections, with each card's title_no, title, authors, genre path segment, absolute URL, thumbnail, WEBTOON's own view counter, UP badge, adult flag and normalised webtoon_type. Use this when you have a title or creator name but no title_no yet, then pass the returned title_no to webtoon_series for episode metadata; choose webtoon_genre, webtoon_originals or webtoon_rankings instead when browsing a whole genre, release day or chart rather than matching a word. scope selects the site's own tab: the default all is a preview of at most 12 cards per section, so page numbers above 1 are rejected there, while scope=originals or scope=canvas serve up to 30 cards per page and return an empty sections list past the last page. A zero-result answer is valid, not an error; search cards carry no genre label, so genre is the hyphenated href path segment (map it through webtoon_genres for webtoon_genre) and is empty for canvas cards.

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": {
      "keyword": "<keyword>"
    },
    "name": "webtoon_search"
  }
}

Input Schema

Name	Required	Description
`page`	No	Optional 1-based results page, default 1. Only originals and canvas are pageable: each serves up to 30 cards per page, and a page past the end returns an empty result rather than an error. A page above 1 with scope=all is rejected because that combined view's own paging skips records.
`scope`	No	Optional search scope, one of: all (default, the site's combined preview), originals or canvas. Use originals or canvas to page results; the combined view previews at most 12 cards per section and cannot be paged.
`keyword`	Yes	Required keyword to search series titles and creators for. It is trimmed before use; a blank or whitespace-only keyword is rejected because WEBTOON answers that with its generic search landing page rather than results.

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say readOnlyHint and openWorldHint, so the description carries the behavioral burden and does so well: it discloses the 12-card-per-section preview cap under scope=all, that pages above 1 are rejected there, that originals/canvas serve up to 30 cards per page and return an empty sections list past the end, and that zero results are valid rather than an error. It also warns that cards carry no genre label so genre must be parsed from the hyphenated href path segment.

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?

The critical routing information (what it returns, title_no handoff, alternatives) is front-loaded in the first two sentences, and the paging caveats follow. It is a dense single paragraph, though, and the keyword/genre notes repeat schema content that could be trimmed or split into a clearer structure.

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 three-parameter search tool with an output schema and read-only annotations, the description covers scope semantics, paging limits, failure-free empty results, and the downstream handoff to webtoon_series. Nothing an agent needs to call it correctly or interpret the response is missing.

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 params are already documented; the description nonetheless ties scope to real behavior (combined preview vs paged tabs) and explains why page>1 fails under scope=all, which is meaning beyond a field-level description. The keyword trimming and blank-rejection notes largely restate the schema, keeping this below a 5.

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?

The description opens with a specific verb and resource ('Search WEBTOON's public catalogue by keyword') and immediately names the shape of the result ('series grouped into ORIGINALS and CANVAS sections'), plus the exact card fields returned. It distinguishes itself from siblings by naming webtoon_series, webtoon_genre, webtoon_originals and webtoon_rankings by name.

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?

It states the triggering condition precisely ('when you have a title or creator name but no title_no yet'), the follow-up action ('pass the returned title_no to webtoon_series'), and the exact conditions that select each alternative (browsing a whole genre, release day, or chart rather than matching a word). This is explicit when/when-not/alternatives guidance.

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

All Crawlora MCP 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.