Skip to main content
Glama

Create meeting preparation

well_create_meeting_preparation

Mark meetings on the user's own calendars as prepared, after you have written their preparation, so Well does not start a separate pre-meeting check for them.

Use this tool when the user asks to prepare, brief or cover their meetings and you have written the preparation for them. Pass every meeting you covered in one call, up to 20.

REQUIRED: meetings, a list of { event_id, occurrence_start }. For one instance of a repeating meeting, pass its occurrence_start as returned by well_list_calendar_events; a single meeting takes null.

Returns { success: true, prepared, already_prepared, refused } where refused lists event ids that a scheduled run did not cover. A call naming a meeting that is not on the user's own calendars fails as a whole and marks nothing.

Input Schema

NameRequiredDescriptionDefault
meetingsYes
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several — a write lands in exactly one workspace and this call would not say which.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
idempotency_keyNoOptional client-supplied key. A retried write with the same key returns the original result instead of re-applying the operation.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.

Output Schema

NameRequiredDescriptionDefault
codeNo
errorNo
refusedNo
successYes
preparedNo
reply_linesNo
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
near_candidatesNo
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
already_preparedNo
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.
near_candidates_truncatedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses the side effect (suppresses an automatic pre-meeting check), atomic failure semantics ('fails as a whole and marks nothing'), the return payload shape including a 'refused' list, and the ownership restriction to the user's own calendars. That is exactly the mutation context annotations cannot express.

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?

Three short paragraphs ordered as effect, trigger/batching, then required shape and return contract. Every sentence carries information an agent needs to call it correctly; nothing is repeated from the schema for padding.

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?

Covers the mutation's purpose, precondition, batch limit, argument encoding, failure mode, and return contract for a 5-parameter write tool. With an output schema present, the return summary is extra confirmation rather than a gap-filler, and nothing material is left undocumented.

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

Parameters5/5

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

Adds real meaning on top of an 80%-covered schema: it defines the meetings object shape and, critically, the occurrence_start convention for a repeating instance versus null for a single meeting, and points to well_list_calendar_events as the source of that value. The 20-item cap is also restated as an instruction rather than left to maxItems.

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 ('Mark ... as prepared'), the exact resource (meetings on the user's own calendars), and the downstream effect (Well skips its separate pre-meeting check). It also scopes the tool implicitly against recurring/single meeting handling, so an agent can identify it without opening the schema.

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?

Gives an explicit trigger ('when the user asks to prepare, brief or cover their meetings and you have written the preparation for them') plus a batching rule ('pass every meeting you covered in one call, up to 20'). It names no sibling alternative other than the source of occurrence_start, so the when-not guidance is only implicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources