Skip to main content
Glama
drxinfra

Directum RX MCP (rxmcp)

by drxinfra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

rx_create_ticket

Creates a card on a Directum RX agile board with board, name, optional column, performers, tags, deadline, priority, and attachments; changes data immediately.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesназвание карточки
tagsNoтеги: названия существующих тегов доски
boardYesдоска: название, префикс или Id (rx_boards)
columnNoколонка: название или Id; по умолчанию первая колонка доски
deadlineNoсрок: ГГГГ-ММ-ДД или ГГГГ-ММ-ДДTЧЧ:ММ (дата без времени = 18:00)
priorityNoприоритет 1..10, по умолчанию 5
performersNoисполнители: фамилии или Id сотрудников
attachmentsNoвложения: в каждом ровно одно из url, file, document_id
descriptionNoописание

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+  ]
+}
  2. 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 a non-readonly, non-idempotent, non-destructive write; the description reinforces this with "Меняет данные сразу" and adds real context: word-based name resolution for board/column/performers/tags, the tag-existence prerequisite, the first-column fallback, and a required confirmation step before calling. It stops short of describing failure modes or the response, but it is well beyond what the annotations convey.

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?

Sentences are dense and front-loaded: purpose, resolution rules, defaults, mutation semantics, alternative tool, then the confirmation requirement. Most sentences earn their place, though the first-column default slightly duplicates the schema description.

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 9-parameter mutation with no output schema, the description covers the prerequisites, defaults, naming resolution, and the confirmation obligation an agent needs. Error handling and attachment-failure behavior are not covered, leaving a small 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 coverage is 100%, so the baseline is 3, but the description adds genuine semantics: board/column/performers/tags accept human-readable names the server resolves, tags must pre-exist, and attachments may be links, RX documents by Id, or local files. This meaningfully extends the field-level descriptions rather than restating them.

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 explicitly names the sibling it is not (rx_create_simple_task for deadline-controlled assignments). An agent can distinguish this from rx_tickets/rx_update_ticket/rx_create_simple_task without opening any 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?

It states the alternative tool and the exact condition that selects it ("Для поручения с контролем срока в самой системе используйте rx_create_simple_task"), notes the prerequisite that tags must already exist on the board, and specifies the default when column is omitted. Explicit when-to-use and when-to-use-something-else guidance is present.

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