Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

netshort_genres

Lists NetShort's label taxonomy across four tabs, returning each label's ID, name, path and play count so callers can look up label IDs instead of guessing them.

Instructions

List NetShort's label taxonomy. Returns NetShort's (netshort.com) label taxonomy as the site's own plot index carries it: four navigation tabs (all-plots, story, characters, settings) and every label value underneath them, each with its labelId, labelName, site path and play count. This is the discovery endpoint for netshort-label, so a caller never has to guess a label id. The capture held 196 labels over the four tabs (146 distinct ids), and three tabs end at exactly 50: that is the upstream's own per-tab cap, not a truncation here, so capped reports it and the list must not be described as provably exhaustive. Labels here are the type-2 id space; the labels attached to a card are a different, type-1 vocabulary.

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

Input Schema

NameRequiredDescriptionDefault
languageNoLocale, defaults to en

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 at all, the description carries the full burden and does substantial work: it discloses the capture size (196 labels, 146 distinct ids), the upstream per-tab cap of 50, and that a `capped` flag surfaces this rather than silent truncation. It does not cover auth requirements, rate limits, or error behavior, and the mention of "capped reports it" is only implicit about the response field.

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 purpose in the first clause, then the return shape, then the caveats. Most sentences earn their place, though the 196/146/50 numeric detail is dense and could be tightened; nothing is redundant with the schema.

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?

No output schema exists, and the description compensates by naming the returned fields (labelId, labelName, path, play count) and the cap signal. For a one-optional-parameter discovery tool, the id-space distinction and exhaustiveness caveat close the gaps an agent would otherwise hit.

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?

The single `language` parameter has 100% schema description coverage including an enum and a stated default of en, so the schema already does the work. The description never mentions locale selection or how language affects label names, adding no meaning beyond the schema — 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 and resource ("List NetShort's label taxonomy") and immediately enumerates the returned shape: four navigation tabs plus every label value with labelId, labelName, path and play count. It also distinguishes this vocabulary from the one used on cards ("type-2 id space" vs "type-1 vocabulary"), so an agent can tell it apart from netshort_label 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 Guidelines5/5

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

Explicitly frames the tool as "the discovery endpoint for netshort-label, so a caller never has to guess a label id," which names the downstream alternative and the condition that selects it. It also warns that three tabs cap at 50 by upstream design, telling the caller not to treat the result as exhaustive — a real usage constraint rather than boilerplate.

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