Skip to main content
Glama
Sign In
atlassian-browser-mcp

atlassian-browser-mcp

by GeiserX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Update Form Answers

jira_update_proforma_form_answers
DestructiveIdempotent

Update Jira ProForma form field answers by question ID, type, and value through the Forms REST API, with automatic ISO 8601 date conversion.

Instructions

Update form field answers using the Jira Forms REST API.

This is the primary method for updating form data. Each answer object must specify the question ID, answer type, and value.

⚠️ KNOWN LIMITATION - DATETIME fields: The Jira Forms API does NOT properly preserve time components in DATETIME fields. Only the date portion is stored; times are reset to midnight (00:00:00).

Workaround for DATETIME fields: Use jira_update_issue to directly update the underlying custom fields instead:

  1. Get the custom field ID from the form details (question's "jiraField" property)

  2. Use jira_update_issue with fields like: {"customfield_XXXXX": "2026-01-09T11:50:00-08:00"}

Example:

# Instead of updating via form (loses time):
# jira_update_proforma_form_answers(issue_key, form_id, [{"questionId": "91", "type": "DATETIME", "value": "..."}])

# Use direct field update (preserves time):
jira_update_issue(issue_key, {"customfield_10542": "2026-01-09T11:50:00-08:00"})

Automatic DateTime Conversion: For DATE and DATETIME fields, you can provide values as:

  • ISO 8601 strings (e.g., "2024-12-17T19:00:00Z", "2024-12-17")

  • Unix timestamps in milliseconds (e.g., 1734465600000)

The tool automatically converts ISO 8601 strings to Unix timestamps.

Example answers: [ {"questionId": "q1", "type": "TEXT", "value": "Updated description"}, {"questionId": "q2", "type": "SELECT", "value": "Product A"}, {"questionId": "q3", "type": "NUMBER", "value": 42}, {"questionId": "q4", "type": "DATE", "value": "2024-12-17"} ]

Common answer types:

  • TEXT: String values

  • NUMBER: Numeric values

  • DATE: Date values (ISO 8601 string or Unix timestamp in ms)

  • DATETIME: DateTime values - ⚠️ USE WORKAROUND ABOVE

  • SELECT: Single selection from options

  • MULTI_SELECT: Multiple selections (value as list)

  • CHECKBOX: Boolean values

Input Schema

NameRequiredDescriptionDefault
answersYesList of answer objects. Each answer must have: questionId (string), type (TEXT/NUMBER/SELECT/etc), value (any)
form_idYesProForma form UUID (e.g., '1946b8b7-8f03-4dc0-ac2d-5fac0d960c6a')
issue_keyYesJira issue key (e.g., 'PROJ-123')

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.4.1
    • addedInput schema / additionalProperties
      Added value: +false
    • removedOutput schema / description
      Removed value: -"Generic wrapper for non-object return types."
  2. Addedv1.0.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true, idempotentHint=true and openWorldHint=true; on top of that the description discloses a genuine API defect (DATETIME times reset to midnight) and the parsing behavior that ISO strings are auto-converted to Unix ms. The remaining gap is that it never says whether the answers array merges with or replaces existing answers — a material question for a destructive, idempotent update.

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

Conciseness3/5

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

The critical DATETIME warning is front-loaded and clearly marked, which is good, but the content is verbose and repetitive: the midnight-reset limitation is stated twice, and the auto-conversion of ISO strings appears both in a bullet and in the trailing type list. The sample answer array largely duplicates the 'Common answer types' bullets.

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?

With an output schema present, return values need not be explained; the description covers the required inputs, the type system, the date parsing contract, a known data-loss caveat, and the documented escape hatch. For a three-parameter destructive mutation this is sufficient for an agent to call it correctly or route around it.

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 coverage is 100%, so the baseline is 3, but the description goes beyond the schema's generic 'type (TEXT/NUMBER/SELECT/etc)' by enumerating each answer type and its value shape (MULTI_SELECT as a list, CHECKBOX as boolean, DATE as ISO string or Unix ms). It does not explain the optional fields or validation failures of the answer objects, keeping it short of 5.

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 ('Update form field answers') and positions itself as 'the primary method for updating form data', which distinguishes it from the read-only proforma siblings (jira_get_proforma_form_details, jira_get_issue_proforma_forms). The reader knows immediately what the tool mutates and how it relates to the surrounding proforma tools.

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?

Explicitly declares itself the primary path, then names the exception and the alternative: for DATETIME fields use jira_update_issue against the underlying custom field, with a step-by-step path (get jiraField from form details). This is exactly the when/when-not/alternative structure that earns a top score.

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