Add set_label, comment_on_issue, and create_repo MCP tools #6
Labels
No labels
domain:backend
domain:devops
domain:frontend
status:approved
status:in-progress
status:needs-fix
status:qa
test:label-a
test:label-b
test:set-label
type:bug
type:devops
type:feature
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ldraney/forgejo-mcp#6
Loading…
Add table
Add a link
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?
Lineage
plan-pal-e-agency→ Phase 3 (Forgejo MCP completeness)Repo
forgejo_admin/forgejo-mcpUser Story
As an agent following the label signaling protocol,
I want to set labels on Forgejo issues, comment on issues, and create repos via MCP tools,
So that the workflow state machine (agent-workflow) can operate without manual intervention.
Context
The agent-workflow SOP defines a label signaling protocol where Dev agents set
status:in-progress,status:qa, and QA agents setstatus:approvedorstatus:needs-fixon Forgejo issues. Currently forgejo-mcp has 17 tools but none for label management, issue commenting, or repo creation. The underlying forgejo-sdk already has all the methods — this issue is purely about adding MCP tool wrappers.This is the #1 blocker for autonomous agent workflow.
File Targets
Files to modify:
src/forgejo_mcp/tools/workflows.py— Add 3 new tool functions following existing pattern (@mcp.tool()decorator,Annotatedparams, JSON return,_error_response())Files to NOT touch:
src/forgejo_mcp/server.py— No changes needed, tool registration is automatic via decoratorssrc/forgejo_mcp/__init__.py— No changes neededAcceptance Criteria
set_label(owner, repo, issue_number, labels)tool exists — accepts label names (not IDs), looks up IDs viaissue_list_labels, callsissue_replace_labelsorissue_add_label. Returns the current labels on the issue after the operation.comment_on_issue(owner, repo, issue_number, body)tool exists — posts a comment on a Forgejo issue. Returns the comment ID and body.create_repo(owner, repo_name, description, private)tool exists — creates a new repository. Returns repo name, URL, clone URL.Annotated[type, Field(description=...)]params, JSON string return,_error_response()error handlingTest Expectations
set_label: create an issue, set a label by name, verify label is appliedcomment_on_issue: create an issue, post a comment, verify comment existscreate_repo: create a repo, verify it exists, clean up (delete repo)pytest tests/ -vConstraints
workflows.pyexactly — no new files, no new abstractionsset_labelmust accept label names not IDs (agents don't know label IDs). Look up viaissue_list_labels(owner, repo)firstset_label, support both "add" mode (append to existing) and "replace" mode (replace all labels). Default to "add" mode since the common case is addingstatus:in-progressalongside existingtype:feature~/forgejo-sdk/src/forgejo_sdk/for available methods:issue.pyfor labels/comments,repository.pyfor repo creationpyproject.tomlalready hasforgejo-sdkas dependency — no changes neededChecklist
Related
project-pal-e-agency— project this affectsPR #10 Review
BLOCKERS
None.
NITS
set_labellabel limit:issue_list_labelsis called withlimit=100. If a repo exceeds 100 labels, some would silently fail to resolve. Consider paginating or raising the limit. Low-risk for now -- no repo in this platform is close to 100 labels.Test file naming:
test_new_tools.pyis generic. As more tools are added this name becomes meaningless. A name liketest_label_comment_repo.pywould age better.comment_on_issueoverlaps withcomment_on_pr: Both callissue_create_commenton the same Forgejo API endpoint (issues and PRs share IDs). Having both is intentional for agent discoverability, but worth documenting the equivalence so future maintainers do not think they are different.CI does not run
pytest: The.woodpecker.ymlpipeline only runsruff checkandruff format --check. Integration tests require live Forgejo credentials so this is understandable, but worth noting that test correctness relies entirely on pre-merge local runs. This is a pre-existing gap, not introduced by this PR.SOP COMPLIANCE
6-add-set-label-comment-on-issue-create-repo)plan-pal-e-agency)Closes #6in PR bodyCode Quality Notes
@mcp.tool()pattern withAnnotatedparams, JSON return, and_error_response()error handling -- consistent with existing tools.set_labelresolves label names to IDs (good UX), validates mode and label existence with clear error messages, and returns current labels after the operation.create_repocorrectly handles both user and org ownership with a secure default (private=True).finallyblocks. Test assertions are specific and well-commented.forgejo-sdksource -- all calls are correct.VERDICT: APPROVED