Skip to main content
Glama
Sign In

DataToRAG

by com.datatorag
OverviewDiscussionsAdmin

atlassian-mcp__confluence_add_comment

Add a comment to a Confluence page: a footer comment on the page, an inline comment anchored to a piece of the page's text with inline_text, or a reply to an existing footer or inline comment with parent_comment_id. A reply goes into the same kind of thread as the comment it answers. An inline_text that does not appear in the page is refused before anything is posted; when it appears more than once, inline_match picks which. Returns the new comment's ID, version, type and parent.

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": {
      "page_id": "<page_id>",
      "body": "<body>"
    },
    "name": "atlassian-mcp__confluence_add_comment"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyYesComment text (plain text; will be wrapped in <p> tags automatically).
accountNoOptional email address of the connected account to use (e.g. 'user@gmail.com'). If omitted, the default account is used.
page_idYesThe ID of the page to comment on.
inline_textNoOptional text on the page to anchor an inline comment to, exactly as it reads on the page. Not used with parent_comment_id.
inline_matchNoWhich occurrence of inline_text to anchor to, counting from 1, when it appears more than once (default 1).
parent_comment_idNoOptional ID of an existing comment, footer or inline, to reply to.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare this is a non-read, non-destructive write, so the description carries most of the burden and does so: it discloses pre-flight validation ('an inline_text that does not appear in the page is refused before anything is posted'), disambiguation via inline_match, thread inheritance for replies, and the fields returned (ID, version, type, parent). That is substantive behavioral context beyond the annotations.

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?

One tight paragraph: the primary action and the three modes come first, followed by behavioral guarantees and the return shape. Every sentence adds information; nothing is redundant with the schema or annotations.

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?

A six-parameter write tool with no output schema, fully documented: the description covers mode selection, validation behavior, occurrence disambiguation, and the shape of the response. An agent has everything needed to call it correctly without inspecting other tools.

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 baseline would be 3, but the description adds real meaning the schema does not: that inline_match chooses among multiple occurrences of inline_text, that replies inherit the thread kind of the comment being answered, and that inline_text must literally match page text or the call is rejected pre-post. Only the body/account parameters get no extra commentary, which is fine.

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 ('Add a comment to a Confluence page') and then enumerates the three distinct modes: footer comment, inline comment via inline_text, and reply via parent_comment_id. This distinguishes it clearly from confluence_get_comments and from the Jira/Notion comment siblings, which operate on different platforms.

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?

Explicitly maps each intent to a parameter mode (inline_text for anchored comments, parent_comment_id for replies) and notes inline_text is not used with parent_comment_id. The one gap is that it never says how to obtain a parent_comment_id, i.e. that confluence_get_comments should be called first to find the thread.

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

All DataToRAG toolsInspect
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