Skip to main content
Glama
Sign In

Decknote

by app.decknote
OverviewDiscussionsAdmin

Add comment

add_comment
Destructive

Adds a comment to a task as the user. By default nobody is notified. With notify: true it notifies @mentioned board members and the card's watchers by push and email, as commenting in the app does; that needs confirm: true, and without it the result is a preview of who would be notified.

Input Schema

NameRequiredDescriptionDefault
textYesMention a board member by writing @ and their name.
cardIdYes
notifyNoNotify mentioned people and watchers, as the app does. Default false.
confirmNotrue performs the action. Without it (or with any value other than the boolean true) nothing changes and the result is a preview of the effects.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / confirm / description
      Previous value: -"Set to true only after the user has seen the preview and explicitly agreed. Without it nothing changes and you get a preview."New value: +"true performs the action. Without it (or with any value other than the boolean true) nothing changes and the result is a preview of the effects."
  2. Changed3 schema fields changed
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "Set to true only after the user has seen the preview and explicitly agreed. Without it nothing changes and you get a preview.",
+  "type": "boolean"
+}
    • addedInput schema / properties / notify
      Added value: +{
+  "description": "Notify mentioned people and watchers, as the app does. Default false.",
+  "type": "boolean"
+}
    • addedInput schema / properties / text / description
      Added value: +"Mention a board member by writing @ and their name."
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations mark it as destructive and not read-only, and the description adds crucial context: notify defaults to false, confirm:true is required for notification, and without confirm the result is a preview. This is valuable behavioral detail beyond annotations. It doesn't explain what 'destructive' means here or what access is required.

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?

Three sentences, front-loaded with the core action, then default behavior, then the notify/confirm interaction. No wasted words. Could be slightly tighter, but every sentence adds value.

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?

Given no output schema and 4 parameters with 75% schema coverage, the description covers the main behavioral caveats (notify + confirm) and default. It doesn't mention return values or error cases, but for a comment-adding tool, this is reasonably complete.

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 75%, and the description explains the interaction between notify and confirm: notify:true needs confirm:true, otherwise a preview is returned. This adds meaning beyond the schema, which individually describes each parameter but not their joint behavior. The text parameter's @mention syntax is only in the schema, not the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Adds a comment to a task') and adds the actor ('as the user'). It does not explicitly distinguish itself from siblings like edit_comment or delete_comment, though 'adds' implies creation rather than modification.

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?

It clarifies the default behavior (nobody notified) and what notify:true does, with a clear condition for using it. But it doesn't mention when to use this instead of edit_comment or react_to_comment, and doesn't explain required permissions or prerequisites.

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

All Decknote 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