Skip to main content
Glama
prmichaelsen

eventbrite-mcp

by prmichaelsen
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

update_multiple_inventory_tiers

Update multiple inventory tiers for an event in one request to change quantities, prices, or sales dates in bulk.

Instructions

Update Multiple Inventory Tiers (Bulk)

Endpoint: POST /events/{event_id}/inventory_tiers/

Updates multiple inventory tiers in a single request for efficient bulk operations.

Authentication: Requires a valid Eventbrite API token with event management permissions.

Use Cases:

  • Bulk update tier quantities or prices

  • Synchronize tier configurations across multiple tiers

  • Efficiently modify complex inventory structures

  • Reduce API calls when updating many tiers

Updatable Fields:

  • name: Tier name

  • quantity: Number of tickets in this tier

  • price: Price for this tier

  • sales_start: When sales begin for this tier

  • sales_end: When sales end for this tier

  • minimum_quantity: Minimum tickets per order

  • maximum_quantity: Maximum tickets per order

Important Notes:

  • Each tier object must include its ID

  • Only provided fields will be updated (partial updates supported)

  • All tiers must belong to the specified event

Error Codes:

  • 400: Invalid tier data or tier IDs

  • 401: Authentication required

  • 403: Insufficient permissions

  • 404: Event or tier not found

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
event_idYesThe event ID containing the inventory tiers
inventory_tiersYesArray of inventory tier objects to update (must include tier IDs)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.6

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so description carries full burden: discloses POST endpoint, event management permission requirement, partial update semantics, required tier ID, ownership constraint, and 400/401/403/404 error codes. Provides substantial mutation context.

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?

Structured with headers and front-loaded title/endpoint. Use Cases bullets are somewhat redundant, all expressing bulk efficiency. Still dense and useful, but could trim some repetition.

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 2-param nested mutation with no annotations or output schema, description covers auth, error handling, partial updates, and constraints. No return format, but error codes and update semantics suffice for correct invocation.

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% for top-level params, but nested inventory_tiers properties lack descriptions. Description lists updatable fields and their meanings, and adds important rules (ID required, partial updates, all tiers belong to event), adding meaning beyond schema. Missing date/price format specifics.

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?

Explicit verb 'update', resource 'multiple inventory tiers', and bulk scope; 'single request' clarifies operation. Distinguishes from single-tier update sibling by 'Multiple' and 'Bulk'.

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?

Use Cases section clearly indicates when to use for bulk operations, reducing API calls. No explicit when-not-to-use or named alternative like update_inventory_tier for single-tier updates, but context implies bulk scenario.

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