Directum RX MCP (rxmcp)

Overview Schema Source Related Servers Discussions Admin

rx_ticket

Read-only

Fetches a full agile board card by numeric ID, including status, assignees, deadlines, tags, attachments, images, description, and comments with authors and timestamps; set text_only to skip images.

Instructions

Одна карточка agile-доски целиком: статус, колонка, исполнители, сроки, трудоёмкость, теги, пронумерованные вложения и картинки, описание и комментарии с авторами и временем. Картинки из описания, комментариев и вложений (скриншоты ошибок) приходят изображениями, до 4 штук; text_only=true отключает их, когда карточек много подряд. Вложение по номеру (docx, xlsx, pdf, txt, json, логи, документ RX) читает rx_ticket_file. Нужен числовой Id карточки: значение id в скобках из rx_tickets или rx_board. Код вида ABC-12 сюда не подходит, по коду ищет rx_tickets. Только чтение, изменить карточку можно через rx_update_ticket, добавить комментарий через rx_comment_ticket. Связи с другими карточками (родитель, дочерние, зависимости, дубли) выводятся в блоке «Связи»; связи нескольких карточек сразу: rx_ticket_relations. Кто и когда менял карточку: rx_ticket_history.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "rx_ticket"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	числовой Id карточки: значение id в скобках в строках rx_tickets и rx_board; код вида ABC-12 не подходит
`text_only`	No	true = без картинок, только текст карточки; удобно, когда карточек много подряд

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.17.0Oct 30, 2026

addedInput schema / properties / text_only

Added value: +{
+  "description": "true = без картинок, только текст карточки; удобно, когда карточек много подряд",
+  "type": "boolean"
+}

Changed1 schema field changedv0.5.2Oct 2, 2026

changedInput schema / properties / id / description

Previous value: -"Id объекта в RX (число из #123)"New value: +"числовой Id карточки: значение id в скобках в строках rx_tickets и rx_board; код вида ABC-12 не подходит"

First observedv0.1.0Oct 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true, openWorldHint=false, idempotentHint=false, and the description is consistent ('Только чтение'). Beyond that it discloses non-obvious behavior: images are returned as actual images, capped at 4, sourced from description/comments/attachments, and text_only suppresses them; attachments themselves are not returned here but read via rx_ticket_file; relations appear in a dedicated 'Связи' block.

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?

One dense paragraph with zero filler and the primary purpose front-loaded; every sentence carries routing or behavioral information. It would read better split into short sections (contents / inputs / related tools), which is the only reason it is not a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only 2 parameters and no output schema, the description must carry the return-shape burden itself, and it does: it enumerates the card fields, the image cap and suppression switch, the relations block, and where attachments and history live. Nothing needed to invoke or interpret the result is missing.

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%, and both the id and text_only schema descriptions already carry the same meaning as the prose (numeric id from rx_tickets/rx_board, ABC-12 not accepted; text_only for bulk reads). The description reinforces but does not extend the schema, so the baseline 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?

Opens with a specific verb+resource ('Одна карточка agile-доски целиком') and enumerates exactly what the card payload contains: status, column, assignees, deadlines, effort, tags, numbered attachments/images, description, and comments with authors and timestamps. It actively distinguishes itself from rx_ticket_file (attachments), rx_ticket_relations (relations), and rx_ticket_history (change log), so an agent can route without opening sibling schemas.

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?

Explicit routing rules: the id must be the numeric value from parentheses in rx_tickets/rx_board, and 'ABC-12' codes are rejected here and must go to rx_tickets. It also states when to set text_only=true ('когда карточек много подряд') and names the mutation alternatives (rx_update_ticket, rx_comment_ticket). Conditions and alternatives are stated, not implied.

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