Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

fever_feed

List a city's curated Fever feed rows and available pill filters to discover editorial plan categories, including category IDs that filter lists omit.

Instructions

List one city's curated Fever feed rows and the feed's pill filter enum. Returns one city's curated Fever (feverup.com) feed: every row with its title, subtype, layout and Fever category id, plus the feed's complete pill enum (creative, culture, wellness, tourist, social, luxe, romantic, detective, nightlife, foodie, adventurer, family). This is a discovery surface, not coverage: the rows are editorial carousels, and each row's items are reached through fever-plans with the row's whatplanfilter_id. It exists because fever-filters is incomplete: Fever runs two disjoint category id spaces, and today's NYC feed exposes nine category ids the filter list never lists (558, 566, 655, 851, 865, 871, 1033, 1070, 1109 on 2026-11-08, drifting by city and day), most of which fever-plans accepts as whatplanfilter_id. pill_id filters the rows and is validated against the pills array in the same response, because the enum is only learnable from the response itself; an unknown pill is a typed invalid-params error listing the accepted ids. A served city is identified by a non-empty pills array, so an unserved city_code is a typed invalid-params error naming the code rather than an empty success. Carousel items are deliberately not exposed: the whatplanfilter item route answers 404 upstream for every variant.

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": {
      "city_code": "<city_code>"
    },
    "name": "fever_feed"
  }
}

Input Schema

NameRequiredDescriptionDefault
pill_idNoFeed pill id to filter the rows, e.g. foodie; the accepted set is the pills array this endpoint returns
city_codeYesFever city code, e.g. NYC

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.8/5.0
Behavior5/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 so: it discloses that an unknown pill is a typed invalid-params error listing accepted ids, that an unserved city_code is a typed invalid-params error naming the code rather than an empty success, and that served status is signaled by a non-empty pills array. It also warns that category ids drift by city and day, which is critical operational context.

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, then progressively harder-won detail. It is on the long side and the paragraph-length enumeration of nine category ids with a date is borderline expendable, though it substantiates the fever-filters gap claim.

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, yet the description specifies the return shape (rows with title, subtype, layout and Fever category id, plus the complete pills enum) and the error behaviors. For a two-parameter discovery surface, an agent has everything needed to call it and interpret the response.

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 baseline is 3, but the description adds real meaning: pill_id is validated against the pills array returned in the same response (making the enum self-learning), and city_code validity is determined by a non-empty pills array. It does not add format or syntax details beyond the schema's own examples, keeping this just short of 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?

Opens with a specific verb and resource: 'List one city's curated Fever feed rows and the feed's pill filter enum.' It immediately establishes scope (single city, editorial carousels) and distinguishes itself from fever_filters and fever_plans by explaining that rows are traversed via fever-plans using whatplanfilter_id.

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 states when to use it and why it exists: fever-filters is incomplete because Fever runs two disjoint category id spaces, and fever-plans consumes the whatplanfilter_id values this endpoint surfaces. It also says what the tool deliberately does not do (carousel items, 404 upstream), which routes the agent away from a dead end.

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