Skip to main content
Glama
Sign In
Directum RX MCP (rxmcp)

Directum RX MCP (rxmcp)

by drxinfra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

rx_send_for_acquaintance

Create and start a document review task for selected employees in Directum RX, setting a deadline and optional electronic signature confirmation.

Instructions

Отправить документ на ознакомление сотрудникам: создаёт и стартует задачу на ознакомление, участники получают задания. Нужны Id документа (rx_find_documents), Id сотрудников (rx_find_employees) и срок. electronic=true требует от участников подтвердить ознакомление подписью в RX. Меняет данные в RX. Перед вызовом перескажите пользователю документ, участников и срок.

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": {
      "document_id": "<document_id>",
      "performer_ids": "<performer_ids>",
      "deadline": "<deadline>"
    },
    "name": "rx_send_for_acquaintance"
  }
}

Input Schema

NameRequiredDescriptionDefault
textNoтекст задачи: что и зачем прочитать
deadlineYesсрок ознакомления, обязателен: ГГГГ-ММ-ДД, ГГГГ-ММ-ДДTЧЧ:ММ, «завтра» или «через 3 дня»
electronicNotrue = электронное ознакомление: участник подтверждает его подписью в RX; по умолчанию обычное
document_idYesId документа: число после # в строке rx_find_documents
performer_idsYesId сотрудников, которые должны ознакомиться (rx_find_employees)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.11.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false but not that it mutates RX state; the description adds 'Меняет данные в RX' and explains the electronic=true side effect (signature-based confirmation). Leaves unclear whether the deadline is enforced, whether the task can be recalled, or what an employee receives.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action, then prerequisites, then the electronic flag, then a mutation warning and a pre-call instruction. Every sentence has a distinct purpose with no padding.

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?

Covers the mutation, the required inputs and their sources, the electronic mode, and the confirmation step. No output schema exists, and the description doesn't say what the agent receives back (task ID, status) or how to handle partial failures among performer_ids.

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 five parameters including electronic semantics and deadline formats. The description restates the three required IDs and the electronic=true behavior but adds no syntax beyond the schema; 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?

States a specific verb and resource in Russian: 'Отправить документ на ознакомление сотрудникам: создаёт и стартует задачу'. Distinguishes from sibling rx_send_for_approval (approval vs acquaintance) by naming the task type explicitly.

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?

Specifies prerequisites (document ID from rx_find_documents, employee IDs from rx_find_employees, deadline) and a pre-call instruction to summarize the document, participants, and deadline to the user. Explicitly names the sibling tools that supply each required ID.

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