forgejo create_issue should accept labels so issue creation is one call, not two #53
Labels
No labels
autonomy
async-consult
autonomy
epic
autonomy
headless
autonomy
live-collab
coherence-core
priority
P0
priority
P1
priority
P2
priority
P3
priority
P4
qa-fixture
role/ai
role/creator
role/design
role/director
role/engineer
role/exec
role/human
role/ops
role/qa
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
coilyco-flight-deck/mcp-beaver#53
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Request
create_issueon the forgejo MCP exposes onlyowner,repo,title,body. Forgejo's own API acceptslabels(an array of label ids) on issue creation. Please project it through.Why
Filing a batch of issues currently costs 2N calls: create, then
add_issue-labelper issue. During a 23-issue QA batch on coilyco-gaming/eco-app#240 that is 23 extra round trips to do something the upstream API does atomically, and it leaves a window where issues exist unlabelled — visible to anyone watching the tracker, and to any automation that filters on labels.Not a capability gap:
add_issue-labelandset_issue-labelare both exposed and work. This is purely about atomicity and call count.Likely shape
labelsis a repeated/array field, so this may depend on the same machinery as #33 (typed repeated query inputs). If array-valued body fields are already supported, this should be an allowlist addition in the forgejo spec rather than new plumbing.Also worth considering
milestoneandassigneeshave the same shape and the same argument. Not requesting them, just flagging that a fix here probably generalises.No runtime change needed - this already works. Verified and pinned with a test in
c61a7f2. Leaving open because the actual edit is deploy's.Your guess that this might depend on the same machinery as #33 was the right question, and the answer is that array-valued body fields are already supported and already tested (
internal/mcpserver/structured_body_test.gocoversarray "labels" items="string"). What blocks it is the flat shorthand, not the plumbing:body "title" "body"mints optional strings and cannot express anything else. The block form can.The deploy-side edit, which is the whole remaining change:
items="integer", not"string"- this matters and it would be easy to get wrong. Forgejo'sCreateIssueOptiontakes label IDs. Your ownadd issue-labelgrant indeploy/services/forgejo-mcp/forgejo.mcp.kdlalready carries the note: "Forgejo's IssueLabelsOption is an integer-id array. Declaring strings caused numeric ids to arrive quoted and mutate nothing." Repeating that here would ship alabelsparameter that silently labels nothing - worse than the two-call sequence, because it looks like it worked.TestCreateIssueAcceptsLabelArrayasserts the ids reach the upstream as JSON numbers, so the runtime side is guarded against that regression.Also updated
examples/forgejo-issues.mcp.kdlto show the shape, since "supported but no example exists" is the same reason #58 sat open on a feature that already worked.milestone(integer) andassignees(string array) have the same shape if you want them in the same pass.