Skip to main content
Glama

AgileHero

by io.agilehero
OverviewDiscussionsAdmin

create_retrospective

Create a retrospective: a new-model retrospective where the workspace has them, a classic retrospective board otherwise; the response is the retrospective as get_retrospective returns it (columns with their uids), so add_retro_items can follow immediately. A new-model retrospective comes from a template (default went_well), is open for notes at once and has you as facilitator; optional: focus, anonymity (default: the template's), participant_ids (a Selected-members retro; omit for every project member with write access), the check_in and feedback question kinds, and votes. The facilitator starts it and runs its stages in the app. Classic boards take name, date and previous_retrospective_id only and refuse the new-model arguments. Requires a Pro or trial workspace.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesRetrospective name
focusNoWhat this retro is about, shown under its name
votesNoVote settings: budget (auto | fixed | unlimited), per_person (1-20), max_per_topic (1-10)
check_inNoCheck-in question (default safety)
feedbackNoClosing feedback question (default roti)
templateNoTemplate key; default went_well
anonymityNoWho is shown on notes: anonymous, optional (authors may add their name) or named
starts_atNoDeprecated alias of starts_on
starts_onNoDate, ISO-8601 (YYYY-MM-DD); defaults to today
project_idYesThe unique identifier of the project
participant_idsNoUser uids of the participants (list_project_users); you are always one
previous_retrospective_idNoClassic boards only: uid of an earlier retrospective whose Actions column shows as "Past actions"

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changed
    • addedInput schema / properties / anonymity
      Added value: +{
+  "description": "Who is shown on notes: anonymous, optional (authors may add their name) or named",
+  "enum": [
+    "anonymous",
+    "optional",
+    "named"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / check_in
      Added value: +{
+  "description": "Check-in question (default safety)",
+  "enum": [
+    "safety",
+    "mood",
+    "esvp",
+    "one_word"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / feedback
      Added value: +{
+  "description": "Closing feedback question (default roti)",
+  "enum": [
+    "roti",
+    "pulse",
+    "one_word"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / focus
      Added value: +{
+  "description": "What this retro is about, shown under its name",
+  "maxLength": 120,
+  "type": "string"
+}
    • changedInput schema / properties / name / description
      Previous value: -"Meeting name"New value: +"Retrospective name"
    • addedInput schema / properties / participant_ids
      Added value: +{
+  "description": "User uids of the participants (list_project_users); you are always one",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / previous_retrospective_id / description
      Previous value: -"Optional uid of an earlier retrospective in this project (from list_retrospectives)"New value: +"Classic boards only: uid of an earlier retrospective whose Actions column shows as \"Past actions\""
    • changedInput schema / properties / starts_at / description
      Previous value: -"Meeting date, ISO-8601 (YYYY-MM-DD); defaults to today"New value: +"Deprecated alias of starts_on"
    • addedInput schema / properties / starts_on
      Added value: +{
+  "description": "Date, ISO-8601 (YYYY-MM-DD); defaults to today",
+  "type": "string"
+}
    • addedInput schema / properties / template
      Added value: +{
+  "description": "Template key; default went_well",
+  "enum": [
+    "went_well",
+    "start_stop_continue",
+    "four_ls",
+    "mad_sad_glad",
+    "kalm",
+    "daki",
+    "starfish",
+    "plus_delta",
+    "sailboat",
+    "rose_thorn_bud",
+    "wrap",
+    "hot_air_balloon",
+    "three_pigs",
+    "project_retro",
+    "postmortem",
+    "kudos_lessons"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / votes
      Added value: +{
+  "additionalProperties": false,
+  "description": "Vote settings: budget (auto | fixed | unlimited), per_person (1-20), max_per_topic (1-10)",
+  "properties": {
+    "budget": {
+      "description": "Votes per person: auto (3-7 by the number of topics; default), fixed or unlimited",
+      "enum": [
+        "auto",
+        "fixed",
+        "unlimited"
+      ],
+      "type": "string"
+    },
+    "max_per_topic": {
+      "description": "Most votes one person puts on one topic (default 3)",
+      "maximum": 10,
+      "minimum": 1,
+      "type": "integer"
+    },
+    "per_person": {
+      "description": "The fixed budget (implies budget fixed; default 5)",
+      "maximum": 20,
+      "minimum": 1,
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}
  2. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations (mutating, non-idempotent, non-destructive), the description adds meaningful behavior: a new-model retro comes from a template, is open for notes immediately, and makes the caller facilitator, while classic boards only accept name/date/previous_retrospective_id and reject the rest. It notes defaults and that the caller is always a participant. It does not discuss failure modes beyond argument refusal or any rate/permission nuances.

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

Conciseness3/5

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

It is front-loaded with the core purpose, but the body is dense, run-on and largely unstructured, packing mode differences, defaults and constraints into fewer, longer sentences. Every clause carries some information, but readability suffers and it could be trimmed and organized better.

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

Completeness4/5

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

For a complex 12-parameter, two-mode tool with no output schema, the description covers both creation paths, key defaults, the required workspace plan, and even the response shape (as get_retrospective returns it). Enough for an agent to invoke it correctly, though it leans on the agent to infer some mode-specific field applicability.

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 description coverage is 100%, so the baseline is 3, but the description adds semantics beyond the schema: participant_ids omitted means every project member with write access, the caller is always included, anonymity defaults to the template's value, and classic boards only take a subset of fields. These clarifications exceed what the field descriptions alone convey.

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 ("Create a retrospective") and immediately differentiates the two modes it can produce: new-model where the workspace supports them, classic otherwise. It also names sibling relationships (get_retrospective's response shape, add_retro_items that can follow), so an agent can place it precisely among siblings.

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 clear conditional guidance: use the new-model path where the workspace has them, otherwise a classic board, and classic boards refuse the new-model arguments. It also discloses the Pro/trial workspace prerequisite. It stops short of explicitly naming an alternative tool to call instead in edge cases, but the when/when-not conditions are well covered.

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

All AgileHero toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources