Directum RX MCP (rxmcp)

Overview Schema Source Related Servers Discussions Admin

rx_complete_assignment

Completes, accepts, returns, approves, acknowledges, or reviews a Directum RX assignment on the user's behalf, including substitutions. It cannot sign; inspect first, as changes are irreversible.

Instructions

Выполнить задание от имени пользователя: простое задание завершить, приёмку принять или вернуть на доработку, согласовать документ (в том числе с замечаниями) или вернуть на доработку, отметить ознакомление, рассмотрение. Без result берётся стандартный результат для типа задания. Задания на подписание не выполняет: подпись ставится только в RX. Если исполнитель задания не пользователь (задание пришло по замещению, строка с « · за <ФИО>»), оно выполняется за исполнителя: RX разрешает это только замещающему, подтверждение и ответ называют, за кого. Меняет данные в RX: задание закрывается, процесс идёт дальше, отменить это нельзя. Сначала посмотрите задание через rx_get_assignment и перескажите пользователю, что будет сделано и за кого.

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_complete_assignment"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Id задания
`result`	No	результат; по умолчанию стандартный для типа задания: простое Complete, приёмка Accepted, согласование Approved, ознакомление Acquainted, рассмотрение Explored или Informed. Можно по-русски: выполнено, принять, согласовать, с замечаниями, на доработку, ознакомлен. Варианты для задания показывает rx_get_assignment

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.11.0Oct 17, 2026

changedInput schema / properties / result / description

Previous value: -"результат: для простого задания Complete (по умолчанию), для приёмки Accepted (принять, по умолчанию) или ForRework (на доработку); можно по-русски: принять, на доработку, выполнено"New value: +"результат; по умолчанию стандартный для типа задания: простое Complete, приёмка Accepted, согласование Approved, ознакомление Acquainted, рассмотрение Explored или Informed. Можно по-русски: выполнено, принять, согласовать, с замечаниями, на доработку, ознакомлен. Варианты для задания показывает rx_get_assignment"

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 only declare write, non-idempotent, non-open-world, non-destructive; the description goes well beyond them by stating the assignment closes, the process advances, and the action cannot be undone, plus the substitution/authorization constraint. The irreversibility warning is valuable context an agent could not infer from the structured fields. The only mild tension is between 'cannot be undone' and destructiveHint=false, but closing a workflow step is not data destruction, so this is not a contradiction.

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-loaded with the verb and the list of supported assignment types, then the constraints and the irreversibility warning. It is dense and purposeful, though the enumeration of approval/return pairs is somewhat repetitive and a reference to 'RX' is left unexplained.

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?

No output schema exists, yet the description explains the observable effect (assignment closed, process advanced, irreversible) and the required pre-check via rx_get_assignment. For a two-parameter mutation tool, nothing an agent needs in order to call it safely 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 coverage is 100% and the schema already documents that omitting result selects the type-specific default and points to rx_get_assignment for valid options. The description restates the default behavior and gives general categories but adds no new syntax, format, or edge-case meaning for the id or result parameters. 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?

The description opens with a specific verb ('Выполнить задание от имени пользователя') and then enumerates exactly which assignment types are covered: simple complete, acceptance accept/return, document approval including with remarks, acquaintance, review. An agent can distinguish this from siblings like rx_get_assignment or rx_send_for_approval without opening the 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?

Explicit routing guidance is present: signing assignments are excluded ('Задания на подписание не выполняет: подпись ставится только в RX'), and the workflow prerequisite is stated ('Сначала посмотрите задание через rx_get_assignment'). The substitution condition (assignment arrived via ' · за <ФИО>') is also spelled out with the authorization rule that only the substitute may act.

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