Skip to main content
Glama

rx_update_ticket

Update an agile board card by changing its name, description, deadline, priority, performers, tags, attachments, or column. Requires the numeric card Id; only provided fields are modified.

Instructions

Изменить карточку на agile-доске: название, описание, срок, приоритет, добавить исполнителей, теги и вложения (ссылка, документ RX по Id, файл с диска) или перенести в другую колонку. Меняются только переданные поля, остальные остаются. Убрать исполнителя, тег или вложение этим инструментом нельзя. Нужен числовой Id карточки из rx_tickets или rx_board. Меняет данные сразу.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesId карточки (число из rx_tickets, не код вида ABC-12)
nameNoновое название; не передавайте, если менять не нужно
tagsNoдобавить теги: названия
columnNoперенести в колонку: название или Id
deadlineNoновый срок: ГГГГ-ММ-ДД или ГГГГ-ММ-ДДTЧЧ:ММ
priorityNoприоритет 1..10
performersNoдобавить исполнителей: фамилии или Id
attachmentsNoдобавить вложения: в каждом ровно одно из url, file, document_id
descriptionNoновое описание целиком; не передавайте, если менять не нужно

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.0
    • addedInput schema / properties / attachments
      Added value: +{
      +  "description": "добавить вложения: в каждом ровно одно из url, file, document_id",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "document_id": {
      +        "description": "Id документа RX из rx_find_documents: к карточке добавится ссылка на него",
      +        "type": "integer"
      +      },
      +      "file": {
      +        "description": "полный путь к файлу на компьютере, где запущен rxmcp; файл загрузится в хранилище доски, до 20 МБ",
      +        "type": "string"
      +      },
      +      "name": {
      +        "description": "подпись вложения; по умолчанию имя файла, название документа или сама ссылка",
      +        "type": "string"
      +      },
      +      "url": {
      +        "description": "ссылка http или https",
      +        "type": "string"
      +      }
      +    },
      +    "type": "object"
      +  },
      +  "type": [
      +    "null",
      +    "array"
      +  ]
      +}
  2. Changed2 schema fields changedv0.5.2
    • addedInput schema / properties / description / description
      Added value: +"новое описание целиком; не передавайте, если менять не нужно"
    • addedInput schema / properties / name / description
      Added value: +"новое название; не передавайте, если менять не нужно"
  3. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Аннотации уже сообщают о мутационном и недеструктивном характере, но описание добавляет важную семантику: меняются только переданные поля, исполнители/теги/вложения только добавляются, данные меняются сразу. Не раскрыты вопросы авторизации, ошибок или возврата, поэтому 4.

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?

Пять коротких предложений: сначала перечень возможностей, затем правило частичного обновления, ограничение на удаление, требование к Id и немедленность изменений. Лишних формулировок нет.

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?

Для инструмента с 9 параметрами и без output schema описание покрывает область изменений, частичную семантику, ограничение на удаление, требуемый Id и немедленный эффект. Аннотации и схема закрывают безопасность и параметры; недостаёт лишь ожиданий по ошибкам, правам или возврату.

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?

Покрытие описаний в схеме 100%: все параметры, включая вложенные варианты вложений, уже документированы. Описание дублирует общий список возможностей и не добавляет синтаксических или форматных деталей сверх схемы, поэтому базовый уровень 3.

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?

Указан конкретный глагол «Изменить» и ресурс «карточку на agile-доске», перечислены изменяемые аспекты и подчёркнут частичный характер обновления. Это позволяет отличить инструмент от rx_create_ticket, rx_delete_tickets и rx_ticket без открытия схемы.

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?

Есть чёткий контекст: нужен числовой Id из rx_tickets или rx_board, и явно сказано, чего инструмент не умеет — удалять исполнителей, теги или вложения. Однако альтернативный инструмент для удаления не назван и нет прямого сравнения с rx_create_ticket/rx_delete_tickets, поэтому не 5.

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