Skip to main content
Glama
soil-dev
by soil-dev

create_comment

Post a comment or threaded reply in Loomio discussions, polls, stances, or outcomes; provide body text and a discussion_id or parent_id/parent_type.

Instructions

Post a comment in a thread: 1 call (2 when discussion_id is a short key). Required body (+ body_format: 'html' for HTML; Loomio stores an omitted format as Markdown) and a target: discussion_id for a top-level comment, or parent_id + parent_type ('Comment' for a threaded reply; 'Poll' / 'Stance' / 'Outcome'). A new thread: create_discussion.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYes
parent_idNoComment, Poll, Stance or Outcome id to reply to (needs parent_type).
body_formatNoDefault 'md'; 'html' when `body` is HTML.
parent_typeNoType of parent_id; required with it.
discussion_idNoDiscussion id or short key (+1 call) for a top-level comment; or use parent_id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv0.0.13
    • removedInput schema / properties / body / description
      Removed value: -"Comment body (required)."
    • changedInput schema / properties / body_format / description
      Previous value: -"Format of `body`. Defaults to Loomio's group default when omitted."New value: +"Default 'md'; 'html' when `body` is HTML."
    • addedInput schema / properties / discussion_id / anyOf
      Added value: +[
      +  {
      +    "pattern": "^[A-Za-z0-9_-]+$",
      +    "type": "string"
      +  },
      +  {
      +    "exclusiveMinimum": 0,
      +    "maximum": 9007199254740991,
      +    "type": "integer"
      +  }
      +]
    • changedInput schema / properties / discussion_id / description
      Previous value: -"ID of the discussion to comment on."New value: +"Discussion id or short key (+1 call) for a top-level comment; or use parent_id."
    • removedInput schema / properties / discussion_id / exclusiveMinimum
      Removed value: -0
    • removedInput schema / properties / discussion_id / maximum
      Removed value: -9007199254740991
    • removedInput schema / properties / discussion_id / type
      Removed value: -"integer"
    • addedInput schema / properties / parent_id
      Added value: +{
      +  "description": "Comment, Poll, Stance or Outcome id to reply to (needs parent_type).",
      +  "exclusiveMinimum": 0,
      +  "maximum": 9007199254740991,
      +  "type": "integer"
      +}
    • addedInput schema / properties / parent_type
      Added value: +{
      +  "description": "Type of parent_id; required with it.",
      +  "enum": [
      +    "Discussion",
      +    "Comment",
      +    "Poll",
      +    "Stance",
      +    "Outcome"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "discussion_id",
      -  "body"
      -]New value: +[
      +  "body"
      +]
  2. First observedv0.0.6

TDQS

A4.5/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnly false, destructive false, openWorld true), and the description adds non-derivable operational context: call cost (1 call, 2 when discussion_id is a short key) and the server-side default that an omitted body_format is stored as Markdown. It does not warn about duplicate posts (idempotentHint=false), which is the main remaining gap.

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 the action, then packs target rules into one dense sentence with no filler. The telegraphic shorthand ('2 when...', '+1 call') is efficient but slightly compressed relative to plain prose.

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 5-parameter mutation tool with no output schema, the description covers purpose, both target paths, the format default, and the sibling alternative. Only the idempotency/duplicate-posting behavior and any required permissions are unaddressed.

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?

With 80% schema coverage the baseline is 3, but the description adds value beyond the schema by mapping parent_type values to intent ('Comment' for a threaded reply; 'Poll'/'Stance'/'Outcome') and by cross-referencing the dependency between parent_id and parent_type in prose.

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?

Opens with a specific verb+resource ('Post a comment in a thread') and immediately scopes it against siblings by naming create_discussion for new threads. The target variants (top-level vs threaded reply) further pin down what this tool does that create_poll/update_comment do not.

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?

Explicitly states which parameter combination selects which behavior: discussion_id for a top-level comment, parent_id + parent_type for a reply, and create_discussion for a brand-new thread. An agent can route correctly without opening any schema.

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