Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

partiful_event

Fetch a public Partiful event by ID to retrieve its title, description, times, timezone, status, cover image, URL, venue, hosts, offers, and suggested events without exposing private attendee data.

Instructions

Get one public Partiful event. Returns one publicly listed Partiful (partiful.com) event: title, host-authored description, start and end time, timezone, status, cover image, canonical URL, venue name plus approximate city and neighborhood, host display names, the page's own advertised offers with a free signal, and the public events Partiful suggests. Take event_id from partiful-city-feed, partiful-city-facets or partiful-explore-cities; ids are twenty alphanumeric characters and are validated locally. An unknown id is a 404, and an event that is not public or requires a password is answered as a 404 because it belongs to the invite-link surface. Privacy is a hard scope limit: guest lists, attendee names and phone numbers, invite/RSVP state, ownerIds, host ids and contacts, exact street addresses and aggregate RSVP counters are 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": {
      "event_id": "<event_id>"
    },
    "name": "partiful_event"
  }
}

Input Schema

NameRequiredDescriptionDefault
event_idYesPartiful event id, twenty alphanumeric characters

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?

No annotations are supplied, so the description carries the full burden, and it does: local id validation, 404 semantics for both unknown and non-public events, and a stated hard privacy boundary enumerating what is never returned (guest lists, attendee names and phones, RSVP state, ownerIds, host ids, exact street addresses, RSVP counters). This tells an agent both what it can rely on and what it must not ask for.

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 payload enumeration is long but front-loaded and each clause carries distinct information: return fields, id sourcing, error behavior, privacy limits. The only minor inefficiency is restating the twenty-alphanumeric-character format already in the schema.

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?

With one required parameter, no annotations, and no output schema, the description compensates fully by describing the returned fields, the error model, and the privacy scope. Nothing an agent needs in order to call it correctly or interpret a 404 is missing.

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, and the description earns an extra point by explaining provenance of the id (which sibling tools produce it) and that it is validated locally before any request. The character-count format is repeated from the schema rather than extended, so it stops 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?

The description opens with a specific verb and resource: 'Get one public Partiful event,' then enumerates the exact payload (title, times, venue, host display names, offers, suggested events). The qualifier 'public' plus 'Get one' separates it cleanly from the sibling feed/facets/explore tools that return lists of events.

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?

It explicitly names the three upstream tools that supply event_id (partiful-city-feed, partiful-city-facets, partiful-explore-cities), states the id format, and defines negative cases: an unknown id yields 404, and non-public or password-protected events also yield 404 because they belong to the invite-link surface. That is an explicit when-to-use, where-to-get-input, and when-not-to-expect-results contract.

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