Skip to main content
Glama
drxinfra

Directum RX MCP (rxmcp)

by drxinfra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

rx_create_ticket

Create a card on an agile board with board, column, deadline, priority, performers, tags, plan/fact hours, and attachments. Writes immediately.

Instructions

Создать карточку на agile-доске. Доску, колонку, исполнителей и теги можно называть словами, сервер сопоставит их сам; теги должны уже существовать на доске. План и факт в часах задаются в plan_hours и fact_hours. В attachments можно сразу приложить ссылки, документы RX по Id и файлы с диска. Без column карточка попадает в первую колонку. Меняет данные сразу. Для поручения с контролем срока в самой системе используйте rx_create_simple_task. Перед вызовом перескажите пользователю доску, колонку, название и срок.

Input Schema

NameRequiredDescriptionDefault
nameYesназвание карточки
tagsNoтеги: названия существующих тегов доски
boardYesдоска: название, префикс или Id (rx_boards)
columnNoколонка: название или Id; по умолчанию первая колонка доски
deadlineNoсрок: ГГГГ-ММ-ДД или ГГГГ-ММ-ДДTЧЧ:ММ (дата без времени = 18:00)
priorityNoприоритет 1..10, по умолчанию 5
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. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the safety profile is covered; the description adds genuine context beyond them: 'Меняет данные сразу', the constraint that tags must already exist on the board (a failure mode), server-side name resolution, and the default-column fallback. It stops short of return/error behavior, so not a 5.

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-loads the purpose, then groups resolution rules, defaults, the destructive note, and the sibling routing into distinct sentences with no filler. It is dense but a couple of clauses (plan_hours/fact_hours restatement) partially duplicate the schema.

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 11-parameter mutation tool with no output schema, the description covers defaults (first column, default priority implied by schema), name-resolution behavior, a key precondition, and sibling routing, while annotations carry the safety profile. Missing only error/return expectations, which is a minor gap.

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 description coverage is 100%, so the baseline is 3; the description still earns credit by explaining semantics the schema does not, namely that board/column/performers/tags may be given as free-form words and the server resolves them, that tags must pre-exist, and that attachments accept links, RX document Ids, or disk files.

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?

Opens with a specific verb+resource ('Создать карточку на agile-доске') and immediately names the sibling it is not ('Для поручения с контролем срока ... используйте rx_create_simple_task'), so an agent can route between the two create tools without opening either schema.

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

Usage Guidelines5/5

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

Gives an explicit alternative and the condition that selects it (deadline-controlled tasks go to rx_create_simple_task), plus a concrete pre-call requirement to restate board, column, name and deadline to the user before invoking. Nothing is left to inference.

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