Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

flickreels_shelf

List one page of a curated FlickReels shelf by shelf ID, returning its title, total count, and twelve titles with playlet IDs, slugs, covers, episode counts, tags, and URLs; page until empty.

Instructions

List one page of a FlickReels curated shelf. Returns one page of a curated FlickReels (flickreels.net) shelf: the shelf's title and the site's own total, plus twelve titles with each one's playlet id, movie slug, title, cover, episode count, tags and canonical URL. Take shelf_id from a flickreels-home shelf; the slug is optional because the upstream ignores that path segment. A shelf can hold far more rows than the home page renders, so page through with the page parameter and stop when a page returns an empty list, which the upstream answers as a valid 200 rather than a 404.

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": {
      "shelf_id": "<shelf_id>"
    },
    "name": "flickreels_shelf"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNo1-based page, twelve rows per page, defaults to 1
slugNoShelf slug from the same shelf; the upstream ignores its value
languageNoLocale code, defaults to en
shelf_idYesShelf id from a flickreels-home shelf

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.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 safety/behavior burden and does well: it discloses the exact return payload, the twelve-rows-per-page window, that the upstream ignores the slug segment, and notably that an exhausted page returns a valid 200 with an empty list rather than a 404. Auth requirements and rate limits are unstated, which keeps it from 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.

Conciseness4/5

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

Front-loaded with purpose and return shape, then prerequisites, then paging strategy — a sensible order with no filler sentences. It is dense and somewhat long, and the return-shape enumeration could be tightened, but every clause carries information.

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?

There is no output schema and no annotations, so the description must define the response, which it does field by field, plus pagination and the empty-list termination signal. For a four-parameter paged-list tool, an agent has everything needed to call and loop it correctly.

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 baseline is 3, but the description adds meaning the schema does not: the page size (twelve rows), the 1-based paging loop and its termination condition, and the provenance of shelf_id. It repeats the schema's note that slug is ignored rather than extending it, so the gain is real but modest.

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 ('List one page of a FlickReels curated shelf') and immediately enumerates the returned shape (shelf title, site total, twelve titles with playlet id, slug, cover, episode count, tags, canonical URL). The sentence about taking shelf_id from a flickreels-home shelf separates it from the sibling that produces shelf ids, so an agent can route correctly without opening either 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?

Gives a real prerequisite chain ('Take shelf_id from a flickreels-home shelf') and an explicit iteration strategy ('page through with the page parameter and stop when a page returns an empty list'). It stops short of naming when not to use it (e.g., versus flickreels_movie for a single title), so it is clear context rather than full alternative routing.

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

Deploy Server

Other Tools