Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

partiful_city_feed

Retrieve a city's Partiful public discover feed, including trending and themed carousels, featured events, and category facets for local event discovery.

Instructions

Get one region's Partiful discover feed. Returns one Partiful (partiful.com) region's public discover feed: the region code and label, its trending carousel, every themed carousel, a flat feed of up to twenty featured events, and the category facets Partiful currently offers for that region. Each event carries its id, title, start and end time, timezone, status, cover image, canonical URL and venue name plus approximate city and neighborhood; pass an id to partiful-event for the full public event. This is a curated discovery feed, never a complete city catalogue: Partiful publishes a fixed slab and there is no page, cursor or offset parameter, so a page parameter is not accepted and coverage is only what Partiful chose to feature. Private-party data is never returned: guest lists, attendees, invite/RSVP state, ownerIds, host contacts, exact street addresses and RSVP counters are dropped, and non-public events are filtered out. Regions come from partiful-explore-cities.

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": {
      "region": "<region>"
    },
    "name": "partiful_city_feed"
  }
}

Input Schema

NameRequiredDescriptionDefault
regionYesRegion code from partiful-explore-cities

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.4/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 the coverage ceiling (fixed slab, only what Partiful features, no pagination), the privacy filtering (guest lists, attendees, RSVP state, ownerIds, host contacts, exact street addresses and RSVP counters dropped, non-public events excluded), and the per-event field set returned. These are exactly the behavioral facts an agent cannot get from structured data here.

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?

The core purpose is front-loaded in the first clause and the later sentences are substantive rather than filler. It is a long, single-paragraph block with mild redundancy ("public discover feed" and the curated-not-complete point are restated), so it is efficient but not tight.

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 and no annotations exist, so the description must supply return shape and limits itself, which it does in detail: field-by-field event contents, the drop list, the coverage constraint, and the cross-reference for full event data. Nothing an agent needs to invoke or interpret this call is missing.

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% and the enum of nine region codes is documented in the schema itself, including the "from partiful-explore-cities" provenance, so the description repeats rather than extends it. Its only added value is explaining why no page/offset parameter exists, which clarifies the single-parameter shape.

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?

"Get one region's Partiful discover feed" states a specific verb and resource, and the following sentence enumerates exactly what the payload contains (region code/label, trending carousel, themed carousels, up to twenty featured events, category facets). It is clearly distinguishable from partiful_event, which is named for the per-event drill-down.

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?

It routes the agent explicitly: regions come from partiful-explore-cities, and event ids go to partiful-event for full detail. It also states what this tool is not (a complete catalogue, no page/cursor/offset accepted). The one gap is partiful_city_facets, whose overlap with the embedded category facets is never disambiguated.

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