Skip to main content
Glama
Sign In

Crawlora MCP

by net.crawlora
OverviewDiscussionsAdmin

dramabox_search

Read-only

Search DramaBox's catalog through the app API: pass a keyword (required, truncated to 80 characters like the app), optional page, limit and sort mode (1, 2 or 3), and get matching titles (id, title, description, cover, link, episode count, tags with tag ids, library flag, listing times) plus matching people (actor/actress id, name, avatar, series count) that dramabox_performer can look up. The app API answers mixed title and people rows. Only public catalog metadata is returned, never playable video.

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

Input Schema

NameRequiredDescriptionDefault
pageNoOne-based result page
sortNoUpstream result ordering mode; omit for the app default. Documented values: 1, 2, 3.
limitNoResults per page
keywordYesSearch text, trimmed and truncated to 80 characters

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly and openWorld, so safety is covered; the description still adds real context beyond them: keyword is truncated to 80 chars like the app, results are mixed title and people rows, and only public catalog metadata is returned (never playable video). These are useful behavioral traits not in the structured fields.

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?

Front-loaded with the core action and the required/optional parameter split, with no filler. It is somewhat dense and enumerates return fields even though an output schema exists, which is slightly wasteful but not confusing.

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 4-parameter search tool with a 100%-covered schema, full annotations, and an output schema, nothing an agent needs to call it correctly is missing: entry point, required input, truncation rule, mixed-result nature, and data-boundary caveat are all present.

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 100%, so the schema already documents all four parameters and the sort values 1/2/3. The description reinforces the keyword truncation behavior and sort values but adds little syntax or format detail beyond what the schema provides, so baseline 3 applies.

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?

States a specific verb (Search) and resource (DramaBox's catalog via the app API), and spells out both what goes in (keyword, page, limit, sort) and what comes back (titles and people). An agent can distinguish this from dramabox_browse/suggest/performer without opening a schema.

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?

The keyword-driven nature makes the use case clear, and it routes the people portion explicitly to dramabox_performer ('that dramabox_performer can look up'). It does not, however, contrast itself with sibling discovery tools like dramabox_suggest or dramabox_browse, so there is no explicit when-not.

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

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