Paxaver MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

update_event

Partially update a school event by changing only provided fields; omitted fields stay unchanged. Use for reschedules, capacity/price changes, or status transitions like cancelled/completed.

Instructions

ADMIN: Partially updates an existing school event — only the provided fields change; omitted fields keep their current values. Use for reschedules, capacity or price changes, and status transitions (cancelled/completed). Prefer cancel_event to cancel outright. Requires pac_cordinator or event_cordinator role. WRITE operation — confirm changes with the user. Get event_id from get_upcoming_events.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	New event name
`status`	No	Event status — cancelled stops sales, completed closes the event
`ends_at`	No	End time (e.g. 20:00)
`event_id`	Yes	Event ID — from get_upcoming_events
`location`	No	Event location (e.g. Gymnasium)
`starts_at`	No	Start time (e.g. 18:30)
`event_date`	No	Event date, YYYY-MM-DD
`description`	No	New event description shown to parents
`max_capacity`	No	Maximum number of attendees/tickets
`ticket_price_cents`	No	Ticket price in cents; 0 for free events

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	No
`name`	No
`status`	No
`eventDate`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.4.3Sep 16, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, but the description adds critical non-obvious behavior: it is a WRITE operation requiring user confirmation, role restrictions, and partial-update behavior. It also clarifies that cancelled stops sales and completed closes the event via the status semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence earns its place: scope, use cases, sibling preference, role requirement, write confirmation, and ID source. It is front-loaded with the core behavior and contains no filler.

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?

Despite having 10 parameters, the combination of 100% schema coverage, an output schema, and a description covering when-to-use, permissions, operational warnings, and ID sourcing makes this fully complete for an agent to invoke correctly.

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 description coverage is 100%, so the schema fully documents all 10 parameters. The description adds helpful context about how the parameters relate to use cases (reschedules, capacity, price) but does not add new per-parameter meaning beyond the schema. Baseline 3 is appropriate.

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 states a specific verb ('updates') and resource ('existing school event') and clarifies the partial-update semantics: only provided fields change, omitted fields keep current values. It clearly differentiates this from create_event and cancel_event by specifying scope and behavior.

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 lists intended use cases (reschedules, capacity/price changes, status transitions) and names the alternative (cancel_event) with a preference rule. It also gives a precondition (required roles) and tells the agent where to get event_id (get_upcoming_events).

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