vrchat_event_create

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

readOnlyHint=false already signals this is a mutation, and the description's 'create' wording is consistent with that (no contradiction). However, the description adds no behavioral context beyond the annotation — nothing about draft vs. published events, notification side effects, permission requirements, or that the event must belong to an existing group. For a write operation, this fails to disclose meaningful behavioral traits.

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

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

The single sentence is grammatically complete and front-loaded with the verb, so it is genuinely concise. But at five words for a 20-parameter mutation tool, it leans toward under-specification rather than disciplined brevity. It reads more like a summary line than a tool definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema, return-value explanation is unnecessary, but the description still omits essential operational context: date-time format requirements, enum semantics and defaults, behavior of isDraft/featured/sendCreationNotification, and the relationship between groupId and the calendar. The sparse readOnlyHint annotation does little to fill these gaps. The definition is incomplete for the complexity of this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for 20 undocumented parameters. It provides no guidance on the five required fields (description, endsAt, startsAt, title, groupId) and no hints about the strict ISO-8601 date-time pattern, enum defaults (category='other', accessType='group'), or optional flags like isDraft, featured, or sendCreationNotification. An agent would have to reverse-engineer semantics from types, validation patterns, and names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a group calendar event' pairs a specific verb with a resource type, clearly identifying a creation operation. The 'create' verb distinguishes it from siblings like vrchat_event_update, vrchat_event_delete, and the various event-read tools. It misses a 5 only because it omits any scope nuance (e.g., the event must belong to a group) that the required groupId parameter implies.

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

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

No usage context is provided — the description says nothing about when to choose this tool over vrchat_event_update, vrchat_event_delete, or the group event read tools. It also omits prerequisites such as group membership or required permission levels to create events. An agent must infer all selection criteria from the tool name alone.

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