Skip to main content
Glama

Add meeting outcome

add_meeting_outcome

Add meeting minutes by recording decisions, notes, or linked work packages against an agenda item in OpenProject.

Instructions

Record an outcome — a decision, a note, a follow-up ticket — against an agenda item.

This is how minutes are written through the API: "decision: ship on Friday" becomes kind='decision' with the text in notes; linking the follow-up work package makes it kind='work_package'. Outcomes appear under their agenda item in get_meeting.

Returns the created outcome: {id, kind, notes, author, work_package, agenda_item}.

Pitfalls — the timing rule matters most. Outcomes can only be written while the meeting state is exactly 'in_progress': before that, and again once it is closed, every outcome write answers a validation error. Start the meeting with update_meeting(meeting_id=..., state='in_progress') first. Items in a backlog section refuse outcomes the same way. This needs the 'manage outcomes' permission, so a 403 is about the account, not the payload. On OpenProject before 17.6 there is no outcomes API at all — the 404 hint says so.

Cross-references: get_meeting for the agenda item id and to read the outcome back; update_meeting to put the meeting into 'in_progress'; update_meeting_outcome / delete_meeting_outcome to correct or remove it while the meeting still runs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNo'information' (a note for the minutes, requires notes), 'decision' (what was decided), or 'work_package' (the outcome IS a follow-up ticket, requires work_package_id).information
notesNoThe outcome text as markdown. Required for kind='information'; optional but usually worth writing for the other kinds.
agenda_item_idYesNumeric agenda item id the outcome is recorded against, from get_meeting's agenda_items. Not the meeting id.
work_package_idNoWork package the outcome points at, from search_work_packages. Required for kind='work_package'; it must be visible to this account.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoOutcome id.
kindNoOutcome kind as the instance defines it, e.g. 'decision'.
notesNoOutcome text as markdown (raw); html is dropped.
authorNoUser who recorded the outcome.
agenda_itemNoAgenda item the outcome is recorded against.
work_packageNoWork package the outcome points at, when one was linked.
Behavior5/5

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

Discloses critical behavioral traits beyond annotations: the timing state machine with a validation error, the 'backlog section' refusal, the 'manage outcomes' permission causing 403, and the OpenProject <17.6 404 quirk. It also specifies the exact return payload shape. Annotations only set hints (readOnlyHint=false), but the description adds real operational context with no contradictions.

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 long but every sentence carries weight. It is front-loaded with purpose, then flows into mechanics, return value, and a dedicated 'Pitfalls' section. For a tool with state constraints and cross-references, this structure is efficient and scannable, not padded.

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?

Given the tool's complexity (meeting state dependency, multiple kinds, permissions, version quirks), the description covers all necessary context: what it does, how to use it, when it fails, what it returns, and how it relates to siblings. The output schema is also explained explicitly enough that a complete picture is provided with minimal reliance on the structured schema alone.

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?

Schema already covers all four parameters with meaningful descriptions, but the description enriches them with concrete usage examples (e.g., 'decision: ship on Friday' becomes kind='decision' with text in notes) and clarifies the relationship between kind, notes, and work_package_id. It also notes that agenda_item_id is not the meeting id, adding beyond the schema.

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 opens with a specific verb+resource ('Record an outcome against an agenda item') and immediately enumerates the exact kinds of outcomes (decision, note, follow-up ticket). It distinguishes itself from sibling tools by framing itself as the way to write minutes through the API, with explicit cross-references to get_meeting and update_meeting_outcome/delete_meeting_outcome.

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?

Provides explicit when-to-use context: it is for writing minutes during an 'in_progress' meeting state, before which and after closure all writes fail. It names the required prerequisite (update_meeting to set state) and the permission ('manage outcomes'), plus points to update_meeting_outcome/delete_meeting_outcome for corrections. This goes far beyond vague guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kar-thik/openproject-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server