Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

partiful_explore_cities

Retrieve the three regions featured in Partiful's Explore hub with carousel titles, icons, and public event details while excluding private or password-protected listings.

Instructions

List the three regions Partiful's Explore hub features. Returns the top of Partiful's (partiful.com) public Explore surface: the three regions its hub features (New York City, Los Angeles, San Francisco), each with the carousel's own title, subtitle, icon and featured events. Every event carries its id, title, start and end time, timezone, status, cover image, canonical partiful.com URL, and venue name plus approximate city and neighborhood. Private-party fields are never returned: guest lists, attendee names and phone numbers, invite/RSVP state, ownerIds, host contacts, exact street addresses and aggregate RSVP counters are dropped, and events flagged isPublic false or requiring a password are filtered out. This is also the discovery endpoint for the region parameter: its region codes are the complete nine-value set (NYC, LA, SF, CHI, ATX, BOS, DC, MIA, LON). Explore is a curated discovery feed, not a city catalogue: there is no pagination anywhere on this surface.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.6/5.0
Behavior5/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 so: it enumerates every returned event field (id, title, start/end time, timezone, status, cover image, canonical URL, venue name plus approximate city/neighborhood) and explicitly lists what is dropped (guest lists, attendee names, phone numbers, RSVP state, ownerIds, exact addresses, RSVP counters). It also discloses the filtering rules — events with isPublic false or password protection are excluded — and the absence of pagination, which is exactly the kind of non-obvious behavior an agent needs before relying on the result set.

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 content is front-loaded — scope first, then return fields, then exclusions, then the region-code role — and every clause carries information. There is mild redundancy in restating the three regions twice ('List the three regions... Returns the top of... the three regions its hub features') and in the paired mentions of the private-field exclusion list, which could be tightened without losing meaning.

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?

For a parameterless read with no annotations and no output schema, the description supplies both the return shape and the negative space (privacy suppression, public-only filtering, no pagination), which covers what an agent needs to call it and interpret results. Only ordering/ranking details are absent, a minor gap for a small, fixed-size 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?

There are zero parameters, so the baseline is 4 and the description adds no per-parameter detail because none exists. It does add adjacent value by documenting the nine region codes (NYC, LA, SF, CHI, ATX, BOS, DC, MIA, LON) that feed the region parameter on downstream calls, though this is technically schema for another tool.

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?

The description opens with a concrete verb and resource: 'List the three regions Partiful's Explore hub features,' and immediately pins the scope to 'the top of Partiful's (partiful.com) public Explore surface.' It also preempts the name/behavior mismatch by naming the actual content (New York City, Los Angeles, San Francisco) rather than leaving 'cities' ambiguous.

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?

'This is also the discovery endpoint for the region parameter' gives an explicit use case, and the note that its nine region codes are the complete set tells the agent exactly why to call this first. 'Explore is a curated discovery feed, not a city catalogue: there is no pagination anywhere on this surface' sets a boundary, but the description never names the sibling alternatives (partiful_city_feed, partiful_city_facets) that an agent would pick for a deeper or paginated listing.

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