Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

fever_plans

List and filter Fever plans for a city by category and session-date window, with pagination and sorting via Fever's public search endpoint.

Instructions

List and filter Fever plans for a city. Returns one page of Fever's (feverup.com) plan catalogue for a city, optionally filtered by category and session-date window and ordered by one of Fever's own sort values. This is the category and date browse Fever's own website refuses (its listing API is a 403), served from the public search endpoint the site and its app already use. page_size is capped at 100: the upstream silently truncates larger values to 100 rows, so anything above 100 is rejected. date_start and date_end are epoch SECONDS; date_start is required whenever a window is given, and a millisecond value is rejected because the upstream silently answers an empty window for one. Category ids come from fever-filters. Latitudes/longitudes default to the city's own centre from fever-top-cities; a city outside that list needs an explicit pair. count is the search index's own match count and is not the website's total_plans, so the two can differ materially.

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_plans"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNo1-based page number, defaults to 1
queryNoFree-text query; empty means no keyword filter
localeNoResponse language for the search index, defaults to en
date_endNoLatest session date in epoch SECONDS; only with date_start
latitudeNoLatitude of the search centre; supply with longitude. Defaults to the city's own centre
city_codeYesFever city code, e.g. NYC
longitudeNoLongitude of the search centre; supply with latitude
page_sizeNoPlans per page, defaults to 20, maximum 100
sort_typeNoResult ordering
date_startNoEarliest session date in epoch SECONDS; required when date_end is set
whatplanfilter_idNoFever category id from fever-filters, e.g. 1040

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.5/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 well: it discloses that the upstream silently truncates page_size above 100, that millisecond timestamps return a silently empty window, that the listing path normally 403s and this uses the public search endpoint, and that 'count' is the search index's match count rather than the site's total_plans. These are exactly the non-obvious behaviors an agent needs before trusting results.

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 scope, then constraints in priority order; nearly every sentence carries a distinct fact. It is a dense single block, though, and the data-provenance sentences (403, endpoint) sit mid-paragraph rather than being grouped, making it slightly harder to scan than it could be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter tool with no output schema, it covers required inputs, defaults, validation failures, and even the meaning of the returned count, which is the most important return-value caveat. It does not describe the shape of individual plan records or how to determine when pagination ends, which are the remaining gaps.

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 genuine meaning beyond the schema: the rationale for the 100-row cap, the rejection of millisecond values and why, and the fallback behavior for latitude/longitude. It does not add much for page, locale, query, or sort_type beyond what the schema already states.

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 and filter Fever plans for a city') plus scope ('one page of the catalogue'), and implicitly distinguishes itself from the single-plan sibling by emphasizing listing/browse. An agent can instantly tell this is the catalogue browse tool rather than a detail or filter-lookup tool.

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 concrete routing guidance to siblings: category ids 'come from fever-filters' and default coordinates come from 'fever-top-cities', with the condition that a city outside that list needs an explicit lat/long pair. It also states the date-window prerequisite. It stops short of explicitly naming when to prefer fever_plan or fever_feed instead, so it lacks a full alternatives comparison but the context is clear.

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