Prubex

Create an event

calendar_create_event

Creates an event: in calendar_id, or in the primary calendar of account_id (needed when you can reach several accounts). Use it when the user asks to book or schedule something; pick a free slot first with calendar_find_meeting_times. With attendees it sends invitations. It can return pending_approval: tell the user a person must approve it in Prubex, and do not retry. online_meeting adds a Teams or Meet link where the provider can; elsewhere the event is created without one and warnings says so. Times are ISO 8601: with an offset (2026-11-02T09:00:00+02:00), or without one to mean time_zone; all-day events use dates, and their end is the day after the last day. Example: { "account_id": "acc_…", "title": "Planning", "start": "2026-11-03T10:00:00+02:00", "end": "2026-11-03T10:30:00+02:00" }.

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": {
      "title": "<title>",
      "start": "<start>",
      "end": "<end>"
    },
    "name": "calendar_create_event"
  }
}

Input Schema

Name	Required	Description
`end`	Yes	ISO 8601 date-time (with an offset, or local to `time_zone`), or YYYY-MM-DD for all-day events.
`start`	Yes	ISO 8601 date-time (with an offset, or local to `time_zone`), or YYYY-MM-DD for all-day events.
`title`	Yes	The event title.
`all_day`	No	An all-day event: start and end are dates.
`location`	No	Where it happens.
`attendees`	No	People to invite; inviting anyone sends invitations.
`time_zone`	No	IANA time zone for dates in and out, e.g. "Africa/Johannesburg". Defaults to the workspace time zone, which prubex_overview returns as `time_zone`.
`account_id`	No	The account to act on (`acc_…` from accounts_list). Required when more than one account could do this; otherwise the error lists the candidates.
`calendar_id`	No	Create it in this calendar; default primary.
`description`	No	Notes shown on the event.
`online_meeting`	No	Add a Teams or Meet link where the provider supports it.
`idempotency_key`	No	Any unique string. Retrying with the same key within 24 h never repeats the action.

Output Schema

Name	Required	Description
`event`	No
`status`	Yes
`message`	Yes	What happened, in words for the user.
`warnings`	No	Accounts that failed or timed out; results from the others are still here.
`account_id`	Yes
`expires_at`	No	When held: when the request expires.
`review_url`	No	When held: where a person approves it in Prubex.
`approval_id`	No	When held: pass it to approvals_get later.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare the generic write/open-world profile; the description adds real behavior: invitations are sent when `attendees` is present, a `pending_approval` result requires telling the user and not retrying, and `online_meeting` may silently degrade with a `warnings` note. These are non-obvious side effects an agent could not infer from the schema.

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?

Front-loaded with purpose and routing, then behavior, then format rules and an example — a sensible order with no filler sentences. It is dense and long for a single paragraph, which slightly hurts scanability, but each sentence carries distinct information.

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 12-parameter mutation tool with an output schema, the description covers the risky parts: approval flow, invitation side effects, meeting-link fallback, and time formatting. Return values need not be explained since an output schema exists, and the two notable return signals are still called out.

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, but the description adds meaning the schema lacks: the ISO 8601 offset-vs-`time_zone` convention, the all-day rule that `end` is the day after the last day, and a worked example. It does not cover every parameter (e.g. `idempotency_key`, `location`), so not 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?

States a specific verb and resource ("Creates an event") and immediately scopes where it lands (`calendar_id` or the primary calendar of `account_id`). This clearly separates it from calendar_update_event, calendar_get_event and calendar_find_meeting_times.

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?

Gives an explicit trigger ("when the user asks to book or schedule something") and names the prerequisite alternative ("pick a free slot first with calendar_find_meeting_times"). It also states the no-retry rule after `pending_approval`, which is a when-not instruction.

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

All Prubex tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?