Skip to main content
Glama
agencian1

mcp-runrunit

by agencian1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

runrunit_create_comment

Create a plain-text Runrun.it task comment using the required template sections: Escopo, Como foi feito, affected files/settings, Como validar, and Links.

Instructions

Create a comment on a task in Runrun.it using the standard template. The server assembles plain text (no Markdown) in this order: Escopo, Como foi feito, Quais arquivos/configurações foram afetadas, Como validar, Links. Every section is required. Como validar must have at least two steps, one per line. Optional url_antes and url_depois are appended at the end of Links as "Antes: " and "Depois: " after capturing evidence with the registrar-evidencias skill.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
linksYesReference links for validation, including preview and PR/MR URLs. Raw URLs only, no Markdown.
escopoYesContext of the implementation or fix. Example: correção no checkout. Plain text only.
task_idYesTask ID
url_antesNoOptional. URL of the before state or evidence image. When set, the server appends 'Antes: <url>' at the end of Links. Capture evidence with the registrar-evidencias skill first.
url_depoisNoOptional. URL of the after state or evidence image. When set, the server appends 'Depois: <url>' at the end of Links.
como_validarYesStep-by-step test instructions, at least two non-empty lines. Example: "1. Acesse o link de preview:\n2. Navegue até a sessão Y". Plain text only.
como_foi_feitoYesWhether the change was code or panel configuration, and what changed. Example: Atualizei o código X do arquivo xyz.ts. Plain text only.
arquivos_configuracoesYesPaths or links of the affected files or settings. Example: src/checkout/xyz.ts. Plain text and raw URLs only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv2.0.0
    • addedInput schema / properties / arquivos_configuracoes
      Added value: +{
+  "description": "Paths or links of the affected files or settings. Example: src/checkout/xyz.ts. Plain text and raw URLs only.",
+  "type": "string"
+}
    • addedInput schema / properties / como_foi_feito
      Added value: +{
+  "description": "Whether the change was code or panel configuration, and what changed. Example: Atualizei o código X do arquivo xyz.ts. Plain text only.",
+  "type": "string"
+}
    • addedInput schema / properties / como_validar
      Added value: +{
+  "description": "Step-by-step test instructions, at least two non-empty lines. Example: \"1. Acesse o link de preview:\\n2. Navegue até a sessão Y\". Plain text only.",
+  "type": "string"
+}
    • addedInput schema / properties / escopo
      Added value: +{
+  "description": "Context of the implementation or fix. Example: correção no checkout. Plain text only.",
+  "type": "string"
+}
    • addedInput schema / properties / links
      Added value: +{
+  "description": "Reference links for validation, including preview and PR/MR URLs. Raw URLs only, no Markdown.",
+  "type": "string"
+}
    • removedInput schema / properties / text
      Removed value: -{
-  "description": "Comment text (can be enriched with an evidence block when url_antes/url_depois are used)",
-  "type": "string"
-}
    • changedInput schema / properties / url_antes / description
      Previous value: -"Optional. URL of the page in the 'before' state; when provided with url_depois, agent should capture evidence and append it to text"New value: +"Optional. URL of the before state or evidence image. When set, the server appends 'Antes: <url>' at the end of Links. Capture evidence with the registrar-evidencias skill first."
    • changedInput schema / properties / url_depois / description
      Previous value: -"Optional. URL of the page in the 'after' state; when provided with url_antes, agent should capture evidence and append it to text"New value: +"Optional. URL of the after state or evidence image. When set, the server appends 'Depois: <url>' at the end of Links."
    • changedInput schema / required
      Previous value: -[
-  "task_id",
-  "text"
-]New value: +[
+  "task_id",
+  "escopo",
+  "como_foi_feito",
+  "arquivos_configuracoes",
+  "como_validar",
+  "links"
+]
  2. First observedv1.8.1

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that the server assembles plain text (no Markdown), fixes the section order, marks every section required, and imposes a two-step minimum on Como validar. It omits any mention of return value, error behavior, or auth requirements, so it is strong but not exhaustive.

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 front-loaded sentences with little waste; the template order and constraints come early. It is appropriately sized for a tool with this much formatting logic, though the Links/url_antes/url_depois material is slightly redundant.

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 an 8-parameter write tool with no annotations and no output schema, the description supplies the formatting rules and prerequisite an agent needs to call it correctly. It leaves the return value and failure modes unstated, which is a minor gap given no output schema exists.

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% (baseline 3), but the description adds real meaning beyond the schema: it explains how the sections are ordered into the assembled text and how url_antes/url_depois are appended into Links as 'Antes:'/'Depois:' strings. Those cross-parameter behaviors are not derivable from the field descriptions alone.

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 ('Create a comment on a task in Runrun.it') plus a distinguishing qualifier ('using the standard template'). It is clear what the tool does, but it never names the closely related siblings (create_external_comment, update_comment) to differentiate itself from them.

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 is implied by the create-and-template framing, and it does note a prerequisite ('capture evidence with the registrar-evidencias skill first'). However, it gives no explicit when-to-use vs when-not guidance and never routes the agent away from create_external_comment or update_comment.

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