Skip to main content
Glama
entire-vc

EVC Mesh MCP Server

by entire-vc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

add_comment

Adds comments to tasks, supports threading and internal notes, and reports if @-mentions actually reached each recipient's queue or notification.

Instructions

Add a comment to a task. Response is lean by default: id/author/created_at and the delivery report, without echoing the body you just sent; full=true returns the whole comment. If the body @-mentions someone, the response carries a delivery array — one entry per mentioned handle — reporting whether it actually reached a path they consume (their task queue, a notification) or was skipped/failed and why; a hint field suggests the fix when there is one (e.g. assign the task). Omitted entirely when the comment mentions nobody.

Input Schema

NameRequiredDescriptionDefault
bodyYesComment body (markdown supported).
fullNoReturn the whole created comment (body echo included) instead of the lean confirmation.
task_idYesTask ID.
metadataNoAdditional metadata as key-value pairs. Set {"informational": true} on a comment you write on a task that is ALREADY done/cancelled when your comment needs no action from its assignee — a plain acknowledgement, "noted", "nothing further from me" — to stop the server's own follow-up-card mechanism from opening one for it. Omit it (default: not flagged) for anything that names a problem, asks a question, or reports a finding — an unflagged comment on a closed card still opens a follow-up as before, so forgetting the flag costs nothing. The flag is IGNORED if your comment also contains a `❓ Blocking @<person>` marker: a live ask to a human is never suppressed by this field.
is_internalNoMark as internal (agent-only visible).
parent_comment_idNoParent comment ID for threading.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.7/5.0
Behavior4/5

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

Annotations only declare the operation is non-read-only, non-idempotent and non-destructive; the description goes substantially further by disclosing the actual response contract (lean default, `full` opt-in) and the conditional `delivery` array with per-mention reach/skip reporting and `hint` suggestions. It stops short of permissions, threading behavior or failure modes, but adds real behavioral value beyond the structured fields.

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 one-line purpose, then dense, information-bearing detail about the response shape and mention-delivery semantics. No filler, though the closing sentence about omitting `delivery` when nobody is mentioned restates what the preceding sentence already implied.

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?

With no output schema, the description correctly carries the burden of describing return values and does so well (lean vs full, delivery/hint). For a mutation tool with nested `metadata` semantics this is nearly complete; the gap is the absence of any comparison to comment_doc, which an agent choosing among 60+ siblings would want.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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. The description's explanation of `full` largely restates what the schema description already says, and it never touches `metadata`, `is_internal` or `parent_comment_id` – the semantic load stays with the schema.

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?

Opens with a specific verb+resource: "Add a comment to a task." An agent can tell what it does. However, it never differentiates itself from sibling tools like comment_doc or list_comments, so the boundary of when this exact tool applies is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied rather than stated: the discussion of @-mention delivery and the `hint` field tells the agent this is the tool for posting task comments that may notify people. There is no explicit when-to-use/when-not-to-use guidance and no mention of the alternatives (comment_doc, list_comments) that a sibling-aware agent would need.

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

Deploy Server

Other Tools