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

Directum RX MCP (rxmcp)

by drxinfra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

rx_update_risk

Updates selected fields of an existing project risk by ID—status, description, probability, impact, category, owner, and plans—changing only provided fields.

Instructions

Изменить риск проекта: статус, описание, планы предотвращения и устранения последствий, вероятность, влияние, категорию, ответственного, название. Меняются только переданные поля; текстовые поля заменяются целиком. Id риска из rx_project_risks. Меняет данные в 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": {
      "id": "<id>"
    },
    "name": "rx_update_risk"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesId риска: число после # в rx_project_risks
nameNoновое название; не передавайте, если не меняется
typeNorisk или possibility
impactNoвлияние: название или Id
statusNoстатус: идентифицирован, отслеживается, предотвращается, реализовался, устраняется, устранён, не актуален
categoryNoкатегория: название или Id
descriptionNoновое описание целиком
probabilityNoвероятность: название, процент или Id
responsibleNoответственный: фамилия или Id
mitigation_planNoплан предотвращения целиком
contingency_planNoплан устранения последствий целиком

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.16.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, so the bar is lower, yet the description adds meaningful context: partial-patch semantics, full replacement of text fields (a data-loss risk the annotations do not signal), the source of the Id, and a mandatory user-confirmation step. It stops short of covering failure behavior for invalid status/probability values.

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 field list, then immediately the patch/replacement rules and the confirmation requirement. Every sentence carries an actionable constraint; nothing is 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?

For an 11-parameter mutation with no output schema, the description covers patch semantics, replacement behavior, Id provenance, and the confirmation protocol. It leaves return/error behavior unstated, but with annotations present and full schema coverage that gap is minor.

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 each property already carries a description, so the schema does the heavy lifting. The description's field list largely restates the schema, adding only the note that the Id comes from rx_project_risks, which the schema itself also states.

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?

Specific verb plus resource ('Изменить риск проекта') followed by an explicit enumeration of updatable fields, which lets an agent distinguish this from rx_create_risks and the read-only rx_project_risks. It never explicitly names those siblings as alternatives, so differentiation is inferred from the verb rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete operational rules: only the passed fields are modified, text fields are replaced wholesale, and the agent must restate the intended change to the user before calling. That is real usage guidance, but there is no explicit when-not or pointer to a sibling for creation vs. update.

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