Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

partiful_city_facets

Retrieve one Partiful region facet with featured events, date and category facets, and linked regions; validates the slug and rejects unsupported or mismatched values.

Instructions

Get one facet of one Partiful region. Returns one facet of one Partiful (partiful.com) region: the requested slug, the facet value Partiful reports for it, its label, the month and date-range labels, the facet's featured events, the date and category facets Partiful offers alongside it, and the other regions it links. Each event carries its id, title, start and end time, timezone, status, cover image, canonical URL and venue name plus approximate city and neighborhood. The slug is validated locally against the complete fifteen-value set (events, today, tomorrow, this-week, this-weekend, thanksgiving, fall, popups, food, free-events, live-music, parties, run-clubs, trivia, lgbtq) because Partiful answers an unknown slug with a 200 that silently degrades to its unfiltered ANYTIME view; the response's facet value must match the slug, or the call fails as an upstream error rather than returning the wrong list. A slug Partiful does not serve for that region is reported as a 400 naming both values. Facet availability is per-region and seasonal, which is why the response carries the arrays rather than a fixed per-region promise. Private-party data is never returned.

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>",
      "facet": "<facet>"
    },
    "name": "partiful_city_facets"
  }
}

Input Schema

Name	Required	Description	Default
`facet`	Yes	Facet slug; validated locally against the complete fifteen-value set
`region`	Yes	Region code from partiful-explore-cities

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

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 local slug validation against the fifteen-value set, explains the upstream 200-with-silent-degradation behavior that motivates it, specifies that a facet/slug mismatch fails as an upstream error instead of returning a wrong list, and notes that unsupported slugs surface as a 400 naming both values. It further flags per-region seasonal facet availability and that private-party data is never returned — none of which is derivable from the schema.

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 operation and return shape, then the failure semantics — a sensible order for an agent scanning the definition. It is dense but mostly earned, since the long field inventory substitutes for a missing output schema; the one flaw is mild repetition in "Returns one facet of one Partiful (partiful.com) region" restating the opening clause.

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 enumerating the returned fields (including per-event id, title, times, timezone, status, cover, URL, venue and approximate city/neighborhood) and the conditional arrays for sibling facets and linked regions. Combined with the error semantics and the private-data exclusion, an agent has everything needed to call this correctly against a two-parameter tool.

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% and both parameters are enum-constrained, so the baseline is already satisfied; the description still adds value by naming the complete fifteen-slug set the facet enum draws from and by tying the region code to partiful-explore-cities as its origin. It adds rationale (why slugs are validated) rather than restating the enum, though it offers no additional naming detail beyond the schema.

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 ("Get one facet of one Partiful region") and immediately delimits scope to a single facet of a single region, which is enough to separate it from a city-wide feed or event lookup. The concrete enumeration of what a facet comprises (slug, facet value, labels, featured events, sibling facets, linked regions) makes the operation unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied rather than stated: the description shows the response shape so an agent can infer when a facet lookup fits, and it points at partiful-explore-cities as the source of region codes. However, it never says when to prefer this over partiful_city_feed or partiful_event, nor any when-not condition — the reader must infer the alternative from the return contents alone.

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

Deploy Server