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

Directum RX MCP (rxmcp)

by drxinfra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

rx_create_gates

Creates up to 30 project milestones (control points) with names and planned dates in a Directum RX project card, validating all input before writing.

Instructions

Создать контрольные точки (цели проекта) и добавить их в карточку проекта, до 30 за вызов. У каждой обязательны название и плановая дата; уровень КТ-0, КТ-1, КТ-2, описание ожидаемого результата, ответственный, владелец и контролёр по желанию. Владелец и ответственный по умолчанию руководитель проекта. Ввод проверяется целиком до записи. Если карточка проекта открыта кем-то на изменение, RX откажет: её нужно закрыть. Нужны права на изменение проекта. Текущие КТ проекта показывает rx_project. Меняет данные в 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": {
      "project_id": "<project_id>",
      "gates": "<gates>"
    },
    "name": "rx_create_gates"
  }
}

Input Schema

NameRequiredDescriptionDefault
gatesYesконтрольные точки, до 30 за вызов
project_idYesId проекта: число после # в строке rx_projects

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.16.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare that this is a non-readonly, non-destructive write. The description adds genuinely new behavioral facts: input is validated in full before any write (atomic behavior), the call fails if the project card is locked for editing, and project modification rights are required. That is substantial context beyond what the structured fields provide.

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?

The most decision-relevant facts (action, batch limit, required fields) are front-loaded, and the remaining sentences each carry distinct operational content. There is minor redundancy, e.g. 'Меняет данные в RX' restates what the annotations already convey and could be dropped without loss.

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?

For a batch-mutating tool with no output schema, the description covers everything an agent needs: what is created, the per-call cap, field requirements and defaults, validation and locking failure modes, permission needs, and where to read the resulting gates (rx_project). Nothing essential is left dangling.

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, but the description adds semantics the schema does not spell out on its own: which fields are mandatory (name and plan_date), which are optional, the default assignment of owner and performer to the project manager, and the 30-item cap. It also defines what a gate's name should express (the expected result, e.g. 'Утверждено ТЗ').

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 resource ('Создать контрольные точки (цели проекта)') plus an explicit batch ceiling ('до 30 за вызов') and the destination ('в карточку проекта'). It points to rx_project for reading existing gates, but never contrasts with the sibling rx_update_gate, so the create-vs-update boundary must be inferred.

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 names prerequisites (project edit rights), a blocking condition (the project card must be closed if someone else has it open for editing, otherwise RX refuses), and an explicit pre-call UX step: show the user the list of gates with dates before invoking. These are concrete when/when-not rules, not implied guidance.

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