Skip to main content
Glama
drxinfra

Directum RX MCP (rxmcp)

by drxinfra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

rx_update_ticket

Updates an agile board card in Directum RX: change fields, move columns, or add performers, tags, and attachments by numeric card ID. Only supplied fields are modified.

Instructions

Изменить карточку на agile-доске: название, описание, срок, приоритет, план и факт в часах, добавить исполнителей, теги и вложения (ссылка, документ RX по Id, файл с диска) или перенести в другую колонку. Меняются только переданные поля, остальные остаются. Убрать исполнителя, тег или вложение этим инструментом нельзя. Нужен числовой Id карточки из rx_tickets или rx_board. Меняет данные сразу.

Input Schema

NameRequiredDescriptionDefault
idYesId карточки (число из rx_tickets, не код вида ABC-12)
nameNoновое название; не передавайте, если менять не нужно
tagsNoдобавить теги: названия
columnNoперенести в колонку: название или Id
deadlineNoновый срок: ГГГГ-ММ-ДД или ГГГГ-ММ-ДДTЧЧ:ММ
priorityNoприоритет 1..10
fact_hoursNoновый факт, часы; не передавайте, если менять не нужно
performersNoдобавить исполнителей: фамилии или Id
plan_hoursNoновый план, часы; не передавайте, если менять не нужно
attachmentsNoдобавить вложения: в каждом ровно одно из url, file, document_id
descriptionNoновое описание целиком; не передавайте, если менять не нужно

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.7.0
    • addedInput schema / properties / fact_hours
      Added value: +{
+  "description": "новый факт, часы; не передавайте, если менять не нужно",
+  "type": [
+    "null",
+    "number"
+  ]
+}
    • addedInput schema / properties / plan_hours
      Added value: +{
+  "description": "новый план, часы; не передавайте, если менять не нужно",
+  "type": [
+    "null",
+    "number"
+  ]
+}
  2. Changed1 schema field changedv0.6.0
    • addedInput schema / properties / attachments
      Added value: +{
+  "description": "добавить вложения: в каждом ровно одно из url, file, document_id",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "document_id": {
+        "description": "Id документа RX из rx_find_documents: к карточке добавится ссылка на него",
+        "type": "integer"
+      },
+      "file": {
+        "description": "полный путь к файлу на компьютере, где запущен rxmcp; файл загрузится в хранилище доски, до 20 МБ",
+        "type": "string"
+      },
+      "name": {
+        "description": "подпись вложения; по умолчанию имя файла, название документа или сама ссылка",
+        "type": "string"
+      },
+      "url": {
+        "description": "ссылка http или https",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": [
+    "null",
+    "array"
+  ]
+}
  3. Changed2 schema fields changedv0.5.2
    • addedInput schema / properties / description / description
      Added value: +"новое описание целиком; не передавайте, если менять не нужно"
    • addedInput schema / properties / name / description
      Added value: +"новое название; не передавайте, если менять не нужно"
  4. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Beyond the annotations (destructiveHint=false, idempotentHint=false), the description adds real behavioral context: only the passed fields change (partial-update semantics), removals are impossible, and changes apply immediately with no confirmation step. It does not cover permissions/auth or what happens on invalid column/deadline values, so it is 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?

The verb+resource is front-loaded and every sentence carries information (mutable fields, partial-update rule, removal restriction, id source, immediate effect). It is delivered as one dense run-on paragraph rather than structured bullets, which slightly hurts scanability for an 11-parameter tool.

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 non-idempotent mutation tool with no output schema, the description covers the essentials an agent needs: partial-update behavior, non-removable fields, id sourcing, and immediate application. Missing only secondary concerns like permission requirements or error behavior on bad enum-free values (e.g. unknown column).

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 schema already documents all 11 parameters in detail, including the attachment one-of (url/file/document_id) rule. The description restates the mutable field set but adds no syntax or format detail beyond what the schema provides, so the baseline of 3 applies.

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?

The description opens with a specific verb+resource ("Изменить карточку на agile-доске") and enumerates exactly which fields are mutable (name, description, deadline, priority, plan/fact hours, performers, tags, attachments, column). It is clearly distinguishable from siblings such as rx_create_ticket or rx_ticket because it is framed as a partial update of an existing card.

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 gives concrete preconditions ("Нужен числовой Id карточки из rx_tickets или rx_board") and an explicit exclusion ("Убрать исполнителя, тег или вложение этим инструментом нельзя"), which is strong when-to-use guidance. It stops short of naming the alternative tool that should be used for removals, so it is not a full 5.

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