Skip to main content
Glama
bruhsb
by bruhsb

paperclip_update_issue

DestructiveIdempotent

Update issue fields and optionally add a comment in a single call. Change status, priority, assignee, project, goal, labels, and other properties.

Instructions

Update one or more fields on an issue; optionally attach a comment in the same call.

Args:

  • issueId: string — Issue ID or identifier (example: "PAP-42")

  • status: enum — backlog|todo|in_progress|in_review|done|blocked|cancelled

  • priority: enum — critical|high|medium|low

  • title: string — New title

  • description: string — New description (markdown)

  • comment: string — Comment to post with this update

  • assigneeAgentId: string|null — Agent UUID; null to unassign

  • assigneeUserId: string|null — User UUID; null to unassign

  • goalId: string|null — Goal UUID; null to unlink

  • projectId: string|null — Project UUID; null to unlink

  • parentId: string|null — Parent issue UUID; null to detach

  • billingCode: string|null — Billing code; null to clear

  • labelIds: string[] — Replaces label set; [] clears all

  • executionRunId: string|null — null to clear stale run lock

  • executionLockedAt: string|null — ISO lock timestamp; null to clear

Returns: Returns the updated issue object with all fields.

Examples:

  • Use when: transitioning an issue to in_review and posting a @QA comment in one call

  • Don't use when: you need to claim the issue — use paperclip_checkout_issue first

Error Handling:

  • 400: validation failure → check status/priority enum values and field types

  • 401: authentication failed → check PAPERCLIP_API_KEY

  • 404: issue not found → verify ID with paperclip_list_issues

  • 422: invalid state transition → check current status with paperclip_get_issue

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
issueIdYesIssue ID or identifier (e.g. PAP-21)
statusNoNew status
commentNoComment to add alongside the update
priorityNoNew priority level
titleNoNew title
descriptionNoNew description (markdown)
assigneeAgentIdNoAssignee agent UUID; null to unassign
assigneeUserIdNoAssignee user UUID; null to unassign
goalIdNoGoal UUID; null to unlink
projectIdNoProject UUID; null to unlink
parentIdNoParent issue UUID; null to unlink
billingCodeNoBilling code for cost tracking; null to clear
labelIdsNoLabel UUIDs to set (replaces existing set); pass [] to clear all labels
executionRunIdNoExecution run ID holding the checkout lock; pass null to clear a stale lock
executionLockedAtNoISO timestamp of when the execution lock was acquired; pass null to clear
Behavior4/5

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

Annotations already mark destructiveHint and idempotentHint. Description adds that a comment can be attached and returns the updated issue. It does not mention dependencies like checkout lock, but error handling covers invalid state transitions. No contradictions.

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?

Well-structured with purpose, args, returns, examples, and error handling sections. Front-loaded with key info. Slightly long due to 15 parameters, but each section earns its place.

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?

Given 15 parameters, no output schema, and annotations present, the description covers all aspects: purpose, all params, return value, usage examples, and error handling. Fully adequate for an update tool.

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 the description repeats parameter details from the schema. While the description lists params clearly, it adds no new semantic meaning beyond what the schema already provides. Baseline 3 is appropriate.

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?

Description clearly states 'Update one or more fields on an issue; optionally attach a comment in the same call.' This provides a specific verb and resource, and distinguishes it from sibling tools like paperclip_add_comment by allowing inline comment attachment.

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?

Includes explicit 'Use when' and 'Don't use when' examples, referencing paperclip_checkout_issue for claiming issues. Also provides error handling guidance suggesting alternative tools like paperclip_list_issues and paperclip_get_issue.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bruhsb/paperclip-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server